Ah that's your point. Yeah I agree that splitting literal a b c is convenient. It is surprising to many (like here) that this happens after variable substitution, and that's not very convenient since you almost never want that. You could define this to happen the other way around, but then you'd obviously have to invent a new syntax for explicit splitting, which would be its own kind of annoying.
Edit: YSH (oil) does that btw. See here.
I disagree. The vast majority of the time when writing shell scripts, I quote variables, because that's almost always what I want. Splitting is basically only useful if you have a list of arguments, and you know for sure there are no spaces in any of the arguments (so no filenames).
(The workarounds in pure POSIX shell are btw super annoying if you want to pass a list arguments that may have spaces in them: You can abuse the special "$@" variable. Or you could probably also construct something with xargs.)
As others have said, if you quote your variables, they won't get split on spaces. The Unix shell unfortunately has ton of gotchas like this, and the reason this is not changed is backwards-compatibility. Lots of shell scripts depend on this behavior, e.g. there might be something like:
flags="-a -l"
ls $flags
If you quote this (ls "$flags"), ls will see it as one argument, instead of splitting it into two arguments. You could patch the shell to not split arguments by default, and invent some other syntax for when you want this splitting behavior, but that would break a ton of existing shell scripts, and confuse users who are already familiar with the way it works right now. It would also make the shell incompatible with other shells, and violate the POSIX standard.
I did it during the gcc 3 transition. I used a very new gcc 3 (maybe even pre-release), which wasn't at all recommended. A couple of (most?) C++ packages didn't compile (some change having to do with namespace scope), which meant I had to fix the source of some packages (generally pretty trivial changes, usually having to prepend namespace:: to identifiers). Overall this problem was pretty rare, like it affected less than 1% of C++ files, but with things like Qt or Phoenix (or whatever Firefox was called back then), with thousands of files, I had to fix dozens of things. I guess running into problems made it more interesting and fun actually.
Did I learn anything? The main thing I learned is about all the different basic packages and what sort of binaries and libraries are included in them and why you need them. Also about some important config files in /etc. And a bit of shell experience, but I dare say I knew most of that stuff already. How much you learn depends a lot on how much you already know.
Overall what I learned was not very deep knowledge, nor was it a very time-efficient way to learn. But it was a chill learning experience, goal-oriented and motivating. And it made me more comfortable and confident in my ability to figure out and fix stuff.
Also it's obviously not practical to keep that up to date, so I switched back to a distro after a couple of months of this.
I'll make an appeal to authority (kernel developer working on memory management):
Disabling swap does not prevent disk I/O from becoming a problem under memory contention, it simply shifts the disk I/O thrashing from anonymous pages to file pages. Not only may this be less efficient, as we have a smaller pool of pages to select from for reclaim, but it may also contribute to getting into this high contention state in the first place.
And then he goes on to say what I said, that it can make the OOM killer quicker to react.
This doesn't work to avoid thrashing. The kernel may invoke the OOM killer slightly quicker if you have no swap, so I guess that can sort of help, but it doesn't properly solve the problem.
On Linux, there's a thing called the page cache (aka disk cache): Every time (part of) a file gets read to or written from, that (part of) the file gets copied to RAM. The file is then kept there unless that RAM is needed for something more important. It is cached in RAM. But since it is also on disk, the kernel can drop the file from RAM anytime it wants.
If you're low on RAM, the kernel therefore evicts all of the disk cache, because it can, because those pages can be reloaded from disk if needed. This means it will drop all the programs you're running, the binary code. So any program you're running is constantly interrupted, because its code is not in RAM.
So it runs a couple of instructions, but oh no! Call to function foo() from glibc, but guess what? That's on disk. Queue wait for the kernel to load that. Oh now it wants function bar() from zlib, shit! Need to load that. Since loading stuff from disk is about as slow as running like a gazillion instructions, all your programs are like 1000x slower now.
This happens even with zero swap.
The correct advice is the one from @RedWeasel@lemmy.world: install/enable systemd-oomd or earlyoom.
Does Russia aim those nukes at Poland? They will if there are nukes there.
Screen is the terminal though?
OK glad you found some workaround!
Man denkt vielleicht: sinnlos. Aber der Sinn ergibt sich, wenn man bedenkt, dass das für's Militär entwickelt wird. Gleis ablaufen, dabei nach Menschen Ausschau halten (am besten autonom, falls der Funkt gestört wird), ist hier ein potentieller Einsatzzweck. In der Ukraine wird gerade regelmäßig entlang von Gleisrouten angegriffen, und auch Roboter (ferngesteuerte Kettenfahrzeuge) wurden schon zur Versorgung von Frontpositionen verwendet.
Ist halt nur Schade, dass die Bahn bei solchen Feldtests bzw. PR-Stunts mitmacht.