The Linux Thread - The Autist's OS of Choice

They just truly can't help themselves can they? Every single time I see multiple redditors talk about something they always speak in such an eerily similar way. It's like some kind of cult. It doesn't help that signing up to that site seems to somehow remove your capacity to speak in a non-smarmy or condescending way. I used to think my hatred for them was due to my spending way too much time on 4chan in my teen years and that it was all just a meme rivalry or something, but now I see that they truly are just reprehensible and vile hive-mind robots.
Nigger Cattle, if you will.
It was a bit better back in the day. And by back in the day I mean like a decade ago probably.

I have a very strong suspicion /r/linux has a lot of posters from IBM's PR team.
 
The fact that so many beginner traps and problems exist in bash shows you how terribly designed it is (which beginners and experienced users both complain about). Fuckery like everything kinda being a string, globbing, quoting, trying to do arithmetic, what happens if a variable isn't assigned, `[` being a command, IFS shell variable, etc.
It goes on and on it's like a fucking minefield. Take what you will from https://mywiki.wooledge.org/BashPitfalls
Also, for all the trouble, it's still slow for any non-trivial computation. At least C lets you communicate to the kernel efficiently should you need that (lots of times you don't). God forbid you actually try to process data beyond simple things like regex.

I have a very strong suspicion /r/linux has a lot of posters from IBM's PR team.
I think I got banned years ago for saying firefox design team keeps making awful changes no one wants. linux users don't like change, especially stuff no one asked for
 
Last edited:
It was a bit better back in the day. And by back in the day I mean like a decade ago probably.

I have a very strong suspicion /r/linux has a lot of posters from IBM's PR team.
There are now several generations of people who grew up on worshiping tech corporations like they can do no wrong and everything they make is manna from heaven. Who needs a PR team when even the people who are supposed to be contrarian neckbeards will fly your flag 24/7 for free?

The fact that so many beginner traps and problems exist in bash shows you how terribly designed it is (which beginners and experienced users both complain about). Fuckery like everything kinda being a string, globbing, quoting, trying to do arithmetic, what happens if a variable isn't assigned, `[` being a command, IFS shell variable, etc.
It goes on and on it's like a fucking minefield. Take what you will from https://mywiki.wooledge.org/BashPitfalls
Also, for all the trouble, it's still slow for any non-trivial computation. At least C lets you communicate to the kernel efficiently should you need that (lots of times you don't). God forbid you actually try to process data beyond simple things like regex.


I think I got banned years ago for saying firefox design team keeps making awful changes no one wants. linux users don't like change, especially stuff no one asked for
The amount of traps is a direct indication of how well a language is adopted nowadays, see Python vs. Perl. However, I still hate writing anything that interacts with the OS in a shell-like manner in Python, so I'd rather just learn to live with the pain of bash & Co. That said, Oil shell is something to look forward to.
 
However, I still hate writing anything that interacts with the OS in a shell-like manner in Python, so I'd rather just learn to live with the pain of bash & Co.
I only use bash when I'm prepared to waste half a day figuring out new syntax as a learning experience. python subprocess is how you do it nowadays in python and is actually platform independent if you care about such things.




That said, Oil shell is something to look forward to.
I have heard of zsh and fish and maybe I'll look into them because they seem to have some nice features and I don't care about shell portability
 
"I switched to Artix for OpenRC since its more secure than Systemd."
Good. I personally don't want a fucking init system setting my DNS fallbacks to google. Makes me wonder what other garbage it's doing in it's millions of lines. Don't know, and don't care. I'm better off with something a lot more simplistic.
 
  • Agree
Reactions: Basil Julep
The fact that so many beginner traps and problems exist in bash shows you how terribly designed it is (which beginners and experienced users both complain about).
It's a shell. The primary purpose is for humans to interact with the computer. Then you realize you want to run the same things multiple times and you wrap your commands into a text file. If you want to program things and have security then you switch to a real language(or Python).

My general rule was once it hit a full screen, in the 80x25 days, it was time to move the shell script into something else.
 
It's a shell. The primary purpose is for humans to interact with the computer. Then you realize you want to run the same things multiple times and you wrap your commands into a text file. If you want to program things and have security then you switch to a real language(or Python).

My general rule was once it hit a full screen, in the 80x25 days, it was time to move the shell script into something else.
yes, it works for running a simple for loop for like imagemagick.
what's horrifying is seeing like 10000 line shell scripts generated by autoconf. then the slow speed really matters. I know people complain about systemd but you can't convince me sysv init bash scripts is the right answer.
 
what's horrifying is seeing like 10000 line shell scripts generated by autoconf. then the slow speed really matters.
Most of the time spent with configuring with autoconf shell scripts is due to compiler invocations with the intent of flag checking, header and library discovery plus many other code compilation prechecks. Although it might use some kind of caching, it has a build system generation way slower than CMake or Meson and its intricacy leads may not be that helpful though :|
 
  • Like
Reactions: awoo
Most of the time spent with configuring with autoconf shell scripts is due to compiler invocations with the intent of flag checking, header and library discovery plus many other code compilation prechecks. Although it might use some kind of caching, it has a build system generation way slower than CMake or Meson and its intricacy leads may not be that helpful though :|
I think I read somewhere about CMake that autoconf does really obscure checks that don't matter for 99.9% of people like checking if the processor is an ancient AIX machine or has proper division support or something. Also you apparently use m4 which has really obscure syntax. I've only had to use simple Makefiles for my personal projects since none of them are GNU giant projects.

 
Outdated books on shell scripting... They do realize that Bash is older than most of them.

