1714447227882617.gif - 2063.35 KB (640x536) SauceNAO
My Artix broke after updating and rebooting..
What's wrong with normal Arch? The only reason some people "hate" systemd is because someone on youtube or 4ddit told them that it's bad. If you use any Chrome or Firefox-based browser that's a piece of software that's 9999 times more bloated and 9999 times more vulnerable than systemd.
>>557 There were multiple occasions where my machine wouldn't probably turn off because off systemd plus dinit is faster.
>>557 https://artixlinux.org/news.php#The_xz_package_has_been_backdoored The popular the software is the more hackers attention it gets You are right about Chrome and Firefox but unfortunately we don't have a good replacement for them but with the init system we have replacements
>>556 im assuming you're a gentooman considering you recommended it. What about gentoo is appealing to you ~w~
>>557 systemd destroys the unix ecosystem and introduces an incredibly complex, half undocumented piece of bloatware, reinventing a large part of user space that was already invented before and fails even to do it correctly, in a usable and understandable manner. The problem of systemd isn't in working or not working. It is in being a huge, fat and complicated nail into GNU/Linux, arbitrary crafter by corporations to prevent Linux from overtaking desktop market. 90% of systemd is reinventing wheels. And its codebase is shit. Nobody even inside systemd has the barest idea what systemd is supposed to do and they just keep adding features nobody even needs in the first place. But you could have just asked chatgpt with you cognitive abilities I doubt you can go any further than that.
>>821 but how does having systemd on my machine impact me? does it slow my pc? is it what periodically fucks up my packages causing crashes? will it allow a backdoor for the chinese?
>>821 systemd is actually not bloated at all, blame kernel devs from moving shit like fucking device naming out of a MONOLITHIC KERNEL
>>822 potentially it could do all those things. the problem is that it is too big and complex so 1. it can't really be audited 2. you depend on the internet to fix it if something breaks I have never had to google how to fix something in gentoo (in 10 years of use) one thing that might be confusing is that when people say "systemd" they are usually not talking about the individual program but the systemd ecosystem in general: systemd comes with a number of other programs for different tasks besides init, and they are all interconnected and depend on each other in complex and obscure ways. this means that 1. individual parts can't really be replaced with alternatives 2. any subsequent program that depends on any part, depends on the whole which means that no matter how bad some of those parts might be, the distributions that have switched to systemd will have to keep using them because replacing them becomes more and more unfeasible as the systemd blob grows
>>824 1.3 million can super be audited, the documentation tells you where to start from and keep going for audits of all the 4 sections of systemd, you are a nocoder parroting Xoomers
>>825 >1.3 million 1.3 million what? lines of code? just to be sure, post the source of this data >can super be audited in theory? yes, it can. in practice it is too much work for the average hobbyist, it can't really be audited besides, you have to add dbus, libpam, libcap, jorunald, networkd, logind, systemctl, loginctl, etc. etc. this is, all the other necessary parts of the systemd environment for reference, openrc, another init system, has 19622 lines of code as of commit cadc1d28400 (19/9/2024), clone and cd src; find . -type f | xargs wc -l
>>826 all the things you mentioned are included in the 1.3 million line count >source look it up, robot.
Redhat retard tries to convince people 1.3 millions lines of code is fine for the fucking init. Kill yourself. Oh you can't, because you're either part of the botnet or just an imbecile. https://forums.debian.net/viewtopic.php?t=120652 How can people be so stupid? Their ecosystem is being locked down by corpo, usability gradually reduced to the level of windows, and they argue that it's OK. Fucking don't ping me ever, until you grow some braincells.
>blame kernel devs They didn't get their retards into programming userspace only. It's dismal.
>>829 >init you dont actually know what an "init system" is, do you? It isnt just about parsing a directory and some configuration files to execute programs, you also have to complement the kernel in renaming files like /dev/* and to service system calls like gethostbyname, you need to service privilege escalation, you need dbus for journal logging >that doesnt justify 4 million fucking lines refer to "complementing the kernel", because its really fucking bare despite being 12 million lines as of v3.13 By the way, what have you tried to do, and couldn't, on systemd? Dont quote me until you have an honest answer to that question.
>>831 >By the way, what have you tried to do, and couldn't, on systemd? Could never feel safe from corporations invading every single aspect of my life. You argue in bad faith. Fuck off.
>>832 >i will trust this amateur software that hasnt been reviewed in years over the software made by paid developers LOL, are you using Linux or Hurd? >You argue in bad faith projection
but it is clear that you are arguing in bad faith so this is my last reply
>>829 >1.3 million the systemd ecosystem on most distros includes at the very least 5 million lines
>defects >"muh internet" schizo babble the day the internet goes down your power outlets wont be receiving electricity either. >a program that depends on... you dont grasp what you are talking about, you dont depend on programs, you depend on what they enable and we have standardized ways of doing things which in this case are the init-assisted syscalls and dbus, more specifically to [insert program] it can swap out its abstract dbus lib for an abstract [insert sockets protocol] lib when it needs to run on a different system, because the contents of messages will stay the same, they are standardized. "But actually [lalala] is not standardized/compatible-with-XXX", not a systemd issue.
You have not standardized anything. You develop a huge undocumented abomination with unnecessary features and such large amount of turd that it is virtually impossible to substitute systemd, impossible to to remove a part, impossible to port. Any software that relies on systemd is not portable, literally. elogind is a creaming proof of that. polkit, dbus, those are all abominations. You should have been employed by microsoft do develop their brainfuckware. Eat shit and die, parasite.
>>840
of course, the issue is always with the developers 
>>841 Let us say you make a compiler >configuration file based assembly translations? >lol no i will just translate [language] directly to [assembler:architecture] >optimisers? yeah i do string operations on the instructions. Did you say "bytecode"? Like ASCII? So yes, it is always the developer's fault, systemd is SYSV compliant wow
i have attained SECR3TZ KNOWLEDGE, call me oldfag in 2 weeks.
1689709576856891.png - 378.76 KB (600x484) SauceNAO
What did my thread turn into..
>>557 systemd provides a lot of useful stuff for operating a GNU/Linux system. sure for most people its uncessary, but it def doesn't deserve as much hate as it gets. systemd-nspawn is amazing for running and testing containers, id argue its more polished than FreeBSD jails and Solaris zones, chroot is fundamentally impractical for containerization since it is extremely escapable, plus systemd-nspawn lets you virtualize your host filesystem without committing any changes, which is actually incredible systemd-homed is great for multiuser systems, plus it integrates with existing popular GNU/Linux technology (say, Btrfs), which makes system administration and rollbacks much more simple systemd-boot is extremely simple, it does its job well without pulling in massive dependencies and ugly configuration files *cough* GNU Grub *cough*, plus it works well with UKI's and secure boot (say what you will about secure boot but some people want/need to use it) systemd units are extremely powerful for system administration, automounting and systemd-cryptsetup save so much complexity with full disk encryption or remote storage needs i am saying this a predominantly FreeBSD and NetBSD user, and i think GNU/Linux without systemd is more of a hindrance than a pleasure for a multi-user system that demands stability, reproducibility, error tolerance and automated startup for basic function
>>857 All of the things you listed are entirely useless. systemd-nspawn must be a separate tool with no dependencies, either to init or to dbus or to whatever. systemd-homed must not exist at all and is entirely useless. That it is a daemon is abominable. If you want users to be self-contained, it must be implemented on useradd level, which isn't even that complex, just move MAIL and stuff to ~/ and set environment accordingly. Encryption and authenticity of data is a job for a separate tool, maybe triggered on login. Both must have no dependency on init or dbus or whatever the fuck. systemd-boot must not exist at all. Just imagine boot loader being part of init. 0IQ design decision. There are no reasons to use systemd-boot. GRUB is configured only once, it is notinit, lylly hard and it is portable and stable. systemd is neither and will not ever be. >GNU/Linux without systemd is more of a hindrance than a pleasure for a multi-user system that demands stability, reproducibility, error tolerance and automated startup for basic function Absolutely wrong, because GNU/Linux is not a system for Windows lamers to escape to to feel special. systemd is a huge hindrance and prevents you from tinkering with basic things, cutting down the value of GNU/Linux several times. It does not offer any significant benefit for anything, anywhere. Init systems such as runit and openrc are unironically sufficient and are actually better than systemd by their simplicity. That nobody has tried to write a new init system to provide some of the flexibility of systemd speaks for itself, nobody needs it, no use cases. systemd does absolutely nothing except causing a major lock down of ecosystem. Even it's stupid design with units is an absolute bloat, partly undocumented, and has no use cases. Most of it's functionality must be provided by separate tools which do not depend on init, dbus, whatever the fuck. systemd deserves every ounce of hate. It just works, true. Same way windows just works if you have more than 1 braincell. It's not an argument at all.
Wtf with my keyboard. GRUB is not dependent on init, is stable, isn't hard to configure actually. Systemd is neither.
>>860 the bootloader being part of the init system is best actually. Not having the kernel and bootloader and init merged into one binary causes a lot of nonsense communication.
>>860 i fundamentally disagree with you, you can't justify anything you've said for any practical reasons besides the fact "it feels wrong" or "it's too complicated" or "you don't need it". >GNU/Linux is not a system for Windows lamers to escape to to feel special this sounds a bit like a projection, or atleast, a lack of awareness. most people who move to a GNU/Linux system come for an alternative to Windows, very little people start off on a UNIX station or Macintosh machine already tinkering in the environment. using GNU/Linux doesn't make you special and you ought to have realized that given this statement >Even it's stupid design with units is an absolute bloat, partly undocumented, and has no use cases. i provided some use cases that i personally see myself using systemd for, also the bloat argument is stupid because nobody with a strict resource limit will benefit from a GNU/Linux system running a X or Wayland session with likely a browser, editor and desktop environment, in those cases the bloat argument is used fallaciously, because it is in-fact relatively small compared to, say, the massive kernel and several drivers loaded on boot the reality is most amd64 machines have atleast 512MB of ram, which is more than enough to run systemd, emacs/vi/acme/kakuone/whatever the new thing is, an email client and a media player under X, you aren't saving yourself resources by picking yet another rc clone and sacrificing all the benefits ive previously mentioned also, if you want to run a UNIX-style init on GNU/Linux, nobody can stop you, but that doesn't make systemd bloated by some sort of equivocation... systemd is not *just* an init, it is a suite of software with tight integration, sure its partly an init and service manager, but not holistically in the end it matters what you want from your system, i want systemd, you don't, you aren't wrong to not want it, i am not wrong to want it if i benefit from it and find it useful
>>863 Your post boils down to "systemd is my preference, fuck off". There are just no use cases to reimplementing half the userspace in an unportable manner. It is possible that in future using alternate inits will be impossible because all major software will be made dependent on systemd shitty infrastructure by puppeteers from Red Hat, GNOME, freedesktop and the like. You just freaked out and " a-anon, i-i like systemd, please don't offend it!!1!" That's what I say that you should eat shit and die. Together with the whole redhat party
Also dinit provides all the benefits of systemd's units system.
>>864 >alternative inits okay dude, i get it, you hate Red Hat and Gnome and SELinux and Wayland and whatever other thing GNU/Linux is slowing migrating over to i don't think you have a justified reason as to why systemd is bad besides the fact you have asserted it is bad with no evidence enjoy using dinit, it seems like its worth your time, but with all due respect, you lack a lot of maturity for someone who is concerned so heavily with shit other people wanna use their development resources/time on, i would have expected you to at least give a counter argument, especially when everything you've said are just vague notions of "systemd is too different and i don't use my system the way you do therefore you should kill yourself"
>>866 Stop being retarded, take your systemd party and go writing unportable software with no use cases elsewhere, preferably on windows.
Init freedom by itself is a good enough reason to not use systemd.
>>870 Soon you'll be unable to. Actually, the problem with unportable/unreplaceable software isn't usability, but when the software causes lockdown, it declares complete monopoly. After that, whoever owns the funds that pay the developers, owns the entire ecosystem and is free to bind it any direction. The whole point of software freedom is that when a part becomes poorly maintained, it is replaced by something else. But soon you'll be unable to do it. If nothing changes, in another 15 years linux ecosystem will be completely locked down and most likely made unusable to such an extent, that it won't be an option anymore. Then they'll bring in paid or closed sourced solutions in the game and you won't be able to do anything about it.
>>860 >>871 You (samefag) are the first in the history of humanity to say that "using software is fun" and that makes sense because its so dumb that all of the dead people would laugh at you. No using software is not fucking fun, you dont have because you are using krita, you have fun because you are drawing, you dont have fun with your init system... ever, you maybe get a serotonin hit after tinkering with configs for 2 hours to fix your broken system retard
>>872 You might pwn my system, but you'll never pwn my soul. You'll choke on me, corporate piece of shit.
>>872 Yes, out of 8 billion people on the planet he's the only person in the history of humanity to ever say using software is fun. If that were the case then video games wouldn't exist. Also you can use kirta on a drawing tablet and that could be pretty fun.
abc0e07c55b1687d6097bbcbac06645bb82b7050c3eca81c3909cffe64962085.jpg - 245.01 KB (1959x1189) SauceNAO
>YES i will use systemd >YES i will use a normie distro that just werks >NO i will not schizophrenically cry about software >NO i will not eat the foot cheese
>>1152
Don't worry next you'll be able to install Arch Linux
>>1153 following the wiki is not hard it's just not worth or necessary for most people
"just werks" is a myth. there are two dichotomies in software first one is "I broke it" vs "it broke by itself" and the second is "can I fix it" vs "can the internet fix it for me" these two axes are like the compass meme but for distros
>>1154 lol i just use archinstall, it gets the job done
Upgrading after a while, fingers crossed. Half of the time it leads to a breakage and sometimes I had such things as pam explode into my face
>>1216 >Things such as pam Systemd pam? You should be worried.
>>1218
libpam-elogind
Unfortunately, even coreutils these says depends on libsystem0, I don't see any solution except to kill Poettering and some of redhat higher ups.
>>1219 i don't care for antisystemd autism, i mean that the login manager shouldn't be breaking when you are using pirated software...
oh my god i thought this was the minecraft thread and you the guy running the server, sorry :p
>>1220
>antisystemd autism
Are you fine with all of the userspace belonging to a single company? Are you perhaps in love with Windows as well?
>>1222 the systemd ecosystem is all lgpl, who cares if the company can change the license in the future, distro maintainers can just pull back to a free version or somebody will just write a new init system, every program that matters is using a framework to interact with systemd so porting software it to that new system would be a joke. I would be concerned too if the license was not permissive, but it is.
>>1223 >distro maintainers can just pull back to a free version or somebody will just write a new init system that's exactly what systemd makes impossible by overtaking userspace, so you're in a very deep fallacy
>>1224 it is not "overtaking userspace", see the framework point, something that works with windows and systemd will work with systemfuture too (after support is added to the framework, and it is recompiled). Unironically, name a program that relies on systemd native libraries, has no up-to-par alternative that doesn't and can't be re-implemented or ported in a week