Systemd is like a cancer metastzing all over Linux
|
| Author | Content |
|---|---|
| linux4567 Oct 17, 2014 10:43 AM EDT |
I hope this article will wake up some of the independent distro makers and stop them from using systemd. The only way to kill systemd is if multiple distros stop using it. That's why the Debian decision was so bad, as many distros are derivatives of Debian. I wouldn't be surprised if the commercial Linux company behind systemd did influence in every way possible the Debian decision-makers to make sure the outcome was in favour systemd. I wonder if any money changed hands... I see systemd as the biggest threat to Linux as we know it. |
| JaseP Oct 17, 2014 11:34 AM EDT |
Money changing hands?!?! No. But influence (a/k/a hijacking),... Yeah, probably. So,... now this thing is going to take over virtual terminals as well?!?! I wonder what the SystemD "yes-men" have to say now??? Let's make it clear. What Poettering is doing is replacing the kernel, bit by bit, because he has a beef with the way Torvalds does things. If Linus was (really and truly) smart,... he'd ban Poettering's code. |
| Bob_Robertson Oct 17, 2014 12:02 PM EDT |
SystemD is a mistake. It's not a disaster waiting to happen. No, systemd is a slow train wreck going on right now. As soon as people stopped obeying the first rule of UNIX programming, that's when the disaster began. Do one thing, do it well. SystemD does lots of things, badly. |
| nmset Oct 17, 2014 12:05 PM EDT |
>Poettering's code Relative to systemd, his code is not in kernel space ! |
| kikinovak Oct 17, 2014 12:13 PM EDT |
In the meantime, the average Slackware user just grabs a huge bag of popcorn and enjoys this huge train wreck in Cinemascope. :o) |
| seatex Oct 17, 2014 12:52 PM EDT |
SystemD. Ebola for Linux. |
| JaseP Oct 17, 2014 1:06 PM EDT |
Quoting: >Poettering's code There's always patches that need happen,... Otherwise Torvalds would have had no reason to ban Sievers... http://linux.slashdot.org/story/14/04/04/1523231/linus-torva... |
| me1010 Oct 17, 2014 7:16 PM EDT |
At this point, I'm all for systemd. After reading a lot and experimenting some, I've come to really enjoy the easy flow of using systemd. It's a great idea, and I'm looking forward to it 'taking over' several dead-end projects sitting around in GNU/BSD/Linux distros - adding new functionality, while also increasing much needed uniformity. However, if you don't like it - feel empowered by the FOSS and join the fork: http://uselessd.darknedgy.net/ |
| skelband Oct 17, 2014 7:44 PM EDT |
@me1010 You create uniformity with standards not by binary lock-in. I'd be all for a new standard attempting to bring components together, like D-Bus. The UNIX crowd love standards. It's what makes it all work. systemd is most certainly not that. |
| me1010 Oct 18, 2014 11:48 AM EDT |
@skelband: There is no such thing as a 'standard' for booting a GNU/BSD/Linux system. It would be great if there was a standard, call it ISO51234 or something, but there isn't one. The FOSS OS world suffers greatly from the historical lack of uniformity in configuration management, process handling, file system formats, and many other areas. I know many FOSS-ers' would indicate that "Choice and preference are good things," however choice and preference can be preserved just fine while also adhering to a uniform underlying basic OS scaffold. The uniformity that wide adoption of systemd will bring, will expand FOSS OS adoption into areas unexplored by desktop FOSS. Imagine if the general large corporation ran a version of GNU/BSD/Linux FOSS OS... Imagine the extreme rapidity of application development for the FOSS world... 'Binary lock-in' ... I'm not sure how this statement is justified. Lock-in refers to the inability to port data from one arena to another because of either undocumented 'features' or requirement for a specific program which can not be duplicated in order to access the data. Neither of these things exist with systemd. Systemd is FOSS, all of it, every line of code. The binary storage format for logging data is well documented. And the logging data can all be exported into nearly any required format. You can even export live logging data in native JSON format! So, I'm not buying this over-hyped statement of 'binary lock-in'. 'UNIX crowd love standards' ... YES! And systemd brings that in spades. And some are all up-in-arms because of that... However, is the code up to par with high quality kernel code? Probably not... but that lack quality has nothing to do with the brilliance of the idea... and code quality is bound to increase with time -- cross fingers.. EDIT: Forgot to add... code quality will increase with time and enough beatings and berating from Linus Torvalds... |
| jdixon Oct 18, 2014 12:20 PM EDT |
> and code quality is bound to increase with time -- cross fingers.. Strangely, that doesn't seem to be the case with pulse audio. :( So I wouldn't hold my breath. |
| linux4567 Oct 18, 2014 2:47 PM EDT |
@me1010: that's a lot of waffle devoid of any actual meaning, do you work in marketing? There is nothing much to be gained by 'standardising' on systemd, there is far more to be lost. I'm saying this as a distro packager so this is something I'm dealing with all the time. Systemd does nothing to 'expand FOSS OS adoption into areas unexplored by desktop FOSS' as you claim (without explaining why) and many large corporations already run Linux, systemd will have no influence on any of this. Systemd is not really a standard either as the devs are still constantly changing it, it's basically a moving target, a nightmare for packagers and programmers of other applications that have to interface with it. There is nothing brilliant about systemd (again you don't explain why it's supposedly brilliant), it is a large mess of binaries who do lots of things badly, it is basically a security nightmare. I bet quite a few serious security exploits of systemd will surface in the next few years, this is a train-wreck far worse than openssl waiting to happen and might even ruin the reputation of Linux as a secure OS. |
| nmset Oct 18, 2014 2:56 PM EDT |
>as a distro packager
>a nightmare for packagers Why did the decision makers of your distribution drop SysV for systemd ? [N.B. : I'm no fan or hater of either.] |
| JaseP Oct 18, 2014 2:59 PM EDT |
Quoting: ...The FOSS OS world suffers greatly from the historical lack of uniformity in configuration management,... How?!?! And what do you mean by that? Configuration is/has been pretty standard,... a set of human readable config files that can be edited with a text editor,... easy... Or use a GUI config tool,... pretty simple,... Quoting: ... The FOSS OS world suffers greatly from the historical lack of uniformity in ..., process handling,... Again, pretty simple,... The kernel scheduler's for threads/processes,... You have kill/killall/et al. (and their system calls, like kill(), killpg(), pthread_kill(), etc.) to kill processes,... the ability to "re-nice" a process for it's priority/time slice usage,... I don't see what is non-standard about that. Plus you have cron/anacron for scheduling processes,... pretty simple to configure once you know how (again, edit a human readable text file or use a GUI app to help)... Quoting: ... The FOSS OS world suffers greatly from the historical lack of uniformity in ..., file system formats, ... I don't know what you mean by that,... File system formats are pretty transparent to the user/developer. The kernel pretty much handles the specifics of dealing with the file format,... ext2, ext3, ext4, FAT, etc., etc,, ad nauseum,... Are you saying that there are too many file formats??? Why would that even matter??? You choose the file format you want when you configure the system, based on what's right for your usage... Nothing you've listed above is a bar to FOSS adoption. The Linux kernel is a pretty straightforward POSIX kernel,... a nice drop in replacement for a Unix kernel, adhearing to standards set more than 40 years ago,... There are even legacy parameters in system calls that are there for backwards compatibility with old (and obsolete) Unix standards (like the tz argument in an int settimeofday(const struct timeval *tv, const struct timezonw *tz) call to update the system clock). How you can say there are no standards is mind boggling. Replacing (any one of) the init system with systemd isn't the real issue. The real issue is systemd's developers locking in developer mindshare by merging other projects and causing dependency on their baby. That might not be a terrible thing if the developers had limited scope and discipline, but Poettering and his crew have repeatedly shown themselves to be big on ideas, and small on discipline, and follow-through (Pulse Audio as the perfect example). He (with the help of RedHat, holding his leash) have helped co-opt other projects to force them into their way. Just in the last few days, Debian has had a motion to put on the table a resolution to maintain other init systems as an option. However, it may be too late. Debian is already over-run with RedHat people in key positions, and same is true of other major projects (Gnome/GTK+, as examples). It may be that short of Gentoo, there will be no option for what init system is used on any Linux platform or distribution, from RHEL to Debian, to Android, to ChromeOS,... And Gentoo will be severely hamstrung into what high end GUI options are available, when all these high-end projects have systemd (and its sub-projects) as a dependency. |
| linux4567 Oct 18, 2014 3:18 PM EDT |
> Why did the decision makers of your distribution drop SysV for systemd ? I package for a RHEL clone, so these decisions are being made by Redhat for us. Systemd is the reason that I'm not involved in EL7, I'm personally sticking with EL6 for the foreseeable future. BTW, not many people know that RHEL6 (and it's clones) uses Upstart, not SysV init. The reason why this is little known is probably because Upstart is actually very similar in many ways to SysV so people don't even notice that they are dealing with Upstart rather than SysV init. Upstart basically is a respectful improvement of SysV init rather than a 'not invented here/taking over the whole Linux ecosystem' kind of software like systemd. Upstart was probably the best piece of software to come out of Ubuntu, IMHO Debian made a great mistake by choosing Systemd (and I still suspect this decision was the result of manipulation by shills from Raleigh, NC). |
| me1010 Oct 18, 2014 3:57 PM EDT |
@JaseP Configuration management: Deployment is easy for one or ten machines. Things get really difficult when deploying thousands of machines. Systemd: All configuration is human readable text files. There is no advantage to sysvinit for also using human readable text files. However, there is an advantage to using systemd - the human readable configuration files are easily understood by less experienced sysadmins. This is a huge advantage which will drive down costs for administration of large deployments. It's also a huge advantage to ensuring uniformity in configuration in the machine pool. Thus making large scale deployment of desktop FOSS machines not only possible, but attractive. File system formats: Yes. There are too many file system formats. The main distros should choose 2 or 3 in the default install, and the rest should installable at some other time. Again, this would ensure less experienced sysadmins can do the admin job - driving down costs - and increasing deployments. Process Handling: I've run into lots of issues over the years with various process handling difficulties. Things could be improved - tools could be improved for finding zombie processes - and lots of other random issues... In any case, desktop Linux AKA "The Year of the Linux Desktop" is all about corporate adoption. If FOSS OS is to thrive - meaning have good driver support [from the vendors] for new or unusual hardware, be able to natively run high demand [by consumers] proprietary application AKA Photoshop, and other 'goodies' -- wide scale corporate adoption is the only path... and that means... making steps toward systemd or systemd-like constructs. Beyond the above thoughts: I'm an electrical engineer. I know how transistors function, how to design and build a 3 transistor amplifier. However, beyond the classroom, no one would do this anymore. The time investment would be massive in comparison to choosing one of the many pre-fab audio amplifiers that can be purchased for $0.50 or less. The point: at a certain moment, the fine control needs to sacrificed for expanded productivity elsewhere... If the FOSS-ers would stop bickering about what is or is not "UNIX-worthy" and instead settle on a single main platform [it really doesn't matter which one]... lots and lots of things would begin to develop... I'm still waiting for a good viable replacement for Microsoft Project. Perhaps the removal of 100 different flavors of "how to boot a GNU/Linux" will free some coding time to challenge the proprietary stalwarts in /all/ areas of software. Don't be afraid, it's still all FOSS - and is still just as forkable as ever. |
| linux4567 Oct 18, 2014 5:23 PM EDT |
@me1010: you don't seem to understand how the Linux world works. You cannot re-allocate volunteer developers who write something in their spare time because they like doing so, at will. No 'init' system developer will start writing a Microsoft Project substitute for you just because his init system is no longer needed, that's simply not how it works. Also the SysV init system (or Upstart) is certainly not something that's a problem in any way for sysadmins. It's systemd that creates the problem as every Unix sysadmin will have to be trained up on it while SysV init or Upstart don't require any training for sysadmins with a Unix background as it's something any Unix sysadmin is familiar with. You need to realise that corporate IT environments generally only use one flavour of Linux (most use RHEL) so the 'issue' of making things work across distros does not exist. From your last post I get the impression that you are better off using Windows, as your ideas for Linux seem to be to basically transform it into another monolithic system like Windows. |
| kikinovak Oct 18, 2014 5:58 PM EDT |
> It may be that short of Gentoo, there will be no option (...) Don't forget Slackware and Crux. BSD Init, crisp and clean. |
| me1010 Oct 18, 2014 6:44 PM EDT |
@linux4567:
FOSS is not really all about the volunteer programmer. http://dirkriehle.com/wp-content/uploads/2013/08/paid-v8-fin... The corporate world uses, develops, ships, and hosts quite a lot of FOSS-ware. The 'free as in beer' world needs the suits with the money. That's just the way it is... > From your last post I get the impression that you are better off using Windows. I haven't touched a Windows or Mac machine nor Microsoft software [except Project when necessary - sigh!] in nearly a decade. I run 5 web servers, including email services all using Debian stable. My home network consists of a collection of Debian machines that provide a nice intranet experience including audio/video DLNA server, file server, and dhcp. I argue with everyone of my engineer friends that FOSS has truly come into its own... I am the GNU/Linux advocate everywhere I go... However, systemd is better than sysvinit. If you don't agree, join the fork [see prior post]. There are many more important things to worry about than the 'init' ... and this nonsensical argument is starting to hurt acceptance level as well as producing fear in 'the suits'. |
| JaseP Oct 18, 2014 7:19 PM EDT |
@ me1010 Did you even read what I wrote??? Too many file formats?!?! I was being facetious. File formats are virtually transparent in the Linux world. The kernel handles it,... reading, writing and checking on files is handled by either OS calls (when programming) or command line instructions (or the equivalent file operations in a GUI file manager). There is absolutely no reason for an admin (Jr. or Sr.) to worry over what file format they chose, as long as it supports permissions (that is,... no FAT formats). Integration with the MS Windows world??? Only a SAMBA server away. Manage thousands of users on an Linux environment? Puppet. PXE boot the machines. Mount your users on the same file system, regardless of which server/system they are running on... Mix and match with those solutions. You're thinking too MS-like (As in MS's way of managing workstations). That's why you are having issues. Linux adoption being hampered by driver support?!?! Give me a break. That's 2003 talking (not even). Most Linux adoption is taking place in the embedded space. Your driver support is right there for it too. I run quite a bit of exotic hardware. You have to be running on a machine that was intentionally developed to thwart Linux adoption to have a problem (like the Viliv machines from the 2006/7 era, once MS "partnered" with them,... and where is Viliv now? Like most MS partners,... defunct). Here are your MS Project alternatives... http://www.techrepublic.com/blog/five-apps/five-free-microso... Take your pick, but #1 on the list looks like the clear winner. Linux adoption does not depend on homogeneous infrastructure. It never has. "The suits" only worry when they aren't being taught right. A good sysadmin will tell them what they need to worry about... |
| linux4567 Oct 18, 2014 7:31 PM EDT |
@me1010: without volunteer programmers the whole business model of companies like Redhat would implode, they could never afford to pay enough programmers to do all the work they get for free, so volunteer programmers are still the backbone of the Linux ecosystem (the document you refer to is just about the kernel which is a special case as it's way too complex for most volunteer programmers these days). Without them none of us would be using Linux as there would be very few interesting desktop apps available. > systemd is better than sysvinit Did you actually read my post and follow the Debian systemd debate? This is not about systemd vs. sysvinit but about systemd vs. upstart! That said even if systemd was well designed and written (which it isn't) the problem is it's mission creep and the attitude and track history of it's developers. Read the article this thread is about again, and read this: http://boycottsystemd.org/ I say it again: Systemd is a security disaster waiting to happen, it will do Linux reputation a lot of damage. |
| me1010 Oct 18, 2014 7:43 PM EDT |
@linux4567: I've read many articles about the 'big three' inits... After many months of paging through arguments along side the documentation while also learning how to use systemd -- I have concluded in my not-so-unprofessional or un-tested opinion that systemd is not only here to stay, but exceeds the alternatives in feature set and goals. The code will come up to par -- and then the numerous pages of MB of arguments will be useless and wasted... Life's short, learn something new, and enjoy the FOSS. |
| linux4567 Oct 18, 2014 9:54 PM EDT |
You still don't get it > exceeds the alternatives in feature set and goals That's EXACTLY the problem, as per subject, Systemd is like a cancer metastzing all over Linux! More isn't always better, especially in the FOSS world, which is based on collaboration rather than 'winner takes it all' style competition! |
| jazz Oct 19, 2014 8:23 AM EDT |
As of this morning there are 39 systemd related bugs in CentOS bugzilla. Some are minor, most of them are major and there are also crashes. This is the lowest quality for a RedHat product I've seen in ages. |
| Bob_Robertson Oct 21, 2014 9:20 AM EDT |
Something occurred to me yesterday, that piqued my Conspiracy Theory (tm) cranial lobe: Systemd and Pulse Audio are written by the same person. Both are subsuming other systems in a very Microsoft way. Microsoft wants to destroy Linux, always has, always will. Skype, a Microsoft product, requires Pulse Audio. Therefore, how much of a leap is it to wonder if Lennart Poettering is a Microsoft mole deliberately sabotaging the Linux community/ecosystem? Insomnia is a terrible thing, the mind wanders. |
| 750 Oct 21, 2014 9:43 AM EDT |
Best i can tell, there are two reasons for pushing Systemd. Cloud, and "high secure seat" management. The former comes with cgroups, containers, and the drive to shift everything into /usr. This allows for quick spin up and down of could instances once the template has been set up by whatever web monkey is on the job. The latter can be found in the integration of SELinux, Systemd (croups) and Logind (allowing Gnome to use Systemd to sandbox user processes). This will make for a "iron clad" seat management in sensitive situations, like military field terminals. The reason the latter needs Systemd as init, as best i can tell, is that the earlier Consolekit could be escaped from via various means. Most likely by way of forking in some way or other. The progression to this seems to have been: Pulseaudio expanding to route audio over networks, avahi for discovery and handshaking of the various taps and sinks, systemd to restart and reap runaway processes of the other two (yep, lets not fix why something crashes. Lets just put another potentially crashy software in charge of restarting the crashy software. This is Windows mentality). While developing avahi, pick up a interest in daemon/server security, get involved with consolekit, find consolekit "lacking", reimplement as logind+systemd to "avoid deficiencies" in consolekit. |
| Bob_Robertson Oct 21, 2014 10:27 AM EDT |
Interesting. Thanks, 750. The systemd process definition files are an improvement over init scripts. If systemd did only that, and used plain text logging, I would have no hesitation to use it. It's clear that there are excellent reasons for the change from init to systemd, just as there was for the change from TNT to atomics. It's just the repercussions of that change to which I object. |
| Steven_Rosenber Oct 21, 2014 1:29 PM EDT |
In theory, this should make FreeBSD, its variants PC-BSD and GhostBSD, and OpenBSD super-popular havens from PulseAudio and systemd. As much as I'm not opposed to PA and systemd, I'd love to see users make an effort to use the BSDs and start contributing to those projects. A bigger user base would go a long way toward an easy-as-Linux BSD world. Right now BSD presents significant challenges relative to Linux in terms of getting and maintaining a working system, and a rush of users could do wonders to smooth that road. I'd love to see this happen, but I bet it won't. |
| flufferbeer Oct 21, 2014 3:23 PM EDT |
@linux4567 You wrote, using these italics: >>>> There is nothing much to be gained by 'standardising' on systemd, there is far more to be lost. I'm saying this as a distro packager so this is something I'm dealing with all the time. Systemd does nothing to 'expand FOSS OS adoption into areas unexplored by desktop FOSS' as you claim (without explaining why) and many large corporations already run Linux, systemd will have no influence on any of this. Systemd is not really a standard either as the devs are still constantly changing it, it's basically a moving target, a nightmare for packagers and programmers of other applications that have to interface with it. There is nothing brilliant about systemd (again you don't explain why it's supposedly brilliant), it is a large mess of binaries who do lots of things badly, it is basically a security nightmare. I bet quite a few serious security exploits of systemd will surface in the next few years, this is a train-wreck far worse than openssl waiting to happen and might even ruin the reputation of Linux as a secure OS. <<<< and then >>>> That said even if systemd was well designed and written (which it isn't) the problem is it's mission creep and the attitude and track history of it's developers. Read the article this thread is about again, and read this: http://boycottsystemd.org/ I say it again: Systemd is a security disaster waiting to happen, it will do Linux reputation a lot of damage. <<<< Double +1 on all the above... VERY well said!! 2c |
| skelband Oct 21, 2014 8:35 PM EDT |
@me1010 The objections that most people are having to systemd is its scope. Whether or not you like or dislike binary log file formats, or one implementation or another of cron, you are free to choose. systemd may be a good idea for an INIT system, but it comes with a huge amount of additional baggage which you may choose not to have. We now hear that gimp (among many gnome friendly apps) has a build dependency (supposedly optional I would admit) on a systemd component. That, right there, should be ringing really loud alarm bells. What on earth does a graphical editing program got to do with system initialisation? You decouple system components by passing messages, POSIX or other well known and non-specific APIS, using kernel features: ANYTHING is better than binary linkage. Even the most entrenched components like glibc can be replaced part for part by another compatible alternative, like eglibc through the medium of standards, in this case POSIX and the standard library specifications. At the very least, such cross-dependency between components is flying in the face of all modern knowledge about what makes for maintainable and enhanceable systems by decoupling and modular, object-oriented design. I just despair. |
| me1010 Oct 22, 2014 9:20 AM EDT |
@skelband: Scope creep is true everywhere. Linux == large monolithic kernel with it's 'fingers and hooks' into every aspect of the system. Heck! It even replaces lower level system BIOS functions when it doesn't like them. How's that for scope creep? X-Windows == massive server for handling everything from a single local display to thousands of networked displays running anywhere in the world. This is how nearly every *nix OS displays a default user gui. X-Windows has pages and pages and pages of options which are or could be vulnerable to attack from random network hosts. X-Windows is nearly the very definition of scope creep, and - yet - it somehow was a vital part of the *nix OS from the beginning. Seriously, the arguments against systemd are really strange considering the *nix world before systemd. If there's truly a desire to avoid scope creep in a *nix environment, give GNU HURD a try. It's a microkernel. The hardware drivers are not integrated into the kernel as modules and don't require re-compiling when the kernel changes. https://archive.fosdem.org/2014/schedule/event/07_uk_dde_on_... Come on... systemd is entirely FOSS and is just as *nix-like as anything else used in prior *nix OSes. Perhaps, it's different. But different isn't bad... And someone even called out the program "Puppet" in order to allow uniform deployment of *nix boxes... "Puppet" but not "systemd"?? Why? I'd rather learn one new declarative language for defining machines locally as well as networked - instead of two or three. Systemd makes life easier for the admin and cheaper for management. The world runs on these things -- cheaper, easier -- that is... Why would anyone seek to stand in the way of that? p=m*v That's why. However, eventually the skids need a little grease, otherwise the ship slows to a halt. Systemd is the current source of grease - it's not necessarily the best source - but I'm sure it will increase v... EDIT: Need to add -- GIMP is graphics editor. If you think about what that means for a few minutes, it may become easy to understand why it might be a good idea to figure out if a certain driver set has been loaded and configured. Claiming that GIMP is the latest 'victim' of scope creep, is like claiming that your USB port is the latest 'victim' of kernel scope creep. The argument simply doesn't make sense... Having written all that - I am no way wedded to a systemd future. As I wrote before "It really doesn't matter which one [init]"... All that really matters is that the "init" is one for all. The precise thing the anti-systemd is both arguing for as well as against -- aka.. the call for standards, but the fight against the new standard. Cheaper, easier - that's a win for FOSS adoption. However, perhaps the 'idea' man needs to get booted out of the code booth, and let the professionals take over. Time will tell. |
| Bob_Robertson Oct 22, 2014 10:36 AM EDT |
> Time will tell. On that, hopefully, we can all agree. |
| mrider Oct 22, 2014 11:02 AM EDT |
One question: if SystemD is so effing awesome, then why are the programmers so bound and determined to make it impossible to avoid? Wouldn't it make more sense to just distribute the awesomeness and let others come fawning at their feet? (okay, that was two questions - so sue me) |
| me1010 Oct 22, 2014 11:26 AM EDT |
@mrider: I believe there's an error in understanding systemd as a conspiratorial package. Have you ever watched the movie "Cube"... http://www.imdb.com/title/tt0123755/ Watch it. And listen for the line about large organizations and conspiracy theories. FOSS is a huge organism. I doubt very much that the systemd programmers seek to make it impossible to avoid using their software. It just happens... One could also make use of your type of argument to ask questions like: If democracy is do effing awesome, then why are most governments world-wide not democracies? See? The type of argument is nonsense... |
| 750 Oct 22, 2014 11:44 AM EDT |
Right now i am reading a discussion over on Hacker News where someone is actually recommending to use strace to figure out a issue with how systemd starts "services". Strace! That finally snapped into place what irks me about the core of systemd, its init part. The logic of the boot is in the init binary. With sysv the logic is in the scripts, not the init binary. All the init binary does is set up the virtual terminals and get the scripts going. This means that if a script fails, one can debug and iterate on it right there with a terminal. With systemd it seems the only options are to have it walk the tree and hope it all looks sane, or reboot and cross your fingers. Never mind the lovely exchange on G+ with Ts'o where he tries to replicate a runlevel switch scheme he had in systemd, and finds the brightness control keys on his laptop being disabled without him touching anything related to that. [url=https://plus.google.com/ TheodoreTso/posts/4W6rrMMvhWU]https://plus.google.com/ TheodoreTso/posts/4W6rrMMvhWU[/url] |
| Bob_Robertson Oct 22, 2014 11:54 AM EDT |
> If democracy is do effing awesome Democracy sucks. |
| me1010 Oct 22, 2014 12:00 PM EDT |
@bob_robertson: quoted my typo... oh well... OT: Which type of government doesn't suck? |
| mrider Oct 22, 2014 12:22 PM EDT |
I honestly don't know which is more disturbing - the thought that the SystemD folks consider it their mission in life to jam their software into Linux, or that they can't be arsed listen to objections. Even Helen Keller would be able to hear the outcry at this point. I'm with linux4567, SystemD is the biggest threat to Linux of our time. Not because of what it does or doesn't do, but because nobody can be bothered to actually listen to other viewpoints. [EDIT] At least I can still use Alsa when PulseAudio doesn't work. Soon I'll have to switch to a different O.S. if I have some reason that SystemD doesn't work. |
| Bob_Robertson Oct 22, 2014 12:35 PM EDT |
> Which type of government doesn't suck? None at all. (see: http://mises.org/daily/1855 with emphasis on paragraph 2) > if I have some reason that SystemD doesn't work True. While I do file bug reports, and made one patch offering on the alter of the Linux Kernel Mailing List, I am one of those "freeloaders" who lives off the Herculean efforts of FOSS developers. If by some miracle those demigods of the Intarwebs are able to make systemd work as it encompasses everything people feel like rolling into it, then at some point I'm sure I'll use it just because there's nothing else. And then one day people will wonder how anyone lived without it, concluding that without systemd there would be no network, without systemd there would be no USB hotplugging, etc. I've seen that before, many times. |
| mrider Oct 22, 2014 12:42 PM EDT |
Quoting:If by some miracle those demigods of the Intarwebs are able to make systemd work as it encompasses everything people feel like rolling into it, then at some point I'm sure I'll use it just because there's nothing else. The way things are going, that sentence needs to be reordered: At some point I'm sure I'll use it just because there's nothing else, then if by some miracle those demigods of the Intarwebs are able to make systemd work as it encompasses everything people feel like rolling into it. The implication being that if they don't get it to work - oh well, tough noogies! |
| skelband Oct 22, 2014 1:01 PM EDT |
@me1010: "Linux == large monolithic kernel with it's 'fingers and hooks' into every aspect of the system. Heck! It even replaces lower level system BIOS functions when it doesn't like them. How's that for scope creep?" It is monolithic within itself. The kernel is messy because interacting with hardware is a messy business. However, interestingly, there is no complex mutual binary linkage with my program. The interaction between the program and kernel is through a small set of POSIX primitives, a portable, abstract, standard API which other systems support, including Windows with the assistance of cygwin. It is entirely independent of the underlying operating system itself because it is sufficiently abstract. This is exactly what we want from our INIT system, or any other conceptually distinct system component. Interestingly the OS kernel is very good example of why this kind of thing to *so* important and additionally why Linus is so anal about consistency and for 99.9999% of the time, it just works. If this argument is a bit too conceptual to deal with actual practicalities, consider the difference between an integrated stereo and hi-fi components. You *could* buy an integrated stereo and it comes with certain advantages like it being tidy and compact and convenient. However, it is incredibly wasteful. If you want a bit more umph for your speakers, changing the amplifier is out of the question. You have to throw away the whole thing any buy a different system because they are so closely integrated that separate upgrade becomes impossible. Thus it will be with the Linux ecosystem. Now I'm not that naive to deny that the Linux system component infrastructure is a bit of an unholy mess. However, this kind of thing is *not* the answer. systemd is a naive solution to a well understood problem that merely needs effort, direction and the will to succeed to solve it. |
| skelband Oct 22, 2014 1:25 PM EDT |
@me1010: "....give GNU HURD a try. It's a microkernel. The hardware drivers are not integrated into the kernel as modules and don't require re-compiling when the kernel changes." I do intend to give it a go at some point. A more modular kernel sounds like a really cool idea and has certain advantages to it. But you know what? Compiling and running my Linux program will likely be extremely simple, particularly if it supports a system POSIX interface. Such is the power of standards. I hope I don't misquote the guy but I hear that Leonard Poettering hates POSIX and thinks is is a big problem. Well, that doesn't surprise me. If he thinks that an alternative is better, let him come up with a sufficiently abstract, portably implementable alternative and put it out for review and adoption to the general masses. He may find that he ends up with something that eventually everyone can agree about. How about, for example, a common system component interface that is sufficiently abstract. I understand that systemd uses DBus. Well that's a good start. But the binary execution has to encapsulate the abstract implementation as well otherwise it fails as a standard. |
| 750 Oct 22, 2014 1:40 PM EDT |
Meh, the systemd crew is itching to replace dbus with kdbus, with systemd sitting as the mediator between kdbus and "legacy" dbus. |
| BernardSwiss Oct 22, 2014 7:03 PM EDT |
skelband wrote:If this argument is a bit too conceptual to deal with actual practicalities, consider the difference between an integrated stereo and hi-fi components. You *could* buy an integrated stereo and it comes with certain advantages like it being tidy and compact and convenient. However, it is incredibly wasteful. If you want a bit more umph for your speakers, changing the amplifier is out of the question. You have to throw away the whole thing any buy a different system because they are so closely integrated that separate upgrade becomes impossible. Analogies can be tricky... but you know -- that's actually a pretty good one. |
| cr Oct 22, 2014 7:10 PM EDT |
> You have to throw away the whole thing any buy a different system because they are so closely integrated that separate upgrade becomes impossible. And, the way the various subsystems are interconnected and encased for minimization, troubleshooting the thing when something goes wrong, even with a schematic, will be not-fun. |
| JaseP Oct 23, 2014 12:17 AM EDT |
The way this systemd thing is shaking out,... We are left with one of three possible outcomes; 1) Yeah-sayers like me1010 will be right and the rest of us will just look back and just laugh & laugh about how pessimistic we were not to trust Poettering and crew, especially considering the bang-up job he and his have done with Pulse Audio. (pretty unlikely). 2) There will be a rebellion and many distros (as well as DE developers) who naively switched to systemd will switch back away from it and plead with their users about how sorry they were to trust Poettering and his gang of anarchists. (also unlikely) 3) There will be a slow realization that systemd is somewhat of a cancer that is metastasizing all over Linux, but a cancer that is inoperable/intractable,... And steps will be taken to limit the impact that Poettering and crew have over Linux, within the framework of systemd and with patches to it (maybe universal patches, maybe distro specific). (the most likely outcome) I would actually hope for #2,... but see #3 as a reasonable outcome, and (as stated above) the most likely outcome... |
| me1010 Oct 23, 2014 7:05 AM EDT |
@JaseP: There's a fourth... Just like Pulse Audio, systemd will used as the default for most distros - there will be a small but vocal number of naysayers, but for most users - the system will work just fine. most probable ~95% confidence level... aka... we found the higgs boson... wait -maybe that's gone too far. |
| jdixon Oct 23, 2014 7:52 AM EDT |
From a user perspective, your fourth option is indistinguishable from JaseP's third option, me1010. |
| me1010 Oct 23, 2014 8:27 AM EDT |
@jdixon: It is different... the first option gives an impression of everyone being happy with systemd. I don't believe this will ever be the case. The naysayers will remain naysayers, because they are *the* naysayers. And thus, option four... It's important to remember that *the* naysayers serve as a reality check. If everyone was happy, you can be sure the system is no good. However, this will probably be my last post regarding systemd anywhere - disengaging from argument. |
| Bob_Robertson Oct 23, 2014 8:33 AM EDT |
> Poettering and his gang of anarchists As an actual anarchist, I find this statement highly offensive. Anarchists are so aware of the dangers of centralized control structures that their entire philosophy is based upon the voluntary interaction of interested individuals all choosing for themselves. Poettering is not an anarchist, he's a projecting control freak in the extreme. |
| JaseP Oct 23, 2014 9:56 AM EDT |
@Bob_Robertson: I stand corrected, sir... @jdixon: Yes,... With a little bit of #1 thrown in... |
| mrider Oct 23, 2014 11:12 AM EDT |
@me1010 - r.e. your penultimate post: First off, I see that you don't wish to continue to post. I respect that. I apologize if it seems like I'm trying to drag you back in. That is not my intention. I just want to make a counterpoint to what you say... I nothing "against" Pulse Audio, it just doesn't work on my computer. Maybe if I were smarter or more experienced I could make it work. But I can't. I spent two days trying to get sound and I finally threw up my hands. Fortunately I was able to do a simple purge of Pulse Audio and install of Alsa after which I got sound. Maybe it doesn't work as well as Pulse would if it worked, but at least sound comes out of the speakers. The way it's going, SystemD will sink its tentacles so deep into GNU/Linux such that a similar issue with SystemD will be a deal breaker. It doesn't offend me that SystemD is being developed. New ideas are always welcome. The problem is that the current path those folks are on is such that soon SystemD will be impossible to avoid without having such a convoluted setup as to be ridiculous. That's what I object to. |
| vainrveenr Oct 23, 2014 12:13 PM EDT |
Quoting:The way this systemd thing is shaking out,... We are left with one of three possible outcomes; On 2), there is a current and related piece entitled 'UNIX greybeards threaten Debian fork over systemd plan', linked to at LXer via http://lxer.com/module/newswire/view/207012. This piece is also related to yet another LXer-linked piece Should Debian be forked because of systemd?, and commented upon in the thread It's not a question of. On 3), in possible attempts to keep systemd-containing distros within the fold, there are two recent and somewhat-related pieces entitled 'Debian leader says users can continue with SysVinit' and 'Avoiding systemd isn't hard', linked to at LXer via http://lxer.com/module/newswire/view/207094 and http://lxer.com/module/newswire/view/206747 respectively. There is a thread Duh? Can two "truths" be true? on the former piece, and a thread Tasksel on the latter. A commentator from the latter thread writes: Quoting:Right now, the Debian installer has check boxes for "laptop", "ssh server", and such.* Note that the LXer commenter and contributor of the recent post http://lxer.com/module/newswire/view/193304/ decidedly favors the systemd-free Slackware, and that the Slackware 'setup' installer already has extensive check boxes for packages, boot startup (LILO), and other key configuration steps. |
| me1010 Oct 23, 2014 1:20 PM EDT |
@mrider: Responding to pulseaudio... I believe pulseaudio relies on alsa for driver support. Here's an architecture diagram from wikipedia: https://upload.wikimedia.org/wikipedia/commons/0/00/Pulseaud... So, I think, saying that alsa works, but not PA may mean that there is some unconfigured or misconfigured alsa component which PA relies on... or perhaps the sound application needs the appropriate PA library support. Here's some of the text from wikipedia: "In a typical installation scenario under Linux, the user configures ALSA to use a virtual device provided by PulseAudio. Thus, applications using ALSA will output sound to PulseAudio, which then uses ALSA itself to access the real sound card. PulseAudio also provides its own native interface to applications that want to support PulseAudio directly, as well as a legacy interface for ESD applications, making it suitable as a drop-in replacement for ESD." https://en.wikipedia.org/wiki/PulseAudio *** And, as always, Arch has the most amazing documentation: https://wiki.archlinux.org/index.php/PulseAudio |
| 750 Oct 23, 2014 1:25 PM EDT |
Or simply that PA foobars something between program and Alsa... PA is after all not just a passive passthrough. It does all kinds of conversions before handing the bitstream off to Alsa. And i think this was what Datenwolf wanted to point out, but never got round to thanks to heckling from a certain developer. Without developer insight into the inner workings of each layer, it is a pain in the behind to try and figure out where in the layercake of daemons and libs is the actual error. End result is that you go around blind, toggeling options and wiggeling cables until something happens. A process more commonly attributed to Windows than Linux of old. |
| mrider Oct 23, 2014 1:28 PM EDT |
@me1010 - (drifting a little off topic here - sorry). Thanks for that. It'll be a while before I have to go digging into sound again, but I'll capture those links for posterity. I like the thought that there was some unconfigured or misconfigured Alsa component. That sounds likely, considering how I installed my current system. Typically I install Debian by using one of the minimal disks (net install is it??). I use this disk with Ethernet disconnected so that I get a genuinely minimal system. Then I go in and edit the repository list by hand and start adding what I need. I've been doing this for years, but it wouldn't surprise me if I did something wrong in that process that caused my Pulse problems. Thanks for the pointers!! |
| me1010 Oct 23, 2014 1:46 PM EDT |
@mrider: For Debian install, I usually do the following: Pull a boot image from here: http://ftp.nl.debian.org/debian/dists/wheezy/main/installer-... Then: Copy boot image to USB media: sudo zcat boot.img.gz > /dev/sdc Pull install iso from here: http://cdimage.debian.org/debian-cd/7.7.0/amd64/iso-cd/ Copy the *.iso onto the USB media... Reboot machine with USB... And away we go. I always have the machine hooked to the internet, so I get the latest packages as well as security updates. If you want a minimal install, just select the base system. You'll get nothing but text interface. I've never really had much success in hand selecting packages via dselect... always forget something necessary. If you're looking for a good minimalist Debian derivative, give Crunchbang a try: http://crunchbang.org/ |
| Bob_Robertson Oct 23, 2014 2:00 PM EDT |
Because Microsoft's Skype requires Pulse Audio, I installed it. Things immediately broke. The USB headset which had always worked with Skype before has ceased to do so. Nothing I do will make it work. So I use Skype on my cell phone, through the wifi. After Pulse was installed, VLC ceased to be able to use the spacebar to pause playback without ALSO clicking on the progress bar. Then, and only then, audio will start back up. There is also, since Pulse was installed, a one second gap between when I change the volume level in VLC and when the volume level changes at the speakers. |
| me1010 Oct 23, 2014 2:16 PM EDT |
@Bob_Robertson and @mrider: These are the problems encountered when ISV's try to release commercial software in a GNU/Linux world... On your system - PA seems to be broken. On my system - PA works flawlessly. This is not because I am 'smarter'. And it may even be the case if we are both running Debian 'stable'. Assigning blame to PA may not be the correct thought process. The blame for PA seeming to break sound systems may be the 'fault' of the FOSS developer working very hard to try to make a proprietary sound card work without proper drivers or architecture information -- it may be the 'fault' of the distro package maintainers not including libraries in the dependency list -- it may be the 'fault' of the system admin misconfiguring something -- it may be the 'fault' of the sound application not outputing correct information -- it may be the 'fault' of PA maintainers accidentally using spell check on source code... The problem could be anywhere... And, no, it's not necessarily a PA problem because "everything broke" when PA was installed. And this is why 'one' and only 'one' basic architecture is a really good idea. Regardless of the 'freedom and choice' flamewars. |
| mrider Oct 23, 2014 3:34 PM EDT |
@me1010 - two posts ago: I'm not necessarily looking for a genuinely thin install, I just like to start from a genuinely thin install so I have a reasonable expectation that whatever is on my computer got there because I put it there. Sort of a Gentoo version for someone too dumb/lazy to actually use Gentoo. I actually read the list of software that will be pulled in when I do an apt-get install, and if I don't like the dependencies to a sufficient degree, I skip the install. @me1010 - last post: "Blame" is not the point of my post. Again, I have no objections regarding Pulse Audio, I just couldn't make it work. That's why I'm glad there is a pathway that leads to "sound comes out of the speakers" - which in my case meant not using Pulse. I'll freely admit that the problem I had was probably self-inflicted. Doesn't change the fact that I currently have sound where I didn't with P.A. Quoting:The problem could be anywhere... And, no, it's not necessarily a PA problem because "everything broke" when PA was installed. I would take the exact opposite position, that having choices is good. Because literally, if one thing won't work, one can try another. That won't work too well if there are no choices at all. Additionally, nobody is telling you that you can't choose what you want (r.e. Pulse or SystemD). And yet plenty of people are telling me that me being able to skip Pulse or S.D. is bad for me. Again me1010, I'm sorry I dragged you back into this. It was not my intention. This is my last post in this thread unless the conversation takes a different turn. I feel as if I'm steering the conversation to places where it shouldn't be, and I don't want to do that. [EDIT] Found a "to" versus "too" issue. |
| me1010 Oct 23, 2014 4:13 PM EDT |
@mrider: I suppose there are several ways to look at 'choice' as it refers to an OS. The user view: Choice A doesn't work, but choice B works fine. So 'choice' is good. The hardware vendor view: We don't have enough resources to program for possible user choice A and B. So we are going to choose A. And 'choice' is bad. The software vendor view: We've designed and built an interface with choice C. However, choice C is no longer installable in target system because it has been replaced by a combination of choice A, B, with a little of D. And 'choice' is bad. The moral of these: If the user wants hardware vendors and software vendors to play 'nice' on user's machine - then 'choice' must be limited. Notice the complete lack of references to freedom or free or free software or view source code or modify source code or discard POSIX or anything other than referring to settling on a single common solution. This is the important point... If there was only one solution for sound, then it would work on your system. If it didn't work on your system, you would be sure that the bug report you filled in that indicates that your system doesn't have sound - would be taken seriously as a fault or issue related to the single particular sound solution. The bug couldn't relate to another solution, because no other solution exists. Also, since a single solution for sound existed, the hardware vendor would be much more easily 'cowed' into providing a correct proprietary driver - if the vendor wasn't willing to provide source code. There's a theory "out there" that desktop GNU/Linux hasn't been the top 'choice' of OS install because of the "chicken-egg" problem... meaning no ISV solutions so no users and no users means no ISV solutions. It seems to me that there is no "chicken-egg" problem. The problem is really the massive variable environments that is the GNU/Linux desktop landscape. Remove the massive variability between distros, possible architectures, possible hooks for system resources -- and viola! both ISV's and hardware vendors will gladly develop native GNU/Linux desktop solutions. Of course, this doesn't solve your immediate sound problems. My suggestion there is to try several 'live-cds' from different distros. One of them is bound to function... however, it's this "bound to function" variability that is the real culprit... "Choice" is a really good thing when a user wishes to "choose" a text editor, a spreadsheet program, or a general user space application... However, "choice" can also lead to a horrible mess of incompatibility when applied to the underlying OS framework. |
| flufferbeer Oct 23, 2014 5:19 PM EDT |
@mrider, >> I would take the exact opposite position, that having choices is good. Because literally, if one thing won't work, one can try another. That won't work too well if there are no choices at all. Additionally, nobody is telling you that you can't choose what you want (r.e. Pulse or SystemD). And yet plenty of people are telling me that me being able to skip Pulse or S.D. is bad for me. I agree, and agree regardless of your typical one-size-fits-all flamewar argument that 'one' and only 'one' basic architecture is a really good idea. At least having an additional fork of a particular project presents pressure on the competition to GET WITH IT or else possibly die out due to lack of usage. Such as having Alsa instead of getting stuck with just Pulse. Or having sysvinit, upstart, uselessd, and others around instead of being stuck with just systemd. I'm sure we can all think of plenty of other projects where having multiple choice is clearly a VERY DESIRABLE thing!! 2 more c's |
| vainrveenr Oct 25, 2014 1:07 PM EDT |
Quoting:I agree, and agree regardless of your typical one-size-fits-all flamewar argument that 'one' and only 'one' basic architecture is a really good idea. This snippet from the uselessd developer's 'ProSystemdAntiSystemd' piece, found at http://uselessd.darknedgy.net/ProSystemdAntiSystemd/, also touches upon the above "choice" argument: Quoting:it’s about choice(Source again is http://uselessd.darknedgy.net/ProSystemdAntiSystemd/) Indeed, the remainder of the uselessd developers's piece may be most insightful in understanding how systemd will increasingly incorporate more features dependent upon it -- and how its opponents will continue to resist it -- despite systemd being labelled as a nefarious EEE project. |
| 750 Oct 25, 2014 1:48 PM EDT |
Found some comments by Ts'o on G+ that was made a month ago. He raises the issue of backwards compatiblity. And i think perhaps this is the sticking point of many a person when they talk about monolithic etc. [url=https://plus.google.com/u/0/ StevenVaughanNichols/posts/7aU9EKgbTot]https://plus.google.com/u/0/ StevenVaughanNichols/posts/7aU9...[/url] Basically, things like Logind replaces Consolekit but do not provide any kind of backwards compatibility with consolekit in the APIs etc that it provides. Thus there is no seamless transition between the two. Nor can someone choose to stay with Consolekit and continue to update the stuff above, because the stuff has moved to Logind as the only option. This in contrast to how they do it in the kernel. From the horses mouth: "In the kernel, we have very strong requirements not to break backwards compatibility. We're not going to change the semantics of say, the wait() system call, and expect everyone to change to keep up. Instead, we've intrdoced wait3(), wait4(), waitpid(), etc. So a statically linked executable (that doesn't have GNOME dependencies --P) that was compiled 10-15 years ago will likely still run on a modern Linux kernel." See how they do it? Even tho the old interface have been tagged depreciated, and devs should avoid using it, they still keep it around. This to allow users etc to run software that they rely on without disruption. |
| theBeez Oct 25, 2014 3:47 PM EDT |
me1010 is your typical systemd troll. They emerge everywhere where a PR problem is suspected, spreading lies and harassing users and sysops. Fun part is that when they write a blog they complain about "the rudeness" of systemd opponents. The bare truth is: it's quite the opposite. Some maintainers of certain distributions are even publicly silent of being "a non-systemd distro", admitting they're afraid of what is called "systemd minions". |
| Ridcully Oct 26, 2014 3:31 AM EDT |
Thanks Beez. :-) |
| kikinovak Oct 26, 2014 9:11 AM EDT |
http://www.microlinux.fr/download/systemd.jpg |
| me1010 Oct 26, 2014 10:43 AM EDT |
@theBeez: OK. Take the bet... http://lxer.com/module/forums/t/35629/ So, far no takers... If no interest by December 15th, I'll donate the $150.00 anyway. I suppose that's how us trolls work our PR magic. |
| JaseP Oct 26, 2014 10:45 AM EDT |
@kikinovak Classic! |
| mrider Oct 26, 2014 11:31 AM EDT |
Okay, I said I wasn't coming back, and yet I just can't let this pass... What we're saying: SystemD may or may not be the correct solution, but all logic aside we're going to get it anyway because the SystemD programmers don't give a spit what we think. What you're saying: SystemD is going to be the default init system. Well no SPIT it's going to be the default system - the programmers don't give a darn what the people in the trenches actually want! To quote Jeff Goldblum - "Yeah, yeah, but your scientists were so preoccupied with whether or not they could that they didn't stop to think if they should." |
| theBeez Oct 26, 2014 12:30 PM EDT |
@me1010 One pawn is sacrificing himself for the good cause of public opinion, while the king keeps moving. Impressive. If you'd have said "the systemd community is listening to criticism" it would have been a much more credible bet. This is too childish for words. Red Hat has put its (political) weight in it for the sake of project Atomic and there is no way to stop this Behemoth - you know it and I know it. It has nothing to do with "acceptance". |
| jdixon Oct 26, 2014 6:27 PM EDT |
> Red Hat has put its (political) weight in it for the sake of project Atomic and there is no way to stop this Behemoth... Sure there is. Abandon Gnome and all it's paraphernalia as being a lost cause. Fork anything outside them that develops a systemd dependency. Would it be easy? No. Is it possible? Yes. |
| Ridcully Oct 26, 2014 6:31 PM EDT |
I wasn't going to join in, but as a biologist with knowledge of plant diseases, I may have a concept to contribute. One of the worst possible situations you can have when trying to prevent a disease spreading, is a monoculture.....ie a crop that is not only the same species but is also the exact same gene base in every plant. It's why plant breeders are constantly trying to vary the gene base, or add new genes from wild stock or even manipulate the DNA by introducing non-host genes as in GM situations. A huge crop area of a monoculture is just like putting up a sign which says to the relevant disease: FREE LUNCH !! Okay..... You prevent this by interspersing crops, rotating them, having different genetic varieties etc. etc. BUT, all of this means you break the monoculture concept and it is this aspect that gives resistance against disease encroachment. In other words, variety is strength not weakness and this, I think, is the underlying problem with systemd which (whether deliberately or not is irrelevant) will produce a monoculture within the Linux kernel area. Some may think this is a good idea; I don't. Many years ago, I used to think, for instance, that Linux would be better with a single desktop manager. But now, perish the thought - in variety there is strength, innovation, choice, resistance to problems (trojans, viruses, etc.), novel ways of doing things. And there, in a nutshell (sorry about that pun) is a biologist's take on what is happening. Monocultures are very dangerous in an ecosytem, such as Linux, that thrives on variety.....My wish would be to see that variety remains and very strongly so, especially in such an important area as initialising the entire operating system. But then, I'm not a programmer - I'm just a user and a biologist.......what would I know ?? |
| gus3 Oct 26, 2014 7:46 PM EDT |
@Ridcully, you perfectly describe the Windows monoculture. |
| Ridcully Oct 27, 2014 1:29 AM EDT |
Yes, Gus3, I know - I think any "true blue Linux user" is aware of that fact........and so is Redmond, and it's why their software resembles a sieve with respect to security. However, in my opinion, the real question is: Do we want Linux to take the first steps towards the monoculture that is Windows ? And that is the question that at least some of the contributors to this thread cannot (or will not) acknowledge - or will find ways to prove that what I have said is utter piffle. But, that's their right. "Shoot the messenger" is a long recognised way of destroying logical opposition. |
| penguinist Oct 27, 2014 6:51 AM EDT |
Ridcully: Great insights! +1 Your analogy between the evolution of biological species and the evolution of an operating system is spot on target. So the original Linux concept where we have decomposed the OS into tiny pieces each doing one job very well allows each piece to be robust, be improved, and to survive. One big monolithic block will not be touched so much (except by the few in the inner circle), and in the long term that "species" must fail. It seems clear to me now that we must continue with a decoupled system if we want Linux to remain robust, and we must resist attempts to create monocultures in our OS. |
| Ridcully Oct 27, 2014 7:50 AM EDT |
Thanks Penguinist......you've put the concepts I have into the context of a software system very nicely - and far better than I could have done. As Gus3 implied, the monolithic "untouchable" block of Windows binary represents the worst extreme of the "OS monoculture" and it was made that way deliberately with the concept of marketing a product that only the "inner circle" of the Microsoft empire could manipulate - and therefore could control to maximise profit. In my opinion, the open source and modular approach of Linux with each piece doing a job and doing it very, very well is a far superior way of programming. From what I am seeing, the developers of systemd are now attempting to make systemd combine and usurp the functions of a number of those smaller Linux modules. Is this a good thing ? My personal opinion is that it is not and for the reasons you and I have just stated. |
| me1010 Oct 27, 2014 10:35 AM EDT |
@Ridcully: Strawman argument... and wrong... I think you've forgotten that most of Microsoft's profits come from licensing of Microsoft Office. The OS is not that profitable. The reason why Microsoft still sells an OS is to provide a suitable platform on which to graft its actual profit making packages... And MS Office is popular largely because of the vendor lock-in due exclusively to the file format -- which has nothing at all to do with the compiled binaries that are MS Windows OS or even MS Office itself. It is this file format which has allowed MS to persist on the 'desktop' for decades. If, instead of OOXML, MS Office saved all new documents in ODF. MS Office, and Microsoft along with it, would disappear in a few short years as upper management in businesses begin to realize that the documents saved 3 or 4 years ago open just fine in competing FOSS products. The proof of the wholesale vendor lock-in of the file format is very clear when examining the case of Munich. The final breaking point was, is, and will be MS Office compatibility... which has nothing whatsoever to do with the 'monoculture' of Windows binaries. However, if desktop GNU/Linux had a non-moving target perhaps Microsoft would port its Office Suite... And that would truly be the year of Linux desktop. I'll stick with LibreOffice, but it would be great anyway. |
| gus3 Oct 27, 2014 1:07 PM EDT |
The "year of the Linux desktop" arrived years ago. It's just too bad so many haters expected it to clone some proprietary thing. My Raspberry Pi can run a Linux desktop. My netbook has a full-on Slackware Linux installation, and can run a desktop GUI on Linux. My mother's desktop system runs Linux. I've used Linux on the desktop, full-time, since April 1998. No Windows, no Mac. Not even Solaris. Linux. Nothing but Linux. Stop blathering about how deficient Linux is for running a "desktop." And don't bother trying to re-define "desktop" to suit your purposes. Linux-based desktops have been more stable, more robust, and more secure than Microsoft has ever been. And before you try to point to how secure MacOS is, let me point out that the first time I ever saw an anti-virus product for a computer (and thereby learned what a computer virus was) was on a Macintosh. MacOS gained security by adopting BSD on Mach. Yeah, MacOS X runs on Unix. Linux was ready for the desktop before BillG and Steve Jobs knew what hit them. |
| me1010 Oct 27, 2014 2:25 PM EDT |
@gus3: No... The year of the Linux Desktop arrived for you a long time ago. It arrived for me around the same time... and to be honest, those first years were really painful -- Star Office was a real dog on the 486 laptop I had... However, there are very few businesses running Desktop GNU/Linux... and this is largely due to MS Office. I don't like it anymore than anyone else in the FOSS world -- it's just reality. ** And, Android is Linux -- but not entirely FOSS -- So, it doesn't count... In my mind, if the OS doesn't have a repo-ed version of SSH, CUPS, and vi, and openbox installable without a tracked user account -- it's not a Linux Desktop. |
| NoDough Oct 27, 2014 3:16 PM EDT |
>> However, there are very few businesses running Desktop GNU/Linux... and this is largely due to MS Office. Nope. MS Office is a factor, but not the deciding factor. It's the vertical market apps that are the real problem. My employer runs AutoCAD and RevIt. (Windows only.) My employer runs specialized ERP for construction. (Windows only.) My employer runs construction estimating software. (Windows only.) My employer runs manufacturing floor automation. (Windows only.) My employer runs specialized PDF software. (Windows only.) My employer runs specialized construction document software. (Windows only.) I've been communicating the advantages of FOSS in general and Linux in particular to my boss for years. He would switch in a second if he could and MS Office does not prevent that. |
| Koriel Oct 27, 2014 4:13 PM EDT |
MS-Office is the least of the problems, my ex-boss asked me if I could get the company switched over to Linux, I simply shook my head and told him their would be just too many issues. First issue being Autocad (Windows only) as mentioned above, second being iFix Scada Development (Windows only), then our own built comms software which would require a re-write plus a whole bunch of other stuff. Office is lucky if it makes it in at the bottom of the list as it would of been the easiest thing to solve. MS-Office would certainly not prevent the switch, its the load of other windows only stuff that are the bigger issues. |
| Steven_Rosenber Oct 27, 2014 4:15 PM EDT |
Now that so many applications are web-based, it should be easier than ever to run desktops in Linux. |
| Ridcully Oct 27, 2014 4:50 PM EDT |
@me1010..two things: 1. You may consider yourself the recipient of the "Red Herring Award" for 2014. Microsoft is incidental and irrelevant and was used only as an extreme example of the monoculture monolithic format. 2. Like I said above: "Shoot the messenger" is a long recognised way of destroying logical opposition. |
| nmset Oct 27, 2014 4:51 PM EDT |
We are getting quite far from systemd and cancer ! Yet, if a company really wants to make the switch, they could get Linux installed on most desktops, and those ones requiring Windows-only apps could do this remotely from Terminal Server Edition instances through RDP. But nah... this won't ever happen ! And here we go again, you can't get rid of Windows cancer, as long as independent software editors bow the knee. Perhaps, gaming activities may boost Linux adoption on the desktop, we've seen good moves with at least Valve/Steam; I would have preferred the workplace rather than games recognizing the value of desktop Linux. |
| Ridcully Oct 27, 2014 5:07 PM EDT |
True nmset....Moreover, the proponents of each concept are now cemented in place. Ain't agonna change. It's really "watch this space" and see whether the large amount of resentment over systemd really does produce a fork that is taken up by the distributions. This thread has thrashed the topic into submission, even if the the towels haven't been thrown in yet. |
| jdixon Oct 27, 2014 9:49 PM EDT |
> However, there are very few businesses running Desktop GNU/Linux... and this is largely due to MS Office. Office has been supported by Crossover for years now. > It's the vertical market apps that are the real problem. > First issue being Autocad (Windows only) as mentioned above, second being iFix Scada Development (Windows only), then our own built comms software which would require a re-write plus a whole bunch of other stuff. Office is lucky if it makes it in at the bottom of the list as it would of been the easiest thing to solve. Yep, and yep. There's a lot of Windows only and customized software out there. Now, you can always run most of those as Citrix apps or in a virtualized environment (VMware View, etc., take you pick of the solution), but that doesn't really fix the problem, it just removes it to a more controlled environment. For some folks that's worth doing; for others it's more trouble than it's worth. > Yet, if a company really wants to make the switch, they could get Linux installed on most desktops, and those ones requiring Windows-only apps could do this remotely from Terminal Server Edition instances through RDP. That's one of the many options, yes. |
| kikinovak Oct 29, 2014 12:27 PM EDT |
> It's really "watch this space" and see whether the large amount of resentment over systemd really does produce a fork that is taken up by the distributions. Or just use one of the happy few (Slackware, Gentoo, Crux, Void) that didn't jump on the systemd bandwagon. |
| Ridcully Oct 29, 2014 3:35 PM EDT |
Apparently at least some percentage of the Debian crowd is really, really upset by systemd: http://www.linuxinsider.com/story/81262.html http://debianfork.org/#sthash.nqNF135C.dpuf I could be wrong (of course) but the feeling I get is that this is, on a smaller scale, the same sort of situation that originally developed with KDE vs Gnome "wars" even if not for precisely the same reasons. What is even more curious is that the claim made in the second url I have cited is that the push to systemd is coming from Gnome........very interesting. PS.....mind you, what I've just said has been mostly mentioned above in this gi-normous thread - it was simply that I wandered around the web this morning and noted these stories in particular; for anyone who wants them. The key to all this appears to be Poettering at Red Hat......again as stated above. |
| gus3 Oct 29, 2014 6:41 PM EDT |
To quote Dru Lavigne: "Systemd has been very good for FreeBSD." |
| 750 Oct 29, 2014 7:27 PM EDT |
@Ridcully i can agree with the "coming from Gnome" bit. I didn't really notice systemd until i bumped into the switchero from consolekit (that i don't really know why i need, but at least it can work on top of whatever init setup i am using) to logind (systemd and systemd only). While my distro of choice is not quite gentoo, i have gotten used to being able to mix and match pieces as i find the need for. The init is sequential and perhaps slower than it can be, but i can't say i am bothered (it is fast enough to login that i barely get my coffee after hitting power). Logind is just the tip of the iceberg. How about when project XYZ depends on networkd, or resolved or whatever? Now if those *ds could exist independently, or with some minimal systemd core running on top of something else (various systemd-as-process-manager alternatives can happily live either on top of another init or be init) i dunno if people would be so up in arms. Then they could drop systemd in on top, test it, and maybe later flip the switch and go systemd as init (or just live with systemd-as-process-manager). But the whole thing quacks like a variation of Embrace, Extend, Extinguish. One example i just bumped into on G+ was that systemd can do boot graphs to indicate speed bumps. Curious thing is that it seems to be based on a earlier project with the same purpose. But while the earlier project was able to work with many similar systems this one can only be used with systemd. Damn it, Microsoft ended up in court over similar behavior with Windows. Just because there is not a economic incentive with systemd does not make the practice any more socially acceptable. |
| Ridcully Oct 29, 2014 8:26 PM EDT |
@750.......Thanks for your info. "My Linux friend" and I have been discussing the matter this morning via emails and something else emerged which is pure hypothesis....and I mean that sincerely because we have no evidence for it other than very circumstantial data. However, when you look at it all, there are some jigsaw bits. First Poettering is the driver for systemd and is in Red Hat. Second Gnome is (as far as I am aware) the default window manager for both Fedora and Red Hat. Surprise, surprise, Gnome is now pushing systemd. SUSE has also taken up systemd. But even more surprisingly, Debian is now on the systemd bandwagon and is creating considerable angst in its developers and users who are getting serious about forking that distribution. So both my friend and I wondered: Is this a drive by the Red Hat stable to usurp initialisation controls for Linux to the extent that by attrition, Red Hat forces the "Linux community" onto systemd and thereby allows Red Hat to dominate and control the direction Linux takes. Red Hat would do this by making systemd control more and more of routines that were previously handled by other modules. Ultimately, to not use systemd would break the relevant Linux distribution unless you knew exactly what you were doing. It would fit in very nicely with your concept of the Windows technique of "Embrace, Extend, Extinguish" and would mean that Red Hat would then be free to force its concepts onto the wider FOSS community. I repeat, we have no evidence other than what you have read above. For the average single user, I don't think systemd matters very much at all......but for the server/network administration areas, where Red Hat makes its money and is trying to expand and dominate, it matters very much indeed. Yeah, I know, a conspiracy theory......but systemd from all I have seen so far, simply doesn't "taste right" and one begins to wonder why Poettering has done this. It is beginning to have the odour of Microsoft ethics and techniques. |
| jdixon Oct 29, 2014 8:40 PM EDT |
> Is this a drive by the Red Hat stable to usurp initialisation controls for Linux to the extent that by attrition, Red Hat forces the "Linux community" onto systemd and thereby allows Red Hat to dominate and control the direction Linux takes. I don't think so. Red Hat already has a great degree of influence in the direction Linux takes, simply because they have so many developers working on it. I think it's just a case of them flexing their muscles. Or, to use a perhaps apropos phrase, they've sneezed and the rest of the Linux world has come down with a cold. Not that their motives matter much when the effects can be so severe. |
| Ridcully Oct 29, 2014 9:19 PM EDT |
Thanks Jdixon......like I said: pure hypothesis, but it still doesn't "taste right". And I agree with the idea that Red Hat has a great degree of influence in the direction Linux takes. I still wonder if they have thought this new direction through. The warning bells have now been going off for some time....but then, can even Red Hat control its programmers ? It's again the old situation of programmers programming to their satisfaction, and the users' dissatisfaction. We never learn from history, and heaven knows there's plenty of examples of programmers ignoring their user bases. |
| caitlyn Nov 03, 2014 11:45 PM EDT |
I've read the entire thread which is a very interesting discussion to say the least. Until theBeez jumped into ad hominem attack land it was entirely respectful and on topic, which is a refreshing change from so many of the FOSS discussions I read where there are sharp disagreements. If someone steps back and tries to form an objective opinion there are a lot of good arguments both for and against systemd here. I've been a supporter, and it's largely because of what me1010 describes early in the thread: it's much easier to administer and maintain, particularly in large and complex enterprise environments. Most of the well reasoned arguments against (and there are a number of them in this thread) don't question the functionality, particularly in regards to the initialization and boot process. Most don't question the usability issue. The counter arguments come down to: 1. *nix philosophy (which systemd does not adhere to) 2. Interdependency issues (probably the best counter argument). This is where the cancer analogy fits, where systemd is required for more and more apps which seem to be unrelated to the original purpose of systemd. Cancer is, of course, a pejorative term. Mission creep is another way to describe it. 3. Backwards compatibility - or really the lack thereof. Try and install the 32-bit build of Springdale Linux (RHEL 7 clone) and see how far you get. Most people can't even get the installer to run. That may seem like a trivial example but it demonstrates very quickly just how broken backwards compatibility is in short order. 4. Dislike of Lennart Poettering and/or Red Hat. Some of this is based on Poettering's other projects (Pulse Audio) while part of it falls back on #1, and the final part is dislike/distrust of anything large and corporate. #1 and #4 involve a lot of emotional arguments and anecdotal personal experience. I don't discard those arguments, but they are certainly less convincing. #2 and #3 represent real problems. While systemd may seem easier when looking at systems holistically as a system administrator, it certainly makes things more complex for developers trying to understand all the bits and pieces that systemd hooks into. As already noted, it also can make troubleshooting when things go seriously wrong in an unexpected way much more difficult. The need to use strace was a good example. It may take less knowledge to administer properly working systems but a systems administrator or devops engineer really earns his or her keep when they solve problems. How will those less skilled admins me1010 refers to manage under adverse conditions? At least it may keep some older, more experienced consultants like me busy :) RHEL 7 made clear how little Red Hat cares about supporting legacy systems. Up until recently most of my work was in small businesses and the occasional non-profit. These are folks who budget very tightly and count pennies. When hardware and/or software gets refreshed they don't throw out an old server that still works. They look at how they can repurpose it. Suddenly, if it's 32-bit, they can't. The just use RHEL 6.x argument doesn't fly when the hardware is perfectly capable of performing a task but the libraries and dependencies in 6.x are just too old to run the required code. Of course, that won't bother their large enterprise customers so Red Hat made a bottom line decision. I see a slightly different likely outcome than what's been presented here. This is where I see it all going: The big distros: Red Hat, SUSE, Debian and Ubuntu, have all decided to go with systemd. Debian may implement a way of using an alternative, but as dependencies on systemd grow that will be less and less practical if you want to use a lot of the larger and more popular applications. Commercial, proprietary apps will be built for the big distros as always. Businesses need such apps and sometimes individuals will need or want them as well. The Debian fork is pretty much inevitable, just as MATE and Trinity were inevitable when the two most popular desktop environments headed off in directions that a lot of people didn't like. That's the nature of FOSS and the fork is a healthy development. In addition, some smaller distros, particularly those aimed at users who get under the hood of their systems, will be developed without systemd. CRUX is an example of a distro that can hold out indefinitely. Slackware is a more interesting case simply because it tries to fill a somewhat larger niche. There probably will be a new batch of lightweight distros designed to work on older, legacy hardware that simply won't be able to run the big distros anymore. Some of the systems that need a systemd free design aren't all that old. systemd will become a dominant paradigm in Linux systems, for better or for worse. All the wailing and moaning and gnashing of teeth won't change that. systemd was designed based on the needs and wants of enterprise customers, not the "community", whatever that is these days. Red Hat does most certainly take input, criticism and make adjustments based on feedback, but it's the feedback of their largest customers that counts. They are a for profit business and while they have continued to adhere to the letter of OpenS ource philosophy and give back to the larger community in a big way, they do so based on their business interests first. Some see that as evil. I don't, but considering who I'm working for now it's obvious where my bread is buttered. |
| JaseP Nov 04, 2014 1:33 AM EDT |
@caitlin; You're mis-stating/under-stating some of the arguments, particularly against Poettering. With regards to Poettering (&/or Sievers), it isn't that he's a young, know-it-all punk (which he is), it's that he and his team have demonstrated a sincere lack of responsibility when developing (like the whole kernel debug thing which caused Torvalds to blow up at Sievers, in the first place). Taken together with the mission creep, and what you have are the ingredients for a disaster. What you have is a sprawling mess, like which occurred with PulseAudio, but with its tendrils wrapped into and through the whole OS. That's different from not liking Poettering. Your points about older hardware are well taken. However, keep in mind that RedHat isn't a cutting edge distro,... The kernel is a patched 2.6 kernel, after all... Those who want to run something truly modern, are going to go with Debian, or SuSE, or even (gasp!) Ubuntu. Packages can be built on just about anything though (as long as the build environment & language supports it,... but that's usually just a PPA away). But the interdependence with systemd is going to severely limit choices (without systemd??? ... want Gnome,... sorry, Out! KDE? Yeah, probably that's out too... XFCE? OK, but watch your GTK+ version, cause it might not play nice...). So, it isn't just a philosophical argument about what systemd represents (although, that matters). It's about having to trust a piece of untested code from punk developers that has itself wrapped into everything, ... And that seriously limits what you can do (or what you can do it on). ... And if you're the tinkering type... Like to play with your system and configure it "just so???" ... Let me introduce you to an architecture called "ARM..." (Good thing it's cheaper, too!) ... 'cause it's the only place you'll have left ... |
| CFWhitman Nov 04, 2014 10:13 AM EDT |
The problems with interdependency issues and backwards compatibility spring from ignoring the Unix philosophy. I think the dislike is mostly for Poettering's attitude about software development, and that becomes dislike for him because that's the only contact people have with him. His attitude about development also contributes to some of the problems with systemd. I'm not going to pretend to be able to predict the future, but I think some of the problems with systemd are too big for it just to keep going the way it is to the point of becoming dominant. I think we will either see significantly scaled back implementations of systemd (that is implementations that stick more to just init; possibly a fork of systemd) or a significant uptake of an alternative init system either in current distributions or new ones. SUSE has already scaled back their implementation of systemd. We haven't seen how the systemd controversy will actually shake out for Debian or Ubuntu yet. |
| caitlyn Nov 04, 2014 11:56 AM EDT |
@JaseP: Perhaps I understated, but I feel you are overstating and allowing personal feelings about the developers to become part of your judgment. That isn't to say I fully disagree with you. I don't. FWIW, the 2.6 kernel was last used in Red Hat 6.x. That isn't the case with 7.0 which is the first version to use systemd. RHEL 7.0 may not be cutting edge, but when a new major version of RHEL ships it's not far behind at all, and that is the case here. Also, FWIW, enterprise (large business, government, educational instutions) don't want to be "modern". They want reliability, stability and support. Most won't start considering adoption of RHEL 7 until 7.1 is released. Like it or not, those are the people driving Linux development since so many developers work for either Red Hat and SUSE. Between those two you have something like 85-90% of the enterprise market in North America and close to that in Europe. (SUSE remains very strong in Europe.) Those are the folks footing the bill. I find the idea that systemd is "untested" humorous. It has been tested in Fedora, openSUSE, etc... and now in RHEL, CentOS, Scientific Linux, etc... Most of the complaints have little to do with how it functions. It does the job. Are there bugs? Oh, heck yes. Show me one major piece of code that doesn't have bugs, particularly shortly after mass adoption. Your argument that you can't configure your system "just so" tells me you haven't worked with systemd much. The ability to configure and customized hasn't been lost. It hasn't even been reduced. You just have to do it differently. There is a definite learning curve, which is why I spent so much time with the RHEL 7 beta. I knew I had to learn to support where my customers were going. However, once you learn it that won't be your complaint. Your other complaints: mission creep, backwards comparability are very real and they are the ones that give me cause for concern as well. Let's step back from arguing philosophy and be practical about what UNIX philosophy means. With the adoption of systemd we've traded modular design for monolithic design, which makes it significantly harder to understand the code and debug it. That's a legitimate cause for concern as well. For me it's less about "systemd" doing too much. If it did all that with a modular design so that we could all get under the hood and understand the whys and hows then my objection would disappear. If it was designed that way it would actually be an assembly of related, smaller pieces of code with more limited purposes. In other words, it could do the same things, as in all of them, within a *nix design philosophy. You'll notice I'm not a blind proponent of systemd. I have given this thought. If I've oversimplified it's because my missive was too long already, not because I don't understand the issues :) The problem the opponents are facing is that the proverbial horse is not only out of the barn, but he's in the next county already. Whether we like it or not, Red Hat does have a huge influence over the direction of Linux development. When Ubuntu has tried to go in other directions it's received huge community push back and other major distros simply haven't followed their lead very often. Debian tries to be all things for all people. systemd is here and it is not going away. @CFWhitman: You offer an alternative that could happen: a scaled back or limited implementation of the core functionality. That's the middle ground, taking what is clearly positive about systemd and leaving the rest behind. Regarding backwards compatibility:, I'll point out that in order to (mostly) fix the shellshock bug the bash developers broke backwards compatibility as well. I don't think that can be put down entirely to the development design. Any time you introduce something new and very different something will break. The problem I see is the cavalier attitude of Red Hat (which may come from Poettering or may be more pervasive) towards all that's come before, including older hardware and legacy code. I suspect a lot of older apps are broken by systemd as well though I have no concrete data to back that up. Again, I'm not a blind supporter. I see problems, but I am stripping away the emotional and philosophical arguments which have no weight outside the "community". I'm also not in the business of predicting the future. systemd is already dominant in the distros that matter to business, and for better or worse those are the only distros that really have influence. Linux hasn't truly been a "community" project in quite some time. Those who push *BSD as an alternative have a point. This is the price or "world domination". |
| gus3 Nov 04, 2014 2:36 PM EDT |
@caitlyn, while I have my own concerns about systemd (being counter to the *nix philosophy), none of them have to do with Poettering personally. But if I did have such concerns, they would be over his past record of shoddy workmanship, PulseAudio being Exhibit A. Trust lost is very hard to regain; he needs to regain that trust before being allowed to mess with such a critical part of the system. And I think Red Hat, Debian, Ubuntu, and SuSE are foolish for allowing themselves to be guinea pigs. |
| 750 Nov 04, 2014 3:51 PM EDT |
Err yeah, tested. Like how how a recent update from fedora 20 to 21 (alpha, but still) ended up getting bitten by a new "feature" in systemd that shuts down the computer forcibly if any service takes longer than 15 minutes to complete. sure, it may be a config oops on part of the Fedora devs. but the scenarios for such a "feature" seems esoteric at best. As such, why is it apparently defaulting to on out of the box? Btw, i noticed that the first patch set for kdbus was introduced to the lkml the other day. And almost immediately poor documentation and head scratching programming choices are being found and pointed out. |
| flufferbeer Nov 04, 2014 3:58 PM EDT |
@gus3, >> And I think Red Hat, Debian, Ubuntu, and SuSE are foolish for allowing themselves to be guinea pigs. As I said a coupla weeks ago in a thread abt whether Debian gets forked or not 'cause of systemd, I think that many Debianistas will simply stick with their non-systemd Wheezy FAR PAST the end of the unfrozen new and "improved"(right, with ::rolling eyes::!!) Debian Jessie stable. That way they can avoid becoming "guinea pigs" for awhile way into the future. Baboontu users and fanbois, otoh, will just end up sticking to their mothership with WHATEVER init+baggage Canubecomical throws out! 2c |
| gus3 Nov 05, 2014 11:02 AM EDT |
Just posted to OSNews: Thoughts on Systemd and the Freedom to Choose (and no, I wasn't trying to rhyme it) |
| Bob_Robertson Nov 05, 2014 12:13 PM EDT |
Nice article, Gus. Thanks. |
| Steven_Rosenber Nov 05, 2014 1:35 PM EDT |
Quoting:Like how how a recent update from fedora 20 to 21 (alpha, but still) ended up getting bitten by a new "feature" in systemd that shuts down the computer forcibly if any service takes longer than 15 minutes to complete. A fix is in for this issue: http://lwn.net/Articles/619202/ Fedora gets to these things rather quickly. |
| Steven_Rosenber Nov 05, 2014 1:39 PM EDT |
If SystemD is that big of a deal, there won't be just one fork, and all of these init/management systems can duke it out. What this controversy should do is shine a light on systems that don't use SystemD, like Slackware in the Linux realm and all of the BSDs. |
| gus3 Nov 05, 2014 1:42 PM EDT |
Yup. See the above quote from Dru Lavigne. |
| caitlyn Nov 05, 2014 2:00 PM EDT |
While I respect Jesse, his conclusion in the article @gus3 linked is simply false. systemd will not be the only available init system for Debian. See: http://www.itwire.com/business-it-news/open-source/65684-deb... I have no problem with reasoned debate. I have every problem with FUD, which is what Jesse's article is. Could feature creep make using another init system impractical in time? Perhaps, for users of specific apps. As one commenter on OS News pointed out, there will always be outlying distros that make other choices. |
| gus3 Nov 05, 2014 3:08 PM EDT |
Quoting from the ITWire article:Quoting:For people wanting to use sysvinit or upstart as PID 1, there is a package (systemd-shim) that works as an emulation layer between systemd components like systemd-logind and an alternate init system: GNOME/XFCE talks to systemd-logind, which talks to systemd-shim (instead of systemd). So, according to this, the systemd components still have to be there, even if PID 1 isn't systemd. If anything, more components have to be put in place. Suddenly, the title of this thread doesn't come across at all like hyperbole. "Cancer"? Maybe, maybe not. But definitely an "unusual growth." |
| mrider Nov 05, 2014 3:30 PM EDT |
In my mind, the bottom line is this: 1) Is SystemD ready for prime time? Yes, no, and or maybe, depending on who you talk to. 2) Can I have a system where SystemD is the only init system? Yes. 3) Can I have a system where SystemD is not the init system? Yes (with some work). 4) Can I have a system where SystemD is not present at all? For now yes, soon - probably not. At least not in Gnu/Linux. We don't really know how long Slackware will hold out. Anybody see a problem when looking at the answers for #1 and #4? |
| jdixon Nov 05, 2014 6:31 PM EDT |
> Is SystemD ready for prime time? For Red Hat's purposes, I'd say it is. For the general public, probably not. > Can I have a system where SystemD is not present at all? For now yes, soon - probably not. At least not in Gnu/Linux. We don't really know how long Slackware will hold out. That is the problem. Slackware doesn't have the number of people needed to maintain a fork. If the main libraries or something critical become dependent on systemd, they'll have to move to it. Unless a number of secondary distro's decide to band together to support a complete fork, I'd say it's only a matter of time. |
| gus3 Nov 05, 2014 6:37 PM EDT |
And now, more than ever: When you learn Red Hat, you know Red Hat. When you learn Debian, you know Debian. When you learn Slackware, you know Unix. The day Pat V. switches to systemd is the day I install one of the BSD's. And I doubt I'm the only one. |
| JaseP Nov 05, 2014 7:11 PM EDT |
Quoting: That is the problem. Slackware doesn't have the number of people needed to maintain a fork. Not just Slack, but just about every distro is in this boat (least all but a small handful). Systemd is pervasive/invasive. It will be very soon that you cannot get around it... Other than to switch to one of the BSDs. Even on ARM it seems that it will be the dominant force. With regards to the BSDs, it's incompatible (too many Linux specific system calls). So with the BSDs,... you're "safe." If you switch to the BSDs, though, you're giving up having a up to date development on drivers, a lack of certain software (unless using FreeBSD's software compatibility layer with Linux, for example). For server use, FreeBSD may be a strong option. For desktop use??? Not so much. Forget about exotic hardware with BSD, and forget about having Chrome (vs Chromium) for things like Netflix or Hulu, or what have you... But maybe enough people will jump ship to BSD to push BSD development to a new level... I've (begrudgingly) come to the conclusion that if you want a "modern" desktop experience with an Open Source OS, then you are going to have to be using systemd (at the very least in a hamstrung mode), unfortunately. I can only hope that, as with PulseAudio, most of the annoying bugs and problems can be ironed out before it is force-fed to us... PS: Oh,... and someone has really got to neuter Poettering, lest he gets his grubby little punk hands on some other important piece of the FOSS software stack... |
| mrider Nov 05, 2014 7:23 PM EDT |
Quoting:If you switch to the BSDs, though, you're giving up having a up to date development on drivers, a lack of certain software (unless using FreeBSD's software compatibility layer with Linux, for example). For server use, FreeBSD may be a strong option. For desktop use??? Not so much. Forget about exotic hardware with BSD, and forget about having Chrome (vs Chromium) for things like Netflix or Hulu, or what have you... But maybe enough people will jump ship to BSD to push BSD development to a new level... Not to mention all the upstream code that is starting to have SystemD dependencies are going to stop working on the BSD versions. Pretty soon it's going to be forget about having Gnome on BSD. Forget about having Gimp on BSD. Forget about having ... on BSD. |
| jdixon Nov 05, 2014 7:36 PM EDT |
> Pretty soon it's going to be forget about having Gnome on BSD. Forget about having Gimp on BSD. Forget about having ... on BSD. Pretty much forget about anything Red Hat touches. And that's a problem. |
| JaseP Nov 05, 2014 8:24 PM EDT |
I just took a look at both FreeBSD and PC-BSD. PC-BSD is a very polished looking distribution based on FreeBSD, with a nice graphical installer and "out-of-box" support for most of the major DEs (Gnome2, KDE, XFCE,...). FreeBSD's Linux compatibility layer means being able to run many of the Linux binaries without modification straight from FreeBSD or PC-BSD. Of course, anything that requires GTK+ 3.X is going to be a problem, as will any other software that has a dependency on systemd... |
| Bob_Robertson Nov 06, 2014 10:02 AM EDT |
And here we have the crux of the matter: Even if systemd worked perfectly, just the growing dependencies are a disaster. And it doesn't work perfectly, either. |
| number6x Nov 06, 2014 11:26 AM EDT |
The systemd debate, as I see it... The proponents claim the benefits of systemd are: It's new and the current init solution is outdated It has many new features It replaces old static text based logs and configurations with binary versions It runs as a binary with pluggable modules It integrates well with Red Hat's virtualization technology It boots really fast And the opponents of systemd claim: It's too new and not as stable as the current mature init solution It has many new features (leading to complexity and increasing the chance of more problems (KISS principle)) It replaces old static text based logs and configurations with binary versions (which adds complexity without real benefit) It runs as a binary with pluggable modules (instead of reducing complexity and dependencies) SysV init works just fine with Red Hat's virtualization technology, not everything needs to be integrated. I boot once a decade and want it to work and not crash during boot Pretty much whatever one side seems to think is a benefit the other side sees as a drawback. They both have good reasons for thinking the way they do. I'm not a sys admin, so I don't really think systemd will affect my use much (except for bugs in young software). I don't see any substantial benefits to the end user. I do see drawbacks during the early years. I can understand a cutting edge test distribution like Fedora using it. Fedora is not meant for real world use, but as a test bed to try crazy things with. I certainly understand the outcry from the debian community. I could see debian doing a systemd spin for a few years, but mainstreaming it seems counter to the purpose of core debian. Give the software some time to mature first. |
| gus3 Nov 06, 2014 7:04 PM EDT |
When GNOME tried to turn my desktop into a tablet, I left it. So did many others. That invigorated XFCE, KDE, LXDE.... The same will happen for the BSD's if Poettering et al. have their way. |
| jazz Nov 06, 2014 8:35 PM EDT |
20 years ago people used to say "nobody ever got fired for buying IBM". Does this apply to systemd? If it goes wrong, can I pretend I didn't know this is a controversial technology? I am looking for software written by professionals. One month ago Pottering became famous ranting about how bad kernel community is, and how bitcoin-payed individuals are out to kill him. Are there other RedHat employees having similar problems? Would this affect the service I get if I buy RHEL? I mean this kernel community is very dangerous, and RH customer support might be in hiding from bitcoiners. Looks like their engineering team already is! |
| penguinist Nov 06, 2014 11:26 PM EDT |
I think I just ran into a specific case of "systemd cancer". I am needing to build some special purpose software which requires usb support from libudev. Well it turns out that Fedora no longer packages libudev so I went on a search and guess where I found it... # yum provides */libudev.so systemd-devel-208-9.fc20.x86_64 : Development headers for systemd Filename : /usr/lib64/libudev.so Sorry, but I object !! |
| JaseP Nov 07, 2014 1:08 AM EDT |
Quoting: It looks like the tenticles are really out there pulling in what they can. So now if I want usb support in a short program, I need to install systemd sources to get it. Yep,... And yet those of us who DO object are looked at as though WE were the ones who were nuts... |
| jdixon Nov 07, 2014 4:08 AM EDT |
> So now if I want usb support in a short program, I need to install systemd sources to get it. Get the source and see if you can compile it without systemd support. |
| Ridcully Nov 07, 2014 6:15 AM EDT |
Perhaps I am naive, but it seems to me that this whole thing begins and ends with Poettering. Why has he done this ? Has anyone tried to tell this young man that he has done something terribly wrong and destructive ? Would he listen anyway ? |
| Bob_Robertson Nov 07, 2014 9:42 AM EDT |
> Would he listen anyway ? If you have to ask, you've already answered the question. |
| Ridcully Nov 07, 2014 5:04 PM EDT |
We do get very, very cynical about developers don't we Bob_Robertson ? They are so essential to Linux; I wonder why they refuse to accept feedback and become so arrogant ? |
| mrider Nov 07, 2014 5:28 PM EDT |
Quoting:They are so essential to Linux; I wonder why they refuse to accept feedback and become so arrogant ?As a developer, I think I'm qualified to answer that question: The trick is that we (developers) are so accustomed to having users ask for totally unreasonable or even impossible things, that it's easy for the unwary developer to just start blowing off the opinions of anyone that doesn't follow their own line of thought. That's a very poor habit to get into, but sadly is all too common. Also, it's all too easy to wind up writing the programmatic equivalent of the "Homer-mobile" if the end user were to get every wish for every feature. The upshot is that it's very easy to get in the habit of "ignore what they ask for and instead give them what they 'need'". Combine that with the fact that those developers are highly intelligent people, and hence are accustomed to being around those that know less than they do about a great many things, and you have a recipe for writing code that only the developer likes, simply because the developer thinks that they know what the user needs more than the user does. Because often times the developer does know more than the end-user about their own needs. The hard part is knowing when to turn off the "I know better than you" 'tude and actually listen to the users. And before you say always, make a point of watching that Simpson's episode. |
| gus3 Nov 07, 2014 5:30 PM EDT |
Quoting:We do get very, very cynical about developers because some of them have given us cause for it. |
| mrider Nov 07, 2014 5:38 PM EDT |
Quoting:because some of them have given us cause for it.95 percent give the rest a bad name. :) |
| Ridcully Nov 08, 2014 5:01 AM EDT |
Y'know mrider, this is where I begin to sit back and simply head to a large tipple of scotch in sheer frustration. I'm white haired, but this little gem has now turned my hairs whiter than white. LOL I have been down this track with KDE and even written a series of articles which when analysed, centre on the fact that the KDE developers could not leave a good window manager alone. It had to be "developed" again and again and again and again, the complexity was increased more and more and the lovely simplicity, flexibility and ease of use of the original KDE was lost. Well, that's my opinion anyhow. I don't want to open that can of worms, but the principle is similar with systemd, as far as I can now understand things. Something that was working well (systVinit), has been replaced by Poettering with something (systemd) that not only isn't doing what many users want, it is apparently usurping more software that many users feel should be kept as separate modules in the initialisation process. It seems to come right back to what you are saying: the developer thinks he knows what the user needs more than the user does. From what I am reading, this simply isn't the case for many of these users; I get the strong indications that they really DO know better than Poettering as to what they need. If this isn't simple arrogance on his part, then find me a better definition. |
| nmset Nov 08, 2014 5:50 AM EDT |
1. It's not Mr Pottering , he works for Red Hat, it's Red Hat deciding. 2. Non technical users are too fancy and ignorant of what it takes to just print a 'Hello world' line to be listened to. Really, developpers know better what non technical users need. Some are convinced that software should anticipate their thoughts, catch them up always when they err, reproduce exactly anachronistic workflows,... make coffee... (This does not cover technical users). |
| Ridcully Nov 08, 2014 6:55 AM EDT |
Well......that's a take on the matter anyhow. And that makes it even more tortuous and mucky. At the moment though, your comment suggests to me that Poettering and RedHat are so intermingled it's hard to say where one ends and the other begins. For the record, although I am not a "programmer", I have had training in programming. I'm an antique though....my programming was done first of all in "minitran", a cut-down version of Fortran, and the data entry was done on punch cards where you used a paper clip to push out the little "bits of cardboard" and then each card was a line in the program......but that was long ago.......long ago, in the 1960's. Later, I became reasonably competent in......wait for it.....wait for it.......Basic. My greatest delight was to produce a program which used a matrix data set in order to do biological key work, much later when personal computers finally began to appear and I had a Microbee.......around the late 1970's. At one stage I even produced a Basic program that was used by POISINDEX, the company that was based in Colorado I think; ah, ..memories. However, once a programmer, you never forget how these things operate.......the pleasure of seeing something you have built come to life......but that pleasure should always be subservient to the user's needs as far as I am concerned. |
| frankiej Nov 08, 2014 10:22 AM EDT |
Quoting:They are so essential to Linux; I wonder why they refuse to accept feedback and become so arrogant ? Keep in mind that they are probably also getting positive feedback on their changes. They are probably listening to the positive feedback :) |
| gus3 Nov 08, 2014 12:19 PM EDT |
@nmset, so what accounts for Debian's deciding, and OpenSUSE's deciding? Or, have Debian and OpenSUSE simply decided to go along with whatever Red Hat decides? *shudder* |
| nmset Nov 08, 2014 12:54 PM EDT |
@gus3: There's some misunderstanding : I meant by that : Pottering develops systemd on Red Hat 's command as an employee, I did not mean that Red Hat decides to use systemd because Pottering develops it independently. As for Debian, I'm still surprised they decided to move to it; this has nothing to do with Red Hat. Yet, all major distros apart Slackware have adopted it, there must be some common denominator apart from faster boot time or simpler unit scripts or forcefully because major libraries rely on it. |
| jdixon Nov 08, 2014 12:55 PM EDT |
> 2. Non technical users are too fancy and ignorant of what it takes to just print a 'Hello world' line to be listened to An excellent attitude for writing software that no one will ever use. |
| JaseP Nov 08, 2014 2:21 PM EDT |
Quoting: As for Debian, I'm still surprised they decided to move to it; this has nothing to do with Red Hat. Surprised?!?! Really?!?! Two reasons you shouldn't be... 1) They (RedHat) stacked the deck in terms of the vote, and 2) Systemd is now a dependency of so many other things, especially when you consider the merges, that they basically had no other choice... Quoting: > 2. Non technical users are too fancy and ignorant of what it takes to just print a 'Hello world' line to be listened to Yes. Exactly! |
| mrider Nov 08, 2014 3:22 PM EDT |
Quoting:Y'know mrider, this is where I begin to sit back and simply head to a large tipple of scotch in sheer frustration. I'm white haired, but this little gem has now turned my hairs whiter than white. LOLI'm with you there. The sad thing is that I'm so soured by the whole "you'll get it whether you like it or not" attitude, that I'm disinclined to use a distro with SystemD even if it's an improvement. [EDIT] Lead me well, and I'll follow you into Hades. Push me, and my feet will dig furrows in the soil even if you're pushing me to paradise. |
| nmset Nov 08, 2014 4:11 PM EDT |
Well, for whatever reasons, sytemd is here and we'll have to do with it, until some party can force in some other init system closer to SysV init. We are just end users of a distro, we don't have any say in works that we don't do. Any kind of discussion will be just vain, we won't have init back. Let's do the best with systemd. By the way, I can recall systemd does not prevent Linus himself from sleeping peacefully. >They (RedHat) stacked the deck in terms of the vote Yep, I forgot that. |
| flufferbeer Nov 12, 2014 3:41 PM EDT |
Sure, systemd is probably all GPLv3'd and whatnot. Still, I can't help wondering what Richard Stallman HIMSELF specifically has to say on systemd. -fb |
| JaseP Nov 12, 2014 3:55 PM EDT |
Quoting: Sure, systemd is probably all GPLv3'd and whatnot. Still, I can't help wondering what Richard Stallman HIMSELF specifically has to say on systemd. This might help: http://www.gnu.org/software/dmd/ |
| kikinovak Nov 13, 2014 5:36 PM EDT |
Systemd folks are a nice bunch indeed. https://bugs.freedesktop.org/show_bug.cgi?id=73729 |
| mrider Nov 13, 2014 5:48 PM EDT |
@kikinovak - that's the first I've seen of that bug track. I find Poettering's comment at 11 very telling:Quoting:udev and systemd are Linux specific. We program against the Linux platform, not against POSIX. No kidding. And everybody wonders why we're so concerned about your code! [EDIT] I pine for the days when "it's not supported" meant "go ahead and try it but don't blame us if it explodes", as opposed to the current "we're actively subverting that". |
| me1010 Nov 13, 2014 8:54 PM EDT |
uclibc and udev: I haven't tried this - - but it looks like it should work... http://patchwork.openwrt.org/patch/3274/ The rest of the bug report is quite a read. If you poke a bear, he's going to bite you. Post #4... them is fighting words. Poettering answered reasonably in Post #2. That should have settled the matter and sent the OP to DDG, where he would have found OpenWRT's build and discard technique. |
| Ridcully Nov 13, 2014 11:10 PM EDT |
@mrider.....I just read down the thread with Poettering's comments. Derogatory statements, personal attack, an unwillingness to consider someone MAY have a valid point and it goes on. Sheer flippin' ARROGANCE. I don't understand the programming, but I can see that "Nico" is so concerned about aspects of systemd, he's prepared to challenge its maker - who didn't like it one teensy bit. These sorts of comments and attitudes emanating from Poettering very sadly give developers a bad name and generally speaking, I consider developers to be the "salt of the earth".....Please, someone, challenge this juvenile twit and what he is doing to Linux ethics and concepts. He may be expert with logical mathematics, but he sure as heck isn't expert with human interaction and Linux ethical concepts - well that's my opinion anyhow. 2c. A true leader knows how to inspire and get the best out of his team.......I don't see that happening here if you shove their suggestions back in their face with insults. |
| JaseP Nov 14, 2014 2:00 AM EDT |
Quoting: The rest of the bug report is quite a read. If you poke a bear, he's going to bite you. Post #4... them is fighting words. Poettering answered reasonably in Post #2. That should have settled the matter and sent the OP to DDG, where he would have found OpenWRT's build and discard technique. Bottom line is that Poettering, Sievers [he] crew lied about compatibility. Mrider had it rifht when he said[/he] Quoting: ] I pine for the days when "it's not supported" meant "go ahead and try it but don't blame us if it explodes", as opposed to the current "we're actively subverting that". Nico might have been provocative, but Poettering goes in with the "white supremacist" nonsense... This the same guy who is rude to others & calls out Torvalds for being rude/crass... Classic "can dish it out but not take it"... I have no respect for Poettering, Sievers or any code they work on... I truly hope the Linux community charges into the systemd project, fixes it (as best they can) and neuters it (limiting its scope) before it's too late. |
| linuxscreenshot Nov 16, 2014 6:58 PM EDT |
And then Longtime Debian Developer Tollef Fog Heen Resigns From Systemd Maintainer Team |
| 750 Nov 16, 2014 8:15 PM EDT |
Here is a lovely one where pam_systemd borks up su. https://bugzilla.redhat.com/show_bug.cgi?id=753882 Yeah, it got resolved. But notice that Poettering argues that su is "broken" because pulseaudio and dbus can't handle it. To me it is that those projects are broken as su is as old as unix it self. And if they can't handle such old functions they have nothing to do on a unix system. |
| me1010 Nov 16, 2014 8:59 PM EDT |
Actually Poettering's argument is very sound and quite good in maintaining low privilege escalation.... read it again: *********** When we decided to base our systemd XDG_RUNTIME_DIR logic on the audit login session id (if it is available) is the thinking that "su" should be minimal in its effect, and almost everything that is not explicitly detached from the old session should continue to be from the old session. i.e. the default should be not to detach rather than to detach. If you want a fully detached text session then use "ssh localhost" or so, which virtualizes everything. *********** See "ninja" http://manpages.ubuntu.com/manpages/hardy/man8/ninja.8.htm This is fantastic reasoning, especially if you want to design a system that keeps "the bad" guys from hijacking accounts and gaining access to things that are not owned by the original login. The PA and dbus are examples of what to keep from the old and get from the new... he is not complaining about them "not handling" anything. I don't know... the more examples of "bad Poettering" that are thrown up here --- the more I like the guy. He's a lot smarter than me -- that's for sure. See Also: http://appleinsider.com/articles/14/11/04/truesec-outlines-r... https://www.youtube.com/watch?v=fCQg2I_pFDk hummm... maybe Poettering is on to something... |
| krisum Nov 17, 2014 3:50 AM EDT |
@mrider If you are going to quote from a bug report, it is only fair to quote the relevant technical parts too in addition to unreasonable responses. Comment #16 (https://bugs.freedesktop.org/show_bug.cgi?id=73729#c16) contains the technical crux: Quoting: > that uclibc doesnt implement 100% of glibcs idiotic add-ons is definitely > not a bug. as well as comment #14 Quoting: Systemd/udev officially uses reasonable glibc APIs, and it will continue to do so. Systemd/udev will not work with libcs which do not provide a reasonable compatibility with glibc. This is a reasonable reason for the commit, as well as for the bug report itself. They have in fact fixed a bunch of security and other issues with that change. Some comments are unreasonable from both sides, but that's no reason to overlook things that really matter. |
| 750 Nov 17, 2014 4:57 AM EDT |
@me1010 Sudo is at best a subset of su. Look at was initially attempted. The bug reporter was trying to use su - (or su -l if you will) to spawn a new login shell as a different non-privileged user. This was not about running something as root. Every entry Poettering makes on that bug report indicates that he overlooked or ignored the - in the command line, and just went on a rant about the evils of su-ing into root. But then, after departing with vague mention of state always being carried over, he eventually implements the very change that apparently would break pulseaudio. This because someone on the pulseaudio mailing list points to how pulseaudio can be changed so as to not break. So what was it, was it a security issue or was it all about not breaking pulseaudio? |
| me1010 Nov 17, 2014 9:40 AM EDT |
@krisum: I agree wholeheartedly. If someone has a technical objection, I'm more than happy to listen. However, endless cherry picking of poorly chosen non-technical banter doesn't sit well with me as an engineer and as a GNU/Linux/FOSS advocate. @750. See above. |
| Bob_Robertson Nov 17, 2014 10:06 AM EDT |
I'll be polite: The attention it's getting could be a good thing, bringing many shortcomings to light even if it's done traumatically. Better now than in 3 years when someone discovers that the NSA has been using systemd to hack every Linux system in the world the whole time. |
| number6x Nov 17, 2014 5:12 PM EDT |
Systemd fans... If I have a system crash in a way that it is completely unable to boot, I can extract the hard drive and examine the init logs. Can I do the same with systemd? I'm not talking about remotely connecting to another running machine and executing a systemd command on a remote host. Can I do the kind of computer forensics I need to do to determine what failed? I'm curious and don't know the answer. |
| cr Nov 18, 2014 3:52 PM EDT |
> The attention it's getting could be a good thing, bringing many shortcomings to light even if it's done traumatically. Especially when it leads to deborging efforts like uselessd. We need that deborging *now*. |
| flufferbeer Nov 18, 2014 7:01 PM EDT |
@number6x, >> Systemd fans... If I have a system crash in a way that it is completely unable to boot, I can extract the hard drive and examine the init logs. Can I do the same with systemd? I'm not talking about remotely connecting to another running machine and executing a systemd command on a remote host. Can I do the kind of computer forensics I need to do to determine what failed? I'm curious and don't know the answer.<< I can't help but notice that Systemd fans are so far strangely quiet on responding to your query so far. And I just KNOW that they're reading comments and actively commenting in the other thread about the systemd attacks and vitriol. You would think the Systemd fans either don't know the answer or else feel that they're just too darned BUSY to best answer this.... other than throwing out some kinda "RTFM" answer!! -fb |
| number6x Nov 18, 2014 7:33 PM EDT |
@flufferbeer It may be as simple as running a config utility to point a running instance to a binary log on a different mount point and using the command to generate a text based log. For sysvinit I'll just mount the drives and read the logs. This is almost always a first step when I get a crashed machine. I have scripts to dump the last day of many text based log files and some cats and greps to look for certain things... Hard drive errors Memory errors cpu temps Other interesting things like usb errors and network errors. As I said it may be as simple as running a config to add to the path where the binary file is, generate a text file and run my scripts. Or it may not. I just don't know. I have read the manual and found how to generate text files from the logs and how to do so on a remote host that is running., just curious if it can be done on a binary file mounted in a location that is not standard for systemd, without affecting your current running logs. |
| mrider Nov 18, 2014 8:04 PM EDT |
Quoting:I have read the manual and found how to generate text files from the logs and how to do so on a remote host that is running., just curious if it can be done on a binary file mounted in a location that is not standard for systemd, without affecting your current running logs. That's an excellent question. Because one would ordinarily boot a CDROM or USB drive and then mount the correct place for text logs. After that, cat, less, grep, and etcetera are sufficient. Heck, even pico could be used. Be interesting to know how to deal with a similar situation if the logs are binary only. |
| Bob_Robertson Nov 19, 2014 11:50 AM EDT |
> one would ordinarily boot a CDROM or USB drive and then mount the correct place for text logs. After that, cat, less, grep, and etcetera are sufficient. Heck, even pico could be used. Exactly! |
| me1010 Nov 19, 2014 12:04 PM EDT |
@number6x: Here's the documentation for the raw binary log format. http://www.freedesktop.org/wiki/Software/systemd/journal-files/ Here's the documentation on connecting to a remote journald. http://www.freedesktop.org/software/systemd/man/systemd-journal-remote.html And you've already figured out how to generate text logs from the binary storage. So, I imagine you've figured out how to configure journald to write a text log in real time as well... http://www.freedesktop.org/software/systemd/man/journald.conf.html Quoting:ForwardToSyslog=, ForwardToKMsg=, ForwardToConsole=, ForwardToWall= |
| number6x Nov 19, 2014 12:42 PM EDT |
@me1010 Thanks that is what I was looking for. Looks like if I get a binary only dead fedora machine I'll have to write a program to access the files. Reading in bson files, converting to json and extracting the text I need. Vastly more difficult than just reading a file. They should add a json version number as a parameter in the header parameters. Future versions of json may have incompatibilities( like trying to read a utf text file with an old text editor). If the user has set up their system to write text logs from the binary journals then I could just read the text, but who knows their system is going to crash hard before it does? It would be nice if systemd would use text journals by default. logs are write only so there is no benefit to binary. I can understand operating cached files that are being used read-write being binary, but even these can be persisted to disk in text format, if needed. Its almost like seeing a program written by someone who is proud that their code is confusing and obfuscated. Systemd is very young and still only deployed in experimental distros like fedora. Things like this should, hopefully, be whittled away over the next few years when systemd might start being used for real deployments. Thanks again |
| CFWhitman Nov 19, 2014 4:02 PM EDT |
I don't see an upside to the binary logs that is worth the downside. Fortunately, I believe you can set systemd to use text logs. Really, I think text logs should be the default, and the binary ones should only be used by people who specifically want them. That would make a lot more sense to me. |
| number6x Nov 19, 2014 4:36 PM EDT |
@CFWhitman I agree totally. As I stated, logs are write only so there is no benefit to keeping them in bson. As a counterexample, mongodb stores data in tables in bson format. The benefits include indexing and search as well as storage. Access for update in a working data store makes sense. Mongodb takes text based json in and will present text based json when queried. You can specify bson for output (ie if piping to a utility or api that expects it). But system logs are really only needed when something goes wrong, they should be write and forget, append only. binary bson does not make sense in this use case. It may be cool and shiny in a 'look what I can do' kind of way, but it is not a good design. If systemd is using logs in a read write kind of way, that is really borked. If systemd has a need for a read write temp storage, it should separate that functionality from the logs. Logs --> write only and read write stuff in a separate file in /var or /tmp or even cached in ram. That would be a like a spool, or cache file. |
| me1010 Nov 19, 2014 4:37 PM EDT |
@CFWhitman: Here's an oldie but goodie rather balanced view of journald and binary logging: http://lwn.net/Articles/468381/ |
| number6x Nov 19, 2014 7:36 PM EDT |
Careful me1010, that is definitely an article you do not want to point to in support of systemd.
I would say that it pretty well captures the reasons why systemd is meeting resistance. Yes there are problems. The problems are due to cruft built up over time. The solution to a house of cards system like that is not to offer a huge overarching control structure that will be bent and twisted to solve all the issues. That would be like hiring Accenture to code your solutions. It is going to end up as more of a nightmare. I think that article may be the straw that pushes me to the anti-sysemd side. It seems like lessons I had learned over the first 10 to 15 years in my career need to be learned by the systemd team. The logs should not be used as inputs to the init system, or for two way communication of services. You really have no idea of the synchronization delays of software writing to logs. It just boggles my mind that a hack like that would even occur to someone. If the init system needs information it should send a message to the service or daemon running and query that information. Those messages are great candidates for binary journalled format. However writing systemd to scrounge the log files for messages is a duct tape and bailing wire solution. It is not just a bad design, but bad in a way that is mind boggling. I'm stupefied. The more I learn The more I am amazed at this and begin to understand the extremely vocal opposition. Bury that article and never mention it again if you are a supporter of systemd. It reads like something we would have hacked together in the early eighties. |
| me1010 Nov 19, 2014 7:58 PM EDT |
@number6x: The article is a really good example of how to discuss the actual technical attributes, issues, and merits of systemd without resorting to posting threads entitled as this one is... I certainly agree there are problems with systemd. But that in no way means it isn't a good forward looking start on something that has the potential to bring very useful innovation to the GNU/Linux world. And the fact that there are problems is definitely not cause to call those who wrote it and support it akin to an 'evil' group intent on destroying the Linux ecosystem. So, yes... the article is a great one to refer to if you happen to be a systemd supporter. |
| number6x Nov 19, 2014 8:13 PM EDT |
I also just noticed that the article is quite old and may not reflect actual systemd design as of today. I will take it with a grain of salt and try not to let it prejudice me too much. I actually said it should not be referred to in support of systemd, it raises troubling issues with the basic design philosophy of systemd back in 2011. |
| me1010 Nov 19, 2014 8:45 PM EDT |
@number6x: quoting from the article I referenced: Quoting: To restrict ourselves to what Unix did is an almost certain way to share Unix's fate. We can do better than that - indeed, we have done better than that - but, to do so, we need to create an environment where developers are willing to take some technical risks. Bad ideas need to be exposed as such whenever possible, but ideas should not be shot down just because they do not preserve the way our grandparents did things. The Journal may or may not turn into a sensible option, but the process that creates things like the Journal is one of the most important things we have. |
| number6x Nov 20, 2014 8:43 AM EDT |
@me1010, The paragraph you quote is probably the best way to summarize the legitimate complaints about systemd. It is one of the strongest arguments against it. The headline for this article should be: "SystemD lead developer agrees with naysayers, declares SystemD not sensible." Yes be bold and Plant a seed. See what grows.But when it comes time to harvest, can the systemd developers be bold and daring? Are they willing to take the ripe fruit, and to also discard the rotten? So far they are not willing. They are doing just as 'their grandfathers' did. They are taking the bad with the good, because they wrote it and cannot bear to discard it or admit it is bad. The bad ideas are being exposed and their response is to ignore the exposure. Again, this is fine in Red Hat's playground distribution, Fedora, but it is, as the systemd developer's say them selves, not a sensible idea. So when you see someone complain, that there are bad ideas in systemd and it does not make sense to do some of these things, then remember this quote. |
| me1010 Nov 20, 2014 9:31 AM EDT |
@number6x: I take the precise opposite interpretation. So, we'll just have to agree to disagree on the meaning, although the comments after the article are mixed with no one, at all, claiming any massive overarching insurmountable obstacle to systemd adoption. |
| number6x Nov 20, 2014 11:34 AM EDT |
@me1010, I think you are beginning to see why there is so much opposition to systemd. The proponents keep listing the benefits they see in systemd, and the opponents keep listing the drawbacks. As I posted earlier in this thread: Quoting:The proponents claim the benefits of systemd are: So what proponents keep thinking will convince others to back systemd is actually causing others to reject and oppose systemd. The more proponents continue to trumpet what they perceive as benefits, the more people are convinced systemd is a fundamentally flawed solution to a problem that was not too big a deal. I started as someone who was interested in learning how things I do will have to be changed as systemd is adopted. The more I learned, and thanks to the information you have pointed out, I now agree that systemd is fundamentally flawed and should not be adopted without major re-writes. It is almost as if someone determined that there was a problem with baby ducklings getting struck by cars when crossing the road in central Florida, and the systemd team has stated that they have a solution, their solution will make sure that the hungry moose in the Yukon territory will be well fed this year. When people complain about the solution not meeting the needs, the systemd team accuses the complainers of not caring about the moose! They need to examine what they have built and fix the problems, but they refuse to accept that their design has any problems. Shiny and new is not usually a good thing. There are good reasons why the most popular programming languages throughout history are old and ugly. Things like COBOL, C and C++. |
| Bob_Robertson Nov 20, 2014 12:28 PM EDT |
Nooooo ! Not COBOL! Think of the child-processes! Oh, the huge manatee! |
| number6x Nov 20, 2014 3:18 PM EDT |
This should still be valid, but it has been many years...
IDENTIFICATION DIVISION.
PROGRAM-ID. SAMPLE.
AUTHOR. NUMBER6X
********************************
** A sample cobol program **
********************************
ENVIRONMENT DIVISION.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
SELECT INPUT-FILE ASSIGN TO SYSIN
ORGANIZATION IS LINE SEQUENTIAL.
SELECT PRINT-FILE ASSIGN TO SYSOUT
ORGANIZATION IS LINE SEQUENTIAL.
DATA DIVISION.
FILE SECTION.
FD INPUT-FILE
RECORD CONTAINS 43 CHARACTERS
DATA RECORD IS DATA-IN.
01 DATA-IN PIC X(43).
FD PRINT-FILE
RECORD CONTAINS 80 CHARACTERS
DATA RECORD IS PRINT-LINE.
01 PRINT-LINE PIC X(80).
WORKING-STORAGE SECTION.
01 ROWS-REMAIN-FLAG PIC X(2) VALUE SPACES.
01 RECORDS-WRITTEN PIC 9(2).
01 DETAIL-LINE.
05 FILLER PIC X(7) VALUE SPACES.
05 INPUT-IMAGE PIC X(43).
05 FILLER PIC X(30) VALUE SPACES.
01 SUMMARY-LINE.
05 FILLER PIC X(7) VALUE SPACES.
05 TOTAL-READ PIC 9(2).
05 FILLER PIC X VALUE SPACE.
05 FILLER PIC X(17)
VALUE 'Records were read'.
05 FILLER PIC X(53) VALUE SPACES.
PROCEDURE DIVISION.
000-RUN-PROGRAM.
PERFORM 100-STARTUP.
PERFORM 300-PROCESS-RECORDS
UNTIL ROWS-REMAIN-FLAG = 'NO'.
PERFORM 500-PRINT-SUMMARY.
PERFORM 900-FINISH.
STOP RUN.
100-STARTUP.
OPEN INPUT INPUT-FILE
OUTPUT PRINT-FILE.
MOVE ZERO TO RECORDS-WRITTEN.
PERFORM 800-READ-INPUT.
300-PROCESS-RECORDS.
INITIALIZE PRINT-LINE.
MOVE DATA-IN TO INPUT-IMAGE.
MOVE DETAIL-LINE TO PRINT-LINE.
WRITE PRINT-LINE.
ADD 1 TO RECORDS-WRITTEN.
PERFORM 800-READ-INPUT.
500-PRINT-SUMMARY.
INITIALIZE PRINT-LINE.
MOVE RECORDS-WRITTEN TO TOTAL-READ.
MOVE SUMMARY-LINE TO PRINT-LINE.
WRITE PRINT-LINE. |
| JaseP Nov 20, 2014 6:16 PM EDT |
@ number6x: Let me guess,... that same program can be written in about 3 lines of python?!?! |
| gus3 Nov 20, 2014 6:21 PM EDT |
And one line of Bash. |
| number6x Nov 20, 2014 6:40 PM EDT |
Yes, but about 10 -12 lines of python would be very clear and expandable. I write programs like this in python everyday. It could be much smaller in COBOL. This is a good shell to start from. It is easily expanded and functionality is compartmentalized in logical sections. It follows the same format as suggested for basic data crunching in books like: Data Crunching: Solve Everyday Problems using Java, Python, and More: Open files an take care of start up tasks. Read first file into input. Loop to process file line by line, doing what needs to be done. read the next record and the end of each processing loop. break out of processing loop at end of file. take care of finalization tasks and close files. end. (Sadly that book is out of print.) A similar program format in python would be: import sys Very expandable and useful pattern for processing sequential data input. |
Posting in this forum is limited to members of the group: [ForumMods, SITEADMINS, MEMBERS.]
Becoming a member of LXer is easy and free. Join Us!