Open Source Software Community - it's about ethics in Code of Conducts

  • 🏰 Deploying update to the Tatarus security page. If you encounter issues, post here.
  • Want to keep track of this thread?
    Accounts can bookmark posts, watch threads for updates, and jump back to where you stopped reading.
    Create account
Shit like that is why I avoided systemd from the get-go on instinct. The whole philosophy of software like systemd is anti-user and meant to put the power in the hand of the developer. Eventually, it'll turn against you. Even if not, best case you end up working for the software and not the other way around.
 
skunt said:


linux is exempt, however i believe systemd already merged it in - like the good little bootlickers they are. thanks leonard!
Click to expand...
Doesn't some other states/countries still require age verification even for open source operating systems, so software will have to implement that anyways (and apply it to everybody since nobody is going to add state/country specific checks, especially state specific since IP isn't that location specific and offline install also needs to work).
 
AmpleApricots said:
Shit like that is why I avoided systemd from the get-go on instinct. The whole philosophy of software like systemd is anti-user and meant to put the power in the hand of the developer. Eventually, it'll turn against you. Even if not, best case you end up working for the software and not the other way around.
Click to expand...
Lol you clearly have never fucked around with rc-files. Even OpenRC is a mess. systemd is fine. scope creep? sure. but the alternative is juggling bash scripts around that only sort of work
 
