Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?
Take advantage of Black Friday with 15% off sitewide with coupon code "BLACKFRIDAY" on Slashdot Deals (some exclusions apply)". ×

Comment Re: I guess they realised... (Score 1) 152

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.

Comment Re:I guess they realised... (Score 1) 152

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.

Comment Re: I guess they realised... (Score 1) 152

Ive spent the majority of my career building distributions. Trust me as a distro developer of some distinction ( 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.

Comment Re: I guess they realised... (Score 1) 152

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.

Comment Re: I guess they realised... (Score 1) 152

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.

Comment Re:I guess they realised... (Score 1) 152

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.

Comment Re:I guess they realised... (Score 1) 152

using a binary system log

$ cat /etc/systemd/journald.conf
# This file is part of systemd.

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.

Comment Re:I guess they realised... (Score 1) 152

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?


Do you understand the problem, now that it's staring you in the face?

I don't see any problem.

Comment Re:I guess they realised... (Score 1) 152

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.

Comment Re:I guess they realised... (Score 1) 152

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.

Comment Re:I guess they realised... (Score 2) 152

No, there is not requirement to use PID files. That is simply a common way to implement a daemon. With sysvinit and sysvrc (or OpenRc), this kind of thing is an implementation detail that is out of scope.

Of course. Keeping track of running services is out of scope for a service management system. Genius.

It seems to me that the reason why pid files still exist is because sysv provides next to nothing, so people end up using the easiest, but about the worst approach available.

Patently incorrect, as I have used syslog to inspect startup crashes many times over the last *twenty years* I've been using UNIX. Maybe this has been a problem for other people, but I've never seen it. If your syslog is configured badly, that's an entirely separate problem.

Not startup. Crashes, as in segfaults. Those of course don't get logged since sysv doesn't monitor what it runs. Add the wonders of pid files to that and you get a service that sometimes needs to be fixed by hand to be restarted.

Also note that I'm talking about the init system, and not about individual services doing their own logging.

While I can't speak for all distributions (you seem to have had some history with poorly-configured environments), there is nothing wrong with using sleep based polling. The only reliable way to detect if a prerequisite service is ready is by directly polling the service. (e..g issue an HTTP GET to a web server) The timeout is to allow startup to proceed in case of an error, (so you don't end up bricked, unable to use your computer)

No, no polling. Just a plain "sleep 5" in a script that hopes that the service it depends on has time to properly get started in time. I sure hope no distribution ships this kind of crap anymore, but I seem to run into such hacks annoyingly often for some reason.

There is a reason most distributions stopped using super-servers like xinetd: on-demand startup isn't that useful. Start your service at boot. You can defer expensive tasks until the first requests, if you want, which is when you would pay that cost anyway in an "on demand" launch. Listen to on the port, block on accept(2) or select(2) or similar, and let the OS page you out to the swap partition.

Of course it's useful. Why should something like cups get started without a printer? Why should the user know to enable it once they get one? These days hardware changes at runtime, and things are expected to work when you plug in a printer or a bluetooth adapter, and not to complain or stop booting if some hardware turns out not to be there anymore.

Want to have some fun? On a systemd box, pretend you just installed some updates, and you need to restart a few daemons so they run the updated versions. Try restarting dbus (system, not user). (You might want to make sure any open files are saved first)

I get a slightly ugly message from systemctl, but other than that everything seems to be working fine. Restarted it a couple times just to be sure, checked that yep, the pid changes.

Also, you might want to actually read about UNIX before you make these kinds of accusations.

I speak from personal experience

Reading taoup is a good place to start.

Thanks, but I'm not religious. I prefer things that are convenient to those that are ideologically pure.

Comment Re:I guess they realised... (Score 5, Informative) 152

Care to point out a couple of those bugs?

Okay, sure.

  1. It does next to nothing. All the real functionality is in distribution specific scripts, which means you need to research and write a script for each distribution you want to support, each with its own particular features and idiosyncracies.
  2. Each script is a bunch of boilerplate that has to reimplement the same stuff. Often badly, especially when an init script has to be improvised.
  3. The functionality is inconsistent between services. Some can be restarted, some not. Some have a status command, some not.
  4. To check whether a service is running, it uses pid files. Pid files are horribly unreliable and prone to failing if a pid file happens to be left around, and something else happens to use the same pid.
  5. If you want start on demand, eg, something like xinetd, that's an entirely different system that's managed differently and separately.
  6. If you want a service to get automatically restarted, that's also done with an entirely different system like monit.
  7. It doesn't have useful logging. Processes can vanish into the ether without useful information in the logs because stderr may not be captured in some cases, and because init doesn't log service crashes.
  8. Service providing services are tricky. You may know the daemon has started, but you don't know it's now accepting requests. Yay for "sleep" hacks.
  9. Breaks horribly the moment something goes wrong. Network cable not plugged in? Well, if you boot like that nothing network related works, so you've got to log in and fix it by hand.

Comment Re:So when are they making something we can AFFORD (Score 1) 323

Because modern solar panels are just 20% efficient, which means you still get 80% of the heat. And the parts not covered by panels keep performing just like in any other car, so you can expect this thing to be what, 10% cooler in the best case?

It could run the AC, but then I suspect it'd get much less charging done.

Comment Sounds cool, but is it practical? (Score 1) 45

It seems to still require an external pump, and liquid cooling didn't seem to take off yet except among hardcore overclocking enthusiasts. It's complicated, messy, and can fail in ways that are much worse than air cooling.

And what happens if those tiny channels erode or get clogged?

Or perhaps this is supposed to be paired with an OEM system intended to be maintenance free to solve such problems?

The article unfortunately is short on useful information.

Nothing will ever be attempted if all possible objections must be first overcome. -- Dr. Johnson