Nah, this is not the scary part. The scary part is going into the bad quadrant of security fixes.
We can look whether the mistakes get auto-replicated, and whether fixes are widely deployable.
In custom application code, the mistake lives where it lives, and needs to be fixed once. In library code, the mistake gets copied, but so do the fixes. Sandboxing sometimes allows to be confident in writing a fix once and deploying it to cover many mistakes.
But if an LLM ever gets a bad security habit in generated code, the mistake gets copied, but then all the copies need to be fixed one-by-one. It's already bad with libraries, here it will be worse…
The whole cloud industry exists so you can easily just throw more money into something that just taking time, skill and knowledge to properly solve whatever problem.
I’ve never heard anyone make “cloud computing is more economical than the alternatives” sound so cynical. Nicely done!
In fact Linux shipped its own libc in the early days, but then glibc got through the long way to 2.0 and got sufficiently ahead for Linux libc to get abandoned. The latest versions of Linux libc were apparently forks of an old glibc, updated to keep up with the early-days kerenel development. This was in 1997, so there are some archived versions of writeups like http://web.archive.org/web/20040411191201/http://people.redhat.com/~sopwith/old/glibc-vs-libc5.html but I am not sure how to find any authoritative statements about motivation
Unfortunately that doesn't solve my problem. Partly that's because the vibecoding tag gets applied very broadly (which has been discussed a lot already and I don't intend to relitigate it here).
F# is another one that is worth looking into (but I personally find the rules overly complicated). See 15: Lexical Filtering of the spec for more information on the rules.
That was their point. Maybe this kind of scare and cooldown is needed for certain permissions. It should then happen at that level, even for verified devs, not at the "install app with no permissions" level
That rings true, and it hints that there is a lot of value in lowering the skills required to self-host securely; another of my hobby horses is that our modern systems are insecure by default (due to Unix lineage where every process assumes the identity of the user and can do almost anything, unless it was specifically constrained in some way, e.g., pledge).
I mean, that's the real problem, right? Play store is full of scam apps, F-Droid isn't, but Play Store is considered secure. Play Integrity API considers a vendor Android that hasn't been patched for 3 years secure, but not a fully up-to-date GrapheneOS. It's all theatre.
In the TCP implementation I wrote, I split up the TCP segments so they were already under the MTU limit – no need for fragmentation at the IP level. Incidentally, this also made the implementation more simple because you split input once at the TCP layer and then pass down unchanged chunks to the IP and ethernet layers.
The upside of relying on fragmentation at the IP level is that you can transmit TCP segments larger than the MTU, thus saving some ACKs (by default, one ACK is sent per segment). The downside is that you need to retransmit the entire segment when a single IP fragment from it is lost because you don’t know which one it is.
I didn’t test which option performed better, and I’m curious how this is handled elsewhere. Splitting segments at the TCP level seems more simple at least. The article makes me think avoiding IP fragmentation is right.
Note: Is was working with an MTU of 1500. The IP standard just requires that the MTU is at round 500 bytes, at minimum. This means that one could still run into IP fragmentation if some link in the connection has an MTU below 1500., but I don’t think encountered this problem. In the article, the smallest MTU they test is 1280 which suggests to me that, in modern networks, 1500 is awfully close to the minimum MYU ever observed.
I am irked by these articles, as the question of “is this token needed” is presented as if the only thing that matters is what the parser needs.
What is needed for unambiguous parsing is not the same as what is readable, for example let’s consider for loops:
For ( expr ; expr ; expr ) statement
With some restrictions on unary plus and minus this can parse unambiguously as
For expr expr expr statement
You could similar probably get for(name:expr) to work without any delimiters.
That’s because asking whether something is parsable is not the correct question when designing a language (that’s just a hard requirement). The question is whether it is readable.
The purpose of many of the “unnecessary” tokens and delimiters in languages has nothing to do with being able to parse the language, but to make it readable.
That’s why I also dislike that posts (or even languages) that focus on reducing the amount you have to write at the syntactic level: excessive verbosity is bad, but code is read by humans much more than it is written.
If you are trying to reduce typing by focusing on removing “unnecessary” delimiters, I feel you are optimizing for the wrong thing.
There are a bunch of examples of the different rules (of varying complexity) that languages have around whether an expression or statement is terminated on a new line. The problem being that sometimes you dont want a new line to terminate. But the moment you make that change the language is more complex: you’ve made termination of a statement or expression implicit rather than explicit.
That’s probably ok when you’re writing the code, but now someone reading the code does not have that information, and the more common task of reading code is now harder.
Link appears to have died?
Some time in the future, we will look back to this era and ask ourselves what went wrong.
Nah, this is not the scary part. The scary part is going into the bad quadrant of security fixes.
We can look whether the mistakes get auto-replicated, and whether fixes are widely deployable.
In custom application code, the mistake lives where it lives, and needs to be fixed once. In library code, the mistake gets copied, but so do the fixes. Sandboxing sometimes allows to be confident in writing a fix once and deploying it to cover many mistakes.
But if an LLM ever gets a bad security habit in generated code, the mistake gets copied, but then all the copies need to be fixed one-by-one. It's already bad with libraries, here it will be worse…
I’ve never heard anyone make “cloud computing is more economical than the alternatives” sound so cynical. Nicely done!
No great surprise
In fact Linux shipped its own libc in the early days, but then glibc got through the long way to 2.0 and got sufficiently ahead for Linux libc to get abandoned. The latest versions of Linux libc were apparently forks of an old glibc, updated to keep up with the early-days kerenel development. This was in 1997, so there are some archived versions of writeups like http://web.archive.org/web/20040411191201/http://people.redhat.com/~sopwith/old/glibc-vs-libc5.html but I am not sure how to find any authoritative statements about motivation
Exactly.
Unfortunately that doesn't solve my problem. Partly that's because the
vibecodingtag gets applied very broadly (which has been discussed a lot already and I don't intend to relitigate it here).F# is another one that is worth looking into (but I personally find the rules overly complicated). See 15: Lexical Filtering of the spec for more information on the rules.
It's unclear from reading the content if this person realizes that what cars did to cities is... Destroy them
That was their point. Maybe this kind of scare and cooldown is needed for certain permissions. It should then happen at that level, even for verified devs, not at the "install app with no permissions" level
And so,
https://git.sr.ht/~rabbits/uxn/commit/4adbd95fe226169a634131731b9e16c5da1efb4e
Maybe!
That rings true, and it hints that there is a lot of value in lowering the skills required to self-host securely; another of my hobby horses is that our modern systems are insecure by default (due to Unix lineage where every process assumes the identity of the user and can do almost anything, unless it was specifically constrained in some way, e.g., pledge).
I mean, that's the real problem, right? Play store is full of scam apps, F-Droid isn't, but Play Store is considered secure. Play Integrity API considers a vendor Android that hasn't been patched for 3 years secure, but not a fully up-to-date GrapheneOS. It's all theatre.
Considering Play store is absolutely full of all kinds of privacy invasive filth and such, I don't think this even does really fix anything.
I think scammers will just go "Your phone takes a day to prepare, we will call you tomorrow!"
In the TCP implementation I wrote, I split up the TCP segments so they were already under the MTU limit – no need for fragmentation at the IP level. Incidentally, this also made the implementation more simple because you split input once at the TCP layer and then pass down unchanged chunks to the IP and ethernet layers.
The upside of relying on fragmentation at the IP level is that you can transmit TCP segments larger than the MTU, thus saving some ACKs (by default, one ACK is sent per segment). The downside is that you need to retransmit the entire segment when a single IP fragment from it is lost because you don’t know which one it is.
I didn’t test which option performed better, and I’m curious how this is handled elsewhere. Splitting segments at the TCP level seems more simple at least. The article makes me think avoiding IP fragmentation is right.
Note: Is was working with an MTU of 1500. The IP standard just requires that the MTU is at round 500 bytes, at minimum. This means that one could still run into IP fragmentation if some link in the connection has an MTU below 1500., but I don’t think encountered this problem. In the article, the smallest MTU they test is 1280 which suggests to me that, in modern networks, 1500 is awfully close to the minimum MYU ever observed.
I am irked by these articles, as the question of “is this token needed” is presented as if the only thing that matters is what the parser needs.
What is needed for unambiguous parsing is not the same as what is readable, for example let’s consider for loops:
With some restrictions on unary plus and minus this can parse unambiguously as
You could similar probably get for(name:expr) to work without any delimiters.
That’s because asking whether something is parsable is not the correct question when designing a language (that’s just a hard requirement). The question is whether it is readable.
The purpose of many of the “unnecessary” tokens and delimiters in languages has nothing to do with being able to parse the language, but to make it readable.
That’s why I also dislike that posts (or even languages) that focus on reducing the amount you have to write at the syntactic level: excessive verbosity is bad, but code is read by humans much more than it is written.
If you are trying to reduce typing by focusing on removing “unnecessary” delimiters, I feel you are optimizing for the wrong thing.
There are a bunch of examples of the different rules (of varying complexity) that languages have around whether an expression or statement is terminated on a new line. The problem being that sometimes you dont want a new line to terminate. But the moment you make that change the language is more complex: you’ve made termination of a statement or expression implicit rather than explicit.
That’s probably ok when you’re writing the code, but now someone reading the code does not have that information, and the more common task of reading code is now harder.
ah right...