Slashdot is powered by your submissions, so send in your scoop


Forgot your password?

Comment: Re:I have an even better idea (Score 1) 277

by Knuckles (#48894637) Attached to: Government Recommends Cars With Smarter Brakes

Most cars have an off switch which disables it, some cars have various settings, and on some you cannot completely disable it (e.g., it will in any case reenable at highway speeds) such as the new Ford models.

Not sure about mechanical failsaves, but in any case, while nothing is 100% fail safe I generally trust automotive engineers or I would not step into a car. A hydraulic circuit can fail as well, for example.

Comment: Re:I have an even better idea (Score 1) 277

by Knuckles (#48894041) Attached to: Government Recommends Cars With Smarter Brakes

I do not approve of any system that will arbitrarily override my basic controls of the vehicle, it's a bad idea. Why should I or anyone relinquish control of braking to some anonymous software writer(s) that may or may not have covered all possible contingencies properly? Just one more system to fail in your vehicle. No, I propose we educate, train, and test drivers more rigorously, and if they're not truly competent, then they don't get to drive.

You may not approve, but ESC is mandatory for new cars in the US, and has been mandatory for longer in other places. It has very clearly improved safety.

Comment: Re:a better question (Score 5, Informative) 585

by Knuckles (#48844373) Attached to: Why Run Linux On Macs?

However, the Apple trackpads are limited to two fingered use on non-Apple operating systems through the use of crippled drivers and therefore something like a Logitech T650 is far superior when using a non-Apple OS.

Wrong. At least on my 2009 MB Pro 3- and 4-finger touch has been working out of the box on Ubuntu for many years.

To answer the question from TFS, I can only echo what others already wrote. When I purchased this laptop, the MB Pro had by far the nicest product design for my needs, and the PC laptops I found in the same price range did not come close: Full-body aluminium instead of plastic, smooth outer shell instead of little knobs and slits everywhere (important, e.g., when having to remove the laptop from the bag at airport security check), low-key LEDs instead of a blinking christmas tree telling me useless stuff like my wifi working (I know, no need to blink for every packet!!!) but require the use of tape when you want to watch a movie.

Comment: Re:I agree with Lennart (Score 2) 551

by Peter H.S. (#48840549) Attached to: Systemd's Lennart Poettering: 'We Do Listen To Users'

None of that speaks to why systemd needs to suck in everything under the sun that has a server mode (like the gimp and open office examples above).

It doesn't.
That a particular distro/package maintainer utilizes their distro's init-system and service manager for launching a daemon is hardly a problem or even controversial.

And just because something's launched often doesn't mean it has to be sucked into systemd. Angry Birds is launched on Linux more often than most stuff the systemd guys play with -- but that doesn't mean all games need insane dependancies on an init system.

It seems to me that have some problems with understanding what an init-system does. SysVinit/systemd/SMF deals with starting daemons and similar processes, not end user programs like games. Of course, if a game has a server mode what uses sockets and what not, then it probably is convenient to use a proper init-system.

Your container example seems to be taking the wrong approach too.

Lightweight containers like Docker seem to suggest it's best to run a single service within a container --- so the last thing such a system needs an init system -- let alone the most bloated init system in the world. A it turns out, it's quite a pain in the neck to run systemd in a docker container.

There are many different OS container modes, from running single services, to full blown servers. Each mode has it advantages and disadvantages. That flexibility is exactly what makes OS containers interesting.

Unlike other OS container implementations, systemd also support running unmodified Linux distros as containers. That means that I can boot a standard Debian distro on top of my Fedora distro, or running a newer unstable version of my distro on top. It takes seconds or minutes (depending on net speed) to launch such a container. A great way to test and debug new stuff without bothering with a full VM.
The "machine concept" that allows maintaining OS containers from the "outside" is also way cool.

All in all, systemd is on its way to become the best OS container manager the world have ever seen, and that is great news for Linux.

Comment: Re:Just keep it away from Gentoo and I'm good (Score 0) 551

by Peter H.S. (#48840389) Attached to: Systemd's Lennart Poettering: 'We Do Listen To Users'

So you like having useless software always running on your machines, that you cannot get rid of, or absolutely turn off? It also still violates do one thing and do it well because it tries to do many things, and seems to do them poorly.

"journald" isn't useless, even if you don't use binary logging, but forward everything directly to syslog.
"journald" works as a syslog helper that enhances syslog by collating all logfiles into a single file (instead of around +5 logfiles, some of them binary like "utmp"), and by collecting logging info from early boot, since journald can log from before even the root file system is mounted. When kdbus is mainlined, it will be able to collect "metal-to-metal" logging info, that means before rootfs is mounted, and after it is dismounted. Try that with syslog.

It also provide per-damon rate limiting and notification when syslog drops messages (syslog silently drops messages).

All in all, it would be stupid to turn of journald, even if forced to rely on flat file text logs.

Comment: Re:Fork it all (Score 1) 551

by Peter H.S. (#48840283) Attached to: Systemd's Lennart Poettering: 'We Do Listen To Users'

Here, I think there's some mendacity as well on the part of Red Hat. Systemd absorbed several RedHat-run open source projects that should be stand alone (D-Bus and udev, for example) and not require a dependency on systemd. That's classic Microsoft-style "embrace and extend" behavior.

There is exactly one project that joined systemd, and that was the basically one-man project "udev". The udev inventor is also the co-inventor of systemd, and that project started way before Red Hat had even started to say "no" to using systemd (they later said "yes"; read the interview). So it is demonstrably wrong to claim that RH could have forced Kay Sievers/udev into the systemd project.

Dbus isn't a single project, but a standard just like tcp/ip with several different implementations. systemd makes heavy use of dbus, and even have some dbus helper libs, but the point is that systemd works with the "standard" dbus specification, regardless of implementation. That is the whole point of using a standard.

All the talk about RH/systemd "subsuming" other projects are simply plain wrong.

Comment: Re:Just keep it away from Gentoo and I'm good (Score 1) 551

by Peter H.S. (#48840205) Attached to: Systemd's Lennart Poettering: 'We Do Listen To Users'

System is broken by design and totally violates the UNIX philosophy

Systemd isn't broken by design, it is in fact a brilliantly designed init-system which is why all major Linux distros are converting to it.

"UNIX philosophy" seems to be a codeword for "I have no real technical arguments against systemd".

But tell me this, if the most popular certified UNIX platforms are using init systems very similar to systemd, like SMF and launchd, aren't you really claiming that certified UNIX'es aren't UNIX?

Even non-certified UNIX clones like FreeBSD are talking about the necessity of having a init-system just like systemd/SMF/launchd. It is only a matter of time before all *BSD's have a modern init-system, and of course, they will clone every systemd feature possible.

Comment: Re:Just keep it away from Gentoo and I'm good (Score 1) 551

by Peter H.S. (#48840133) Attached to: Systemd's Lennart Poettering: 'We Do Listen To Users'

Systemd does startup, it does logging, it does ntpd, it manages processes.. What do you think it does that is just one thing?

The point is that this is all done by different daemons and tools. So each systemd tool basically just do one thing. It is documented in the man pages if your are interested in facts.

Oh and by the way, systemd doesn't do "ntpd". Claiming that is a sure sign that you haven't studied the systemd documentation. systemd comes with an optional sNTP client that is meant for use in OS containers, which have special timekeeping needs because of timedrift between host and container when sleeping etc.

Comment: Re:The very first thing out of his mouth (Score 1) 551

by Peter H.S. (#48840019) Attached to: Systemd's Lennart Poettering: 'We Do Listen To Users'

The only real fault I could give it is that in my experience, if you're so tightly wired into external things that you become an essential part of them, that's probably not the optimal system design.

That really isn't the case with systemd; it basically depends on glibc and util-linux for "mount" etc. just like most other init-systems, but everything else is optional.

That upstream projects actually make use of systemd features like systemd-logind can hardly be a problem either; all the non-systemd platforms are free to provide their own similar services that upstream projects can use, so there are no problems there either.

I DO have a lot against the binary logging for very good reasons. I've worked with a lot of products that did their logging in proprietary binary formats over the years, and even when the internal data formats are well-published, the mere fact that intermediary services are required to access and format them has made their respective products harder to work with.

Some facts first; systemd's journal isn't proprietary. It is a well documented standard with a stable API and language bindings:
There are several independent journal readers already. I can't think of any non-contrived user case where it is a problem that the logs are binary.

In fact, I can't think of any non-contrived user case where old style flat text file logging is better than systemd's journal; it scales better in every direction and allows for powerful filtering in a much better way than using humongous regex lines, is much more secure, allows for a single collated system log and much better debugging, etc. etc.
Not forgetting that it is now possible to have reliable, robust logwatch scripts and even make a log viewing GUI that isn't just a glorifed "less" with windows decorations.

Just like you I have been bitten by (proprietary) binary log files (and much worse; binary config files). And just like you I was really, really skeptical about systemd's binary log format. But the more I used it, and the more documentation I read, the more I became really glad about it: systemd's journal just solves so many problems I have had over the years with syslog files. It is a really well thought out and well designed logging system.

Comment: Re:I agree with Lennart (Score 1) 551

by Peter H.S. (#48838743) Attached to: Systemd's Lennart Poettering: 'We Do Listen To Users'

I don't understand why 90% of the crap systemd's trying to suck in (like networking). Yet the systemd guys continue to glom everything in there.

If you don't understand it, it is probably because you don't use OS containers. Almost all new features and development on systemd the last couple of years have been OS container related; the sNTP client, networking, dhcp etc., are all meant for massive scale OS container deployment, and for the special need for OS container regarding keeping time (their environment can start-stop/freeze without notice, so time drift between host and container is a problem).

Google launches 2 billion OS containers a week, that is 3300 OS containers every second. The speed of "booting" a single OS container is therefore crucial for such massive deployments.

In fact, OS containers are rapidly becoming a central part of all new Linux deployment, and systemd is a central part of that.

Comment: Re:The very first thing out of his mouth (Score 1) 551

by Peter H.S. (#48838649) Attached to: Systemd's Lennart Poettering: 'We Do Listen To Users'

I tend to grit my teeth when people say "If it ain't broke, don't fix it" about IT. IT tends to erode from the outside in, if no other way.

On the other hand, if you do "fix it", don't break things that people like and rely on.

So nothing on Linux must ever change, because there is always some reactionary, lazy admin somewhere who can't be bothered to learn something new and change his work-flow.

I have seen so many examples of such "IT-fossilization" during the last three decades. Some people scream and moan about how "new way" is bad and "old way" is much better. The end result is always the same; they get ejected out of the IT business when their old and obsolete skills are no longer needed.

If you work in tech, you just better have to learn to adapt to new and better technology like systemd. The first step in this is to be factually informed about how the new technology works.

And don't have the hubris to tell people that they're wrong/misguided/old-fashioned when they complain. That's the sin that both gnome3 and systemd committed.

Don't tell me you rely on hearsay from some swivel eyed systemd-hater to know the technical facts about Gnome and systemd?

It is a plain view fact that Gnome 3 runs on non-systemd platforms like BSD. So where is the problem?
Is the problem that Gnome developers for years have pleaded for someone to step up and actually maintain crucial infrastructure needed by Gnome in order to work on non-systemd systems?

Life is a whim of several billion cells to be you for a while.