Become a fan of Slashdot on Facebook


Forgot your password?

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

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) 129

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) 129

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) 129

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) 129

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) 129

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) 129

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) 129

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.

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

What's the point of that? It's large, ugly as sin, and the concept only works assuming low use anyway. It's also not going to work as intended if you park it in a garage, inside parking spot, or in the shade.

I wonder if it's even practical in ideal conditions, because a car parked in the sun gets hot as hell, and batteries don't like that much.

It's much better to put those panels on your roof instead. That way you can go with cheaper and less efficient panels because there's less need to squeeze all the possible power in the small amount of room available, they'll be unobstructed as much as possible, collecting power at all times when there's any to collect, and it can be used for things besides the car.

Comment Re:wrong analogy (Score 1) 528

You are ignoring how other countries have benefitted from our pollution. China's economy would still be shit with 2 billion starving people instead of 1 billion.

And the glazier benefits from broken windows. That your actions had an effect that was positive for somebody doesn't mean you get out of paying damages. See the broken window fallacy.

What this country needs is a good five cent ANYTHING!