I assume they whine about the K&R C manual as well.
I first got into BASH by taking out of the library "UNIX For Dummies" (pls no bully, it was actually really good) in 2004, and the edition was from the nineties I think. There's plenty in there I still use today, probably at least a quarter of my daily knowledge. Saying a BASH book is outdated is stupid.
I only use bash when I'm prepared to waste half a day figuring out new syntax as a learning experience.
It's the exact opposite for me. BASH is what I go to first, what I know best. Last time I loved a langauge this much was Spectrum BASIC. It can always do what I need. Just instead of importing libs, you run programs and grep/awk the results to feed into other stuff. BASH has the most libraries of anything, basically anything installed in /bin. It's the tits.
 
While the Shellcheck subject is still relatively fresh, I figure it's worth mentioning that they've got a great wiki for the individual error codes it provides. The pages are typically concise while also providing examples of bad and good usage, along with the rationale. I love shellcheck.

Some examples:
read without -r will mangle backslashes.
Use "${var:?}" to ensure this never expands to /* .
I second shellcheck being a very useful tool and lots of people's code in any language (C, python, bash, you name it) would be improved just by running through a code style checker
 
yes, it works for running a simple for loop for like imagemagick.
what's horrifying is seeing like 10000 line shell scripts generated by autoconf. then the slow speed really matters. I know people complain about systemd but you can't convince me sysv init bash scripts is the right answer.
Better answer than systemd, because all they do is start and stop services.
 
Better answer than systemd, because all they do is start and stop services.
isn't that the point of init? to do that in parallel which would save a lot of time over executing bash scripts?
 
isn't that the point of init? to do that in parallel which would save a lot of time over executing bash scripts?
Parallel starting of services is intensely overhyped. I mean, it's nice and all, possibly quite a feat of engineering. But if you think about for a moment, how often do you reboot the system and how many seconds will you save due to parallel service starting?

Does it justify complexity in the software and/or init-scripts/systemd units themselves? [because you need to carefully specify dependencies or mutual exclusions]
 
Parallel starting of services is intensely overhyped. I mean, it's nice and all, possibly quite a feat of engineering. But if you think about for a moment, how often do you reboot the system and how many seconds will you save due to parallel service starting?

Does it justify complexity in the software and/or init-scripts/systemd units themselves? [because you need to carefully specify dependencies or mutual exclusions]
I mean, back in the good old days of spinning hard drives openrc on Ubuntu used to save a good 10-20 seconds over sysvinit. But I've never seen a good argument for why the deliberate sabotage that systemd engages in is necessary, apart from Lennart Poettring's lust for boy-ass.

There's no good reason a replacement init system couldn't utilize old sysvinit scripts or the rc.d scripts from BSD init, it just would require some level of rational thinking. Like, instead of running all the scripts symlinked in the runlevel directories in alphabetical order in series, use some helper to run them in parallel.

Maybe you run all symlinks that start S01.... S02....... S36.... S99 at the same time and don't finish until they all do, and vice versa when halting/rebooting. Maybe you add a /etc/init.d.extra directory that hosts config files with extra metadata about services that do have dependencies, and the new parallel init system can take advantage of that. Perhaps by starting absolutely everything that doesn't have explicit dependencies defined in init.d.extra at once, or to be more cautious, either leaving starting services which don't have such files to the end, or if you have say 10 symlinks in your runlevel 3 directory for services and 'randomd' which is linked as 'S40randomd' doesn't have a init.d.extra file, you could start up all services up to the 'S40' level up relying on the dependency logic in the init.d.extra files, and then wait until the randomd init script runs through, before you finish executing the rest of them in parallel on the basis of the extra logic.

None of this hopelessly compromises and complicates your system, and it all works while giving you a 100% always sound fallback, which is not running things in parallel.

EDIT: Turns out this dependency information was already written into many distribution's init scripts comments as part of Linux Standard Base standards, in a way that could have been parsed by a parallel init system directly (not ideal) or updated into more succint configuration files by running a simple tool (to be executed at the end of package installations or manually if neccessary). That's right, folks, part of the sabotage of Debian and other distributions with systemd was a move away from Linux Standards compliance, because Poettring is an enemy of all things good, from Linux Standards to the anal virginity of young boys.
 
Last edited:
But I've never seen a good argument for why the deliberate sabotage that systemd engages in is necessary, apart from Lennart Poettring's lust for boy-ass.
I was going to ask the same thing - why is it that Poettering's corporate backers love the idea of "Systemd Plus Gnu" so much? Is something about it more convenient if you want to run a datacenter rather than a desktop?
 
I was going to ask the same thing - why is it that Poettering's corporate backers love the idea of "Systemd Plus Gnu" so much? Is something about it more convenient if you want to run a datacenter rather than a desktop?
It's because he'll put in sploits for the alphabet boys that don't get patched, I'm convinced.
 
It's because he'll put in sploits for the alphabet boys that don't get patched, I'm convinced.
I mean, you wouldn't be wrong

Google is seemed to be linked to systemd in regards to networking and everyone knows what a piece of shit Google is. Wouldn't be surprised if they are creating, or have created, some sort of backdoor
 
  • Informative
Reactions: Stabmaster Arson
You guys may be the only people who would care. I upgraded the RAM in my desktop today from 8GB to 24GB, finally (bought 16GB more and had enough slots to add it without removing the old RAM).
I can now finally have my work virtual machine portal open, a browser for here, and whatever video game I'm playing all at the same time.
 
Last edited:
Back