There’s also no uppercase d in systemd
, the word is entirely lowercase (but I’ll still write it with an uppercase s at the start of sentences).
There’s also no uppercase d in systemd
, the word is entirely lowercase (but I’ll still write it with an uppercase s at the start of sentences).
Yeah, the manpages for systemd are large but also informative. Most of us only use a small subset of the features—much like we never explored everything possible with separate init programs.
Having used Linux on the desktop for some two decades and worked as a Linux sysadmin for a good while I don’t miss the init scripts. My impression is more that a certain cohort wants to pretend that service management is easy by ignoring large amounts of it. It’s easy to write a bad init script that breaks when you really need it, or be out of your depth with more complex cases.
Not to mention the whole conformity by convention thing. Systemd unit files are descriptive and predictable by their nature. So-called init scripts didn’t really have to be scripts, they just usually were, and their arguments and output and behaviour was also unenforced—there’s nothing really stopping you from writing a compiled program that self-daemonizes and place the binary with the init scripts rather than in /bin. Ultimately people who make programs also have to be good at writing init programs with that setup.
So we’d have people doing dumb shit themselves and getting angry at others doing dumb shit. PHP was also pretty popular and full of dumb shit. Lots of “worse is better” to go around.
Ultimately it’s more of the stuff covered in Bryan Cantrill’s Platform as a reflection of values. Some of us value predictability and correctness, others feel it’s a straitjacket. There’s no way of pleasing everyone with the same platform.
And currently the people who want to distribute their own riced-out init programs in bash, perl, php, node.js and so on are SOL. (They can still use them on their own machines.)
By that logic we would still be using horses since technically we don’t -need- cars.
Most of us would be using our feet and transit (and possibly bikes); both our households and our economies would be better off financially and bodily if car use was restricted to goods hauling and some few other uses (not to mention the environment). Mass motorism has turned out to be mostly a way to enrich the auto industry, not our societies, with North America as a warning to the rest of us. (See !fuckcars@lemmy.world for more.)
There are plenty of times where humanity has chased the latest fad without considering the costs & benefits properly. The amount of energy and hardware being blown away on LLMs are another example; same goes for creepto and NFTs.
That said, having a look around for various applications, including terminals, is generally good. If someone finds something that covers their needs but with lower costs, that’s good. And if they find something with a shiny new bell or whistle at exorbitant cost, eh, maybe think twice before choosing it.
Ah, so we didn’t have to wait until 2038.
There are people who don’t really enjoy food either. They might be fantasizing about replacing all eating with just taking a pill, or they might be soylent enthusiasts.
There are also people who don’t enjoy any music; misophonics.
And very old. Part of the sales pitch for the COmmon Business-Protected Language was that anyone could learn to code in almost plain English.
Also, the stuff they wind up making is the kind of stuff that people with no coding experience make. Cooking up an ugly website with terrible performance and security isn’t much harder than making an ugly presentation with lots of WordArt. But it never was, either.
Between COBOL and LLM-enhanced “low code” we had other stuff, like that infamous product from MS that produced terrible HTML. At this point I can’t even recall what it was called. The SharePoint editor maybe?
Yeah, Rust tries to find as many problems as it can during compilation. It’s great for those of us who want the bugs to be found ahead of release, not great for those who just want something out the door and worry about bugs only after a user reports them.
Different platforms have different values, and that also affects what people consider fun. At the other end of the scale you find the triple-equals languages like js and php, which a lot of people think are fun and normal, but some of us think are so wobbly or sloppy that they’re actually much harder languages than other, stricter languages.
If you value correctness and efficiency, Rust is pretty fun.
I think I’ll stick to alacritty, but options are always fun
Yeah, I switched to deezer then, haven’t had any trouble with it.
Batteries seem to work fine in rural Norway. If you live somewhere warmer and/or with a bigger population or population density than Norway, you should be fine.
Idunno, that might be approaching “one day of patchy electricity can change how you view computers vs mechanical typewriters”. Here people would likely use their mobile internet, especially if the company is paying their phone bill.
I’ve been using Fantasque sans mono for a bunch of years now.
Yeah, that’s the correctness focus. Some people dislike it as a straitjacket, some even take it as a personal insult because they see it as a skill issue. They, the good devs, shouldn’t be held back like that (spoiler: they aren’t as good as they think they are).
Personally I like that aspect of Rust, but I also write Python with a typechecker and a loong list of enabled lints in ruff
. I can get the happy path done without it, but having just the happy path often isn’t good enough.
Enforced correctness helps a lot with confidence for those of us who know we sometimes make bad assumptions or forget some nuance or detail. But it will be absolutely infuriating for people who can’t stand being told they made an error, even one of omission.
Still remains to be seen if a potential rust ABI can avoid becoming a chain to the wall the way the C++ ABI seems to have become. When a lot of C++ers apparently agree with “I’m tired of paying for an ABI stability I’m not using” it’s not so clear it would really be a boon to Rust.
That said no_std
appears to be what people go to for the lean Rust.
And a lot of us are happy not having to juggle shared dependencies, but instead having somewhat fat but self-contained binaries. It’s part of the draw of Go too; fat binaries come up as a way to avoid managing e.g. Python dependencies across OS-es. With Rust and Go you can build just one binary per architecture/libc and be done with it.
The serious answer here likely has several components:
$NEWTHING
, they’re likely to get … grumpy. Both they and the government may be correct here, even if they’re at odds—they have different scopes and concerns.Socks were invented to be used in sandals, it’s the one true way!
(Typed wearing big woolen socks in birkenstocks)
I think I wouldn’t find it particularly useful, as I’m used to the quasi-programming I can do in a terminal. The shell commands take some time & effort to learn, but once you’re over that hump, being able to extract and compose information is really good. The primary shell tools I’d miss in a gui are |
, jq
, awk
, sed
and grep
/rg
, as well as for
, if
, while
, variables, and having everything in one lightweight window.
Ultimately clients pay good money for me to look after their systems, systemd or not, so I probably shouldn’t grumble, but I miss the days when Linux was a clean and elegant system, without this multi-tentacled thing sitting on top of it.
I also have a sysadmin/devops/sre type career, and my impression is rather the opposite: With systemd Linux became a lot cleaner and predictable, compared to the mess of shell scripts we had before. There’s never been anything clean or well-architected about shell scripts, they’ve always been a messy collection of not-quite-the-same languages that have all safeguards turned off by default, and it’s up to the programmer to turn them on and hope they actually work. Good for one-shots and exploration in the terminal, though.
I also don’t miss logrotate or finding out that some app places its logs somewhere mystical. Being able to read app logs just by knowing the service name is wonderful, as are the timestamp and boot arguments.
systemd didn’t appear as just one guy’s brain child, nor could it rise to the dominance it has if the way it works was as controversial or bad as it is in your opinion.
I haven’t been on-call for the past few years, but my impression is that there have been fewer and fewer on-call events over my career. That’s also largely on app developers and a shift to Kubernetes, but it’s a generally pleasant change. There’s nothing I hate more than being woken up.
I also find that calling systemd “SystemD” is a tell that someone is unfamiliar with or has a conspiratorial relationship to it. It’s named “systemd”, all lowercase (but I’m likely to capitalize it on sentence starts like a normal word). Using an ungrammatical uppercase D at the end of the word, that isn’t even something the creators claim is correct, is … a choice.
(And it’s a choice that reminds me of e.g. how rabid anti-cyclists in Norwegian can’t even spell “cyclist” correctly, but instead consistently use “bicycleist”.)
Here in Norway the thirteenth yule-day is just the day we throw out the yule-tree and take down the decorations. We should start having cake after we’re done cleaning!