dec05eba said:
Doesn't some other states/countries still require age verification even for open source operating systems, so software will have to implement that anyways (and apply it to everybody since nobody is going to add state/country specific checks, especially state specific since IP isn't that location specific and offline install also needs to work).
Click to expand...
Setting aside whatever the fuck the banana republics of the world are doing (because they don't matter), other US states have been pushing similar bills. Virtually all of them have a simple achilles heel: They apply solely to software being distributed from third parties. IOW, if you're willing to fork everything you intend to offer through a package manager and claim you're offering it yourself, then those laws do not apply to you. One exception to this is Texas. Texas drafted a law (SB2420, the App Store Accountability Act) so hopelessly vague that it applies to everybody. They're currently eating a lawsuit to fight that. I fully expect that law will be burned to the fucking ground with no survivors, and if they try again they'll end up pushing something either like Utah's approach or something closer to California's.

TL;DR This will paralyze open source for about five minutes until someone just says "fuck it" and starts using AI to rewrite/maintain everything... and don't give me any shit about how AI code is terrible. At this point it can't possibly be any worse than either jeetcode or trannycode.
 
AmpleApricots said:
bashisms in my init scripts? Only clean POSIX sh. That way they remain portable.
Click to expand...
"Portable init scripts". This actually meant something back when people ran a variety of different operating systems, different shells, and different init systems. Now 99% of servers run some Linux distribution, with systemd and bash. There's nothing quite as portable as using Linux with systemd and bash.
 
The biggest lie told by the systemd people is that your average linux desktop needs that mess. There doesn't need to be anything complicated about init, neither the process (PID 1) nor service supervision, which most of the init discussion is really about. These things are actually pretty trivial if you have some idea what makes a Linux system come together. I've used sysvinit and then busybox' sysvinit implementation for a long time, and then slowly migrated to runit, because its a bit more "modern" and flexible with some stuff. I wrote all init scripts myself, including the ones bringing up and bringing down the system, and they were based on even older scripts I wrote somewhen in the 00s. I did that "runit upgrade" once, oh, I wanna say 10 years ago and basically never touched them since. How often in that time did a systemd user need to relearn and redo things because systemd moved it's goalposts? I even just copy my init scripts between my computers because they're that simple, using them with whatever linux software collection I ever tried out. Beyond that, my kernel uses efistub with a small init script that mounts the encrypted harddrive and then gives control to runit's init. There are two variants of that setup I made for myself, one allows the mounting with authentication from a remote system. Again, I did this once and then really never needed to touch it again. I can only wager a guess what a a bizzare (and most likely brittle) stack of NuLinux software you need for the same results if you buy into this new paradigm. I don't know. I don't really want to know.

The big lie that started systemd off was "a good way to ensure that process dependencies are properly resolved, so we can start processes in parallel", which is something somehow all linux users needed, all of a sudden. In my personal setups, I barely care about this as I only use daemons that are well behaved. If you have a daemon that freaks out because the system is not in some expected accurate state when it starts up, then that is a poorly written piece of software that makes too many assumptions for it's scope. If I, for some reason, wanted to integrate such a daemon/service/whatever in my sytem anyways, it'd be a question of a short sh-script.

My "non-prallelized" "obsolete" and "slow" approach is also much faster than systemd. I don't have a single system where I actually get the chance to read the messages from my init scripts before the X server has started, if it is a graphical system. I haven't measured but I don't think the time from decrypting the drive to desktop exceeds 5 seconds on my normal PCs. Probably closer to three. Only thing that is slower is resuming from ssuspend-to-disk, as the RAM contents need to be shoveled back.

So the conclusion is: init is not hard. Service supervision is not hard. If it somehow is, then it's because the used software is shit. I maintain this opinion and it has always been true so far. This is *especially* true for a desktop system which is a lot less complicated to begin with.

I maintain my custom approach not because I'm some crazy hacker who likes to tinker with his system all the time, but because I'm lazy. I just want shit to work. I also still want it to work - the same way - in a month, or a year, or five years. I don't like suprises. If something changes, then it needs to be because I wanted that change, not because somebody forced it on me. This was the only way to get there.

If this is past your skill level to setup and maintain, you simply don't really understand *nix systems. That might sound harsh but I'm kinda tired of talking around it.
 
Kokonut Kangs Klan said:
What do you think he's been using while avoiding systemd? Obviously he has fucked around with init scripts, there's no other (mainstream) option. Reading is hard for niggers.
Click to expand...
I mean he clearly hasn't truly done stuff like complex socket based activations in parallel otherwise he'd have quickly found out rc/init scripts only somewhat work for them and you need something that's systemd shaped if not systemd to fix that

lol @ "clean" sh scripts half these servers had sh symlinked to bash and bashisms creep in. or for openrc, you use its wack openrc-run interpreter

it's fine anyway, LLMs can write good enough systemd unit files and people who janitor older systems are nearly obsolete
 
Markass the Worst said:
Yes. Because he doesn't need to. As he literally just explained.
Click to expand...
Good for him then? He should stick to a distro that doesn't need it and quit bitching about a tool that satisfies a use case that he never runs into?

Init is not hard if you never actually have a use case where it requires complex service coordination, which is not always something you have a choice to use like a handcrafted desktop. Good for you that you system doesn't need it.

The average desktop doesn't use the full capability of systemd either, it just inherited from Red Hat's usage for more involved requirements. You're fully free to remove it and also remove the bloated DE's that need its user management services.

And lmfao at 5-8+ second boot times jesus that is painfully slow (and would be illegal in at least one case I had to deal with).
 
bort420 said:
complex socket based activations in parallel
Click to expand...
Shit nobody needs, your server can take an extra 10 seconds to boot. Or just let services fail until their dependencies are ready, either way it doesn't actually matter. You either need the service or you don't, socket activation is fake and gay.

AmpleApricots said:
I wrote all init scripts myself, including the ones bringing up and bringing down the system, and they were based on even older scripts I wrote somewhen in the 00s.
Click to expand...
I rewrote all the init scripts for my first laptop, it was for college so I only cared about fast startup. There was no real need to manage long running services, so I could manually background and parallelize almost everything while reaching getty asap. That machine was a real piece of shit, sub-1Ghz and slow storage, every bit helped, I didn't even have an initrd. Systemd didn't exist yet anyways, upstart was still the niggercattle preference of the time.

Today I can afford decent hardware, so whatever systemd does by default is good enough for me. Still gonna laugh at retards who think init scripts are some huge burden though.
 
Lard Shart said:
"Portable init scripts". This actually meant something back when people ran a variety of different operating systems, different shells, and different init systems. Now 99% of servers run some Linux distribution, with systemd and bash. There's nothing quite as portable as using Linux with systemd and bash.
Click to expand...
Back in the 60s, an init script could be 20,000 punchcards, and that was a bitch to lug around, making portable init scripts a dream of a better future…
 
You must log in or register to reply here.
Back
Top Bottom