No I am fully aware that systemd targets Linux and OpenBSD is, well, not Linux. But seriously, what's the status of init in OpenBSD? Last time I used it (around 5.2 for some odd sparc servers that didn't support anything else apart from Solaris) it was still/etc/rc.d scripts, and no respawn if a service crashed etc.
by Anonymous Coward writes:
on Sunday October 18, 2015 @12:49PM (#50753895)
No, it doesn't have systemd.
If a Poettering-like asshole was detected anywhere near OpenBSD, they would be shot down like an aircraft flying over the White House without clearance.
By no means am I an expert but systemd seems needlessly complicated. It seems that systemd was implemented for sake of change rather than addressing a true need. As others have pointed out, UNIX traditionally is a compilation of tools that each do a single thing well and play well together.
For variable values of "improvements". Some people (usually ones with a lot of experience and insights) think that the makers of systemd do not understand how Unix works or how to do professional system administration and hence view systemd rightfully as a step backwards.
Unix is an evolving class of operating systems and they work the way we make them work. Sometimes we come up with new ideas that may or may not improve it. Almost no one agrees that Unix of the 90s was at perfection and that nothing would ever have to be changed again.
That there's no point in talking about "how Unix works" since Unix has never been consistent unless you're talking about some of the really old AT&T releases. Once there were multiple Unix vendors things started changing all the time. What we're seeing now in the Linux space is no different from what has always been the case.
What you claim is not possible. You seem to be stupid. But actually, my guess is you are just a systemd shill working from its propaganda manual. Just es he is.
by Anonymous Coward writes:
on Sunday October 18, 2015 @01:59PM (#50754193)
The UNIX philosophy was always groups of simple tools that do one thing and do it well. You pipe them together and parse the data however you want. Systemd does the exact opposite of that. One monolithic service doing everything but poorly. None of these new ideas have undergone any real testing other than shipping the distro when they compile. You're beta testing this bullshit.
No, it wouldn't be Unix any more if it were microkernel-based.
I'm not sure why, exactly. AFAIK Unix doesn't dictate any particular kernel structure. NetBSD uses an 'anykernel' that is definitely Unixy but modular and more flexible.
It's not like the Unix kernel never changed. Mach was originally just an attempt to restructure the Unix kernel, and the microkernel philosophy emerged out of that as they abstracted more services out of the 'core' kernel.
(OSX doesn't really use its microkernel, it's really just u
Agreed 100% that post #50754359's AC is an uninformed blowhard... however...
XNU (OSX's kernel) does have a bunch of Mach-based code running in it, and it is being "used"; in fact it is performing critical functions:
Preemptive multitasking and multithreading Memory protection Virtual memory management Inter-process communication Interrupt management Real-time support Kernel debugging support Console I/O
There is also a bunch of FreeBSD-based code running in XNU, implementing essentially all the other kernel functions, including POSIX support, filesystems
Is XNU microkernel-based? That's one for the semanticists to debate. Arguably the Mach-based code is not performing microkernel functions. What is not debatable is that there are or have been Unix-"alike" OS'es baed on microkernels. Minix is one. Hurd is another. They are as Unix-alike as Linux is. I would say POSIX defines Unix-ness, and there is absolutely nothing to prevent a microkernel from implementing POSIX just as fully and faithfully as a monolithic kernel.
OSX uses a microkernel. Besides, there are/were plenty of Unix that used microkernels: OSF/1, Digital Unix/Tru64, etc.
The point is moot any way, most of you aspies don't understand the debate is moot because Linux is not unix.
The debate is moot because too many people involved in the debate are using "Unix" as a hammer to beat down anything that provokes their nerd rage.
I'd say that "the Unix philosophy" is spelled out by the various documents that the Wikipedia "Unix philosophy" page [wikipedia.org] cites. Whether it covers mechanisms such as the init system, much less the kernel-mode code, is, well, subject to debate.
And something doesn't have to "be Unix" in the trademark sense or in the "you can draw some line of descent by which the cod
XNU (OSX's kernel) does have a bunch of Mach-based code running in it, and it is being "used"; in fact it is performing critical functions:
They are not using Mach, the microkernel part, to do any of that shit. For example, they are not using it to do process management. That's done by the kernel, not the microkernel. That's the primary reason why XNU is not actually microkernel-based any more than NT is. It has a microkernel-like architecture, but then they underutilize it.
I would say POSIX defines Unix-ness, and there is absolutely nothing to prevent a microkernel from implementing POSIX just as fully and faithfully as a monolithic kernel.
If you actually used the microkernel, then you would have some processes managed by the microkernel, and perhaps some managed by the kernel. But they're not using the microk
Absolutely, since it actually is microkernel-based. And GNU's not Unix, and neither is The Hurd. It's a POSIX-compatible Unixlike operating system, but it ain't Unix or UNIX.
Absolutely, since it actually is microkernel-based. And GNU's not Unix, and neither is The Hurd. It's a POSIX-compatible Unixlike operating system, but it ain't Unix or UNIX.
As far as I know, nobody has run GNU/Hurd through the Single UNIX Specification validation suite, and therefore it's apparently not eligible to have the "Unix" trademark used for it (i.e., it's not a "Unix(R) system"), and none of its code can trace its ancestry to any Unix code from Bell Labs.
However, it probably looks enough like actual Unix systems that one could ask whether it violates the "Unix philosophy"(TM) or not; given that its userland is GNU, Doug McIlroy might argue that it's been fed enough g [dartmouth.edu]
As far as I know, nobody has run GNU/Hurd through the Single UNIX Specification validation suite, and therefore it's apparently not eligible to have the "Unix" trademark used for it (i.e., it's not a "Unix(R) system"), and none of its code can trace its ancestry to any Unix code from Bell Labs.
No, not Unix(R), but UNIX(R). Unix is the name for the family of Unixlike. UNIX is the trademark, or at least, that's the convention people use to differentiate between Unixlikes and UNIX. The convention was created by UNIX, which was emphatic about the all-caps until recently, and not by the community.
If you think The Hurd is Unix, then so is QNX, right?
As far as I know, nobody has run GNU/Hurd through the Single UNIX Specification validation suite, and therefore it's apparently not eligible to have the "Unix" trademark used for it (i.e., it's not a "Unix(R) system"), and none of its code can trace its ancestry to any Unix code from Bell Labs.
No, not Unix(R), but UNIX(R). Unix is the name for the family of Unixlike. UNIX is the trademark, or at least, that's the convention people use to differentiate between Unixlikes and UNIX.
There may well be people who use that convention, but I am not one of them. Another convention that people use is to refer to Unix-like systems, whether they passed the SUS validation suite or not and whether they contain code derived from Bell Labs UNIX code or not, as "Un*xes".
The convention was created by UNIX, which was emphatic about the all-caps until recently, and not by the community.
The UNIX philosophy was always groups of simple tools that do one thing and do it well. You pipe them together and parse the data however you want. Systemd does the exact opposite of that. One monolithic service doing everything but poorly. None of these new ideas have undergone any real testing other than shipping the distro when they compile. You're beta testing this bullshit.
More accurately it's about tight versus loose coupling.
Under systemd, while there are many CLI commands, they are bound together and cannot be used independently. You can't really use journald, hostnamed, machined, timedated, etc., independently or replace them with something else that you've developed.
It's all very well to write a "better init", and maybe it has, but you're stuck with also running journald and can't put in rsyslog instead (only run in parallel). timedated may be good, and you want to use i
Well, those that do not understand Unix are bound to re-invent its mechanisms, poorly. Systemd is a text-book example of that. Unfortunately, with the Linux community growing, far more idiots came in in recent years than people with a clue.
Well, Android proved that Linux doesn't belong to the unix community. The good thing is, the unix community has never suffered from being a small subset of the entire computer-using public. And hey, then. This is a BSD topic so the fate of linux isn't central anyway. Personally I quit using linux and switched to NetBSD for my unix-like needs because of Red Hat 5.0 and the mess that was PCMCIA ethernet support at the time (a clown in a sidecar, when NetBSD had the drivers right in the kernel), and haven't lo
Well, those that do not understand Unix are bound to re-invent its mechanisms, poorly. Systemd is a text-book example of that. Unfortunately, with the Linux community growing, far more idiots came in in recent years than people with a clue.
Here we go again.
Init is standard because it is the best and why change for the sake of change? Name one other OS that has switched away from init? 1. Solaris EMF (2008)... uh 2. MacOSX LaunchD(2006)... well I guess it is not really Unix 3. NetBSD (2008?)... hey wait a minute. It is still init... well modules in its place. You edit those. Hmmm different and not the traditional unix way 4. Ubuntu Upstart(2010?)... hey wait a minute pal! Ubuntu is cool and no way and you MR. GATES ARE A TROLL!! 5, Linux (Syste
You are missing what is going on here: Making the boxes more "friendly" to novices and at the same time throwing out reliability, simplicity and security. Of course most users like that as most users do not have much of a clue how their box works. But when a distro like Debian (which is still regarded as the "rock solid thing for the server", but probably not much longer) does it, then this massive dumbing down and all its drawbacks start to affect people that actually have a clue and that is where the oppo
You may have read that, but reality is shit like systemd hanging indefinitely waiting to detect a wireless mouse dongle (noticed it was hung booting and rebooted after five hours, then pulled the dongle and rebooted again). The parallel idea didn't happen. The rage is due to it being perpetually a half finished sack of shit expanding into other areas before the existing ones are fixed. It's more rage at poor implementation than the idea itself.
From what I read SystemD is modular and has separate components and follows the Unix philosophy more than Init.,
That's not what's meant by the unix philosophy. None of those components is independent of systemd, they're all part of it. You can't for example swap out syslog for jounrnald on a Gentoo machine running OpenRC. This is not like having GNU AWK and MAWK installed and switching one for the other.
The systemd modules are just that, modules. Like the kernel. They're not separate components which do thi
This bad? That is staggering. I think the following applies pretty well to the systemd team:
"Someone who considers himself too important for small jobs is often too small for important jobs" -- Jaques Tati
Solid engineering requires attention to detail. Rushing off to break even more other functionality before your replacement stuff works well is a sure recipe for disaster. Incidentally, while I do not have "rage" for them (they are far too unimportant to me), the defects of the idea itself ma
One thing the world has been plagued with is people who can't write init scripts for crap. Redhat was particularly bad and ubuntu was only a little better. Arch, prior to switching had rather short, simple RC scripts, certainly nothing like you describe. Oh and it booted faster with it's RC scripts than systemD, so there's that too.
Ah, yes. I have observed that too. Funny thing is the ones I wrote myself never gave me any trouble later. Of course, moving to systemd to fix that is about the worst thing they could have done. Hiding complexity does not make it go away, it just makes it so much worse when something breaks. Genuine simplicity can only be replaced by genuine simplicity and systemd has nothing of that.
The UNIX philosophy was always groups of simple tools that do one thing and do it well. You pipe them together and parse the data however you want. Systemd does the exact opposite of that. One monolithic service doing everything but poorly.
If you build systemd with all configuration options enabled you will build 69 individual binaries. These binaries all serve different tasks, and are neatly separated for a number of reasons.
A package involving 69 individual binaries can hardly be called monolithic. What is different from prior solutions however, is that we ship more components in a single tarball, and maintain them upstream in a single repository with a unified release cycle.
Much of the debate about systemd is academic at this point because here's a truth that you'll discover in Debian 8, Ubuntu 15.04, and just about every other major distro around: systemd is here.
Red Hat is the inventor and primary booster of systemd, so the best distros for playing with it are Red Hat Enterprise Linux, RHEL clones like CentOS and Scientific Linux, and of course good ole Fedora Linux, which always ships with the latest, greatest, and bleeding-edgiest.
Oh the one you linked. The bit about concentrating on code rather than interfaces. I'd not thought of it like that, but that makes a good deal of sense.
For variable values of "improvements". Some people (usually ones with a lot of experience and insights) think that the makers of systemd do not understand how Unix works or how to do professional system administration and hence view systemd rightfully as a step backwards.
So what? Use BSD, and revel in your superiority. If it is better, it will take over in no time.
From what I have read from y'all, it simply does not work, causes cancer, and will make your dog run away, and your wife either leave you or come back - whichever situation you don't want.
Exactly what features or improvements would that be? restarting capability for badly designed crap code that keeps falling over (instead of robustly written services)? integrated firewall, masquerading etc that should be in a separate system (and IS in BSD)?
Your "problems" are not a need for systemd, they are a need for proper tools and methodologies that exist already.
We did complain, but the minority in charge deleted threads and banned anyone that said a word against it, that happened at both Debian and Arch. It was a total fsck up and I'll happily go to bsd before having anything to do with that shit that is systemd and any users that use it deserve it, reboots and all.
This article isn't even about Linux, yet the comment section is filled with people who are pointing out serious flaws with systemd and the way it was shoved into every major distro.
In the articles that are actually about Linux, the comment sections look like war-zones. A significant amount of people voice their disapproval with systemd and the process by which RHEL shoved an extremely unpopular and major change into Linux. Yes, the distros did not have to adopt it. No, the distros can't defy RHEL's massi
linux doesn't have a systemd problem, systemd has an ignorant trolls problem
I would say they do considering this IS NOT A LINUX/SYSTEMD story!
Shoot I feel like I am watching Foxnews comments or MSNBC where a dog gets run over by a car caught on video and somehow it all goes back to Obama's fault. It is alike an autistic obession with these trolls.... also that rant has nothing to do with OpenBSD either I may add.
But I see parallels now with anti SystemD here. What's next? A story about a new NVMe SSD storage breakthru... a comment comes up about systemD in that in how we wouldn't
GNOME depends on an dbus api, that logind implements, and logind is part of systemd. GNOME does not directly depend on systemd or logind. If you implement the API then GNOME will work just fine.
GNOME depends on an dbus api, that logind implements, and logind is part of systemd. GNOME does not directly depend on systemd or logind. If you implement the API then GNOME will work just fine.
However, package managers are not able to express dependency on APIs. The only dependencies they can express are on other packages, or libraries. Now, dbus as an independent package has been terminated, so as it stands at present the way package managers express GNOME's true dependency on the DBUS API is to just list
NetBSD has twm, and that's all that's needed, though an upgrade to fvwm2 is kinda nice. twm is a binary that you get automatically in the base install, from the 406MB iso if you're on an x86 platform.
Which is all well documented in the O'Reilly X11 manual set. (The User's Guide is Vol. 3, the Administrator Guide is Vol. 8)
NetBSD has twm, and that's all that's needed, though an upgrade to fvwm2 is kinda nice. twm is a binary that you get automatically in the base install, from the 406MB iso if you're on an x86 platform.
twm is a Window Manager, not a Desktop Environment. As such, it has no start menu, taskbar, etc, and does not come packaged with a set of apps such as a file manager, print manager, etc. As such you will have a damn tough sell trying to get anyone used to using a DE to convert to a bare WM. If you want to run a
If a Poettering-like asshole was detected anywhere near OpenBSD, they would be shot down like an aircraft flying over the White House without clearance.
Only one allowed per project (cough Theo De Raadt cough). I do grant that Theo's stuff works.
A penny saved is a penny to squander.
-- Ambrose Bierce
Does it have systemd? (Score:0)
No I am fully aware that systemd targets Linux and OpenBSD is, well, not Linux. But seriously, what's the status of init in OpenBSD? Last time I used it (around 5.2 for some odd sparc servers that didn't support anything else apart from Solaris) it was still /etc/rc.d scripts, and no respawn if a service crashed etc.
Re:Does it have systemd? (Score:1, Interesting)
No, it doesn't have systemd.
If a Poettering-like asshole was detected anywhere near OpenBSD, they would be shot down like an aircraft flying over the White House without clearance.
Re:Does it have systemd? (Score:5, Funny)
No, I don't know of any OpenBSD 'features' that involve pissing off its userbase with half-functioning, amorphous garbage code like systemd.
Re: (Score:2)
Re: (Score:2, Insightful)
For variable values of "improvements". Some people (usually ones with a lot of experience and insights) think that the makers of systemd do not understand how Unix works or how to do professional system administration and hence view systemd rightfully as a step backwards.
Re:Does it have systemd? (Score:4, Insightful)
Re: (Score:1)
Your point?
Re:Does it have systemd? (Score:4, Informative)
Re: (Score:1, Offtopic)
Re: (Score:2)
What you claim is not possible. You seem to be stupid. But actually, my guess is you are just a systemd shill working from its propaganda manual. Just es he is.
Re: (Score:1)
Nice. You are now a criminal in quite a few jurisdictions. No surprise, matches the expressed mind-set.
Re:Does it have systemd? (Score:5, Insightful)
The UNIX philosophy was always groups of simple tools that do one thing and do it well. You pipe them together and parse the data however you want. Systemd does the exact opposite of that. One monolithic service doing everything but poorly. None of these new ideas have undergone any real testing other than shipping the distro when they compile. You're beta testing this bullshit.
Re: (Score:1)
Re: (Score:2)
The Unix philosophy is about the userland, not the init system and other core components of the system
Who told you that? Or did you just come to this conclusion on your own? Either way, it's wrong.
If it was then Unix would have a micro kernel.
No, it wouldn't be Unix any more if it were microkernel-based. (OSX doesn't really use its microkernel, it's really just used as a HAL.)
Re: (Score:1)
I'm not sure why, exactly. AFAIK Unix doesn't dictate any particular kernel structure. NetBSD uses an 'anykernel' that is definitely Unixy but modular and more flexible.
It's not like the Unix kernel never changed. Mach was originally just an attempt to restructure the Unix kernel, and the microkernel philosophy emerged out of that as they abstracted more services out of the 'core' kernel.
Re:Does it have systemd? (Score:5, Informative)
Agreed 100% that post #50754359's AC is an uninformed blowhard ... however ...
XNU (OSX's kernel) does have a bunch of Mach-based code running in it, and it is being "used"; in fact it is performing critical functions:
Preemptive multitasking and multithreading
Memory protection
Virtual memory management
Inter-process communication
Interrupt management
Real-time support
Kernel debugging support
Console I/O
There is also a bunch of FreeBSD-based code running in XNU, implementing essentially all the other kernel functions, including POSIX support, filesystems
Is XNU microkernel-based? That's one for the semanticists to debate. Arguably the Mach-based code is not performing microkernel functions. What is not debatable is that there are or have been Unix-"alike" OS'es baed on microkernels. Minix is one. Hurd is another. They are as Unix-alike as Linux is. I would say POSIX defines Unix-ness, and there is absolutely nothing to prevent a microkernel from implementing POSIX just as fully and faithfully as a monolithic kernel.
Re: (Score:2)
Is XNU microkernel-based? That's one for the semanticists to debate. Arguably the Mach-based code is not performing microkernel functions.
I'm not sure that it arguably is performing them; it seems pretty clear to me that it isn't.
What is not debatable is that there are or have been Unix-"alike" OS'es baed on microkernels. Minix is one. Hurd is another.
The Hurd is definitely a better example.
Re: (Score:3)
OSX uses a microkernel. Besides, there are/were plenty of Unix that used microkernels: OSF/1, Digital Unix/Tru64, etc.
The point is moot any way, most of you aspies don't understand the debate is moot because Linux is not unix.
The debate is moot because too many people involved in the debate are using "Unix" as a hammer to beat down anything that provokes their nerd rage.
I'd say that "the Unix philosophy" is spelled out by the various documents that the Wikipedia "Unix philosophy" page [wikipedia.org] cites. Whether it covers mechanisms such as the init system, much less the kernel-mode code, is, well, subject to debate.
And something doesn't have to "be Unix" in the trademark sense or in the "you can draw some line of descent by which the cod
Re: (Score:2)
XNU (OSX's kernel) does have a bunch of Mach-based code running in it, and it is being "used"; in fact it is performing critical functions:
They are not using Mach, the microkernel part, to do any of that shit. For example, they are not using it to do process management. That's done by the kernel, not the microkernel. That's the primary reason why XNU is not actually microkernel-based any more than NT is. It has a microkernel-like architecture, but then they underutilize it.
I would say POSIX defines Unix-ness, and there is absolutely nothing to prevent a microkernel from implementing POSIX just as fully and faithfully as a monolithic kernel.
If you actually used the microkernel, then you would have some processes managed by the microkernel, and perhaps some managed by the kernel. But they're not using the microk
Re: (Score:2)
The Hurd is definitely a better example.
Absolutely, since it actually is microkernel-based. And GNU's not Unix, and neither is The Hurd. It's a POSIX-compatible Unixlike operating system, but it ain't Unix or UNIX.
Re: (Score:2)
The Hurd is definitely a better example.
Absolutely, since it actually is microkernel-based. And GNU's not Unix, and neither is The Hurd. It's a POSIX-compatible Unixlike operating system, but it ain't Unix or UNIX.
As far as I know, nobody has run GNU/Hurd through the Single UNIX Specification validation suite, and therefore it's apparently not eligible to have the "Unix" trademark used for it (i.e., it's not a "Unix(R) system"), and none of its code can trace its ancestry to any Unix code from Bell Labs.
However, it probably looks enough like actual Unix systems that one could ask whether it violates the "Unix philosophy"(TM) or not; given that its userland is GNU, Doug McIlroy might argue that it's been fed enough g [dartmouth.edu]
Re: (Score:2)
As far as I know, nobody has run GNU/Hurd through the Single UNIX Specification validation suite, and therefore it's apparently not eligible to have the "Unix" trademark used for it (i.e., it's not a "Unix(R) system"), and none of its code can trace its ancestry to any Unix code from Bell Labs.
No, not Unix(R), but UNIX(R). Unix is the name for the family of Unixlike. UNIX is the trademark, or at least, that's the convention people use to differentiate between Unixlikes and UNIX. The convention was created by UNIX, which was emphatic about the all-caps until recently, and not by the community.
If you think The Hurd is Unix, then so is QNX, right?
Re: (Score:2)
As far as I know, nobody has run GNU/Hurd through the Single UNIX Specification validation suite, and therefore it's apparently not eligible to have the "Unix" trademark used for it (i.e., it's not a "Unix(R) system"), and none of its code can trace its ancestry to any Unix code from Bell Labs.
No, not Unix(R), but UNIX(R). Unix is the name for the family of Unixlike. UNIX is the trademark, or at least, that's the convention people use to differentiate between Unixlikes and UNIX.
There may well be people who use that convention, but I am not one of them. Another convention that people use is to refer to Unix-like systems, whether they passed the SUS validation suite or not and whether they contain code derived from Bell Labs UNIX code or not, as "Un*xes".
The convention was created by UNIX, which was emphatic about the all-caps until recently, and not by the community.
The convention was created by the people who created it. Eric Raymond claims that Dennis Ritchie says the all-caps version stems from being "intoxicated" by the ability to produce small caps with troff and the new typesetter, and [catb.org]
tight versus loose coupling (Score:1)
The UNIX philosophy was always groups of simple tools that do one thing and do it well. You pipe them together and parse the data however you want. Systemd does the exact opposite of that. One monolithic service doing everything but poorly. None of these new ideas have undergone any real testing other than shipping the distro when they compile. You're beta testing this bullshit.
More accurately it's about tight versus loose coupling.
Under systemd, while there are many CLI commands, they are bound together and cannot be used independently. You can't really use journald, hostnamed, machined, timedated, etc., independently or replace them with something else that you've developed.
It's all very well to write a "better init", and maybe it has, but you're stuck with also running journald and can't put in rsyslog instead (only run in parallel). timedated may be good, and you want to use i
Re:Does it have systemd? (Score:5, Insightful)
Well, those that do not understand Unix are bound to re-invent its mechanisms, poorly. Systemd is a text-book example of that. Unfortunately, with the Linux community growing, far more idiots came in in recent years than people with a clue.
Re: (Score:1)
Well, Android proved that Linux doesn't belong to the unix community. The good thing is, the unix community has never suffered from being a small subset of the entire computer-using public. And hey, then. This is a BSD topic so the fate of linux isn't central anyway. Personally I quit using linux and switched to NetBSD for my unix-like needs because of Red Hat 5.0 and the mess that was PCMCIA ethernet support at the time (a clown in a sidecar, when NetBSD had the drivers right in the kernel), and haven't lo
Re: (Score:2)
Well, those that do not understand Unix are bound to re-invent its mechanisms, poorly. Systemd is a text-book example of that. Unfortunately, with the Linux community growing, far more idiots came in in recent years than people with a clue.
Here we go again.
Init is standard because it is the best and why change for the sake of change? Name one other OS that has switched away from init? ... uh ... hey wait a minute. It is still init ... well modules in its place. You edit those. Hmmm different and not the traditional unix way ... hey wait a minute pal! Ubuntu is cool and no way and you MR. GATES ARE A TROLL!!
1. Solaris EMF (2008)
2. MacOSX LaunchD(2006)... well I guess it is not really Unix
3. NetBSD (2008?)
4. Ubuntu Upstart(2010?)
5, Linux (Syste
Re: (Score:2)
You are missing what is going on here: Making the boxes more "friendly" to novices and at the same time throwing out reliability, simplicity and security. Of course most users like that as most users do not have much of a clue how their box works. But when a distro like Debian (which is still regarded as the "rock solid thing for the server", but probably not much longer) does it, then this massive dumbing down and all its drawbacks start to affect people that actually have a clue and that is where the oppo
Re: (Score:2)
The rage is due to it being perpetually a half finished sack of shit expanding into other areas before the existing ones are fixed. It's more rage at poor implementation than the idea itself.
Re: (Score:1)
From what I read SystemD is modular and has separate components and follows the Unix philosophy more than Init.,
That's not what's meant by the unix philosophy. None of those components is independent of systemd, they're all part of it. You can't for example swap out syslog for jounrnald on a Gentoo machine running OpenRC. This is not like having GNU AWK and MAWK installed and switching one for the other.
The systemd modules are just that, modules. Like the kernel. They're not separate components which do thi
Re: (Score:2)
This bad? That is staggering. I think the following applies pretty well to the systemd team:
"Someone who considers himself too important for small jobs is often too small for important jobs" -- Jaques Tati
Solid engineering requires attention to detail. Rushing off to break even more other functionality before your replacement stuff works well is a sure recipe for disaster. Incidentally, while I do not have "rage" for them (they are far too unimportant to me), the defects of the idea itself ma
Re: (Score:2)
One thing the world has been plagued with is people who can't write init scripts for crap. Redhat was particularly bad and ubuntu was only a little better. Arch, prior to switching had rather short, simple RC scripts, certainly nothing like you describe. Oh and it booted faster with it's RC scripts than systemD, so there's that too.
Ah, yes. I have observed that too. Funny thing is the ones I wrote myself never gave me any trouble later. Of course, moving to systemd to fix that is about the worst thing they could have done. Hiding complexity does not make it go away, it just makes it so much worse when something breaks. Genuine simplicity can only be replaced by genuine simplicity and systemd has nothing of that.
FUD. (Score:2, Insightful)
The UNIX philosophy was always groups of simple tools that do one thing and do it well. You pipe them together and parse the data however you want. Systemd does the exact opposite of that. One monolithic service doing everything but poorly.
If you build systemd with all configuration options enabled you will build 69 individual binaries. These binaries all serve different tasks, and are neatly separated for a number of reasons.
A package involving 69 individual binaries can hardly be called monolithic. What is different from prior solutions however, is that we ship more components in a single tarball, and maintain them upstream in a single repository with a unified release cycle.
The Biggest Myths [0pointer.de]
[2013]
You're beta testing this bullshit.
Then you are in damn good company.
Much of the debate about systemd is academic at this point because here's a truth that you'll discover in Debian 8, Ubuntu 15.04, and just about every other major distro around: systemd is here.
Debian 8: Linux's most reliable distro makes its biggest change since 1993 [arstechnica.com] [May 1, 2015]
Red Hat is the inventor and primary booster of systemd, so the best distros for playing with it are Red Hat Enterprise Linux, RHEL clones like CentOS and Scientific Linux, and of course good ole Fedora Linux, which always ships with the latest, greatest, and bleeding-edgiest.
Understanding and using Systemd [linux.com]
Re: (Score:2)
Systemd does the exact opposite of that. One monolithic service doing everything
Presumably by "service" you're not referring only to what process 1 does by itself (rather than by services it runs) on a system with systemd.
Re: (Score:3)
If you want to know why systemd doesn't follow the Unix way (which means it's lousy), I discuss parts of it here [slashdot.org].
Re: (Score:1)
That's a very well elucidated description of the problem.
Re: (Score:2)
Re: (Score:1)
Oh the one you linked. The bit about concentrating on code rather than interfaces. I'd not thought of it like that, but that makes a good deal of sense.
Re: (Score:2)
I remember you've written posts in the past about systemd that were rather insightful, too.
Re: (Score:2)
Yes, there is a point in talking about Posix standards as the way Unix works.
Re: (Score:2)
For variable values of "improvements". Some people (usually ones with a lot of experience and insights) think that the makers of systemd do not understand how Unix works or how to do professional system administration and hence view systemd rightfully as a step backwards.
So what? Use BSD, and revel in your superiority. If it is better, it will take over in no time.
From what I have read from y'all, it simply does not work, causes cancer, and will make your dog run away, and your wife either leave you or come back - whichever situation you don't want.
Re: (Score:2)
Exactly what features or improvements would that be? restarting capability for badly designed crap code that keeps falling over (instead of robustly written services)? integrated firewall, masquerading etc that should be in a separate system (and IS in BSD)?
Your "problems" are not a need for systemd, they are a need for proper tools and methodologies that exist already.
Re:Does it have systemd? (Score:5, Insightful)
Re: (Score:3)
Re: (Score:1)
This article isn't even about Linux, yet the comment section is filled with people who are pointing out serious flaws with systemd and the way it was shoved into every major distro.
In the articles that are actually about Linux, the comment sections look like war-zones. A significant amount of people voice their disapproval with systemd and the process by which RHEL shoved an extremely unpopular and major change into Linux. Yes, the distros did not have to adopt it. No, the distros can't defy RHEL's massi
Re: (Score:1)
Re: (Score:2)
linux doesn't have a systemd problem, systemd has an ignorant trolls problem
I would say they do considering this IS NOT A LINUX/SYSTEMD story!
Shoot I feel like I am watching Foxnews comments or MSNBC where a dog gets run over by a car caught on video and somehow it all goes back to Obama's fault. It is alike an autistic obession with these trolls. ... also that rant has nothing to do with OpenBSD either I may add.
But I see parallels now with anti SystemD here. What's next? A story about a new NVMe SSD storage breakthru ... a comment comes up about systemD in that in how we wouldn't
Re: (Score:1)
Re: (Score:3)
Re: (Score:3)
However, package managers are not able to express dependency on APIs. The only dependencies they can express are on other packages, or libraries. Now, dbus as an independent package has been terminated, so as it stands at present the way package managers express GNOME's true dependency on the DBUS API is to just list
Re: Does it have systemd? (Score:1)
dpkg most certainly can express virtual depends, such as depending on a package providing a dbus api.
Re: (Score:2)
Re: (Score:2)
Re: (Score:1)
NetBSD has twm, and that's all that's needed, though an upgrade to fvwm2 is kinda nice. twm is a binary that you get automatically in the base install, from the 406MB iso if you're on an x86 platform.
Which is all well documented in the O'Reilly X11 manual set. (The User's Guide is Vol. 3, the Administrator Guide is Vol. 8)
Re: (Score:2)
twm is a Window Manager, not a Desktop Environment. As such, it has no start menu, taskbar, etc, and does not come packaged with a set of apps such as a file manager, print manager, etc. As such you will have a damn tough sell trying to get anyone used to using a DE to convert to a bare WM. If you want to run a
Re: (Score:2)
Re: (Score:3)
If a Poettering-like asshole was detected anywhere near OpenBSD, they would be shot down like an aircraft flying over the White House without clearance.
Only one allowed per project (cough Theo De Raadt cough). I do grant that Theo's stuff works.