Lennart Poettering Announces the First Systemd Conference 416
jones_supa writes: Lennart Poettering, the creator of the controversial init system and service manager for Linux-based operating systems has announced the first systemd conference. The systemd.conf will take place November 5-7, in Berlin, Germany. systemd developers and hackers, DevOps professionals, and Linux distribution packagers will be able to attend various workshops, as well as to collaborate with their fellow developers and plan the future of the project. Attendees will also be able to participate in an extended hackfest event, as well as numerous presentations held by important names in the systemd project, including Poettering himself.
Obligatory (Score:2)
https://www.youtube.com/watch?... [youtube.com]
Re: (Score:3)
Is this a clip from the last systemd conference?
Startup management subsystem (Score:5, Insightful)
Re: (Score:2)
I've noticed a trend- conferences that are paid-for by third-parties that sponsor the attendees, be they employers or charities or governments, are usually held in places where people want to go, while conferences that are paid for by the attendees themselves are usually held in less-desirable places or times (ie, winter in Minneapolis or summer in Phoenix). If the attendees are sponsored they go whole-hog, and if they pay th
Re: Startup management subsystem (Score:3)
Cold and full of Germans *hides*
Re: (Score:3)
I wonder which Berlin is in November? I've never been there myself.
Berlin is always worth a visit. Late November in German cities are nice, since you will find small booths selling "Glühwein" and various food (like sausages) everywhere.
While Berlin is nice in the summer with its biergartens, trees and sailing on the Spree, they have top notch museums too, like everything in the "museumsinsel/ Museum Island".
Re:Startup management subsystem (Score:4, Informative)
It does seem a bit much, but the systemd transition is a slow one. Many packages are still using init.d startup scripts, which means we can't take advantage of systemd's features with them.
Systemd isn't really a startup management subsystem. It's a full blown service manager. It can be set, at the user's choice, to restart services when there's a problem. It can provide detailed logs from each service.
The best part is the service descriptor files follow a standard. If all people did at this conference was convert package init scripts to systemd I would be ecstatic.
Re: (Score:2)
It does seem a bit much, but the systemd transition is a slow one. Many packages are still using init.d startup scripts, which means we can't take advantage of systemd's features with them.
You should be able to take advantage of all of systemd's features whether the daemon is designed to be run from an init script or not, and even whether it is run from an init script or not. If not, there is either something deeply wrong with you (incompetence) or deeply wrong with systemd (poor design.)
Re: (Score:3)
Key features like dependency management, whether a service terminated with an error condition, and what to do when a service terminates are things that you CAN NOT DO if all you have is an init script.
Of course you can. You know the PID of the init script, and you know PPIDs. What prevents you from doing that? Even a shell script could do it.
Re:Startup management subsystem (Score:4, Insightful)
Systemd isn't really a startup management subsystem. It's a full blown service manager.
OK...
.
If a service manager subsystem needs its own conference, it is doing too much.
Re:Startup management subsystem (Score:5, Informative)
Call for Presentations We’d like to invite presentation proposals for systemd.conf 2015. We are looking for talks including, but not limited to the following topics: - Use Cases: systemd in today’s and tomorrow’s devices and applications, - systemd and containers, in the cloud and on servers, - systemd in distributions, - Embedded systemd, - systemd on the desktop, - Networking with systemd, - D-Bus and kdbus IPC systems, - and everything else related to systemd.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
The best part is the service descriptor files follow a standard. If all people did at this conference was convert package init scripts to systemd I would be ecstatic.
Honest question (to who ever might know) ... are systemd service descriptor files distribution independent?
People will tell you init scripts can be and can point you to standards for writing them, but in practice it usually doesn't work out too well. Not in a way that takes advantage of the various features of any given system. Distributions tend to be unique in various ways.
I'm just wondering if systemd fixes that or if each distro is still going to have to roll their own because of distro unique conve
Re: (Score:2)
Re: (Score:3, Informative)
You could refute that trivially by clearly stating what problem it actually solves. Yet you chose not to do that.
Re: (Score:2)
Re:Startup management subsystem (Score:4, Insightful)
You could refute that trivially by clearly stating what problem it actually solves. Yet you chose not to do that.
systemd solves many old Linux problems; besides the technical ones like proper service management, it also solves the problem with fossilized development of subsystems like init and logging, and solves the old problem of lack of coordination between userland, kernel space, and the plumbing layer between.
systemd, as init and process manager, actually takes on the coordination responsibility that lacked previously. It is way cool how "namespace" isolation and kernel Capabilities(7) are integrated so system admins can turn on such security features just by adding a Boolean value in a text file. It also means that every iteration of systemd distros become ever more hardened per default, making ever more difficult for the the black hats to gain privilege escalation.
By dismissing every systemd feature and everything systemd does as "bad", systemd-opponents like you paint yourself and all your fellow travelers into an ever smaller corner, where "SysVinit/OpenRC" is the pinnacle of evolution without ever needing more features.
Good luck with that.
Re: (Score:3, Interesting)
it also solves the problem with fossilized development of subsystems like init and logging,
Not a problem, and also not actually a thing. Several competing init systems which didn't bring baggage with them already existed, but Lennart is a real NIH kind of guy so he didn't start with one of those. Stable init and log daemons are features, not bugs.
systemd, as init and process manager, actually takes on the coordination responsibility that lacked previously. It is way cool how "namespace" isolation and kernel Capabilities(7) are integrated
You do realize that cgroups is a thing you diddle with very small commandline programs, right? And by making directories? These are things which could be done in init scripts. Most distributions use standard init script libraries where such initializatio
Re:Startup management subsystem (Score:4, Insightful)
I think you need to read up about cgroups - https://en.wikipedia.org/wiki/... [wikipedia.org] - or are you saying cgroups are a solution looking for a problem?
"Most distributions use standard init script libraries where such initialization can take place." -not really, you can't always transfer a script from one distro to another and expect it to work without modification which is another problem systemd has addressed
Re: (Score:3)
Re:Startup management subsystem (Score:5, Interesting)
I'd rather have a system that does it better without having to resort to scripts all over the place to make up for deficiencies in the system.
You seem to be making the tacit assumption that everything works perfectly. If I am debugging a system then I would much prefer to deal with scripts (usually all in one place or otherwise easily found) than have to try to debug C and C++ code and XML schema. See Theodore Ts'o comments [google.com] that were linked to above.
It reminds of me dealing with Microsoft systems (many years ago from the NT days, maybe they have changed since then). *IF* everything works pefectly then it is fine but as soon as you are in the mode of tracking down problems then it becomes a nightmare. This is why I made the switch from Windows-NT to Linux when I was doing sysadmin at a university. If I wanted to use a system that was like that then I would use Windows. This tacit assumption that the system was designed perfectly so there is no need for any intervention is one of the reason people don't want to give up init scripts on their Linux systems and replace them with systemd.
Re: (Score:3)
Isn't that an argument that everything should be written in shell script?
It's an argument that everything which reasonably can and should be written in a shell script (that is, without compromising security or performance) should be. A shitload of what makes a modern Linux go is just scripting. Sadly, many of them are python scripts; shell scripting will do the jobs they do without exception, but people jumped on the new shiny (like they did with perl, as well) and that results in a system where you have to understand three scripting languages to maintain it, not just one. Clear
Re:Startup management subsystem (Score:4, Informative)
it also solves the problem with fossilized development of subsystems like init and logging,
Not a problem, and also not actually a thing. Several competing init systems which didn't bring baggage with them already existed, but Lennart is a real NIH kind of guy so he didn't start with one of those. Stable init and log daemons are features, not bugs.
Yes, it is a "thing". The problem with the fossilization of the Linux plumbing layer meant that crucial progress was being held back. All the init-systems in use at the time where just "slightly improved SysVinit" style init-systems. They all relied on executable config scripts to manage daemons, and none of them tried to step up an take proper responsibility for the boot and init process.
Upstart was a nice pioneering effort, but not a good solution as it were. But there are still other problems; crond fx. Why can't it handle hibernation properly? Probably because it was made when Unix servers where hand grafted out of shell scripts an always on. But there is no "cron" upstream developer group that takes RFE's, and no coordination between the many fragmented crond forks and userland developers, making all new development practically impossible. It would have been freaking nice if crond could have been dragged into the modern world 10-15 years ago, but as of now, we have to use crond+at+whatever instead.
systemd, as init and process manager, actually takes on the coordination responsibility that lacked previously. It is way cool how "namespace" isolation and kernel Capabilities(7) are integrated
You do realize that cgroups is a thing you diddle with very small commandline programs, right?
You are probably thinking of the old cgroups interface, but that is being deprecated in the near future in favor of the "single writer"/"unified hierarchy" that requires a writer that abstract away the kernel cgroup API so userland doesn't use it directly.
http://www.linuxfoundation.org... [linuxfoundation.org]
The point is that system already comes with such an abstraction layer for capabilities, namespaces and cgroups, making it trivially easy for the admin to harness their power without coding, by simply setting the value "ProtectSystem=true" in the service file, or using similar features (see man systemd.exec). Better yet, distro maintainers can lock down the daemon per default, giving "out-of-the-box" security.
There is nothing else that even comes close to the power of systemd when it comes to such security integration. The systemd security framework for these kernel technologies are not only easy for humans to read and understand, but it is machine parsable and scalable too.
To my knowledge nobody in the non-systemd camp is even working on similar ideas, or even on an alternative cgroups single writer implementation.
Not tying it to a specific log daemon is the really important part, though!
Which is _exactly_ what journald _doesn't_! You can use it together with any "syslog(3)" daemon. So if you have a legacy setup, you can use with journald and it will even enhance it by providing logging info syslog normally can't get.
Re: (Score:3)
All the init-systems in use at the time where just "slightly improved SysVinit" style init-systems.
You're missing the point, deliberately I hope because the alternative is too pathetic to contemplate. Those init systems were in use at the time because you could swap between them freely. Systemd deliberately breaks that state of affairs and that is what is primarily wrong with it.
They all relied on executable config scripts to manage daemons, and none of them tried to step up an take proper responsibility for the boot and init process.
Proper responsibility? No, you have that wrong. They did everything they had to do.
You are probably thinking of the old cgroups interface, but that is being deprecated in the near future in favor of the "single writer"/"unified hierarchy" that requires a writer that abstract away the kernel cgroup API so userland doesn't use it directly.
Oh great, more influence of systemd shitting up my Linux. Just want I wanted to hear about. So instead of a simple, working interface to cgroups,
Re: (Score:2, Redundant)
"I don't actually have any particularly strong opinions on systemd itself. I've had issues with some of the core developers that I think are much too cavalier about bugs and compatibility, and I think some of the design details are insane (I dislike the binary logs, for example), but those are details, not big issues."
Re: (Score:2)
Re: (Score:2)
Indeed, they are. At least those integrated into the system. I found that whenever I implement some service, I need special things for monitoring and restarting it anyways. It is really not hard doing your own service manager that then just gets started by init.
Re:Startup management subsystem (Score:5, Funny)
I tried to register for it, but the system said no tickets were available. I sent in a note about that and got a response saying that ticket availability wasn't in the plans and that I was stupid for wanting one.
Re: (Score:2)
If a startup management subsystem needs its own conference, it is doing too much.
Correction : startup management system backed , propagated and funded by Redhat
Re: (Score:2)
Systemd don't need no stinken' conference? (Score:2)
That has to be the dumbest statement I have read on any technical forum - ever !
I suppose if he didn't organize a conference, people like you would complain that he was dictating to Linux developers.
Re: (Score:2)
Fascinatingly, none of the self-destructiveness claimed by the systemd fanatics against the systemd opponents has ever manifested itself. Maybe it is just propaganda?
Re: (Score:3)
"Has systemd actually seen a code audit? With all this new, relatively
Free speech zone (Score:2)
Re: (Score:2)
Re:Free speech zone (Score:5, Interesting)
In brief, the good:
* Systemd makes it easier for distro maintainers to write startup scripts, which is something a lot of them wanted.
The bad:
* Poor understanding of interfaces by the lead developers.
* Poor understanding of portability by the lead developers.
* Poor understanding of separation of concerns.
* Scope creep (there is no reason Gnome should depend on systemd).
* Binary files are a symptom of idiocy......more specifically, binary/text is not something that should be decided by the init system.
Re:Free speech zone (Score:5, Insightful)
>* Scope creep (there is no reason Gnome should depend on systemd).
Gnome doesn't depend on systemd as such, but on the systemd-logind API. Until recently (perhaps it still does) it also supported the old ConsolKit API as alternative even though CK had been dead for +1½ year with no upstream bug fixing or security support, and no one bothered to maintain it anyway.
The problem seems to be that the systemd-opponents really don't understand how Open Source software works and being developed, something that requires coordination, and positive contributions with either code, documentation, or money.
Claiming that the systemd developers are incompetent and doesn't understand software development will get you nowhere. You have to employ your superior knowledge into actual competing projects in order to be taken seriously. But that is the problem isn't it? The total lack of effort by the systemd-opponents to actually create something useful.
Re: (Score:3)
The problem seems to be that the systemd-opponents really don't understand how Open Source software works and being developed, something that requires coordination, and positive contributions with either code, documentation, or money.
The problem seems to be that you didn't read any of my posts that I linked to earlier. From what you've written, it doesn't even seem like you understand systemd very well. Yet somehow you are a huge proponent of systemd. I don't know. What do you like about it? That's a serious question.
Re: (Score:2)
Yes it does [slashdot.org]. You can't separate logind from systemd (although that would be good software engineering, if they were separable). The systemd-logind API is deeply integrated into systemd. It shouldn't be, but it is.
You are misinformed. CK2 and systemd-shim are alternative implementations of the systemd-logind API (or at least the subset of the API Gnome/KDE actually need). The CK2 developers abandoned the old CK API in favor of the systemd API, simply because the systemd-logind API developed by Lennart Poettering is much nicer
There are actual good technical reasons why systemd is made like it is and why systemd-logind is part of the systemd project. You simply can't get the same features such as multi-seat without suc
Re: (Score:2)
You simply can't get the same features such as multi-seat without such integration.
There was multi-seat X before there was systemd. How can it be that you can't have multi-seat without such integration?
Re:Free speech zone (Score:4, Interesting)
There are actual good technical reasons why systemd is made like it is and why systemd-logind is part of the systemd project.
There are no good technical reasons. Having a window manager depend on a particular startup manager is poor design, there's no way around that.
You are misinformed. CK2 and systemd-shim are alternative implementations of the systemd-logind API (or at least the subset of the API Gnome/KDE actually need).
I discuss that here [slashdot.org]. If you think I am misinformed, I will look into it more deeply.
Re:Free speech zone (Score:5, Informative)
ok, so now I'm interested. You are clearly a strong proponent of systemd (some might even say 'fanboy'). What is it about systemd that you like so much? What are the features that really help you? What inspires your advocacy?
Not really a fan boy. Actually I don't care at all what other people use as init-system. I am cool with Slackware going their own way, and I respect P. Volkerding's Linux vision, even though it isn't the same as mine.
The main reasons why I am going into the systemd debate was that I frankly was tired of all the stupid misinformation spread about it. Some of it deliberate lies, but most often it is misinformation copied from some swivel-eyed loony and then repeated again and again until people take it as truth.
My favorite example on this was the often repeated claim that Gnome had "hard dependencies on systemd" and these where "pushed/forced" into Gnome by Poettering. Just because Gnome support systemd for session management, doesn't mean it can't support an alternative too.
And in fact, Gnome did exactly that, despite that ConsolKit was dead and unsupported upstreams, they still supported it years afterwards, while pleading on various blogs and mailing lists (including Debian's) that some should either maintain CK or make an alternative. Nobody did that and the non-systemd camp can only blame themselves for that.
Perhaps one of the reasons why nobody started to make an alternative could be that so many people claimed that Gnome had hard dependencies on systemd, making it look like Gnome only cared for systemd support, so why bother. A self fulfilling prophecy.
I have been a Linux user since Slackware came on 40 floppies. I like Linux, I like the technical progress it has experienced since, and I actually remember technical discussions before year 2000 on the problems with SysVinit, and syslog and the lack of coordination of the Linux plumbing layer.
To me systemd was an answer to my prayers with what I didn't like with Linux: SysVinit (it is only simple when doing simple things, and it is only simple because it outsources complexities into daemons etc, the complexities are still there.), service management; new and inconsistent tools among each distro, and lets not forget the time wasted on grafting some service management system on top. Logging too. I had high hopes for Rsyslog when they started in 2005, and while I really respect their work, they didn't solve several of the problems they set out to solve (perhaps not incidentally many of the same problems systemd have actually solved). The reason wasn't lack of will, but total lack of coordination in Linux between userland, the OS layer (where Rsyslog belongs) and kernel.
I have always played with new tech, including ones I didn't have a need for at the moment. So when systemd came out, I actually sat down one afternoon and just started to read, and read the documentation. I then started to play around with it. It really convinced me how good systemd was, and how much potential it has.
systemd is different, and it really does require some serious studying in order to use it. You just can't wing it, even if you have loads SysVinit/Upstart experience.
There are several technical things I like about systemd and I find superior to similar solutions, especially security. But perhaps what I really like about _using_ systemd is how much the developers care for the end users. It is in the small details like awesome bash-completion, sane defaults, how everything us documented in the man-pages, there is even a manpage containing a list of all the systemd man-pages (man systemd.index ) and a reverse list of every file, config option, CLI option etc (man systemd.directives) and overview pages like "man bootup" that shows and explain the boot process. And the way they abstract away all the difficult bits into simple declarative statements that goes into structured text files. And tools like "systemd-delta" that instantly gives an overview of changed service files.
Re:Free speech zone (Score:4, Insightful)
Don't give me that crap;
STFU? Anyone can insult, it doesn't make your point stronger.
Poettering has a CS degree and has coded Linux for +10 years now,
So have I......so what? When Poettering writes straight code, it's pretty good. I would be happy to have him as a coworker. The problem is when he starts architecting, that's where he lacks skill. He would be wise to read some basic documents on the topic [catb.org].
Then sometimes he makes amusing rookie [slashdot.org] mistakes [slashdot.org]. So that's where he is as a programmer: good code, poor design.
Not studying systemd is simply professional suicide when it comes to Linux.
Thanks, I appreciate the concern. I don't make money based on my ability to use whatever software, I make my money designing good software. Although I've spent plenty of time studying systemd, so my career is safe.
btw, that points to the difference between people who like systemd, and people who don't. Those who favor it tend to look at the features, and say they are decent. Those who dislike it tend to look at the design, and say, "that's kind of wonky." A person can hold both opinions, they are not logically inconsistent. Unit files clearly fill a need people have.
Re: (Score:3)
Seriously, you are handicapped because you don't understand architecture, so you can only repeat things you've heard. It's hard to have a reasonable discussion with you on this topic, because you lack the necessary skills. That's ok, not everyone needs to be a programmer.
Here is an example you should be able to understand, though. Your response will show whether you blindly worship at the feet of systemd
Re: (Score:2)
"Poor understanding of interfaces by the lead developers." - thats a new one - where did you get that from, give us some backup to see what you mean.
"Poor understanding of portability by the lead developers." - portable to where?
So where is this years GrepCon and BashCon? (Score:2)
We are systemd (Score:5, Funny)
We are systemd. Lower your MBR protection and surrender your init system. We will add your daemons, libraries, and utilities to our own. Your code will adapt to service us. Resistance is futile.
We don't need more systemd hate! (Score:3, Funny)
all we need is a nice little bomb... We know when and where they will be - take out their leaders and we can move on to something useful!
Re: (Score:2)
Re: (Score:3)
Sounds like a job for Cron.
Re: (Score:2)
Sounds like a job for Cron.
Better yet, systemd/Timers: https://wiki.archlinux.org/ind... [archlinux.org]
Re: (Score:2)
No, not funny. Go write a better init replacement yourself then, no need to even joke about violence.
The comments on here .. (Score:2, Offtopic)
Re: (Score:2)
The comments on here, a classic example of just how badly slashdot has gone to the shits ..
We thank you for your ironically illustrative contribution. Sadly, we cannot pay you for your efforts, except in raspberries.
BDSM convention (Score:2)
It seems to me that a systemd conference wouldn't be much different from a BDSM convention.
Re:BDSM convention (Score:4, Funny)
It seems to me that a systemd conference wouldn't be much different from a BDSM convention.
The BDSM convention will have a higher percentage of protected sex, and nearly everyone getting screwed will be doing so consensually. Most of them will have a good sense of humor about what they are doing, heavy D/S tops aside.
You're naming a conference systemd.conf? (Score:2)
systemd is great (Score:2)
The name is a bit funny (Score:3, Funny)
Nuke it. (Score:3)
Nuke it from orbit, it's the only way to be sure!
Re: (Score:2)
> Learn from your mistakes.
By that you must mean: stop using Linux and learn FreeBSD.
Re: (Score:2)
stop using Linux and learn FreeBSD.
Maybe after it switches to launchd..
Re: (Score:2, Informative)
FreeBSD has had its new binary package system for over 2 years now.
pkg install kde4
done.
Also, if you want a Fedora like experience, use PCBSD (FreeBSD + gui installer and a full set of packages by default)
Re:Looks like you guys lost (Score:4, Insightful)
Maturity isn't really about age, but of total development hours. Popularity matters, because it helps to attract contributing developers, and more can be done in a shorter amount of time. Because of it's popularity, I think it's probably fair to say that Linux has matured faster than FreeBSD. As a counter-example, GNU/Hurd has been in development for fifteen years and is still not ready for prime time at version 0.6.
Re:Looks like you guys lost (Score:4, Insightful)
This fight is not over. From all the error-reports on the mailing-lists of the distros that have started using systemd, at the moment the only thing the opponents need to do is watch the fireworks and occasionally remind people that there are superior init systems and service managers.
We will see how this plays out. I expect there will be some rather quiet reversal in several distros in the not too distant future. And if not, there is no real need to have a Linux kernel under a GNU system. I also see no really serious problems keeping SYSVinit going. The only hurdle seems to be udev, but there is eudev and if that does not work out, I never really had any need of udev in the first place. Overall, it probably cost me more time than it saved. I may just go back to ultra-reliable static device files.
Re: (Score:2)
" I expect there will be some rather quiet reversal in several distros in the not too distant future." - just don't hold your breath
"And if not, there is no real need to have a Linux kernel under a GNU system. " - thats true, you could install the modular Hurd kernel instead of the monolithic Linux kernel.
"I also see no really serious problems keep
Re: (Score:3)
You know, for a known systemd-shill, you are being exceptionally lazy here. Methinks all this reflection of my arguments is because you have nothing of your own.
Re: (Score:2)
You didn't make any arguments to answer, you just made some vague comments and predictions with no substance that suits your opinion. Now who is getting lazy or have you run out of anti-systemd comments that haven't been refuted?
i've got no problem with people who do not like systemd (in the same way i don't like liver) but when they come out with crap and lies to justify it then it gets tedious.
Re:Looks like you guys lost (Score:4, Interesting)
I am currently porting multiple RHEL 5/6 servers over to other distros without systemd. Going to RHEL7 is just not a viable option for us.
Similar for workstations, where we have stopped ordering Dell N systems with Red Hat, and instead order them with Ubuntu (which we then wipe out - Ubuntu just because it's the cheapest option).
We have multiple in-house daemons, devices and mounts that need to start, stop, and yes, crash without an overseer interfering. Not handing off control is a must. Humanly readable logging is a must. No chance of a buggy startup process taking out the entire startup is a must. Not having buggy software auto-restarted is a must - if we wanted that, we'd use inittab. That we don't mean that we don't.
The amount of red hat subscriptions we have has gone down by around half since RHEL7 was releaseds. This is not a coincidence. Red Hat seems to still be on the cloud bandwagon and thinks that we'll eventually buy their cloud services. Sorry, but disregarding your customers' explicit requirements does not make that exceedingly likely.
Even IBM has abandoned ship, and gotten out of the business of selling RH systems. That this occurred when RH switched to systemd is not only a coincidence. They saw the devil on the wall and pulled out of the certified midrange market at the right time.
Re: (Score:2)
Re: (Score:2)
Giants collapse slowly. Or rather bloated monsters do.
Re:Huh? (Score:4, Funny)
Re: (Score:2)
Re: (Score:2)
Berlin is way cool; music, culture, food, drink, world class museums, world history; Berlin has it all.
Re:Ah, Berlin (Score:4, Informative)
A binary file avoids the need to have a bloated text parsing engine.
It doesn't do that, because all the data is interpreted by humans as text, and has to be presented to them as such. It also has to be understood as text, so if the journal processing tools do any of the things that systemd proponents claim they do, they will need a "bloated" text parsing engine.
Re:Ah, Berlin (Score:4, Insightful)
I really don't get the fetish for text file configuration that Linux has.
And that's why you, and people like you, persist in trying to ruin Linux. You don't understand why it's successful.
The ones I hated the most were init scripts that were common a few years ago which every source on the internet said "they're just like shell scripts," but they clearly weren't as there were commands in there about dependancies and somehow the same script managed starting a service and stopping it, but no one had documented the syntax anywhere because they thought it was too easy, and as a result, it was an init system I never used.
Just admit it: you don't understand shell scripts. Once you admit that, life will become a lot easier. You'll pick up a book on the subject, perhaps, or you'll read some websites. Then you'll learn how to read the scripts, and figure out where they're getting those "commands" that don't appear in the filesystem, not even when you use find instead of which. You'll see that they source a library at the top of the init script, and you'll follow up and read that library and you'll figure out how those variables at the top of the script which handle dependencies work. And then you'll see that there is really no need for systemd; cgroups support could have been added to those shell scripts, for example.
but nearly all text configurations suck, e.g. if you want to change a setting for which there isn't an example, you then have to spend hours reading the manual and testing ideas to figure out how to type something up which the software will parse as commands to make it do what you want. If the software had a GUI configuration tool like virtually every piece of modern software has, you could just look through a few logically-named tabs until you found the option you need, then just check the box beside it
Binary configuration files don't solve this problem! They don't magically make GUI configuration dialogs appear! Many Unix programs have complicated configuration files with no GUI to configure them because what they do is complicated, and a GUI capable of fully configuring them would also be very complicated. You're not going to automagically get GUI config tools for all those programs. If you outlawed ASCII, human-readable config files tomorrow, what you would actually have is a hodgepodge of different binary configuration file formats, each with their own inscrutable command-line tool for manipulating them.
It's also worth noting that many if not most windows programs have text configuration files! So, are you trolling, or do you really not understand that this is not the point of contention? It's over binary log files, not config files! Even systemd has ASCII configuration files! For now, anyway...
Re:Ah, Berlin (Score:5, Insightful)
I really don't get the fetish for text file configuration that Linux has.
Text is attractive because it's a least-common-denominator and *universal* format. However inconvenient it may be to parse and organize, you can write a reasonably simple script to do it, and you can pipe it through just about any command to transform or process it in whatever way you want. With text, you never have to worry about a black box of a file, because it's always human-readable, and thus more amenable to hacking.
The downside for log files is that text-based formats are incredibly inefficient as backing stores for any substantial amount of data. And as a configuration format, it's incredibly difficult to write front-end configuration software for scripts, although less so with regular formats like json or xml. Once the configuration is in a script, automated management of that configuration pretty much goes out the window - you're essentially committed to maintaining scripts by hand. This is not a problem for system administrators or advanced users, but horrible for normal users and GUI systems.
There are legitimate points on both sides, and which side you come down on may depend on your primary use case.
Re: (Score:2)
Re: (Score:2)
Re:Piss off systemd (Score:5, Funny)
Systemd conference -- you're going whether you want to or not.
systemd is my fault (Score:5, Funny)
'I need you to prevent something horrible from happening in the future, Steve.' He then nodded at the TV. There was a game on and along the bottom of the screen was a stock ticker. After reading from his tablet for a moment he said, 'Jackson is gonna score on a third-down pass in a minute.'
We watched three plays and sure enough, he was right. He proceeded to call the next series exactly. 'Nice trick.' I said, 'But this broadcast must be delayed.'
'That stock ticker isn't though, is it? Check your timepiece. The market closes in ten minutes.' He then showed me the closing price for both exchanges and bought me another stout.
It must have been a wild day on Wall Street because prices were feverishly swinging up and down. But he got the final numbers, right down to the penny. 'I'm from the future.' he said.
Now you hear all sorts of crazy talk at the Z-80 Lounge. And San Francisco IS the golden cultural capital in the hearts of hippie hackers everywhere. So I figured he hacked my tablet. "You have to stop it. It's called system..." But just then, a big hand clamped over his mouth and two big guys in suits grabbed him and dragged him out so I never knew until now what he was talking about.
Sorry.
Re:Piss off systemd (Score:5, Funny)
Systemd conference -- you're going whether you want to or not.
Oh for fuck sakes, you neckbeards never give up, do you?
First off, it's not a conference at all. We're just putting a few hundred people into the same room and giving talks. Just because you think that's a conference doesn't make it one. It's actually a confluence, which is something completely different that we just made up right now.
Second, nobody's forcing you to go. We're just relocating your office there for the week. If you have a problem with that, take it up with your boss. We didn't force anyone to move; we only changed the location of the building you're presently occupying.
Third, it's not one conference at all. It's just a collection of independent sessions in which a sentence is started in one session
and finished in another. But they're complete
ly independent of one another.
And why do you hate Dear Lead—er, Lennart so much? I find his work inspiring, a triumph of the will... if you will. His Kamp—er, his struggle— has been an inspiration for everyone who loves the discipline and honour of coding in der recht*cough*sorry in the Right Way. It's merely historical necessity that you unterprogrammers must be dealt with. No mercy for the dirty hippies! You cannot continue harming the purity of the FatherCode! Hail SystemD! Lebensraum for SystemD!
The critical question... (Score:3)
Re: Piss off systemd (Score:5, Insightful)
Ah, but with every single major distro adopting it, you better quit crying and get used to it, buddy!
They changed to systemd, they can change away just as well. Oh sure, the systemd cancer has spread to many daemons, but it can be excised from them as well. (Ironically, the daemons need exorcism...)
Re: (Score:3, Interesting)
Re: Piss off systemd (Score:5, Insightful)
Yeah, it'll be so terrible because... because...
Can you explain why this is a bad thing? Or is this another purely emotional "I don't like it!" tantrum?
Re: (Score:3)
Re: (Score:2)
I agree to that. Nothing important is dependent on systemd, except maybe udev. But even that can be replaced with reasonable effort if there is enough motivation. And Gentoo already has a replacement with eudev. Trying an "embrace and extend" move on Linux is ultimately futile. Sure, you can make a lot of people waste a lot of time, but that is it.
Re: (Score:3, Informative)
Whew, it's a good thing that you're posting your full real name, "Microlith", and not some sort of a pseudonym! Otherwise we'd have to think that you're posting anonymously, like some sort of a coward.
That aside, the problems with systemd are well-known. There's nothing "knee-jerk" about standing against it.
We really shouldn't have to rehash the problems with systemd each and every time it comes up. We know what the problems are. Its philosophy is backward. Its architecture is full of bad ideas (binary logg
Re:Piss off systemd (Score:5, Insightful)
Actually, Debian should have been forked to include systemd, not forked to exclude it!
That's the whole point of forking. You fork, do experimental stuff like integrate systemd in this fork, and then throw the fork away when it becomes clear that the idea was a dumb one.
When done sensibly like that, the source is left unaffected by experimentation that proves to be disastrous.
Debian users could have continued to use a stable, sane, reliable, trustworthy system, like they've been accustomed to for a couple of decades now.
Those who want newfangled and unproven doodads and curiosities could have used the systemd fork of Debian. When they got bored, or suffered from one failure after another, they could always limp back to Debian.
Re: (Score:3)
The use of systemd by default in Debian, along with pretty much every other major Linux distro (sorry, Slackware, you're a relic; Gentoo, you're impractical) has driven away the best Linux admins and developers there are.
That's some interesting logic. So, most Linux distros are going down the drain because they use systemd, and I quite agree with that. And then those that don't use systemd, they are also doomed by definition?
I used NetBSD for a while around 2002, and I loved the pure Unix way after using all these Fisher-Price Linux distros. However, it was seriously lacking in hardware support and software availability. Fortunately, I soon discovered Gentoo that combined everything that was great in both Linux and BSD,
Re:systemd is the best init system for FreeBSD. (Score:4, Insightful)
"(sorry, Slackware, you're a relic; Gentoo, you're impractical)"
Sorry AC , you don't get it: It doesn't matter whether 1 or 1 billion people use a distro, they are exercising their choice - their ability to choose what they want. That is the most powerful aspect of free software whether it be Gentoo, Slack, Yggdrasil (my first), *BSD or whatever.
YOU GET A FUCKING CHOICE OF WHAT OS TO PUT ON YOUR COMPUTER.
Your insinuation that FreeBSD will somehow slide into the breech to replace Linux is almost as laughable as this being the year of Linux on the Desktop.
BTW I use Gentoo quite a lot (50 odd systems) and they all have pid 1 == systemd ...
Cheers
Jon
Re: (Score:3)
I thought it was part of the philosophy - you're free to inspect, modify, and re-distribute the code....so why is it now a bad thing for there to be lots of options for users to choose from?
You're absolutely right about the documentation.
Re: (Score:2)
I'm sure that if a significant number of credible DevOps (and not the few trolls that make the most noise based on lack of knowledge) voiced valid technical reasons not to use it, Redhat et al would have dropped it.
Some DevOps must be getting worried that more automation of some tasks in their job descriptions are going to be career limiting and the number of Dev
Re: (Score:2)
I'm sure that if a significant number of credible DevOps (and not the few trolls that make the most noise based on lack of knowledge) voiced valid technical reasons not to use it, Redhat et al would have dropped it.
You're sure? That's all you have? The distros are using systemd because it makes writing startup scripts easier. They take up fewer lines. That's about it. It has nothing to do with DevOps.
"Of those, I've asked around, and I haven't found any DevOps people who like systemd." - maybe your circle of devops is very limited in number.
Indeed, I don't have the resources to do a full survey of DevOps professionals. I can only ask the people I know.
If you are DevOps, or even know of someone in DevOps who uses systemd, I would be interested in hearing your experience. If you're talking from ignorance, then you're boring.
Re: (Score:2)
Re: (Score:2)
The distros are using systemd because it makes writing startup scripts easier. They take up fewer lines. That's about it. It has nothing to do with DevOps." -
you mean configuration files, not startup scripts.
No, no he does not, and there is no obvious reason how you might come to that conclusion except deep ignorance. The configuration files for the programs differ little when systemd is involved. The startup scripts are intended to go away, and be replaced by unit files, which are indeed easier to write than init scripts as they are simply a collection of variables. They are organized into sections segregated by square brackets like a windows ini file, but AFAICT the names of the variables are all globally uni
Re: (Score:3)
"The distros are using systemd because it makes writing startup scripts easier. They take up fewer lines. That's about it. It has nothing to do with DevOps." - you mean configuration files, not startup scripts. That may or may not be the distros reasons for it but i doubt it. I'm sure they have the staff capable of taking a bash script, copying it and changing a line or two in it for it to work in sysvinit if they wished to,
That is the reason Debian adopted systemd. You don't have to doubt, they've been public about their decision: it makes writing init files easier. I've written [slashdot.org] at length [slashdot.org] on this topic.
Re: (Score:2)
What, tools that any competent sysadmin can actually understand and customize? We cannot have that!