Debian May Need To Re-Evaluate Its Interest In 'Init System Diversity' (phoronix.com) 135
"Debian Project Leader Sam Hartman has shared his August 2019 notes where he outlines the frustrations and issues that have come up as a result of init system diversity with some developers still aiming to viably support systemd alternatives within Debian," reports Phoronix:
Stemming from elogind being blocked from transitioning to testing and the lack of clarity into that, Hartman was pulled in to try to help mediate the matter and get to the bottom of the situation with a lack of cooperation between the elogind and systemd maintainers for Debian as well as the release team. Elogind is used by some distributions as an implementation of systemd's logind, well, outside of systemd as a standalone daemon. Elogind is one of the pieces to the puzzle for trying to maintain a modern, systemd-free Linux distribution.
Various issues were raised that are trying to be worked through albeit many Debian developers face time limitations and other factors like emotional exhaustion. Hartman noted in his August notes, "I think we may be approaching a point where we need to poll the project -- to have a GR and ask ourselves how committed we are to the different parts of this init diversity discussion. Reaffirming our support for sysvinit and elogind would be one of the options in any such GR. If that option passed, we'd expect all the maintainers involved to work together or to appoint and empower people who could work on this issue. It would be fine for maintainers not to be involved so long as they did not block progress. And of course we would hold the discussions to the highest standards of respect."
Various issues were raised that are trying to be worked through albeit many Debian developers face time limitations and other factors like emotional exhaustion. Hartman noted in his August notes, "I think we may be approaching a point where we need to poll the project -- to have a GR and ask ourselves how committed we are to the different parts of this init diversity discussion. Reaffirming our support for sysvinit and elogind would be one of the options in any such GR. If that option passed, we'd expect all the maintainers involved to work together or to appoint and empower people who could work on this issue. It would be fine for maintainers not to be involved so long as they did not block progress. And of course we would hold the discussions to the highest standards of respect."
some history (Score:5, Informative)
The main problem is fixes being ignored. Emulation of systemd's APIs other than unlamented systemd-shim was and tested in January 2018, revisited in June 2018, redone and resubmitted in Nov 2018 -- all without any positive response. But our work was heeded, oh yes -- the existence of this work was used to rip away systemd-shim. The result was Buster being released with no working non-systemd GUI. And just before freeze, policykit's maintainer requested a completely different approach, which required a substantial rework -- implemented shortly after freeze, and then predictably rejected. Joy.
So it's not a case of no one willing to do the work, it's about fixes being intentionally turned down.
Why systemd and not flat flies. (Score:2, Interesting)
Is it really so awful to make a less monolithic system. Separate flat config files. They let individuals improve separate components separately without trying to drink from the whole spitoon. Lets' novices visualize this better. less interdependencies. less like "the registry". More like unix.
Re:Why systemd and not flat flies. (Score:5, Insightful)
and while we're at it why not text logs instead of a format that needs special tools to read
Re: (Score:2)
Re: (Score:2)
There are a few advantages to it. See here: https://www.freedesktop.org/wi... [freedesktop.org]
Re: (Score:2)
You can have text logs. Set journald to forward logs to syslog, and there you go.
Re: (Score:3)
I could have text logs without having to forward them, or have journald or its 1.2MLOC systemd altogether.
And that's what I'm doing by using a distro without systemd. But the point is that all the behaviours wanted existed before this was pushed on people.
Are you going to say that "fine, just choose another distribution"? I had to wait until the VUA came up with a workable Devuan.
Could all of this grief have been entirely obviated if this "diversity" move honestly were a "diversity" move and didn't push the
Re: (Score:3)
useless, when troubleshooting a system someone else set up, because the systemd defaults (and design) is stupid.
Re: (Score:2)
you only sure your inexperience as a systems admin
the "structured logs", databases, are useless in many scenarios when trying to recover crashed system, and the defaults are to be useless.
of course, anyone who doesn't understand why text logs are to be preferred isn't a serious system admin dealing with hundreds or thousands of systems that others might have set up
Re: Why systemd and not flat flies. (Score:2)
Re: (Score:2)
The difference is I have to work on systems set up by others, and those non-default settings of the stupidity that is systemd are not set, because systemd was designed by someone who knows nothing of the Unix way of doing things nor anything about systems administration. It panders to idiots.
Re: (Score:2)
I certainly know how to use systemd
you are the one that doesn't seem to know the value of ascii logs vs. the "binary format" that systemd uses.
You are being an arrogant cunt, "binary format" is an expression to mean non-text data.
You are of the same ilk with no common sense that brought us systemd
Re: (Score:2)
and while we're at it why not text logs instead of a format that needs special tools to read
Why not both? That is how all by Debian machines log, I haven't had to configure anything, just installed the right package
Re:Why systemd and not flat flies. (Score:5, Informative)
If you want text logs, turn the damn things on.
The Unix norm is text-based logs.. If they are default-disabled now or you have to "flip a switch"; then that's a bug. The state of that switch should be you get the expected classic Linux/Unix behavior by default.
Re: (Score:3, Informative)
Re:Why systemd and not flat flies. (Score:4, Informative)
Re: (Score:2)
But software development should also NOT be a place where people make changes for the sake of changes, or because they think they know better than everyone else. If you want to haul out old saws, how about, "if it ain't broke, don't fix it."
Oh geez, well what about toss it all on the wall and see what sticks. Or open source being the thing that let's you work on that one itch of yours? Let people make change for the sake of change. Let people be free to do what they want to do, and if they sell it better than the old solution, well then maybe no one was really sold on the old solution to begin with?
Re: (Score:2)
Isn't that why people keep building new systems, instead of making changes of the old ones? Because sometimes there *are* better ways to do things, but you wouldn't know without trying?
Re: (Score:2)
There are lots of technical reasons for having a monolithic init system.
Care to elaborate on what those reasons are?
Re: (Score:2)
Just because we've always done it that way, doesn't mean it isn't incredibly stupid
Unix has used text only logs for a long time. Its not true that "We've always done it that way." /var/run/utmp --- those were a total disaster when attempted, because they fail to provide the most important thing that a log is supposed to provide;
There have been some-formatted binary logs used in the past - see such remnants as
Easy access by humans and the standard unix tools.
If each part had to be initialized separately
Re:Why systemd and not flat flies. (Score:4, Interesting)
Compulsory tattoos. Now, where in history have we heard that idea before? (You're probably just using hyperbole to make a point, but a comment like that is nevertheless revealing of the... overzealous ...frame of mind behind it.)
Luddites, really? I'm skeptical of a broad generalization like that. I wonder if you're truly surrounded by technologists who resist all new technologies, or if you're actually surrounded by a people with a variety of perspectives and experiences, and you have simply failed to see value in their needs when they don't match your own agenda and limited experience.
By the way, text logs are much easier to work with when you have to do post-crash forensics with limited tools, and enabling both binary and text logs needlessly increases wear on flash storage. Both involve tradeoffs. When I see someone claim that a binary journal is a universal improvement, I know that they are either making pronouncements from a position of ignorance, or trying to sell something, or both. Either way, they lose credibility.
Re: (Score:2)
Luddites, really? I'm skeptical of a broad generalization like that. I wonder if you're truly surrounded by technologists who resist all new technologies, or if you're actually surrounded by a people with a variety of perspectives and experiences, and you have simply failed to see value in their needs when they don't match your own agenda and limited experience.
By the way, text logs are much easier to work with when you have to do post-crash forensics with limited tools, and enabling both binary and text lo
Re:Why systemd and not flat flies. (Score:5, Insightful)
Why don't we keep entire databases in text? Why not store all google search results in text?
Because logs aren't databases, and don't require the same kind of structure.
There's a reason why databases keep their own logs in plain text format, even when they are specifically designed for information storage and retrieval. They are hedging against catastrophic system failure, in which the only way to diagnose problems is outside the system. That's pretty much the role of logs. They're diagnostic tools. And they are designed—well, supposed to—be accessible when the system itself isn't working. So that you can find and fix what's wrong with the system.
People suggesting that it's sufficient to intercept the logging data as it's being gathered and stored in binary format probably aren't experienced (or bitter) enough to understand the multitude of mysterious ways in which systems can fail, and have yet to come to terms with the paradox of simplicity, and why its beauty transcends all ornamentation.
Re: (Score:2)
On the embedded side where bandwidth, computing power, battery power and memory are heavily constrained binary logs are often preferred. Translating to text has overhead, and the resulting log entry is usually much larger than binary.
The other issue is internationalization. Users often want to read messages in their own language and on embedded systems it can be a pain to have multiple different languages stored in the firmware, not to mention wasteful of memory. Instead you can just have a byte or two that
Re:Why systemd and not flat flies. (Score:5, Insightful)
But why should the needs of the specialized embedded use case leak into the general purpose desktop distro? Wouldn't it be better to have a pluggable logging subsystem that you can swap out for an implementation that writes binary records for embedded applications?
Re: (Score:2)
Isolating and maintaining little bits is the answer to the wrong question
Re:Why systemd and not flat flies. (Score:5, Insightful)
The problem seems to be that for all of these init systems to be plug-and-play, there *needs* to be an abstraction layer.
Yeah... its called a standard. There should be a standard for the filesystem and program interface to the init system -- just like other System APIs have a standard; just like there was something called the Linux Standard Base --- The standard should not say "use systemd" The standard should specify the format of configuration files/scripts and/or the interface for registering services.
Re: (Score:2)
good i hope it spreads like cancer and that systemd eventually becomes a hardware module mandated by UN globalist law. hahahaha.
Re: (Score:3, Insightful)
You're wasting your breath trying to prop up the fall of the Roman Empire.
Move to OpenBSD. The code is clean and small, and community still believes in Unix. We want your help.
Re: (Score:3)
Those of us who love(d) Debian since close to the beginning and were pissed when systemd was shoved down our throat, in many cases, have dumped Debian and moved to Devuan.. Debian withOUT the bullshit that IS systemd....
Re: (Score:2, Insightful)
Re: some history (Score:2)
Why bother? (Score:3, Insightful)
" Hartman noted in his August notes, "I think we may be approaching a point where we need to poll the project -- to have a GR and ask ourselves how committed we are to the different parts of this init diversity discussion. "
Why bother. If they paid any attention to the results, we wouldn't have systemd in Debian. They'll just do what they feel like.
Re: (Score:3)
Why bother? If they paid any attention to the results, we wouldn't have systemd in Debian. They'll just do what they feel like.
Could you expand on that a bit? I didn't follow all the ins and outs. From what I saw, the TC voted by a slight majority in favor of systemd. Ian Jackson's GR about loose init coupling didn't make it.
Which results are you talking about? Who are the "they"?
Re: (Score:2)
This is all coming about because someone dared question systemd, and even managed to somehow install a system without it, that is completely unacceptable and must be stopped!
Re:Why bother? (Score:5, Insightful)
Uhm no -- a GR is voted upon by developers, not users. Systemd is a big non-modular blob, the lack of modularity meaning it's pre-integrated and thus requires less work from maintainers. For sysadmins, though, it's a nightmare as you can't adapt it to your needs or debug problems you could do with basic shell knowledge with sysv-rc.
Re:Why bother? (Score:5, Insightful)
Re:Why bother? (Score:5, Insightful)
I have no experience with systemd or even Linux since playing a bit with Mandrake in early 2000s, so please believe me when I say I have no horse in this race whatsoever.
With that said, take a look at what you just posted and replace 'systemd' with 'Windows'. Wasn't Linux supposed to do things differently from Windows because being unable to modify Windows however you want is seen as The Problem(tm)?
Re:Why bother? (Score:5, Informative)
Re: (Score:3)
With that said, take a look at what you just posted and replace 'systemd' with 'Windows'. Wasn't Linux supposed to do things differently from Windows
With modification and customisation comes problems and complexity, often providing more than enough rope for users to hang themselves. Doing things differently from Windows does not make something automatically better. It's always important to focus very carefully on the exact thing and way something is being done and what purpose it was originally trying to achieve.
Re: (Score:2)
That may be so. If you leave out programming, that's me. But I also keep thinking of Devuan and one of the BSDs. (It's only the lack of a flle system compatible with both Linux and BSD that has kept me from trying that. Well, and the lack of a spare computer "just in case".)
Many recommend Gentoo, but the last time I tried that I bounced. I suppose I could try Arch or something. But with only one computer I tend to be a bit conservative. This, however, doesn't mean I like systemd, or that I have EVE
Re: (Score:2)
Why bother. If they paid any attention to the results, we wouldn't have systemd in Debian.
What makes you say that? A tiny number of vocal users bitching is not the same as conducting a referendum on the issue.
Well what do you want to be? (Score:5, Interesting)
GNU/Linux, a system whose entire point is that you (the user) can adapt it however you want, to suit your needs, because everything can interoperate, thanks to everything being a file, plain text config and script files, and small tools that do one thing and do it right. Developed by a distributed community.
Or systemd/Linux. A monolithic OS with central control and only one tool and king to rule them all. Like Windows or macOS.
Of couse you are free to inflict upon yourself whatever you want. But if you choose the latter, you can't go around, acting like you are the former.
And for the sake of sanity, "Linux" shall continue to mean "GNU/Linux". Otherwise Android/Linux could call itself that too, and it wouls become a big mess. /..)
How about PoetteringOS? Since he already tried to have the kernel his way anyway, even if it meant losing compatibility with everything else. (As reported here on
Welcome to Poetterix (Score:5, Funny)
How about PoetteringOS?
I've seen "Poetterix" used in discussions about the expanding scope of systemd. From this IRC log [qdb.us]:
Re: (Score:3, Funny)
Lennax
Re: (Score:2)
Re:Welcome to Poetterix (Score:5, Insightful)
Re:Welcome to Poetterix (Score:5, Interesting)
Re: (Score:2)
He solved a problem that the distro maintainers had. All the other init systems seem to be focused on the user and flexibility, which makes them a pain for the people putting the distros together.
Re: (Score:2)
I use systemd on thousands of VMs at work, and I would prefer sysvinit if possible. Unfortunately, RHEL and derivatives only go one way... the Poettering way.
Re: (Score:2)
It's the long term effects on Linux that you are not considering. Suddenly SystemD is dictating how Linux works, rather than a myriad of changable pieces. This will have a bad effect on the future of Linux. The only "king" Linux had before was Linus himself, and now this Pottering guy is just shoving all the lessons of the past aside for his goofy vision.
Re: (Score:2)
Re: (Score:2)
An this is a good example of the limits of that approach. Making everything interoperate with everything is O(N^2) complexity, testing and conflicts. It means maintainers having to adopt awkward shims an
It's O(1) when you do it the Unix way (Score:5, Insightful)
More than once I've run grep on a partition or on a disk.
Did you know send, grep, awk, cut, etc support disk drives, partitions, LVM volumes, keyboards, modems, and a thousand other things they can operate on?
They don't have to support any of those, it happens "magically" because a drive is a file. A partition is a file. A volume is a file. A modem is a file. A keyboard is file. Ed, sed, grep, awk and Perl operate on files. Cut and all the other tools operate on files. It's O(1) for everything to work together when each software package doesn't invest its own weird interface.
Re: (Score:2)
Indeed. And while you are absolutely right, this is an example of what I would call the "sysadmin mindset" -- which comes from the rich history of sysadmins that were the journeymen of computing. Everything is a file that can be grepped and sedded on the fly, configuration is flat text, the sysadmin know what is configured where and expertly watches over everything.
By contrast, there is another view of computing which is the "developer mindset". This comes from the point of view of those that write software
awk /etc/crontab, use Config:: Crontab (Score:5, Informative)
I've been writing software on Linux for 20 years. /etc/crontab, it might be time to refer back to that "For Dummies" book.
Guess what? Your example of crontab as an interface for people, not software - well if you can't write code to parse
If you don't WANT to write 8 lines of code to handle /etc/crontab, perhaps you'd like to use the appropriate module for your language of choice, to have an OO interface:
https://pypi.org/project/pytho... [pypi.org]
https://metacpan.org/pod/Confi... [metacpan.org]
If you've been programming for at least a few months, I bet you can pretty well imagine in your head the code for these modules. It's pretty simple, splitting a tab-separated line.
Oh btw, /etc/crontab actually *is* a file. One field in each line refers to a job, and each job is a - you guessed it, a file.
Re: (Score:3)
Dealing with a monolithic crontab file is a pain when you maintain software. It is difficult to reliably remove crontab rules, you cannot be 100% sure that what you remove is what you put in. Hence /etc/cron.d and similar solutions.
However, cron does not currently know about "invoke this when the system is woken up from standby" or "invoke this whenever removable media is inserted". Cron could be taught about removable media and standby, of course, but it is unlikely that such a small enhancement with so mu
Called udev.Send message and see if it is received (Score:5, Interesting)
For the last 15 years, hardware events such as device insertion have been handled by udev. Before that, by /etc/hotplug/NAME.agent. If you've been writing THAT code over and over, you've not only been repeating yourself, you've been re-inventing system functionality, while probably not doing it as well as the system already did it.
Systemd isn't needed for that. On fact, the way systemd implemented that was quite literally by copying and pasting the existing udev code into the systemd directory, then jacking up the input and output so that it no longer used handy text files.
As for your "check if it's running and then send a message, but that's a time of check time of use" problem, any decent JavaScript developer has learned the trick for that - send the message and see if it's received. Just try writing to the socket. If you get an error saying the socket isn't there, your daemon wasn't running. Of course you can get a tad more robust and very slightly more complex by using a mutex. But mutexes are a second semester construct. We can also do it entirely with first semester coding.
Ps mkdir is a cheap mutex (Score:2)
Speaking of solving TOCTOU by using the thing, then checking to see if it worked, a specific idiom is doing that with mkdir, or create directory. On Linux systems, attempting to create a directory is atomic - it will either succeed if the directory doesn't exist, or fail with an indication that it already existed. Which makes this pattern useful:
If mkdir /bar/spool/mydaemon
Do stuff
That avoids checking if the flag exists, then creating it, which could allow two pids to check, t
Re: (Score:2)
Yup, that's an oldie but a goodie.
Of course, if the daemon crashes without removing the directory (I think we had a catch for it somewhere) then you're hosed. Hence later the invention of the pidfile, which at least lets you recover from that situation.
Re: (Score:2)
And if the socket is there when I send the message, but the program calls exit() before it is read out of the socket?
Re: (Score:3)
Or if the program crashes while handling the request?
Or if some version of the program uses the network and the network is down? When expecting some external program to do some work on your behalf, it's a good idea to have some error handling / checking. The "calls exit without reading" is actually the EASIEST case because you'll get both a sigpipe and a error writing to the socket, so you'll have TWO notifications of the problem, and you *really* should have been planning for the write error because tha
Re: (Score:2)
Re: (Score:2)
This assumes that my service is running at all times, no matter what else the device is doing, just to be able to react to events. This is not an ideal state of affairs -- my service should be launch only when it is needed and then cleanly terminate itself when it's not longer needed.
That's pretty basic common sense -- don't consume
Re: (Score:2)
GNU/Linux, a system whose entire point is that you (the user) can adapt it however you want
What "GNU"? My Linux doesn't have any of these stinking GNU hippies.
Or systemd/Linux. A monolithic OS with central control and only one tool and king to rule them all.
Is systemd controlled by a single entity like FSF that controls all of the GNU? Or maybe like the kernel that is effectively controlled by a single individual?
Like Windows or macOS.
Or FreeBSD.
Re: (Score:2)
GNU/Linux, a system whose entire point is that you (the user) can adapt it however you want
Unless you're building Linux From Scratch your comment is woefully ignorant of just how many customisations are *not* possible by and end user in every distribution, and just how much gets dictated to you in the first place. This specialised and locked in approach is precisely the reason we have such a large variety of distributions to thank, being someone who doesn't like a package manager, or someone who prefers a DE that wasn't available to them, or someone who wanted to adopt a fork that isn't upstreame
When did groupthink get promoted? (Score:5, Interesting)
I'm not arguing for one system over the other, but software diversity has always lead to improvements to all projects.
clang and gcc complement each other. FreeBSD and Linux have both refactored their code to compile on both.
Initsystems are not a 'one size fits all'. What works on a desktop might not be the best solution for a car's infotainment system.
FreeBSD had the forked FutureBSD project that tried out launchd. [Personally launchd was pretty cool, I hated the xml config]. Sun's SMF was interesting as was Upstart.
As long as the tool was completely FOSS, Debian used to embrace it as making its platform. The kFreeBSD project still is a really interesting idea.
Re: (Score:3)
Which is fantastic. But note that you can't just start saying you want gcc's lever but clang's AST representation passed to gcc's optimizer and then compiled to LLVM-IR.
There's competition and users can chose either, but the two toolsets are completely disjoint and their components entirely non-interoperable. The intermediate products of compilation (PCHs, object files, ASTs, IR) are in binary formats,
Re: (Score:2)
On systemd feature creep, I just found these articles.
Lennart Talks Up systemd's SD-Boot + Boot Loader Specification [phoronix.com]
Systemd lead developer Lennart Poettering presented on systemd-homed as a new component to systemd that is focused on improving home directory handling. [phoronix.com]
Just what the fuck.
Re:When did groupthink get promoted? (Score:5, Interesting)
everyone's throats by RedHat.
RedHat is a company. What makes companies the most money often wins. They're now owned by IBM, IBM tools exist to make IBM money and not actually *do* anything. I say this as a victim of ClearCase, DOORS, DOORS NextGeneration, Jazz SCM and others.
Just because RedHat was built on Linux doesn't mean they carry the torch well.
2019 is weird and everything has changed. I trust Microsoft 2019 more than RedHat 2019. They're a $34B company that have blessed the ecosystem with systemd. That had bugs at one time like "wipes out my raid-1" or other BS. It should have never made it this far.
Pottering gave us PulseAudio before he moved on to init systems. Argued that a username starting with an int was invalid, even though it's in the UNIX spec [github.com]. His comment there says everything you need to know about him and how he operates.
Re: (Score:2)
You can't blame IBM for systemd. Red Hat foisted it on the community of its own corporate will. Look at the timing. (I'll grant that IBM probably likes the idea.)
Re: (Score:2)
At work, I support clearcase, doors, doors ng, jazz, etc for our engineering departments. My god the bugs that even ibm cant fix. Jazz let go of their main devs and have in some cases 1 person who knows the code.
IBM is a shit show for their produts, they aquire and fire, dont ever use IBM. I'm very sad that Redhat is now owned by IBM.
Re: (Score:2)
Jazz let go of their main devs and have in some cases 1 person who knows the code.
Can you elaborate on that? I was let go from one of my last jobs because we were evaluating packages and despite half the company already using Git (Atlassian) mid level management insisted on Jazz SCM. No amount of anything would convince them how much their engineers would hate their life.
There was one guy whose full time job was keeping the DOORS installation up, which he failed at doing. It took 30 seconds to load the landing page.
Hearing that they got sucked into a boat anchor is some schadenfreude.
Comment removed (Score:5, Interesting)
Re: (Score:3)
That's how many problems we've had on RHEL 7 with SystemD doing things like "so I see you trying to authenticate that user with Kerberos... yeah, not on my watch..."
Took us all of about 30 minutes to get our RHEL7 image to authenticate users with Kerberos. We know have hundreds of servers happilly all authenticating against the KDC. I don't get what issues you are having nor what systemd has to do with it since the only part of systemd we used is the default SSSD unit file to start the service.
Only thing I could see would be the SELinux label problem on /var/cache/krb5ucache, since RedHat decided to only label /var/cache/krb5rcache in their default policy. We simply
Re: (Score:3)
Easy. Drop SystemD (Score:4, Insightful)
It is after all a load of shit.
Re: (Score:2)
You overstate the case. It doesn't benefit individual users. It has reportedly benefited system admins dealing with multiple systems.
I wish systemd would go away, but I haven't yet taken any direct action to cause that to happen. That will occur when I replace my current computer.
Many people seem to be happy with systemd (Score:2)
Re: (Score:2)
systemd works for me where the system is simple. But when I want to change things or when the system is weird and hackish then it doesn't want to allow me to succeed. So if I'm just installing a vm for some task I don't care if it's systemd or not but if it's my actual system and I might have to do something weird to solve a problem someday it's a hard no.
Re: Many people seem to be happy with systemd (Score:3)
The reasons you talk about are the reasons I prefer systemd. Setting up a network share is trivial.
With sysvinit, it was a tangled mess of crap service code, copied and pasted endlessly, with poor support for anything beyond the most basic "run this script at startup; good luck".
Sounds another systemd goal is about to be ... (Score:5, Interesting)
.
But go ahead, eliminate any possibility of another system providing any manner of escape from that snowball rolling down the mountain.
Re:Sounds another systemd goal is about to be ... (Score:4, Interesting)
It's not that simple. Compare the configuration files of grub with grub2. Gurb was relatively easy to deal with. Grub2 is unintelligible. The people writing the systems have gotten divorced from the individual users. (This has always been a problem. Back in the days of Debian Potato the install manuals were gibberish, if you didn't already know what they were saying, and just needed a reminder. A lot of the time they obviously expected you to "just ask your local expert".)
Re: (Score:2)
Or they expected you to "read the source".
Re: (Score:2)
Ahhh....read the source to a computer operating system before you've installed the operating system?
I get that you were being humorous, but that just isn't a plausible answer. (Unfortunately, it may be correct. Often I got the idea that they thought I had a couple of spare systems to experiment on.)
Re:Sounds another systemd goal is about to be ... (Score:5, Funny)
I have given up on figuring out where grub2 keeps its stuff. I only interact with it through the tools, and every time I touch it I need to Google.
There is a file called grub.cfg in /boot/efi/EFI/fedora. Despite the name it is only a config file in the sense that sendmail.cf is a config file.
The second line is "# DO NOT EDIT THIS FILE". To whoever wrote that: "Fuck you too". Do not presume to tell me what I can do or do not do on my system.
Re: (Score:2)
To whoever wrote that: "Fuck you too". Do not presume to tell me what I can do or do not do on my system.
Which implies that the entire grub configuration is duplicated...somewhere....
i mentioned that a long long time ago (Score:4, Interesting)
Re: (Score:2, Interesting)
Re: (Score:2)
Systemd proponents do not want choice. They know they would never win if people actually had choice. Choice therefore cannot be permitted.
Is that why they bend over backwards giving you things you bitch about like being able to execute init files, or being able to produce text logs, or offering you the choice of doing things the old way at every bloody step of the way?
Re: (Score:3)
Translation: "Is that why they bend over backwards giving you everything you had previously, now with 1.2+M LOC that you don't want, doing things that make your life harder, require extra work to give you everything you had previously; and now Debian are considering whether they are at all committed to having anything other than the broken new stuff, because the systemd maintainers are too exhausted to even explain why they're exhausted, in the face of everybody else trying to make their stuff work?"
Re: (Score:2)
i said Debian should build an init agnostic distro so during the install of the OS it has a screenie offering a choice of init systems to choose from like the old trational sysV or systemd or runit or whatever else is available
Not going to happen. You don't seem to realise the insane amount of work that maintainers would need to do to make something like this happen. For you it's a choice between A and B, for a maintainer it's making available A and B, and system C to select between A and B, and now they maintain 3 systems, except software D, E, and F, now needs to be tested and made compatible with 2 system, configuration changes to the system need to be made available in 2 systems... this isn't a doubling of work, it is a major
Re: (Score:2)
> You don't seem to realise the insane amount of work that maintainers would need to do to make something like this happen.
Err, we already had multiple init systems supported and working in Debian prior to the systemd takeover. Including systemd.
Somehow, it was entirely possible for many years to support this. But today it's "insane". I wonder why that might be...
systemd sucks (Score:5, Interesting)
Re: (Score:3)
Systemd doesn't kill any processes it doesn't know about, other than child processes run by a user in a user session at user log-out and that behavior IS entirely optional.
Re: (Score:2)
And this is why djb is now reviled (Score:5, Interesting)
Dan J. Bernstein wrote a very good init tool, "daemontols", available at http://cr.yp.to/daemontools.ht... [cr.yp.to] . It's bog stable and did the *important* thing that systemd did" replaced the often fragile init system with a much more stable and reliable one. But djb wanted a license where no one but him could build and publish the software with any patches applied. It meant that no Linux distribution would use it, because much like systemd, he widdled all over the top of the / filesystem in violation of the File System Hierarchy.
Systemd has basically blown 15 years getting back to a stable such point because it insists on redesigning *everything else* along the way. Do not get me *started* on the replacement dhcp network stack, the automount replacements, and the insistence on killing all your jobs after you log out to kill nohup and tux and screen use, without recording anywhere that it killed your process. And oh, yes, replacing /etc/resolv.conf with a symlink that it then refuses to re-establish.
Re: (Score:3)
Re: (Score:2)
Because you say so. I guess that's settled, then.
I disagree, however. I think systemd is very un-fine, and efforts to circumvent it is energy well spent.
Re: (Score:3)
Lennart, is that you?
How did you get to be such a jerk? Were you born this way, or did you have to work at it?