Devuan "jessie" is designed to match Debian "jessie" as much as possible, and is a one-off copying of the release name in order to mark the branching point in the histories of the two distros as they diverge slightly over time.
As the release announcement says:
"Devuan is the Debian that was and could have been. Our goal is to provide a viable and sustainable alternative. It is a new path, nurtured with your help and support."
so Devuan could be considered the true inheritor of the "jessie" name, and of the name "Debian", for that matter, although keeping that would obviously be too confusing.
Well, yes, I think we all got that point. It's just that Google's search bot may not. I'd be absolutely fine with something mechanically derived from "Jessie" (etc).
Reminds me of dragonfly bsd. Anyone still use that?
I stayed on 4.x until 6.x came out and later Scott Long actually admitted that 5.x was a bad release.
So Devuan now wants to continue Debian with tons of shell scripts to maintain while most other major distros move to systemd. That means package maintainers are moving to systemd. So Devuan will have to maintain separate init scripts for their distro mostly on their own.
I mean who in their right mind would write a 27 line init script when they could write a 7 line systemd unit?
"I mean who in their right mind would write a 27 line init script when they could write a 7 line systemd unit?"
27 lines is horribly optimistic. Complex services like Apache, MySQL, etc. could have initscripts hundreds of lines long, plus the library of support scripts that most distros ship to make the initscripts shorter and more manageable. Most initscripts are like 50%, or more, boilerplate that's the same across all services, but, it's still a pain in the ass to maintain them.
I will not miss initscripts, even if I might have some occasional complaints about systemd.
As I pointed out at https://news.ycombinator.com/item?id=14169188 , there's a discussion of MySQL on the systemd-devel mailing list right now. Clearly some people in that discussion are not familiar with MySQL. Clearly some of the people in this discussion are not familiar with MySQL either.
To help combat this ignorance, here are some actual systemd units:
So these figures that people are pulling out of thin air are erroneous by anywhere from half the actual length to an order of magnitude too small. And, ironically, the Apache systemd service unit is using a System 5 rc shell script under the covers to do all of the work. The apachectl program is in fact a System 5 rc script from 1997, complete with start/stop/restart/status verbs.
Yeah, legacy code is hard, sometimes, and sometimes complexity can't be hidden entirely.
The initscripts for MySQL/MariaDB are still orders of magnitude larger than these (unusually large) systemd unit files. Managing complexity is hard. SystemD helps. More modern service design, and simpler services, helps (compare/contrast Apache startup vs nginx or caddy, or MySQL vs MongoDB; sure, the newer options do less, but they do "enough" for some use cases).
You really should take the tack of learning about this subject rather than following rubbish numbers pulled out of thin air with more rubbish numbers pulled out of thin air. Here's the System 5 rc script for MariaDB. At 453 lines it is not even one order of magnitude larger than the systemd service unit, let alone orders of magnitude.
I recommend actually learning about the reality of MongoDB. For starters, the systemd service units supplied in the likes of Ubuntu and Debian do not set any of the settings recommended for MongoDB by its authors, so here (as in so many cases with systemd service units in the wild, alas) shortness actually equates to not doing things properly.
I recommend actually learning about Caddy, too. Ironically, the subject of its service unit came up here on Hacker News only a day ago. It is 43 lines long, some 6 times the length of the supposed 7-line systemd service unit being bandied about here, and not as far different from those for MySQL and Percona as you imply; and it does not attempt to be "more modern" as you claim, as it entirely lacks the socket unit that would make it more in line with the systemd way of doing things.
The idea that this is "modern service design" is borne of not knowing the subject, too. The sort of design changes recommended by the systemd people are in fact pretty much the same sort of design changes recommended by IBM in 1992 for services managed by the System Resource Controller and recommended by quite a lot of other people since, including Apple and ... well ... me for many years. Whilst this is good service design, it is not "modern", and not in any way unique or original to systemd. To further alleviate the ignorance of MySQL as well as demonstrate how this is far from "modern" and not something that one gets to claim for systemd service units, I point out that people were running mysqld without mysql_safe, in the very way that the systemd people are by all appearances just learning about in their mailing list discussion, under daemontools in 2002. I strongly suspect that that wasn't even the earliest occasion of that.
Counting empty lines and comments is hardly the way to make your point. The mariadb unit file you linked to is only 34 actual lines, the mysql unit file only 22, percona 23.
And if you're writing your own unit files rather than ones for public consumption, you probably won't include lines like "Documentation=" and some other minor args.
Actually, counting lines, whether empty, comment, or otherwise, very much is the way to make the point. The reality of actual service units that people write is not anything like the picture that was being painted. You erroneously think that the point is that short is good and long is bad, rather than what it actually is, which is learn the subject and don't make facile arguments based upon rubbish numbers plucked from thin air. Actually looking at reality and counting, rather than pulling the number 7 from a hat, is part of that point.
I recommend reading the design of the Mewburn rc system, http://jdebp.eu./FGA/run-scripts-and-service-units-side-by-s... , and some of the entries in the systemd House of Horror. This whole "It's just writing 7 lines and it's easy!" argument falls apart when one looks at the reality of short service units that are either grossly wrong or turn out to be underpinned by the very things that their lengths are being compared to (which also means that it is still those rc scripts that are being used and maintained by software authors -- from 1997 in the example of apachectl), real world service units that are not short, other systems of long standing that are equally concise, and -- yes -- the reality that people include commentary for maintainability.
One of the amusing things about this argument that is of particular relevance to the Devuan release is that back when Devuan was announced someone put up a "fork Fedora" WWW page criticizing the Devuan people, with a systemd service unit side by side with a van Smoorenburg rc script. It is sad to note that few people observed that the systemd unit described just one service, whereas the van Smoorenburg rc script ran two. Since you are on the subject of commentary, I invite you to observe which of the twain included comments and which did not, as well, and determine what point the "fork Fedora" people were in fact demonstrating. (-:
Thank you for putting this argument across so succinctly and with such good research behind it. Everytime I hear the arguments in favor of systemd, I wonder when these people actually come down from their ivory towers to do some real life work, where the rubber meets the road.
The argument of "lines of code" in a startup script is such a stupid strawman, it defies belief. I design and build large scale production system, and have exactly zero interest in the size (or complexity) of a startup script. I am interested in being secure in the knowledge that a control script handles all possible cases, including edge cases, that might present themselves during the forseeable lifecycle of the service/application in a predictable and understandable manner. If it takes a bit more time and work to understand these scripts, so be it - what are a few extra hours (which, incidentally, force you into a better understanding of the thing your working on - always a good thing) when seen across the timeline fo the service lifecycle?
systemd does a few cool things, and many blindingly retarded things. It is probably really nice to have on your laptop, what with the fast boot times and all, but many of the things touted as "advantages" really do not hold up for server work. What do I care if my boot time is a few seconds less on a server? rebooting a prod server is usually a scheduled event, with (depending on the context) can call for anywhere between a 30 to 120 minute maintenance window.
The systemd people should be made to work building and maintaining a real-life backend environment for a while.
You don't maintain an init script. You write it once. It doesn't do anything but run a program with an argument. There is no need to modify it except once every few years if your system or your application changes significantly in how it is started or stopped.
On Slack, the init scripts range from 6 lines (rc.font) to 445 lines (rc.S). Mean: 105, Median: 64, Mode: 56, 36, 48. BSD probably has even less complicated init scripts.
Your system might have more complicated init scripts, but it doesn't need them to be complicated. I suggest you direct your ire at your distribution, not init. (Most distributions totally misuse init and try to make it do things it was not intended for)
However, few sysv init scripts are the same structure. Each one is written by different people, who do things slightly different ways (and occasionally get things slightly wrong), and on different distros they use different tools. Debugging sysv init scripts is more complex than debugging a systemd unit file.
One example that neither camp does well is 'status'. Systemd is too verbose, but at least always the same standard output. Sysv init is whatever random noise the author decides to put out. Sometimes it's multiline. Sometimes it's no line, but an exit code. Sometimes it has colour. Sometimes it doesn't tell you whether it's running or not, but just outputs the service name. Sometimes you just have to be familiar enough with running the service such that you have what the status lines actually mean already in your head.
> It doesn't do anything but run a program with an argument.
It also needs to find that program again in order to provide status on it, stop it, and if the application has support, reload it. Very few init scripts are fire-and-forget startup scripts.
If you don't like the internal structure, you can change it! If you don't like the output formatting, you can change it! All with a few lines of shell script, immediately, no compiling, no rebooting!
You can't say the same of systemd. It has to be whatever systemd has compiled in. (Which, by default, is terse status, followed possibly by journal data, or just system status if no units are available) Sysctl status also loads a unit at run time, and then may unload it afterward, meaning it is not useful to see if a unit was already loaded. It also uses a UTF colored dot, combined with different lines that can be interpreted different ways. In other words: it is a complex arrangement of information. And for machine output, you need the 'show' command, and more options.
With sysv, you ask it for status and it tells you if it's running, if the script supports status. Clearly a complicated mess.
Your last comments don't make sense. Sysv init scripts don't have to "find" a program any more than any other method of executing a program. And all init scripts I can think of are fire-and-forget, as much as systemd or any other init program is. The only thing they don't do is continue to try the same operation over time or wait around for a dependency, if that's what you meant (which Sysv scripts aren't really supposed to do, but inittab supports it anyway)
I'll do you one better on your first comment: ALL Sysv init scripts are a different "structure" internally. Even in the way they are used! The reason is, they're just scripts. Outside of inittab, there is no real standard for how they work, so each system makes them work however they wish. They can write them so they're all the same, or all different, and make them called the same or different, and give them different features, or no features. This is why some people love Sysv - it is totally flexible. You can make it do anything you want, and all you need to know is csh.
With other apps (not just systemd, but lots of things) complicated custom domain-specific languages are invented to do little things, like change configuration files' permissions, or send a file somewhere. Csh/Bash allows you to do the same, except it's a lingua franca that is compatible with every Unix-like operating system. It's interpreted, it's flexible, it's portable, it's backwards compatible, it's composable, it's extendable.... I mean, this is really an amazing thing that no other language or tool can claim (other than web browsers). Any problem you have with Sysv you can fix it within Sysv, without requiring compiling code, or even rebooting. I know i'm beating a dead horse here, but I just can't see how anyone would want to throw all this amazing power away or see it as limiting.
If you wanted, you could write a systemd clone in bash, and make service/unit files out of bash. I don't know why nobody has done this yet, but probably because it would be self-defeating.
Yes of course, I was referring to the skeleton script in wheezy to be fair. ;)
A more normal systemd unit I wrote for one of my own services is actually 15 lines but that's for a Python service, with virtualenv and above all no shell script wrapping.
Not from my viewpoint. I'm the one installing the packages and writing the occasional unit/override unit in my daily work.
I don't see those complex use cases systemd critics often point to. I mostly see the fact that I get to maintain a few lines of ini-style configuration instead of many lines of bash.
I'm sorry but those links are no good argument to me.
I've already commented on the fact that MariaDB service unit is 173 lines of ini-style configuration with most of the lines commented for example purposes.
So I'd still gladly trade many lines of bash for hundreds of lines of ini-config.
And sure some projects still depend on shell script wrapping, I myself did for many python services that I run in virtualenv. But I learned more about systemd and eventually could get rid of all shell script wrappers.
But even in a worst case scenario where some project might have to use shell script wrapping, it's still better than ALL projects using 100% shell script.
I've been a Void user for a year and some months now. It's a great system. Xbps (the package manager) is so ridiculously fast, it puts zypper, apt and dnf to shame.
The base system is extremely light and nimble. Getting FDE up and running was a breeze, even with the fairly barebones installer, and it being a rolling release makes it very nice as well. It's maybe a bit too bleeding edge to run on servers, but as a workstation distribution, I can't fault it.
Disclaimer: I'm donating monthly to the project, and am currently trying to contribute a few servers to the build farm, so I'm probably very biased.
this looks interesting. I have been looking to replace ubuntu as my weapon of choice for servers for some time now. I am hesitant of the rolling release idea though. I like the idea that my servers remain in a specific state, but remain up to date with security patches, and don't like the idea of spending time fixing update issues. How is that handled in Void?
I'm glad the project exists and I hope it's stable enough to be adopted by companies in the future - my fear is that debian/rhel are entrenched now though.
Sidenote- So far this is not necessary, debian still has pluggable init systems as long as you don't add something which hard depends on systemd (like gnome)
I have done this one 5 of my own servers used for various things (including virtualhost/docker host) and it hasn't been an issue for over a year now.
> I'm glad the project exists and I hope it's stable enough to be adopted by companies in the future - my fear is that debian/rhel are entrenched now though.
It's not just debian/ubuntu/rhel, almost everyone has moved to systemd, even Arch Linux and Gentoo. As much as I agree with the ideas behind Devuan, knowing and understanding all the intricacies of systemd is now required knowledge for anyone doing Linux-based software development or devops. After putting it off for a while, I've moved on and have learned systemd. It's not the way I would have liked for the Linux ecosystem to have moved (I thought upstart was a decent base to build on), but I'm clearly in the minority here.
What's bothering most at this point are the binary log formats. But that changes from week to week. But it's here to stay, so I'm getting used to it.
> While Gentoo supports systemd, by default it will still use init scripts.
It's my understanding that notwithstanding the current accomodations, systemd is the future for Gentoo, is that incorrect? I'm not a Gentoo user, just what I've heard from people who are.
While you can find stage3 tarballs for systemd, OpenRC is still the default for Gentoo AFAIK. (And speaking of Arch Linux, I can't really say I miss initscripts)
It's fine for my desktop and laptop, it's not fine for my server.
My servers (generally speaking) do one thing and that thing absolutely can't be mucked with, systemd does a lot of what I would consider mucking.. binary complexity and weird integration I seriously dislike.
But it's actually beneficial on a desktop system.
My friends who have learned systemd are basically the same as you- "Eh, it's alright when it works.. and it's where everyone has gone so I guess I'll live with it"
I take exception to that statement entirely, this is open source, the land where you can replace your kernel with a BSD one and continue trucking with GNU ultilities as if nothing happened basically- why do we have to go backwards in usability for someones ego.
(and it's hard for me not to see it as one mans ego given his repeated hostility and arrogance regarding how other people use computers professionally)
> I take exception to that statement entirely, this is open source, the land where you can replace your kernel with a BSD one and continue trucking with GNU ultilities
Fair enough. And to be fair to me, I've been thinking seriously about moving my workstation over to a BSD. But even if I do that, I'd still have to deal with Linux for work at times.
As someone out of the loop with any of this (I've always just been content with using Debian as-is, and I haven't done much work with systemd), can someone explain why systemd is as bad as it seems to be? As in, why is it so bad that an entire major Linux distro was forked and created with the seemingly sole purpose of removing this program?
Poorly-designed, poorly-implemented, half-baked ideas, legendary feature creep that presents a corollary to Zawinsky's Law, awful developers, clear political agendas in the devteam, Embrace-Extend-Extinguish tactics, against the basic UNIX concept of "many small apps that do one thing and do it well", an informal adoption of Windows service/logging techniques, political lobbying by the developers, and a literal RPC-based backdoor into the enforceability of the GPL.
Some of the 4chan people trolling about systemd try to make people believe that communicating over tcp sockets, pipes or dbus with other processes is a "backdoor" around the GPL. Because a non-free program could talk to a GPL progam. Shocking!
52 comments
[ 5.0 ms ] story [ 120 ms ] threadCome on... if you're going to fork a distribution, use different release names.
They call Jessie a "Matching release", I guess the intention is to stress the fact that you can safely migrate from Debian without a reinstall.
... but I actually agree with duskwuff. It's hugely confusing and possibly even disingenuous to call it "jessie".
As the release announcement says:
"Devuan is the Debian that was and could have been. Our goal is to provide a viable and sustainable alternative. It is a new path, nurtured with your help and support."
so Devuan could be considered the true inheritor of the "jessie" name, and of the name "Debian", for that matter, although keeping that would obviously be too confusing.
Reminds me of dragonfly bsd. Anyone still use that?
I stayed on 4.x until 6.x came out and later Scott Long actually admitted that 5.x was a bad release.
So Devuan now wants to continue Debian with tons of shell scripts to maintain while most other major distros move to systemd. That means package maintainers are moving to systemd. So Devuan will have to maintain separate init scripts for their distro mostly on their own.
I mean who in their right mind would write a 27 line init script when they could write a 7 line systemd unit?
27 lines is horribly optimistic. Complex services like Apache, MySQL, etc. could have initscripts hundreds of lines long, plus the library of support scripts that most distros ship to make the initscripts shorter and more manageable. Most initscripts are like 50%, or more, boilerplate that's the same across all services, but, it's still a pain in the ass to maintain them.
I will not miss initscripts, even if I might have some occasional complaints about systemd.
To help combat this ignorance, here are some actual systemd units:
* https://github.com/MariaDB/server/blob/10.1/support-files/ma... -- MariaDB's official systemd service unit, 173 lines long
* https://github.com/mysql/mysql-server/blob/5.7/scripts/syste... -- MySQL's official systemd service unit, 60 lines long
* https://github.com/percona/percona-server/blob/5.7/scripts/s... -- Percona's official systemd service unit, 61 lines long
* https://sources.debian.net/src/apache2/2.4.25-3/debian/apach... -- Debian's third party systemd service unit for Apache2, 15 lines long
So these figures that people are pulling out of thin air are erroneous by anywhere from half the actual length to an order of magnitude too small. And, ironically, the Apache systemd service unit is using a System 5 rc shell script under the covers to do all of the work. The apachectl program is in fact a System 5 rc script from 1997, complete with start/stop/restart/status verbs.
The initscripts for MySQL/MariaDB are still orders of magnitude larger than these (unusually large) systemd unit files. Managing complexity is hard. SystemD helps. More modern service design, and simpler services, helps (compare/contrast Apache startup vs nginx or caddy, or MySQL vs MongoDB; sure, the newer options do less, but they do "enough" for some use cases).
* https://github.com/MariaDB/server/blob/10.1/support-files/my...
I recommend actually learning about the reality of MongoDB. For starters, the systemd service units supplied in the likes of Ubuntu and Debian do not set any of the settings recommended for MongoDB by its authors, so here (as in so many cases with systemd service units in the wild, alas) shortness actually equates to not doing things properly.
* http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/vivid/mo...
* https://sources.debian.net/src/mongodb/1:3.2.11-2/debian/mon...
* https://docs.mongodb.com/manual/reference/ulimit/#linux-dist...
Another example of such is WSO2 Carbon, with a 14-line system service unit from one source that gets things grossly wrong.
* http://jdebp.eu./FGA/systemd-house-of-horror/wso2.html
I recommend actually learning about Caddy, too. Ironically, the subject of its service unit came up here on Hacker News only a day ago. It is 43 lines long, some 6 times the length of the supposed 7-line systemd service unit being bandied about here, and not as far different from those for MySQL and Percona as you imply; and it does not attempt to be "more modern" as you claim, as it entirely lacks the socket unit that would make it more in line with the systemd way of doing things.
* https://news.ycombinator.com/item?id=14167704
The idea that this is "modern service design" is borne of not knowing the subject, too. The sort of design changes recommended by the systemd people are in fact pretty much the same sort of design changes recommended by IBM in 1992 for services managed by the System Resource Controller and recommended by quite a lot of other people since, including Apple and ... well ... me for many years. Whilst this is good service design, it is not "modern", and not in any way unique or original to systemd. To further alleviate the ignorance of MySQL as well as demonstrate how this is far from "modern" and not something that one gets to claim for systemd service units, I point out that people were running mysqld without mysql_safe, in the very way that the systemd people are by all appearances just learning about in their mailing list discussion, under daemontools in 2002. I strongly suspect that that wasn't even the earliest occasion of that.
* http://jdebp.eu./Softwares/nosh/mariadb-and-mysql.html#Promp...
And if you're writing your own unit files rather than ones for public consumption, you probably won't include lines like "Documentation=" and some other minor args.
I recommend reading the design of the Mewburn rc system, http://jdebp.eu./FGA/run-scripts-and-service-units-side-by-s... , and some of the entries in the systemd House of Horror. This whole "It's just writing 7 lines and it's easy!" argument falls apart when one looks at the reality of short service units that are either grossly wrong or turn out to be underpinned by the very things that their lengths are being compared to (which also means that it is still those rc scripts that are being used and maintained by software authors -- from 1997 in the example of apachectl), real world service units that are not short, other systems of long standing that are equally concise, and -- yes -- the reality that people include commentary for maintainability.
One of the amusing things about this argument that is of particular relevance to the Devuan release is that back when Devuan was announced someone put up a "fork Fedora" WWW page criticizing the Devuan people, with a systemd service unit side by side with a van Smoorenburg rc script. It is sad to note that few people observed that the systemd unit described just one service, whereas the van Smoorenburg rc script ran two. Since you are on the subject of commentary, I invite you to observe which of the twain included comments and which did not, as well, and determine what point the "fork Fedora" people were in fact demonstrating. (-:
The argument of "lines of code" in a startup script is such a stupid strawman, it defies belief. I design and build large scale production system, and have exactly zero interest in the size (or complexity) of a startup script. I am interested in being secure in the knowledge that a control script handles all possible cases, including edge cases, that might present themselves during the forseeable lifecycle of the service/application in a predictable and understandable manner. If it takes a bit more time and work to understand these scripts, so be it - what are a few extra hours (which, incidentally, force you into a better understanding of the thing your working on - always a good thing) when seen across the timeline fo the service lifecycle?
systemd does a few cool things, and many blindingly retarded things. It is probably really nice to have on your laptop, what with the fast boot times and all, but many of the things touted as "advantages" really do not hold up for server work. What do I care if my boot time is a few seconds less on a server? rebooting a prod server is usually a scheduled event, with (depending on the context) can call for anywhere between a 30 to 120 minute maintenance window.
The systemd people should be made to work building and maintaining a real-life backend environment for a while.
Also most of it is commented as examples.
On Slack, the init scripts range from 6 lines (rc.font) to 445 lines (rc.S). Mean: 105, Median: 64, Mode: 56, 36, 48. BSD probably has even less complicated init scripts.
Your system might have more complicated init scripts, but it doesn't need them to be complicated. I suggest you direct your ire at your distribution, not init. (Most distributions totally misuse init and try to make it do things it was not intended for)
One example that neither camp does well is 'status'. Systemd is too verbose, but at least always the same standard output. Sysv init is whatever random noise the author decides to put out. Sometimes it's multiline. Sometimes it's no line, but an exit code. Sometimes it has colour. Sometimes it doesn't tell you whether it's running or not, but just outputs the service name. Sometimes you just have to be familiar enough with running the service such that you have what the status lines actually mean already in your head.
> It doesn't do anything but run a program with an argument.
It also needs to find that program again in order to provide status on it, stop it, and if the application has support, reload it. Very few init scripts are fire-and-forget startup scripts.
You can't say the same of systemd. It has to be whatever systemd has compiled in. (Which, by default, is terse status, followed possibly by journal data, or just system status if no units are available) Sysctl status also loads a unit at run time, and then may unload it afterward, meaning it is not useful to see if a unit was already loaded. It also uses a UTF colored dot, combined with different lines that can be interpreted different ways. In other words: it is a complex arrangement of information. And for machine output, you need the 'show' command, and more options.
With sysv, you ask it for status and it tells you if it's running, if the script supports status. Clearly a complicated mess.
Your last comments don't make sense. Sysv init scripts don't have to "find" a program any more than any other method of executing a program. And all init scripts I can think of are fire-and-forget, as much as systemd or any other init program is. The only thing they don't do is continue to try the same operation over time or wait around for a dependency, if that's what you meant (which Sysv scripts aren't really supposed to do, but inittab supports it anyway)
I'll do you one better on your first comment: ALL Sysv init scripts are a different "structure" internally. Even in the way they are used! The reason is, they're just scripts. Outside of inittab, there is no real standard for how they work, so each system makes them work however they wish. They can write them so they're all the same, or all different, and make them called the same or different, and give them different features, or no features. This is why some people love Sysv - it is totally flexible. You can make it do anything you want, and all you need to know is csh.
With other apps (not just systemd, but lots of things) complicated custom domain-specific languages are invented to do little things, like change configuration files' permissions, or send a file somewhere. Csh/Bash allows you to do the same, except it's a lingua franca that is compatible with every Unix-like operating system. It's interpreted, it's flexible, it's portable, it's backwards compatible, it's composable, it's extendable.... I mean, this is really an amazing thing that no other language or tool can claim (other than web browsers). Any problem you have with Sysv you can fix it within Sysv, without requiring compiling code, or even rebooting. I know i'm beating a dead horse here, but I just can't see how anyone would want to throw all this amazing power away or see it as limiting.
If you wanted, you could write a systemd clone in bash, and make service/unit files out of bash. I don't know why nobody has done this yet, but probably because it would be self-defeating.
Yes of course, I was referring to the skeleton script in wheezy to be fair. ;)
A more normal systemd unit I wrote for one of my own services is actually 15 lines but that's for a Python service, with virtualenv and above all no shell script wrapping.
That is a gross and asinine misrepresentation of the impact of systemd.
I don't see those complex use cases systemd critics often point to. I mostly see the fact that I get to maintain a few lines of ini-style configuration instead of many lines of bash.
I've already commented on the fact that MariaDB service unit is 173 lines of ini-style configuration with most of the lines commented for example purposes.
So I'd still gladly trade many lines of bash for hundreds of lines of ini-config.
And sure some projects still depend on shell script wrapping, I myself did for many python services that I run in virtualenv. But I learned more about systemd and eventually could get rid of all shell script wrappers.
But even in a worst case scenario where some project might have to use shell script wrapping, it's still better than ALL projects using 100% shell script.
The person who already knows the one tool, but not the other, I suppose. Or who finds it easier to read a shell script than a new DSL.
https://news.ycombinator.com/item?id=14173666
No issues hardware-wise either so far:
- Intel Core i7-7700K
- MSI Z270 Gaming Pro Carbon
- Gigabyte GeForce GTX 1060 WINDFORCE OC 6G
- Samsung 960 EVO 1TB (M.2, NVME)
The base system is extremely light and nimble. Getting FDE up and running was a breeze, even with the fairly barebones installer, and it being a rolling release makes it very nice as well. It's maybe a bit too bleeding edge to run on servers, but as a workstation distribution, I can't fault it.
Disclaimer: I'm donating monthly to the project, and am currently trying to contribute a few servers to the build farm, so I'm probably very biased.
The single issue I have had so far, is that backports weren't marked as non-automatic: easily solved with a manual pin-priority rule.
I mailed them about it, so it could be solved now.
Sidenote- So far this is not necessary, debian still has pluggable init systems as long as you don't add something which hard depends on systemd (like gnome)
I have done this one 5 of my own servers used for various things (including virtualhost/docker host) and it hasn't been an issue for over a year now.
http://without-systemd.org/wiki/index.php/How_to_remove_syst...
It's not just debian/ubuntu/rhel, almost everyone has moved to systemd, even Arch Linux and Gentoo. As much as I agree with the ideas behind Devuan, knowing and understanding all the intricacies of systemd is now required knowledge for anyone doing Linux-based software development or devops. After putting it off for a while, I've moved on and have learned systemd. It's not the way I would have liked for the Linux ecosystem to have moved (I thought upstart was a decent base to build on), but I'm clearly in the minority here.
What's bothering most at this point are the binary log formats. But that changes from week to week. But it's here to stay, so I'm getting used to it.
It's my understanding that notwithstanding the current accomodations, systemd is the future for Gentoo, is that incorrect? I'm not a Gentoo user, just what I've heard from people who are.
* http://repo.or.cz/archnosh.git
* https://wiki.gentoo.org/wiki/Nosh
It's fine for my desktop and laptop, it's not fine for my server.
My servers (generally speaking) do one thing and that thing absolutely can't be mucked with, systemd does a lot of what I would consider mucking.. binary complexity and weird integration I seriously dislike.
But it's actually beneficial on a desktop system.
My friends who have learned systemd are basically the same as you- "Eh, it's alright when it works.. and it's where everyone has gone so I guess I'll live with it"
I take exception to that statement entirely, this is open source, the land where you can replace your kernel with a BSD one and continue trucking with GNU ultilities as if nothing happened basically- why do we have to go backwards in usability for someones ego.
(and it's hard for me not to see it as one mans ego given his repeated hostility and arrogance regarding how other people use computers professionally)
Fair enough. And to be fair to me, I've been thinking seriously about moving my workstation over to a BSD. But even if I do that, I'd still have to deal with Linux for work at times.
Changing old init scripts to systemd scripts is un-asked for work for many. And it is made by a polarising figure, which leads to emotional refusal.
Poorly-designed, poorly-implemented, half-baked ideas, legendary feature creep that presents a corollary to Zawinsky's Law, awful developers, clear political agendas in the devteam, Embrace-Extend-Extinguish tactics, against the basic UNIX concept of "many small apps that do one thing and do it well", an informal adoption of Windows service/logging techniques, political lobbying by the developers, and a literal RPC-based backdoor into the enforceability of the GPL.
Oh, I didn't hear that one before - any more info?