That's excellent logic there. I suppose there is no problem with unmaintained rusty bridges either. It's been standing like that for many years, therefore it's not going to fall all of a sudden, right?
Look, I'm not completely unsympathetic to nuclear power, but fighting to keep a plant online that's had a long history of problems is not in your interest if you want to keep it around. Nature cannot be fooled. Either you do things right, or something will go wrong sooner or later, and another Fukushima isn't going to be good PR for nuclear power.
Anybody interested in nuclear power surviving should be very aggressively taking care of any issues that pop up, because most of the problem isn't with tech, but with people.
If that's really intentional on Rusty's part, I would have liked to have some sort of announcement, and some sort of goodbye. Perhaps a post-mortem analysis. And ideally, have it remain online frozen, as an archive, because in the past there have been many very good articles on it, before it went to shit.
Of course, the site has already been effectively dead for what, more than a decade now, I think? It's a real pity, because it used to be a really cool place where interesting, and sometimes important (Wikipedia, OpenNIC, etc) discussions took place.
The place was unique enough that it took me years to find a suitable replacement for it.
The thing is that those problems have permanent solutions.
I can see a day when we have a grid that can be run purely on wind and solar. It may take some tech and development, but once it's there, it's there.
On the other hand, there won't be a day when radioactivity becomes a simple and pleasant thing to handle.
So it may well happen that eventually we'll decide that the hassle of dealing with variable power sources is less than the hassle of dealing with radioactivity.
Meaning I'm fine with it existing, but don't have any particularly romantic notions about it either.
Nuclear power necessarily comes with a long list of downsides. The enormous expense of building a powerplant, the amount of care that needs to be exercised to properly run it, the problem with waste disposal, the problem with that a dismantled powerplant still needs maintenance, the problem that disaster preparation is absolutely essential, the problem that the critical parts of the infrastructure are so highly radioactive it's not even possible to have a camera in them, which means any work on that is enormously expensive...
And then there's the problem of that if things go wrong it causes the evacuation of a huge amount of the population. Now I know this isn't instant death of course, but it still means that accidents are enormously expensive and insurance is difficult.
Then there is that all of this critically depends on people, who in many cases have reasons to cut corners in dangerous places.
Once you take all of that into account, I think it becomes considerably less amazing than it is in theory. IMO, current nuclear power is something that will go away eventually. Many of its downsides aren't going anywhere, so it may well happen that we'll find a way to run a grid purely on solar and wind power, and just accept the downsides of that in exchange for not having to deal with radioactivity.
That said, I'm all for improving the tech as far as possible and looking into thorium and of course fusion research.
A problem with 2048 bit keys is standards. Debian for instance wants 4096 bit keys (though they do allow 2048 bit ones), so if you start just working with the command line, making a 4096 bit key is the logical choice. If then you get a device that can't handle it you have the problem of having to deal with creating a new, weaker key just for that.
Not a fatal problem, but it's an undesirable inconvenience.
Easy solution: Use a good passphrase, and a secure computer. Have a dedicated computer that is well protected and that you don't install random crap on. Back the key up properly.
Harder solution: Use a smartcard, for instance a Yubikey. They allow keeping the key safely on a small USB device that fits on a keychain. The key never leaves the smartcard, and in the very worst case, a compromise still doesn't retrieve your key, it can only succeed in signing stuff while the key is physically in the computer.
The downside is that it can take some messing around to get it to work, and that many smartcards are limited in the key size they allow, for instance the Yubikey only accepts 2048 bit keys.
Nobody is trying to make a general intelligence because nobody wants it. What is wanted is domain specific algorithms that are very good at what they do.
Although, it seems that the tech is quite general and learned to play multiple Atari games without having to be tuned for each.
Fees are going to be required universally anyway, and current clients already suggest that you pay a fee by default.
There is a limit to the amount of bitcoin that can be made ever, and the reward for block mining is halved every 4 years. This means that transaction fees are needed to motivate people to keep on mining and the network operating.
And I think you misunderstand me -- I'm not some crazy bitcoin evangelist. My point is simply that bitcoin is unlikely to die to such temporary hiccups, because there are quite a lot of people interested in keeping things working. It might cause tension and problems once in a while, but there is plenty motivation for people to find some sort of solution, eventually.
There are enough people interested in things working that when something does break, the dust eventually settles. Now this isn't ideal, but that's what you have to deal with in exchange of decentralization: when some problem is found you have to convince other people to adopt your fix.
The main reason to even bother with bitcoin is the attraction to its lack of central control and regulation. The other, closely related one, is that it works anywhere and for any purpose.
There's really no other reason to use it than the above. It has technical and practical limitations that normal electronic transfers don't have. Mistakes are forever, scams are rampant, technical understanding of what you're doing is vital if you like keeping your money.
There's no reason to bother with it over something like paypal or bank transfers if you're not into it for the lack of control or philosophical reasons, and a system controlled by a bank would do away with that.
But that's not Wayland, it's X11, and only works for X11 applications. It'll stop working as soon as Linux applications transition to Wayland and the toolkits drop the X11 code.
An UPS won't protect against intentional power cycling.
Let's say you have a problem that really needs a reboot. Perhaps the UI locked up, or the machine is swapping so much it's unusable, or the video card crapped out and you can't see anything. Is it safe to hit the power button and reboot?
In the worst SSD implementations the problem is not the swap file getting corrupted, it's the metadata that keeps the SSD itself functional getting corrupted, which risks making the entire drive unusable.
I saw it recently, and walked out very unimpressed. It's not horrible, or painful to watch. But nothing about it impresses it, and everything is forgettable. And the more you think about it, the less things make sense.
There's nothing really bold. Yet ANOTHER Death Star? Oh, this one's bigger, whoop dee doo.
Rey comes from some hole where she barely manages to eat enough, and suddenly can pilot and repair ships, use the Force though she thought it was a myth, and competently use a lightsaber, all without training. She also instantly takes Han's place, while Chewbacca is oddly ignored.
Kylo Ren really looks like a parody of Darth Vader. He's like an emo teenager with a high position and access to tech to make himself a cool suit. Maybe that was the point, but how is this guy in a leading position of anything? And what is his motivation? Where on earth did he get a positive view of Darth Vader from?
The plot makes no sense. Let's see, Luke got upset and ran away, but rather than contacting his closest friends made up some sort of treasure map to himself, and decided to hang around on a hill to see if anybody managed to find the map? Seriously, who does that? And how does it even make sense to have a "hunt the floppy" plot in 2015? That plot device is two decades out of date.
What is the political background? How come the resistance has been sitting on their asses while a third death star was getting built? Why is it a random improperly brainwashed stormtrooper that knows all the details, and not them?
It's been a while since I had to work with upstart, so I don't remember the exact list of grievances I had with it. But I do remember that one problem I had is that it has a seriously weird dependency model that works backwards: rather than saying what you need for your service to work, your service starts when it has what it needs.
As far as system administration goes I find this is very weird and undesirable. If a service is for some reason not starting it's now my problem to figure out what it wants, and isn't getting.
I guess that given that slackware lacks package dependency resolution, it can be expected that you don't have a problem with hunting down dependencies. I, on the other hand, prefer to leave the boring and simple jobs like dependency resolution to the computer, and have more time for things that require actual brains.
And as for init systems - there was nothing, absolutely nothing, that was more sheer hell to administer than SMF. SMF was a truly horrendous and unmanageable piece of crapware. Building a system similar to it is an act of sheer, calculated sadism.
Actually I never worked with SMF, so I don't know much about it besides that it exists. What I was pointing out that the deviation from the holy "unix philosophy" is getting pretty much universal, and that if the old way of things was so wonderful we wouldn't have multiple completely independent companies looking for alternatives and coming up with similar conclusions.
Certainly there are better and worse approaches of the same style. I have no love for upstart, but no issues with systemd so far.
Ive spent the majority of my career building distributions. Trust me as a distro developer of some distinction (linux.com once said that I did for slackware what Ubuntu did for debian, my distro at its height ran 95% of all computers in an entire country)
Ooh, that explains things.
when i tell you i know the decision making process and the motivation for adopting systemd has absolutely nothing to do with technical superiority.
So what is it, then?
But its worthless debating you. I showed you a legitimate case for not ever integrating core utilities. You responded with work arounds. I told you work arounds are not good enough.
An option that makes something do exactly what you want is a workaround? In what way?
You pretend I changed topics !
More like you ran out of geniune technical concerns and started ranting about philosophy.
This seems to be the main fundamental disagreement here: I just don't think that the Unix Philosophy has holy status. Hell, the Linux kernel violates it. Why aren't you running HURD, anyway?
Then you give examples of binary formats nobody minds... all of them databases, the very thing I said in five posts earlier was the only case in all software where binary formats for textual data had a legitimate case. Logs dont have the needs of databases or the constraints. Databases are an edge case. You dont apply edge case reasoning to core technology. Its bad engineering.
A database is a nice fit for a log system. What were the errors yesterday? What are all the messages logged by this service? What was logged on Monday, between 10 and 12 AM? What are the statistics of the various types of messages? Those are all questions that a database is well qualified to answer, and the practical concerns I have when doing system administration.
And here is the real issue. In the past I could swap out any utility on my box for any other utility that was compatible. This allowedfor experimentation. For competition and evolution. I could replace sysv in any distro with upstart or openrc. Nothing else would be affected. Nothing would break. Now if I try replace the init system it breaks the message bus and that breaks the desktop.
Finally another technical matter. You are aware that dbus has multiple implementations of it, right? It's not intrinsically bound to systemd. While systemd does have its own implementation, nothing is stopping you from running another. In fact, since slackware doesn't use systemd, I imagine that's what they do.
Ah the classic "call it a religion" and you can dismiss it argument. There's just one problem - this is the exactly OPPOSITE of a religion: because it's based on solid evidence.
Well, I don't see this evidence of yours.
Look at how this conversation has gone. I started by answering your technical concerns. Initially you had a real technical issue, a real need for better performance than the system originally provided, and how you needed to be able to replace the logger to solve it.
So I explained how systemd allows to do the exact same thing. You can have your syslogd if you want it, and you even have a special mode that logs to RAM that might have solved your particular issue without needing to roll your own daemon in the first place.
With that answered (since you didn't have any counterargument to the solution I provided), what's your answer? That it's no excuse, that the unix philosophy is absolutely holy and critical to keep for reasons you can't quite articulate. You keep on railing against the binary log format despite that I told you it can be disabled, as the very idea of binary data seems to offend your sensibilities.
And that's why I call it a religion. Because you've ran out of real technical concerns and now your only argument is that it goes against the True Way of doing things.
Taking it away is a terrible thing to do, the developers are assuming that the use-cases THEY can think of are all the use-cases that can legitimately exist.
I'll repeat for the third time that if you want syslogd, you can have syslogd. Maybe saying it for the third time will sink in finally.
It's arrogance, plain and simple.
Now there's something that sounds a lot like religion. When lacking a legitimate technical argument, complain of the arrogance.
So maybe, indexing is not as useful as you initially thought ?
Why would I ever conclude that? Modern computing is heavily reliant on indexing information. No need to look further than Google.
There are plenty of other formatted text outputs without the overhead of JSON though - the colon-seperation format of the passwd file for example. We've solved these problems very well, repeatedly, for 40 years without ever having to abandon clear-text for a core utility,
Sure, separate by colons data in a file with fields that can contain colons. That'll be nice and convenient to parse with awk.
And there's core stuff that has binary data. lastlog and package managers for instance. Berkeley DB is as UNIX as it gets, and I don't hear anybody whining it's a binary format. How about RRD? You probably use that for graphs, and that's binary too.
Or I can do what I did do - change distros to one that doesn't use systemd. But since Linux is now the unix of enterprise, and the distros that are being used professionally have all found the dependency hell created by systemd overwhelming and given up on offering alternatives - the problem isn't solved by that, it solves it for me at home, but it leaves me dealing with it when I get to the office in the morning.
What dependency hell? Systemd is being adopted for a very simple reason: the people who actually do the work of making distributions like it. It saves them lots of work, improves debuggability and performance, and provides additional functionality for free. At the start there was a first adopter, and they couldn't have adopted it because everybody else was already dependent on it.
It's very interesting that you have so many arguments about historical evidence but keep on ignoring the one that's staring you in the face: that the people who most directly deal with these things disagree with you.
None of those are good enough reasons to violate a fundamental unix design principle thats been in place since Thompson's earliest experiments.
Oh dear. Unix turned into a religion. I guess we're going to disagree here because I'm not religious and don't care about staying true to the doctrine.
I cant edit the log with vi ? Then you broke unix. Its not unix anymore.
That's actually entirely intentional. journald contains a way to sign log files in such a way that it would make tampering detectable.
Why not store it in json then ? You could get all those features without losing text as a format.
First it wouldn't be as quick to access, second it would take a lot more space. An 87 byte log line (in the format normally seen in/var/log) turns into 1085 bytes of JSON. There's quite a lot of data stored in there.
But I guess if you want that anyway you could try submitting a patch. It's an open source project after all.
That's just it though - if any component didn't do EXACTLY what I want, I want to be able to swap THAT component out with anything else I choose, or write, and the init system has no business telling me what that should be.
You ARE aware that systemd is configurable, right? You can ask it to direct your data to syslogd (where you can use your own implementation), you can configure it to log only to RAM (for maximum performance for the case you mentioned), and you can tell it to turn off its own logging (so it all goes to syslog and nowhere else)
The pipeline concept fundamentally depends on not violating one of the principle unix philosophy rules which systemd does not honour: everything should always be clear-text. Never store data in a binary format. It is NEVER a good idea. The sole justifiable exception to that rule is relational databases and I'm not even sure it was a good idea to make that exception. Everything should always be editable with standard tools. And nothing, should EVER be strongly coupled, weak coupling only.
The point of the binary format is that it's indexed and quickly seekable. You can search it by date, by service, by boot, etc. You don't need to wonder what to grep for and whether LVM ever logs something without the string 'LVM' in it (in fact it does) -- there's a service for LVM, and anything it logs can be found under that.
If you want to grep/sed/whatever it, then journalctl outputs the data in text, so you can do that to your heart's content. This even has some nice things to it, for instance the output is customizable. It'd be more comfortable to grep with ISO 8601 timestamps? There's an argument for that. You want the data in JSON? There's that too.
Also while binary, it's an append only format, which means that if it does go wrong it's not going to do anything to the data that's already been logged.
$ cat/etc/systemd/journald.conf # This file is part of systemd. ... [Journal] ... #ForwardToSyslog=no
Change that to "yes", and there you go.
using binaries for helper programs
start-stop-daemon was written in C last time I checked. So was bash, and awk, and perl and a whole bunch of other stuff system scripts use.
and xml files for configuration (what's wrong with using shell scripts and flat text???)
Try actually looking at the config files? They're INI style text files, as quoted above. Systemd in fact doesn't depend on libxml at all, so I have no clue where you got that from.
Thirdly, it violates the very thing that underlies nearly every single component of UNIX or a UNIX-like operating system: have tools that do one single thing and do it well.
Who cares? Apple, Ubuntu and Solaris also have or had systemd-like init systems. In fact, Solaris is a true UNIX system, certified and all, and it has SMF, which seems to be a quite similar idea.
But that still wouldn't be a fair comparison because systemd does so many more things not remotely related to sysvinit+init scripts. So what are we going to compare, systemd vs init+scripts+httpd+ntpd+consolekit+policykit+this+and+that?
Yes
Do you understand the problem, now that it's staring you in the face?
then rejecting it requires a strong, rational argument - and even the best such arguments are likely to hold only in very rare niche cases.
There are quite a few reasons. For instance, like I already mentioned, sysv init has no logging and bad error handling. Processes may disappear without any logs being emitted. PID files may result in services not properly restarting. It's not a very reliable system, it's fragile and can break in ways that require you to manually do its job.
Consistency is not in any way enforced, for instance the S/K system means that changing from runlevel 1 to 2, and from 3 to 2 can result in different things running.
Performance can be much improved, because there's no parallel startup in many implementations and no on demand loading.
Processes are not tracked, if you see some mysterious process in the process list, the system doesn't help you figure out what service it belongs to. systemd uses cgroups and always knows what a process belongs to.
Things like CPU and memory limits have to be hacked in by hand, rather than being supported by the system itself.
And the problem with systemd is it violates virtually every one of the principles of that philosophy and offers NO rational reason for ANY of the violations - and it isn't doing so in a niche where perhaps some of those principles are genuinely not applicable, it's doing it to the heart of the system.
The sysv init reached the end of its life. There is a reason why Ubuntu, Apple and Solaris (which is by the way True Unix, which nevertheless decided that init scripts were getting rusty) moved on to better things. This isn't even new, it's been coming for ages. Dependency systems and parallel boot have long been a feature added on top of sysv init in Linux distros, but it rarely worked perfectly.
Why do you think it took them 20 years to implement the bare beginnings of proper multi-user support ? Because the policy of single user was tied fundamentally into the mechanisms of the system 20 years earlier.
Unix wouldn't have fared much better if it didn't have multiuser from the start. It's a fundamental part of the API, you can't just graft on multiuser to something that didn't have it before. Take for example that on a multiuser system there are access restrictions. An application made for an initially single user system will often poke to deep into where a multiuser system can't allow it to, and a flexible policy isn't going to save you from that.
It violates the rule that applications should always expect simple clear text as input, and produce simple clear text as output. That rule is so fundamental to the flexibility and power of unix that to break it at the init level is to completely destroy that power. If systemd becomes universal, linux will lose all the marketshare it gain in every market, and lose it to unix systems that kept the rule - because the next breakthrough in technology will require adaptations - which systemd will have made incredibly hard.
Hah. Linux lost market share to OS X, which by the way has a very systemd-like service system. Interestingly nobody seems to have got turned off by that.
More-over, it weakens what you can do with the system - the ability to string commands together in utterly arbitrary ways via pipelines have allowed a relatively small set of primitive applications to serve literally ever conceivable user need, exactly by NOT trying to conceive of every possible user need - but providing the means to construct whatever solution you could possibly want on the fly.
Um, systemd isn't about to take over the commandline. Pipes still exist, you know.
In fact, systemd makes it easier to string stuff together. You can trivially make even a single line script into a systemd service in about a minute. sysv init is rather more involved.
I have no problem with shell scripts. I just don't see the point in keeping 20 copies of the same script, slightly customized. It's much cleaner to have a systemd style config file, where the file only contains what's important, and lacks any boilerplate content that might or not have been customized.
What kind of flexibility are you talking about, by the way? I've been using systemd for a while and don't really feel limited.
Slashdot Mirror
That's excellent logic there. I suppose there is no problem with unmaintained rusty bridges either. It's been standing like that for many years, therefore it's not going to fall all of a sudden, right?
Look, I'm not completely unsympathetic to nuclear power, but fighting to keep a plant online that's had a long history of problems is not in your interest if you want to keep it around. Nature cannot be fooled. Either you do things right, or something will go wrong sooner or later, and another Fukushima isn't going to be good PR for nuclear power.
Anybody interested in nuclear power surviving should be very aggressively taking care of any issues that pop up, because most of the problem isn't with tech, but with people.
If that's really intentional on Rusty's part, I would have liked to have some sort of announcement, and some sort of goodbye. Perhaps a post-mortem analysis. And ideally, have it remain online frozen, as an archive, because in the past there have been many very good articles on it, before it went to shit.
Of course, the site has already been effectively dead for what, more than a decade now, I think? It's a real pity, because it used to be a really cool place where interesting, and sometimes important (Wikipedia, OpenNIC, etc) discussions took place.
The place was unique enough that it took me years to find a suitable replacement for it.
Weasels may be clever, but eagles don't get fried by particle accelerators
The thing is that those problems have permanent solutions.
I can see a day when we have a grid that can be run purely on wind and solar. It may take some tech and development, but once it's there, it's there.
On the other hand, there won't be a day when radioactivity becomes a simple and pleasant thing to handle.
So it may well happen that eventually we'll decide that the hassle of dealing with variable power sources is less than the hassle of dealing with radioactivity.
Meaning I'm fine with it existing, but don't have any particularly romantic notions about it either.
Nuclear power necessarily comes with a long list of downsides. The enormous expense of building a powerplant, the amount of care that needs to be exercised to properly run it, the problem with waste disposal, the problem with that a dismantled powerplant still needs maintenance, the problem that disaster preparation is absolutely essential, the problem that the critical parts of the infrastructure are so highly radioactive it's not even possible to have a camera in them, which means any work on that is enormously expensive...
And then there's the problem of that if things go wrong it causes the evacuation of a huge amount of the population. Now I know this isn't instant death of course, but it still means that accidents are enormously expensive and insurance is difficult.
Then there is that all of this critically depends on people, who in many cases have reasons to cut corners in dangerous places.
Once you take all of that into account, I think it becomes considerably less amazing than it is in theory. IMO, current nuclear power is something that will go away eventually. Many of its downsides aren't going anywhere, so it may well happen that we'll find a way to run a grid purely on solar and wind power, and just accept the downsides of that in exchange for not having to deal with radioactivity.
That said, I'm all for improving the tech as far as possible and looking into thorium and of course fusion research.
A problem with 2048 bit keys is standards. Debian for instance wants 4096 bit keys (though they do allow 2048 bit ones), so if you start just working with the command line, making a 4096 bit key is the logical choice. If then you get a device that can't handle it you have the problem of having to deal with creating a new, weaker key just for that.
Not a fatal problem, but it's an undesirable inconvenience.
Easy solution: Use a good passphrase, and a secure computer. Have a dedicated computer that is well protected and that you don't install random crap on. Back the key up properly.
Harder solution: Use a smartcard, for instance a Yubikey. They allow keeping the key safely on a small USB device that fits on a keychain. The key never leaves the smartcard, and in the very worst case, a compromise still doesn't retrieve your key, it can only succeed in signing stuff while the key is physically in the computer.
The downside is that it can take some messing around to get it to work, and that many smartcards are limited in the key size they allow, for instance the Yubikey only accepts 2048 bit keys.
Nobody is trying to make a general intelligence because nobody wants it. What is wanted is domain specific algorithms that are very good at what they do.
Although, it seems that the tech is quite general and learned to play multiple Atari games without having to be tuned for each.
Fees are going to be required universally anyway, and current clients already suggest that you pay a fee by default.
There is a limit to the amount of bitcoin that can be made ever, and the reward for block mining is halved every 4 years. This means that transaction fees are needed to motivate people to keep on mining and the network operating.
And I think you misunderstand me -- I'm not some crazy bitcoin evangelist. My point is simply that bitcoin is unlikely to die to such temporary hiccups, because there are quite a lot of people interested in keeping things working. It might cause tension and problems once in a while, but there is plenty motivation for people to find some sort of solution, eventually.
It's already gone down back to normal:
https://blockchain.info/charts...
There are enough people interested in things working that when something does break, the dust eventually settles. Now this isn't ideal, but that's what you have to deal with in exchange of decentralization: when some problem is found you have to convince other people to adopt your fix.
The main reason to even bother with bitcoin is the attraction to its lack of central control and regulation. The other, closely related one, is that it works anywhere and for any purpose.
There's really no other reason to use it than the above. It has technical and practical limitations that normal electronic transfers don't have. Mistakes are forever, scams are rampant, technical understanding of what you're doing is vital if you like keeping your money.
There's no reason to bother with it over something like paypal or bank transfers if you're not into it for the lack of control or philosophical reasons, and a system controlled by a bank would do away with that.
But that's not Wayland, it's X11, and only works for X11 applications. It'll stop working as soon as Linux applications transition to Wayland and the toolkits drop the X11 code.
An UPS won't protect against intentional power cycling.
Let's say you have a problem that really needs a reboot. Perhaps the UI locked up, or the machine is swapping so much it's unusable, or the video card crapped out and you can't see anything. Is it safe to hit the power button and reboot?
In the worst SSD implementations the problem is not the swap file getting corrupted, it's the metadata that keeps the SSD itself functional getting corrupted, which risks making the entire drive unusable.
The implementation is a rather trivial one:
I saw it recently, and walked out very unimpressed. It's not horrible, or painful to watch. But nothing about it impresses it, and everything is forgettable. And the more you think about it, the less things make sense.
There's nothing really bold. Yet ANOTHER Death Star? Oh, this one's bigger, whoop dee doo.
Rey comes from some hole where she barely manages to eat enough, and suddenly can pilot and repair ships, use the Force though she thought it was a myth, and competently use a lightsaber, all without training. She also instantly takes Han's place, while Chewbacca is oddly ignored.
Kylo Ren really looks like a parody of Darth Vader. He's like an emo teenager with a high position and access to tech to make himself a cool suit. Maybe that was the point, but how is this guy in a leading position of anything? And what is his motivation? Where on earth did he get a positive view of Darth Vader from?
The plot makes no sense. Let's see, Luke got upset and ran away, but rather than contacting his closest friends made up some sort of treasure map to himself, and decided to hang around on a hill to see if anybody managed to find the map? Seriously, who does that? And how does it even make sense to have a "hunt the floppy" plot in 2015? That plot device is two decades out of date.
What is the political background? How come the resistance has been sitting on their asses while a third death star was getting built? Why is it a random improperly brainwashed stormtrooper that knows all the details, and not them?
It's been a while since I had to work with upstart, so I don't remember the exact list of grievances I had with it. But I do remember that one problem I had is that it has a seriously weird dependency model that works backwards: rather than saying what you need for your service to work, your service starts when it has what it needs.
As far as system administration goes I find this is very weird and undesirable. If a service is for some reason not starting it's now my problem to figure out what it wants, and isn't getting.
I guess that given that slackware lacks package dependency resolution, it can be expected that you don't have a problem with hunting down dependencies. I, on the other hand, prefer to leave the boring and simple jobs like dependency resolution to the computer, and have more time for things that require actual brains.
Actually I never worked with SMF, so I don't know much about it besides that it exists. What I was pointing out that the deviation from the holy "unix philosophy" is getting pretty much universal, and that if the old way of things was so wonderful we wouldn't have multiple completely independent companies looking for alternatives and coming up with similar conclusions.
Certainly there are better and worse approaches of the same style. I have no love for upstart, but no issues with systemd so far.
Ooh, that explains things.
So what is it, then?
An option that makes something do exactly what you want is a workaround? In what way?
More like you ran out of geniune technical concerns and started ranting about philosophy.
This seems to be the main fundamental disagreement here: I just don't think that the Unix Philosophy has holy status. Hell, the Linux kernel violates it. Why aren't you running HURD, anyway?
A database is a nice fit for a log system. What were the errors yesterday? What are all the messages logged by this service? What was logged on Monday, between 10 and 12 AM? What are the statistics of the various types of messages? Those are all questions that a database is well qualified to answer, and the practical concerns I have when doing system administration.
Finally another technical matter. You are aware that dbus has multiple implementations of it, right? It's not intrinsically bound to systemd. While systemd does have its own implementation, nothing is stopping you from running another. In fact, since slackware doesn't use systemd, I imagine that's what they do.
Well, I don't see this evidence of yours.
Look at how this conversation has gone. I started by answering your technical concerns. Initially you had a real technical issue, a real need for better performance than the system originally provided, and how you needed to be able to replace the logger to solve it.
So I explained how systemd allows to do the exact same thing. You can have your syslogd if you want it, and you even have a special mode that logs to RAM that might have solved your particular issue without needing to roll your own daemon in the first place.
With that answered (since you didn't have any counterargument to the solution I provided), what's your answer? That it's no excuse, that the unix philosophy is absolutely holy and critical to keep for reasons you can't quite articulate. You keep on railing against the binary log format despite that I told you it can be disabled, as the very idea of binary data seems to offend your sensibilities.
And that's why I call it a religion. Because you've ran out of real technical concerns and now your only argument is that it goes against the True Way of doing things.
I'll repeat for the third time that if you want syslogd, you can have syslogd. Maybe saying it for the third time will sink in finally.
Now there's something that sounds a lot like religion. When lacking a legitimate technical argument, complain of the arrogance.
Why would I ever conclude that? Modern computing is heavily reliant on indexing information. No need to look further than Google.
Sure, separate by colons data in a file with fields that can contain colons. That'll be nice and convenient to parse with awk.
And there's core stuff that has binary data. lastlog and package managers for instance. Berkeley DB is as UNIX as it gets, and I don't hear anybody whining it's a binary format. How about RRD? You probably use that for graphs, and that's binary too.
What dependency hell? Systemd is being adopted for a very simple reason: the people who actually do the work of making distributions like it. It saves them lots of work, improves debuggability and performance, and provides additional functionality for free. At the start there was a first adopter, and they couldn't have adopted it because everybody else was already dependent on it.
It's very interesting that you have so many arguments about historical evidence but keep on ignoring the one that's staring you in the face: that the people who most directly deal with these things disagree with you.
Oh dear. Unix turned into a religion. I guess we're going to disagree here because I'm not religious and don't care about staying true to the doctrine.
That's actually entirely intentional. journald contains a way to sign log files in such a way that it would make tampering detectable.
First it wouldn't be as quick to access, second it would take a lot more space. An 87 byte log line (in the format normally seen in /var/log) turns into 1085 bytes of JSON. There's quite a lot of data stored in there.
But I guess if you want that anyway you could try submitting a patch. It's an open source project after all.
You ARE aware that systemd is configurable, right? You can ask it to direct your data to syslogd (where you can use your own implementation), you can configure it to log only to RAM (for maximum performance for the case you mentioned), and you can tell it to turn off its own logging (so it all goes to syslog and nowhere else)
The point of the binary format is that it's indexed and quickly seekable. You can search it by date, by service, by boot, etc. You don't need to wonder what to grep for and whether LVM ever logs something without the string 'LVM' in it (in fact it does) -- there's a service for LVM, and anything it logs can be found under that.
If you want to grep/sed/whatever it, then journalctl outputs the data in text, so you can do that to your heart's content. This even has some nice things to it, for instance the output is customizable. It'd be more comfortable to grep with ISO 8601 timestamps? There's an argument for that. You want the data in JSON? There's that too.
Also while binary, it's an append only format, which means that if it does go wrong it's not going to do anything to the data that's already been logged.
Change that to "yes", and there you go.
start-stop-daemon was written in C last time I checked. So was bash, and awk, and perl and a whole bunch of other stuff system scripts use.
Try actually looking at the config files? They're INI style text files, as quoted above. Systemd in fact doesn't depend on libxml at all, so I have no clue where you got that from.
Who cares? Apple, Ubuntu and Solaris also have or had systemd-like init systems. In fact, Solaris is a true UNIX system, certified and all, and it has SMF, which seems to be a quite similar idea.
Yes
I don't see any problem.
There are quite a few reasons. For instance, like I already mentioned, sysv init has no logging and bad error handling. Processes may disappear without any logs being emitted. PID files may result in services not properly restarting. It's not a very reliable system, it's fragile and can break in ways that require you to manually do its job.
Consistency is not in any way enforced, for instance the S/K system means that changing from runlevel 1 to 2, and from 3 to 2 can result in different things running.
Performance can be much improved, because there's no parallel startup in many implementations and no on demand loading.
Processes are not tracked, if you see some mysterious process in the process list, the system doesn't help you figure out what service it belongs to. systemd uses cgroups and always knows what a process belongs to.
Things like CPU and memory limits have to be hacked in by hand, rather than being supported by the system itself.
The sysv init reached the end of its life. There is a reason why Ubuntu, Apple and Solaris (which is by the way True Unix, which nevertheless decided that init scripts were getting rusty) moved on to better things. This isn't even new, it's been coming for ages. Dependency systems and parallel boot have long been a feature added on top of sysv init in Linux distros, but it rarely worked perfectly.
Unix wouldn't have fared much better if it didn't have multiuser from the start. It's a fundamental part of the API, you can't just graft on multiuser to something that didn't have it before. Take for example that on a multiuser system there are access restrictions. An application made for an initially single user system will often poke to deep into where a multiuser system can't allow it to, and a flexible policy isn't going to save you from that.
Hah. Linux lost market share to OS X, which by the way has a very systemd-like service system. Interestingly nobody seems to have got turned off by that.
Um, systemd isn't about to take over the commandline. Pipes still exist, you know.
In fact, systemd makes it easier to string stuff together. You can trivially make even a single line script into a systemd service in about a minute. sysv init is rather more involved.
I have no problem with shell scripts. I just don't see the point in keeping 20 copies of the same script, slightly customized. It's much cleaner to have a systemd style config file, where the file only contains what's important, and lacks any boilerplate content that might or not have been customized.
What kind of flexibility are you talking about, by the way? I've been using systemd for a while and don't really feel limited.