Kernel DBus Now Boots With Systemd On Fedora

An anonymous reader writes "Red Hat developers doing some holiday hacking have managed to get a bootable system with systemd + KDBUS on Fedora 20. KDBUS is a new DBus implementation for the Linux kernel that provides greater security and better performance than the DBus daemon in user-space. Systemd in turn interfaces with KDBUS for user-space interaction. Testing was done on Fedora 20 but the systemd + KDBUS configuration should work on any modern distribution when using the newest code."

Comments

"Slashmirrored"

[Anonymous Coward]

So do we just mirror phoronix on slashdot, now?

Re: "Slashmirrored"

[Anonymous Coward]

KDBUS!

The same group of Prople behind

Wayland
Gnome3
Pulseaudio
Systemd
Journald
Alienating Udev
Alienating 95% of their Userbase

If you all have so much problems with the ideology of Unix then why do you use a Unix based System. Why don't you move on and create your shabby world elsewhere ? Without causing more damage to ours ?

Btw: Why is KDBUS code full with 'goto' calls ?

Re: "Slashmirrored"

[Anonymous Coward]

The KDBUS source is in BASIC? Well there's your problem!

Re: "Slashmirrored"

[SumDog]

My first experience with systemd was on OpenSUSE. Although it seems like a good idea, it seems to add some unneeded complexity. /etc/init.d/someservice restart now redirect to systemctl, with no real output. Oh I have to run status to see if it succeeded. Now I have to use journalctl to see why it failed.

I'm all for dependency based init systems, but I feel Gentoo got that right with OpenRC. It gets rid of all that rc1,2,3,4,5 crap while keeping the /etc/init.d/ structure we're familiar with.

Gentoo can not be setup to use systemd too. I guess it's now the future; better get use to it.

Re: "Slashmirrored"

[Desler]

Btw: Why is KDBUS code full with 'goto' calls ?

For the same reason the kernel uses them. Because they aren't mindless ideologues.

Re: "Slashmirrored"

[sjames]

Actually, overall I would prefer sticking with /etc/rc[1-5]. It is simple and functional.

All the new crap strikes me as some combination of fixing what's not broken and a solution desperately seeking a problem.

Re: "Slashmirrored"

[Sri Ramkrishna]

You realize that a lot of systemd is supported by kernel developers. These things just don't get integrated by accident. The kernel has features, kernel devs want them used. If you want classic Unix, go head over to the BSD world.

Re: "Slashmirrored"

[modmans2ndcoming]

because RC[1-5] works so well with sleep and hibernate states on Laptops....oh wait....no it doesn't.

Re: "Slashmirrored"

[modmans2ndcoming]

here I thought it was because it was created by a bunch of self taught garage hackers.

Re: "Slashmirrored"

[Desler]

Nope, it's because gotos are very nice for error handling over rats nests of if/else. Which is what its predominate use in the kernel is.

Re: "Slashmirrored"

[sjames]

All that was required was to either wake from sleep OR go through the usual rc[1-5] scripts.

Re: "Slashmirrored"

[sjames]

What makes you think I don't? Of course, that's on my own systems since once the pollution is allowed in, the old stuff doesn't work so well anymore.

Re: "Slashmirrored"

[sjames]

So what you're saying is that there is already a maintainer? Me not being from the universe with a bearded Spock, I figured I probably shouldn't kill anyone to take their place.

Re: "Slashmirrored"

[Mister Liberty]

Hi Theo!

Re: "Slashmirrored"

[armanox]

Don't tempt us. The users, admins, and engineers that have to keep these systems running are not happy.

Re: "Slashmirrored"

[JSG]

>> Gentoo can not be setup to use systemd too

Are you sure? My laptop begs to differ:
$uname -a
Linux jglaptop 3.12.6-gentoo #1 SMP PREEMPT Sat Dec 28 11:22:53 GMT 2013 x86_64 Intel(R) Core(TM)2 Duo CPU P8600 @ 2.40GHz GenuineIntel GNU/Linux

and spits out things like this:

gerdesj@jglaptop:~$ systemctl status apache2
apache2.service - Apache Web Server
      Loaded: loaded (/etc/systemd/system/apache2.service; enabled)
      Active: active (running) since Sat 2013-12-28 12:18:03 GMT; 1 day 10h ago
    Process: 2719 ExecStart=/usr/sbin/apache2 $APACHE2_OPTS -k start (code=exited, status=0/SUCCESS)
  Main PID: 2796 (/usr/sbin/apach)
      CGroup: /system.slice/apache2.service
                      2796 /usr/sbin/apache2 -D INFO -D MANUAL -D SSL -D SUEXEC -D LANGUAGE -D PHP5 -D DEFAULT_VHOST -D SSL_DEFAULT_VHOST -D SECURITY -D PERL -k start
                      2797 /usr/sbin/apache2 -D INFO -D MANUAL -D SSL -D SUEXEC -D LANGUAGE -D PHP5 -D DEFAULT_VHOST -D SSL_DEFAULT_VHOST -D

Cheers
Jon

Re: "Slashmirrored"

[Anonymous Coward]

The unneeded complexity, moreover, does not befit a Unix. If you want one of those, you need to steer clear of most everything the freedesktop crowd, most notably mister Poettering, come up with. Otherwise, what you get is a sort of linux in windows-like sauce, compatible with nobody like a good little redmond product. If that's what you want, go for it. But software developed for this environment will no longer play well with other Unices. In fact, it is no longer a Unix, certainly not in spirit.

Note that I'm not condemning this per se, but it does have far-reaching implications that honesty compels you to be aware of.

Re: "Slashmirrored"

[jcdr]

I am a user, an admin of a few systems, and an engineer of a numbers of systems.
And I am really very happy by the KDBUS and systemd move.

Not only there are technically good, but I hope that others concurrent projects will fork this common code base and start talking together what will be valuable to merge, instead of creating a yet another pointless unconnected project that will never gain enough audience to change anything but increasing the number of choice problems for a lot of distributions.

Re: "Slashmirrored"

[Desler]

Instead of the empty threats, simply do move on. I'm sure the kernel devs won't miss you.

Re: "Slashmirrored"

[chrylis]

Pretty obvious typo for "can now be".

Re: "Slashmirrored"

[whois]

I agreed with you until Windows 8 came along and could cold boot to GUI in less than 3 seconds. I would still agree for servers. Boot up speed doesn't matter if you never shut down, but the market is changing.

Boot speed matters if you spinup and shutdown instances all the time. It also matters on the desktop, both markets are larger than the "pure server" market. So you can either maintain two boot sequences for different purposes or you can put all your attention into the new sequence. The advantage of the second is that even people who don't need fast boot now are learning how the new stuff works.

And it sucks, but that doesn't mean it can't be improved and made as good as the old system or better.

Re: "Slashmirrored"

[celle]

"Btw: Why is KDBUS code full with 'goto' calls ?"

      For the structured programming crowd:
AAAAAAAAAAAAAAAAAAAAAAHHHHHHHHHHHHH!!!!!!!!!!!!!!!!!!!!

Now start breathing again and be happy it's not your code. I'm probably going to look at the code soon just to see any 'goto' statements(been awhile) and my internal coding voice is saying in a sinister tone "You're going to drinking early tonight."

cap noonday

Re: "Slashmirrored"

[loonycyborg]

It seems to me that it removes unneeded complexity too. Like no longer having to have initscripts in bash which is a fully featured programming language. Most of them consist of boilerplate and most people don't have complete understanding what exactly it does. Naturally it leads to more bugs. I don't believe systemd adds any new complexity but more like moves it from individual initscripts and special purpose utilities to common base. I think it leads to less work for everyone because you don't have to reinvent wheels.

Re: "Slashmirrored"

[armanox]

What they won't miss is me. What they will wonder is why organizations, such as the US Department of Energy, start moving away from Linux servers. And that will be because of people like me.

Re: "Slashmirrored"

[PlusFiveTroll]

Even on fast SSDs I've never seen 8 cold boot it in 3 seconds. 9-12ish maybe. Add in windows networking and it's much slower. Also Windows delays a lot of tasks so you are to the GUI but your actual services are not running yet. In the server market your boot speed is highly dependent on network resource dependencies with varying delays.

Re: "Slashmirrored"

[celle]

"go head over to the BSD world."

    I already have. As a Linux user from very near it's beginning(93-94) and dumping Windows completely over it's shenanigans in the early 2000s. I'm now seeing Linux become Windows. Unfortunately BSD is affected by the influence of the shadow(guess the reference) as well(applications and support systems). Guess Plan9 if it's developers would stop treating it as their personal toy and expand it's application support to something a wider audience could actually use...

Re: "Slashmirrored"

[MikeBabcock]

I started using DJB's /service system back with qmail and quite liked it, then thought systemd might be something even better. Sadly, its not.

I find it quite frustrating that auto-restarting scripts that just run in their own directories can still be that much easier to configure than the default boot system.

Re: "Slashmirrored"

[MikeBabcock]

Boot up speed is incredible with /service (see http://cr.yp.to/daemontools.html) and dependencies aren't hard to wire into those scripts at all. What kills me is that systemd is so much more complex for no gain over something so simple as an auto-restarting shell script.

Re: "Slashmirrored"

[MikeBabcock]

That's the most ignorant thing I've read all day -- the vast majority of people using Linux are not kernel developers, and I'm quite certain they don't navel-gaze enough to think they are.

I'm quite literally nervous about moving client servers to systemd in the future and we've purposely held back because the old init system is predictable and easy to manage.

Re: "Slashmirrored"

[MikeBabcock]

Don't be a jerk just because you can. Try backing up and looking at a situation from all sides before you go mouthing off and maybe you'll come up with a rational response instead.

Re: "Slashmirrored"

[Anonymous Coward]

The thing is Windows makes shutdown take longer. (Overall for me with Windows 8.1 less time is wasted with disabling the hibernation).

Slightly slower boot faster shutdown.

Re: "Slashmirrored"

[sjames]

Most tablets and such hibernate rather than rebooting these days and I never reboot my desktop machines (though unreliable power does so once or twice a year).

However, I do see the value for firing up instances and that others might value it as well. I don't see why not just have the rc system fire off all scripts with the same priority level at once. Then if desired, run a priority optimizer to fix the links up based on dependencies.

Re: "Slashmirrored"

[Sri Ramkrishna]

I assume you mean that Linux is being monolithic instead of following the Unix credo.

Re: "Slashmirrored"

[Sri Ramkrishna]

I fail to see what is ignorant about people writing features and wanting people to use them. You have companies like Red Hat whose job is to integrate them in a stable manner with some extra work to migrate to the new paradigm. How often do you touch your init system, honestly? I never touched mine in my 20 years of doing Unix systems. You need to read up about systemd and understand how it works and what it does. You fear change, but your level of risk is no different than integrating some new product from a vendor. If you decide to move to RHEL or some other enteprise linux,, you'll be covered. Now if you are winging it, then of course, you should take as long as you need to do it correctly. I suggest you read Lennart's series of documentation on system administrating systemd. You're not losing any functionality and gaining some.

Re:"Slashmirrored"

[codeusirae]

"So do we just mirror phoronix on slashdot, now?"

Since when is news about a LInux distro considered off-topic on slashdot ..

Re: "Slashmirrored"

[drinkypoo]

because RC[1-5] works so well with sleep and hibernate states on Laptops....oh wait....no it doesn't.

It would if it were used as it is intended. That is to say, sleep and hibernate states ought to themselves be runlevels. I have never been able to puzzle out why this is not so already.

Re: "Slashmirrored"

[Sri Ramkrishna]

How do you know the U.S. Dept of Energy isn't asking for this stuff in the first place?

Re: "Slashmirrored"

[Anonymous Coward]

My systems just sleep. They don't need to fuck around with init.

Re: "Slashmirrored"

[dpilot]

It was kind of fun to see Linus' reaction when the systemd developers attempted to push binary logging into the kernel.

Maybe some kernel developers are pushing systemd, not all.

Re: "Slashmirrored"

[Sri Ramkrishna]

This is true, but a lot of systems folks have been looking forward to this.

Re: "Slashmirrored"

[Anonymous Coward]

Correct, the 3 second boot times are when Windows 8 logs out and hibernates instead of shutting down.

Re: "Slashmirrored"

[Anonymous Coward]

>> Gentoo can not be setup to use systemd too

Are you sure? My laptop begs to differ:

I think what he *meant* by that is "cannot be set up to use openrc and systemd at once".

I'm proud to say that on my Gentoo machines, this is what I get when I type systemctl
bash: systemctl: command not found

Re: "Slashmirrored"

[unixisc]

How is BSD being influenced by the shadow? They have not adopted Systemd, don't support GNOME 3 (except OpenBSD), and are only adopting technology they consider suitable, not anything & everything.

As for Plan 9, there is an FOSS version of it called Inferno. You could try that out.

Re: "Slashmirrored"

[unixisc]

Theo? OpenBSD is the only BSD that supports GNOME3: even GhostBSD doesn't - and won't.

Re: "Slashmirrored"

[armanox]

Because until recently I was a network engineer to the DOE (contractor). And they don't like a lot of things in Linux - they disable iptables and selinux, for example. They also have no interest in Linux on the desktop, only in a server capacity. And that was fading when I left.

Disclaimer (probably required after that statement): I am a former federal contractor, and my opinions expressed here do not necessarily represent official opinion or policy of the United States Department of Energy or my former employer.

Re: "Slashmirrored"

[visualight]

There are no "choice problems". NONE. There is not one single distribution with a preponderance of devs who think choice is a problem.

Having choices is the POINT.

This is a case of someone in a long line of wheel re-inventors shutting the door behind him so no one else can come after.

Re: "Slashmirrored"

[Anonymous Coward]

"They don't like a lot of stuff" so they will just disable it, that is the whole point.

But why do you assume they know what they are doing? Sounds to me like they don't.

Re: "Slashmirrored"

[Anonymous Coward]

The only people developing Plan9 today are 9front and Erik Quanstrom (9legacy), There is only one guy employed and Bell, part time, to accept patches, and he doesn't accept patches that add functionality or hardware support.

I have in-depth experience with this, as a former 9front developer. I left 9front because of the immature demeanor of the 9front development team (see #cat-v on freenode), and the technical infeasibility of adding shared memory or efficient IPC to Plan9. Pretty much all IPC is copied at least twice (four is common) in Plan9, and it gets worse quickly when you add layers of 9P servers.

While I love the namespace isolation (security and reusability by design) which simplifies a great many tasks, the constant 9P marshalling (the kernel implementation) renders Plan9 terminally deficient in performance.

I would like to see/build a Plan9-like system, where the filesystems are exposed to the OS via a more fuse like API, which would greatly improve performance and remove a large amount of the IPC bottleneck of Plan9. For example, a filesystem could be exported through another filesystem without invoking serialisation, unless network topology actually necessitated it.

I'm not going to post my identity here, because of the childish abuse I received from the 9front cult last time I voiced my opinion on these technical matters, though it is probably obvious to cinap_lenrek and aiju who I am, so I expect abuse anyway.

Re: "Slashmirrored"

[Anonymous Coward]

That's why they contracted him. And yes maybe they had special requirements that sellinux caused problems with.

Re: "Slashmirrored"

[Anonymous Coward]

If you'd never touched sny initscripts within your past 20 years of unix then you should be the person who cares less about systemd at all.

But the way you comment and cheerlead about it shows big signs of agressive community work and massive manipulation of people.

They must love systemd regardless of the consequences.

I tell you - they don't have to. It's theor good right to not learn about it and to raise a voice against it.

I am sick of people forcing crap down our throath - first - and then having us wearing the shoe - afterwards. We did not ask for systemd , we don't want it and we don't need to explain it either. We also don't want to be put in a position where WE need to excuse us afterwards for things implemented by YOU.

Re: "Slashmirrored"

[Pseudonym]

Why is KDBUS code full with 'goto' calls ?

Without looking at the KDBUS code, there are typically two answers to that question.

1. It's the easiest (and arguably cleanest) way to model a state machine.
2. Linus doesn't want C++ in the kernel and it's the only way to do stack unwinding in C.

Re: "Slashmirrored"

[Anonymous Coward]

Well, dependency management for one. And the idea that I want my device to always be in one of a very few number of discrete states for another. What if I want WiFi off and GPS on and the disk spun down based on the AC power state and the display sleep based on the media playback state and the BitCoin miner based on the combination of Internet connectivity and AC power states? rc.d is pretty bad even at managing a small number of states, let alone the huge number of interdependent states available in modern systems with a slew of independently powered and managed subsystems.

Like systemd or don't, but let's not pretend the rc.d is just a slight tweak away from dealing with modern systems.

Re: "Slashmirrored"

[Pseudonym]

C++ automatic stack unwinding is even nicer, but you can't have C++ in the kernel because mindless ideologues.

Re: "Slashmirrored"

[Anonymous Coward]

No one with senses did look forward for binary logging!

Looking in my /var/logjournald/hash/

Directory shows 4x 8mb files per default. That is 32mb of binary skeleton only after first startup of fedora 20

After a while the 8mb of systemd.journal gets a multiple of 8mb in size increased. After just 1 week I had nearly 200mb of binary log files sitting in that directory

No proper way to grep or even read the bugs.

For every user added to your server (someone who logs in) another new 8mb skeleton is build. A large server farm in a facility will probably get quite upset by all this.

1000 users x 8mb of initial logs

Re: "Slashmirrored"

[YoungManKlaus]

> Btw: Why is KDBUS code full with 'goto' calls ?

checking https://github.com/gregkh/kdbus/blob/master/bus.c
because it makes more sense than a huge nested if/else structure. if it was oop you'd also do "if(bla) throw ex1; if(b) throw ex2; ..." and then handle the common exit operations in the finally block. Nothing else going on there.

Re: "Slashmirrored"

[Anonymous Coward]

You are seeing Linux become Windows? That's true! We now have GUIs and a Steam client with games to play!

I waited long time until my desktop could be free of Windows and yes, we are slowly coming there. IMHO that's A GOOD THING.

Re: "Slashmirrored"

[Anonymous Coward]

RC levels don't properly support the idea of a transition graph. That is to say, RC levels should have been modeled as nodes, the allowed transitions between them as arcs, and the actions needed as properties of those arcs. Essentially this is a sparse matrix (can't go from hibernate to sleep, for instance) so a more efficient representation can be used. systemd does better in that respect, although you can argue implementation.

Re: "Slashmirrored"

[drinkypoo]

Well, dependency management for one.

That's handled by the user. But a tool could be developed which would create all the symlinks for you, if that's too hard. A simpler one, I mean, besides all the ones which already exist.

And the idea that I want my device to always be in one of a very few number of discrete states for another.

Yes, that's what runlevels are for.

What if I want WiFi off and GPS on and the disk spun down based on the AC power state and the display sleep based on the media playback state and the BitCoin miner based on the combination of Internet connectivity and AC power states?

That's a job for another daemon, as it is now. There's still no reason for that daemon not to switch runlevels when power state is detected.

rc.d is pretty bad even at managing a small number of states, let alone the huge number of interdependent states available in modern systems with a slew of independently powered and managed subsystems.

Huge number of inderdependent states available in modern systems? Availble, yes. Used? No. Systems usually use about three different states, awake and a couple of sleep states. Some people use hibernate as well, so there's four. That's well within the reach of rc.d. Systemd already doesn't handle all of the possible states a computer can be in; the init system only has to care about the major ones.

Re: "Slashmirrored"

[Anonymous Coward]

Automatic stack unwinding in the kernel? Are you entirely insane?

There are good reasons for not using C++ in the kernel, not least of which is you basically can't use the vast majority of C++ features because they make too many assumptions about the runtime environment, and the kernel can't make any guarantees.

Re: "Slashmirrored"

[jcdr]

http://www.phoronix.com/scan.php?page=news_item&px=MTQ5NzQ

Re: "Slashmirrored"

[Anonymous Coward]

I think he meant to type "now", since "not" seemed to directly contradict what he said in the sentence before.

Re: "Slashmirrored"

[Anonymous Coward]

How do you solve socket activation (and any of the other features in SystemD) with your auto-restarting shell script?

Re: "Slashmirrored"

[Anonymous Coward]

You forgot the part where it would introduce a LOT of new problems to solve a problem that doesn't exist. But yeah, blind ideology, right.

Re: "Slashmirrored"

[Desler]

I'm not being a jerk. I'm simply stating that the person should actually do something rather than just blather on with empty threats. They aren't going anywhere and they know it.

Re: "Slashmirrored"

[chill]

They probably disable iptables because they don't use system-level firewalls on servers, regardless of the OS.

And they disable SELinux because they probably don't have anyone who understands how to use it, much less use it well. MAC is great for security, but requires a depth of knowledge of your systems that most places just don't have.

I've seen both actions at several government agencies for those exact reasons.

Re: "Slashmirrored"

[staalmannen]

There are several real Plan9 variants and they are all FOSS (LPL is OSI approved) 9atom: http://9atom.org/ 9front: https://code.google.com/p/plan9front/ 9legacy: http://www.9legacy.org/ and the real bell labs distro: http://plan9.bell-labs.com/plan9/

Re: "Slashmirrored"

[coolsnowmen]

haha, where is my +1 troll mod?

Re: "Slashmirrored"

[visualight]

"...It would be a miracle if they would vote against adopting upstart..."

Seems pretty set, unlike the dramatic phoronix headline. In any case, having a choice is not something anyone seems to have an issue with.

Re: "Slashmirrored"

[Anonymous Coward]

C++ automatic stack unwinding is even nicer, but you can't have C++ in the kernel because mindless ideologues.

History begs to differ... they tried it

Re: "Slashmirrored"

[shaitand]

Admins want certain core systems needed to admin a box to be standardized. It's an init system, there is only so much benefit you can have from one over another and those benefits don't outweigh the problems of distributions all being different.

An admin should be able to log in to a box and perform basic administration without having to care what distro it is running.

Re: "Slashmirrored"

[shaitand]

"And they disable SELinux because they probably don't have anyone who understands how to use it, much less use it well. MAC is great for security, but requires a depth of knowledge of your systems that most places just don't have."

Not talking about government agencies but there certainly are a lot of people who don't understand SELinux, mostly because it is confusing as hell and poorly documented. But even if you do understand it, it is cumbersome, it never becomes a silent player that just works, and to get any real benefit out of it requires TONS of additional time and overhead in system configuration.

What I usually see is people leave it on until the first instance of cryptic failures that can be traced back to SELinux problems.

Re: "Slashmirrored"

[Sri Ramkrishna]

Yeah, most people find SELinux difficult to use. I can understand disabling it. That doesn't make the entire system bad.

Re: "Slashmirrored"

[shaitand]

I'd contend that the idea is good but the implementation is bad. That's probably because it was designed by a government agency for government use that parallels the screwed up government models for controls and access to information.

For a system that is single purpose and just sits there except at update time I use SELinux every time. Because everything that raises the security bar is a good thing. For a system with lots of activity I take a pass, SELinux just adds too much troubleshooting and configuration overhead. If you invest that time and effort across the board it is almost certainly costing you more than additional risk of not running SELinux.

At least as things stand now. If Linux were attacked with the frequency and in the same ways the windows platform is attacked SELinux might quickly become a painful fact of life. But I'd expect if that were the case someone would come along and develop something a bit more sane to work with.

Re: "Slashmirrored"

[Anonymous Coward]

Socket activation was solved ages ago by inetd.

Pottering touts the "I'm going to preallocate ALL THE UNIX PIPES!" method as superior to the "Each daemon manages its own Unix pipe" method. Frankly, if you're writing software that speaks over sockets/pipes (sockets), and you don't handle the cases where the socket doesn't exist, can be sent no more data, or has a disconnected remote end, you're doing it wrong.

Pottering et. al. should not be encouraging people to write broken software that only works because of the handholding provided by systemd.

Re: "Slashmirrored"

[MikeBabcock]

Its unnecessary. See AC response.

Re: "Slashmirrored"

[MikeBabcock]

I shouldn't need to read half as many words as I do to understand systemd and how it works. Let me give you a counter-example:

Using daemontools, each service has a directory in an arbitrary location that is symlinked to /service. Any directory with a symlink in /service will have its "run" script executed on startup if it exists. That script's output will be piped to the run script in the subdirectory log. If the run script exits, it will restart again in two seconds. To prevent automatic startup, create a file named "down" in that service's directory. Each service executed in this way is forked securely in its own memory space.

That's it.

Added functionality is provided by additional software meant to be called from within said run scripts, such as softlimit to impose memory or fd limits on processes, tcpserver to launch a program for each incoming connection (much like inetd) and envdir to create environment variables based on the contents of files in a directory. All of these things are optional and so configuring a new service without a reference manual is possible in just a minute or two.

Feel free to update me when a fully functional systemd script can be explained that simply.

Re: "Slashmirrored"

[MikeBabcock]

People leave Linux every day. Its not like we have 80% market share or anything. I know at least five people who tried and gave up on Linux this year alone. Its sad, but their own reasons were all perfectly valid.

The one constant in Linux promotion and usage is sysadmins. Angering that population is very bad PR, whether you think PR is worth anything or not.

Re: "Slashmirrored"

[Anonymous Coward]

OpenRC is also a system that moves a lot of complexity into a central core. It, too handles automatic service dependency determination and parallel startup. It does *not* handle event-based service startup, but I'm on the fence about the usefulness of that. For Poterring's tiny, tiny, slice of the Linux world (automotive infotainment displays and controls) this feature makes a bit of sense.

Re: "Slashmirrored"

[Pseudonym]

Automatic stack unwinding in the kernel? Are you entirely insane?

Are you saying it would be worse than the goto-heavy manual stack unwinding it currently uses?

Re: "Slashmirrored"

[Anonymous Coward]

You can't have C++ in the kernel because you clearly don't understand how the kernel works and why C++ is unsuitable to start jamming in there.

Re: "Slashmirrored"

[Anonymous Coward]

Only when you don't have sibling call optimization... which the kernel should, at least within a single module, since it's written in GNU C and not ANSI C.

Re: "Slashmirrored"

[Anonymous Coward]

Yes, it's particularly "nice" when you're in the middle of unwinding the stack and a destructor calls a function that calls another function that throws an exception. That's a fun little easter egg in the C++ standard, right there.

Re: "Slashmirrored"

[Pseudonym]

I understand how the kernel works technically (along with several dozen production OS kernels which are written in C++ with no problem). But more to the point, I understand that C++ is unsuitable because of how the Linux kernel works sociologically. Despite the "mindless ideologues" comment (which should have been clear was a facetious call-back to an ancestor comment), I'm perfectly fine with this.

Why, oh why?

[Anonymous Coward]

Why do we need in-kernel DBUS implementation. And please don't tell me about performance, lot's of software with much higher performance requirements is more than happy in userland...

Re:Why, oh why?

[armanox]

Canonical is innocent - it's Red Hat's doing. Just like Pulseaudio and a million other innovations (some good, some less then good). But Red Hat has had a hand in most of the desktop development that people see.

Re:Why, oh why?

[fisted]

Because GNU!

Fortunately, the BSD world is much less insane.

Re: Why, oh why?

[Anonymous Coward]

Most of those people are hired and paid by Red Hat to code what Red Hat envision.

What happens right now is the biggest and most agressive consolidations process since the existance of Linux.

systemd and jounald as coreOS that consolidates all we had known. Logging, inetd, sysvinit, timed, udevd, ipc etc.

Gnome3 for dumb people as main Desktop dealing a lot with systems.
Kernel that now implemented kdbus to explicitly communicate to systemd.

Wayland to replace X11 to work close to Gnome3.

All a big consolidation!

linux (kdbus) -> systemd -> wayland / gnome3

What remains from what we know ? Nothing!

I am not against consolidation but I am against this sort of agressive behaviour!

In 2-3 years nothing remains that reminds of Linux to be Unix related.
Even worse there are talks to have some sort of iPhone or Android like package mechanism to place apps with all deps (libs etc) in a sandbox within an apps directory. Even systemd already provides dealing with that.

What kind of OS is that?

Re:Why, oh why?

[Anonymous Coward]

We don't need in-kernel DBUS. Userland can run such things just fine. Is there a "need for speed" and prompt response? Well, so raise priority of the userland dbus daemon then. Right up to real-time priority if need be. That works for jack, which have real-time constraints that can be hard to meet. It works for robot control software. So surely a userland approach will work for something as benign as dbus.

You can even run a linux system without any dbus at all - it is definitely not needed in the kernel.

Re:Why, oh why?

[Anonymous Coward]

Lennart Poettering, nothing he touches is easy to remove once it has a foothold. And it seems everyone who packages it is drinking the same coolaid. Sometime I wonder if packaging tools should have a 'shit can list' that allows packages to be block per developer.

Just blocking this guy would prevent pulseaudio, systemd and avahi.

Re: Why, oh why?

[epyT-R]

What kind of OS is that?

An OS ready for the radiant fascist/socialist future where the user has no control over the computer driven devices he supposedly owns.

Re:Why, oh why?

[SumDog]

Pff. Of course it's needed in the Kernel. How else is Linux going to get bloated as Windows? I mean come on, the Windows kernel has JPEG and PNG decoders in kernel space! (or at least it did at one point in time, hence the endless amount of IE6 security problems back in the day).

Re:Why, oh why?

[epyT-R]

Is OpenBSD really suitable for typical desktop uses? Does it perform well?

Re:Why, oh why?

[epyT-R]

I thought those vulnerabilities were vectors because IE6 ran with escalated privileges..

Re: Why, oh why?

[Anonymous Coward]

I recently tried NetBSD but it had an ancient version of XFCE (4.6 from 2009). There is an experimental 4.8 version in -WIP bur I haven't tried it.

Compares to Linux, NetBSD shops a lot of really outdated packages. But I was told that the reason behind it are mainly the huge dependencies that Linux uses. ConsoleKit. PulseAudio, PolicyKit, PoetterKit etc.

Re: Why, oh why?

[sjames]

Windows.

Re:Why, oh why?

[sjames]

I'm not convinced we need DBUS at all, much less in the kernel.

Re:Why, oh why?

[sjames]

The biggest audio performance boost I have gotten was when I killed pulseaudio so that everything would use ALSA.

Re:Why, oh why?

[jcdr]

I good reason is the future possibility to manage kernel features in a more formal way than with the /proc or /sys interfaces.

It has taken about a decade to bring a standard IPC protocol to Linux. I mean a protocol that truly work between applications from different team of developers.It's now time to use it from a wider audience. Making it part of the kernel not only make it a bit more fast, but it clearly make it a more appealing choice for applications that need IPC.

Re:Why, oh why?

[Sri Ramkrishna]

KDbus is being done by Greg K-H of Linux Foundation. There are some good reasons for having a kernel bus. The first rev was killed, but the second rev is being worked on. Linus has already signed off on getting this integrated. It's just a matter of working out the details. A lot of this is driven by desktop projects, so things like smooth transition to a login screen, wayland, application sandboxing are good reasons to have it.

Re: Why, oh why?

[MichaelSmith]

A sandbox would be a good idea. If I install software to interface to a printer, or read a spreadsheet I should reasonably expect that the software should only be permitted to what it claims to do. A good, working sandbox for drivers and applications would be good for the user and a significant advantage over windows.

Re:Why, oh why?

[Anonymous Coward]

Good for you. Why should anyone care? Pretty sure Greg K-H knows more than you.

Re: Why, oh why?

[Sri Ramkrishna]

Surely, all you really need is something like fvwm2 or something right? I mean, two bars, some extra stuff, and you're good right? The only thing is that you don't have compiz effects. But otherwise, you'll probably have a pretty useful desktop with full control.

Re:Why, oh why?

[jcdr]

Comparing a KDBUS to a JPEG or a PNG decoders ?
Try instead to compare the Linux KDBUS code to the Linux TCP/IP stack...

Seriously, the Linux kernel is only bloated by the fact that it need thousands of drivers to handle decades of hardware diarrhea that released incompatibles devices as fast rate. Certainly not by the KDBUS code.
 

Re:Why, oh why?

[Sri Ramkrishna]

We'll have Greg K-H talk to you personally. Without your sign off, it'll be unlikely Linus will integrate it without overriding your objections.

Re:Why, oh why?

[sjames]

So you believe I have no right to an opinion? Or just no right to express it?

Re:Why, oh why?

[sjames]

Argument from authority?

Re:Why, oh why?

[Anonymous Coward]

Sure, because he's got more than a decade of kernel development experience. You're just some random whiner on Slashdot.

Re:Why, oh why?

[x_t0ken_407]

Can't speak of OpenBSD, but I currently use FreeBSD + KDE4 on my gaming desktop (when I'm not gaming), and it's phenomenal. More stable than Arch Linux ever ran on this machine, but I suppose I can't speak much to performance since pretty much anything should run very well on this beast.

Re:Why, oh why?

[Sri Ramkrishna]

You have every right to express it, but it won't change anything unless you happen to be a working on the kernel. You'll have to trust that they are doing the right thing.

Re:Why, oh why?

[sjames]

And you are just an Anonymous Coward.

Re: Why, oh why?

[Anonymous Coward]

You have a right to both, which you are excersizing in addition to your right to whiiiiiiine.

Re:Why, oh why?

[x_t0ken_407]

Amen to that. I was mildly irritated when I first saw systemd take over Fedora (I forget what release it was), so I moved to Arch Linux -- which I figured I could count on to be the Unix-like system I always loved and forever adhere to the K.I.S.S. philosophy...then they ALSO shoved systemd down our throats. Have been using FreeBSD on the desktop [where practical] ever since; it was already what I used on my servers.

Re: Why, oh why?

[sjames]

It seems you are the one doing the whiiiiiiiining. I simply expressed my opinion and moved on.

Re:Why, oh why?

[sjames]

So why all the sarcasm then?

Re:Why, oh why?

[Anonymous Coward]

No, Windows does not have PNG and JPEG decoding APIs that run in kernel space. That'd be totally daft. Not everything in ntdll.dll actually runs in kernel space.

Re: Why, oh why?

[armanox]

Honestly, I was happy with KDE 3 + compiz. And still am on some days (TDE is great!). I was not happy that I had to move my old work laptops (Dell C400 and D510, I needed the serial ports) back to Windows because they're no longer supported in Linux (and I was required to run 'supported and up to date' software and such by workplace requirements at the time).

Re:Why, oh why?

[Anonymous Coward]

Sure, doesn't change the fact that your opinion is basically meaningless.

Re:Why, oh why?

[serviscope_minor]

Why do those features need a kernel dbus?

Re:Why, oh why?

[bzipitidoo]

Tell me, was HAL the right thing? They seem to have changed their minds and abandoned it.

I've read the reasons for systemd. Faster boots, cleaner, more flexible, better at handling dependencies. Did I miss anything? Now, the reasons against systemd would seem to be that it adds dependencies, especially dependencies on systemd of other system tools such as dbus, it's more fragile, it certainly isn't as well tested, and it may not be so good at managing dependencies and being flexible as it proponents say it is.

Whatever else, systemd goes against the UNIX principle of having lots of small pieces that each do one simple thing and do it well.

Re:Why, oh why?

[moderators_are_w*nke]

I thought the idea for a kernel dbus came out of Nokia's Maemo team originally?

Re: Why, oh why?

[Sri Ramkrishna]

Most of those people are hired and paid by Red Hat to code what Red Hat envision.

What happens right now is the biggest and most agressive consolidations process since the existance of Linux.

systemd and jounald as coreOS that consolidates all we had known. Logging, inetd, sysvinit, timed, udevd, ipc etc.

Gnome3 for dumb people as main Desktop dealing a lot with systems. Kernel that now implemented kdbus to explicitly communicate to systemd.

Wayland to replace X11 to work close to Gnome3.

All a big consolidation!

linux (kdbus) -> systemd -> wayland / gnome3

What remains from what we know ? Nothing!

I am not against consolidation but I am against this sort of agressive behaviour!

In 2-3 years nothing remains that reminds of Linux to be Unix related. Even worse there are talks to have some sort of iPhone or Android like package mechanism to place apps with all deps (libs etc) in a sandbox within an apps directory. Even systemd already provides dealing with that.

What kind of OS is that?

What's wrong with a sandbox? For application developers it is now easier to target only one platform "Linux" regardless of distribution. Are you telling me you never ran into a problem when you ran across a tool or application and find out that the only packages available are for Ubuntu, and you had to go and compile the thing yourself? Then spend about 2 hours because it didn't quite work right. Come on...

Re:Why, oh why?

[Sri Ramkrishna]

Because, you're arguing in the wrong place. Join LKML and ask there. Declarative statements like yours will likely be met with some amount of sarcasm because nobody here answering you are involved in kernel development. Also, it's a personal weakness. The sarcasm that is.

Re:Why, oh why?

[Anonymous Coward]

Yeah, OpenBSD is decent for desktop use. I find that the ports system (3rd party applications -- ie. things like chrome/mozille/etc/etc) are really up to date and more stable than netbsd/freebsd (not trying to bash those BSD's but that's my experience). OpenBSD is probably not a bad starting choice to try out BSD world. It's easy to try it out too, the install can be done in On the other hand, the intended users had better be programmers. The OpenBSD community sometimes can seem downright hostile to newbies/non-programmers.

On the desktop, although I can do pretty much everything I need, I'll admit that there there are certain things that need more work to get going than you'd want (the typical example is flash or youtube or java). But on the other hand, these days with Chrome taking over the world with javascript, etc that's less of an issue.

(p.s. i love how all the anti-bsd moderators voted the comment about OpenBSD -1).

Re:Why, oh why?

[deconfliction]

KDbus ... A lot of this is driven by desktop projects, so things like smooth transition to a login screen ...

I'll bite- how does K/Dbus help with a smooth transition to a login screen?

Re: Why, oh why?

[jcdr]

Developers have no ideas of the real requirements and demands of systems engineers, administrators, network specialisty or users.

For proprietary code managed by dummies, maybe. But the Linux community developers count a lot of systems engineers, administrators, network specialists, and users that are code in the kernel precisely because there want to make it better at handling there real requirements and demands. You are free to do the same if you think that you can improve Linux for your need.

Re:Why, oh why?

[jcdr]

Yes, and also because he is not alone at wanting DBUS in the kernel.

Re:Why, oh why?

[sjames]

Someone COULD have offered a rationale for DBUS (or at least some benefit they believe it offers) or it's inclusion in the kernel. They might have even convinced me making wrangling with LKML unnecessary. Apparently, nobody on /. has one. It would be rude to just bust in on LKML without at least attempting to gain some background first, eh?

Re:Why, oh why?

[kenshin33]

gentoo, or something gentoo based, like sabayon?

Re:Why, oh why?

[Anonymous Coward]

Tell me, was HAL the right thing? They seem to have changed their minds and abandoned it.

It might have been right at the time. Nothing is ever right for all time. Either way, debating it here rather than on LKML is pretty meaningless since it's unlike Greg K-H will care about the opinion of random Slashtard.

Re: Why, oh why?

[Sri Ramkrishna]

I posted the rationale with some links

Re:Why, oh why?

[Anonymous Coward]

Doesn't Arch use xml for config files? (I've read about it but haven't checked) wtf is up with that?

Re:Why, oh why?

[broken_chaos]

KDBUS sounds okay to me. Apparently it, in a lot of people's views, boils down to "DBUS done right" -- the protocol is completely different under-the-hood, and will be (or is intended to be, if the userspace side people don't fuck it up like they constantly do to udev) supported in userspace by a translation layer for old-DBUS programs.

Further, the kernel devs have a habit (substantially creditable to Linus Torvalds) of doing a lot of things right, and making sure they don't break anything in the process, so I expect KDBUS will end up being stable and usable. Unlike, for example, udev which has made about a half-dozen hard backwards-compatibility breaking changes in the past year or so.

Re: Why, oh why?

[Rutulian]

What do you mean by supported, and why do you think your laptops weren't?

Re:Why, oh why?

[armanox]

I was referring to systemd becoming the defacto standard. No idea on kdbus.

Re: Why, oh why?

[sjames]

That was much more useful, thank you.

Re:Why, oh why?

[x_t0ken_407]

Having been familiar with FreeBSD (and running it both as a server and a desktop at times before), it just felt like the natural transition to make. I was pleasantly surprised to find that KDE4 finally reached the same usability as on Linux, and I haven't really looked back since. The ONLY issue is that I can't also run it on a laptop, unless I don't care about sleep/hibernated. For that reason, my E6400 still runs Arch.

Re: Why, oh why?

[armanox]

Why weren't my laptops supported? Intel i8xx graphics in Linux hasn't worked for years. And the vesa driver is not a substitute. What used to run perfect died with the introduction (and requirement) of KMS. The D510 sucked since AMD dropped support for 'legacy' graphics in Linux, and the radeon driver doesn't cut it (not really the fault of Linux or the Distro maintainers, just a fact).

Supported meant an operating system, either Windows, OS X, or Linux, that was actively receiving patches and updates for the purpose of this discussion. There was a reason (I can't recall right now) that I couldn't use RHEL 5.x on the C400, which should have worked.

Re: Why, oh why?

[Anonymous Coward]

The Gnome Crowd has abandoned everything in the past. Even Gnome got absndoned in favor of an abortion.

gnome-config got abandoned by bonobo-config which never really saw it's light because it got abandoned by gconf which got abandoned by dconf.

Get the point ? Half finished things being replaced by other half finished things being replaced by ...

Same with fspot vs the new one or rhythmbox vs banshee or evolution by geany or what its name was.

We still carry all that abandonware with us. Until today.

Thank you Gnome crowd. Thank you Eugene de Icatzza

Re:Why, oh why?

[fisted]

he's already a BSD user, so why would he want to switch to a Linux distro which tries hard to be BSDish (see e.g. portage, openrc) (and in fact is as close to a BSD as it gets in the Linux world)?

Re:Why, oh why?

[Anonymous Coward]

Because the newbies think its cool.

Everytime I see dbus, I think dbag.

Re:Why, oh why?

[Eythian]

That would make doing useful things with sound that much harder though. I like my per-application sound controls without having to screw around with config files.

Re: Why, oh why?

[celle]

"An OS ready for the radiant fascist/socialist future where the user has no control over the computer driven devices he supposedly owns."

1. Windows -- Obvious proprietary reasons.
2. OSX -- Dido(1)
2.5 Proprietary applications -- Self-evident.
3. Linux -- Because the Linux kernel has become so large and complex no one will be interested or can find anything out in that gigantic morass of code.
3.5 Open source applications -- Dido(3).(firefox, libreoffice)
4. BSDs -- potential dido(3).
5. Plan9 -- very distant dido(3).
6. Ios -- dido(1), android --dido(1)(3), WP --dido(1).

Re: Why, oh why?

[Rutulian]

Uhhhh....
http://www.ubuntuupdates.org/package/xorg-edgers/precise/main/base/xserver-xorg-video-intel

If you're telling me it doesn't work (don't have one to verify myself), fine, sounds like it needs a bug report. KMS has nothing to do with anything. Using an older AMD driver doesn't preclude you from using a new and updated distribution. Ubuntu has had "nvidia-legacy" packages for similar reasons for years. Not sure why you don't like the radeon driver, but https://launchpad.net/~makson96/+archive/fglrx. It says 13.10 and beyond will be more of a pain, but 12.04 is supported now and will be until 2017.

Re:Why, oh why?

[MikeBabcock]

This, precisely. I haven't seen a good rationale for it either -- nor have I seen one to justify the huge mess that is systemd.

Re:Why, oh why?

[Anonymous Coward]

Yep Linux is getting like XP (Whereas Windows is getting cleaner - stuff like Powershell is great).

Everything Lennart Poettering makes causes no end of unnecessary problems. (pulseaudio / avahi / systemd).

If Oracle lets us have sysv init we are moving from RHEL to that. (Regardless of how little I personally like Oracle and what they did to the good work Sun did).

Re:Why, oh why?

[Anonymous Coward]

Xmonad seems pretty close to perfect.

People hate the Windows 8.1 Metro UI but the rest of it is as good as it has ever been and better than Windows 7.

Powershell is getting better. Linux is getting more and more broken.

Re:Why, oh why?

[celle]

"I'll bite- how does K/Dbus help with a smooth transition to a login screen?"

      Absolutely nothing. The hardware is so fast the software could stop and take a leak during the transition and no human would notice due to short time of the incident. Like all the other changes in that linux dependent group(systemd, etc) all it really does is kill portability as applications that other systems currently use eventually use linux exclusively. Congratulations on becoming Microsoft. Linux seems in the same condition now as the US legal/ethically now vs US in the 80's. Steve Ballmer must be laughing his ass off.

Re:Why, oh why?

[Anonymous Coward]

Is OpenBSD really suitable for typical desktop uses? Does it perform well?

No. It's a pain in the ass to set up and to keep updated. Other than that, it mostly does the same things as your X.org setup under Linux.

Re:Why, oh why?

[Anonymous Coward]

It seems to be the Linux way these days. As soon as a subsystem starts becoming mature, usable, and stable, they just throw it out and start with something new all over again. Then you're forced to learn the new way of doing things, and experience all the bugs all over again because its all new code. Lather, rinse, repeat.

Re:Why, oh why?

[multi io]

I good reason is the future possibility to manage kernel features in a more formal way than with the /proc or /sys interfaces.

What's wrong with /proc and /sys for kernel and hardware configuration tasks? It's easy and twekable, you can poke around in it without writing a program first, and it conforms to "everything is a file".

It has taken about a decade to bring a standard IPC protocol to Linux. I mean a protocol that truly work between applications from different team of developers.It's now time to use it from a wider audience. Making it part of the kernel not only make it a bit more fast, but it clearly make it a more appealing choice for applications that need IPC.

IPC is between processes, not between a process and the kernel.

Re:Why, oh why?

[jones_supa]

And you are just an Anonymous Coward.

Come on, man. Greg Kroah-Hartman is like the main wingman of Linus Torvalds.

Re:Why, oh why?

[Anonymous Coward]

> like smooth transition to a login screen

kdm already gave me this. You should drop it from your bulleted list.

Re:Why, oh why?

[celle]

"I've read the reasons for systemd. "

You win a cookie.

"Faster boots"

Drop an SSD in the box. Problem non-existent.

"cleaner, more flexible, better at handling dependencies"

Is it? Seems to add more complexity to me. Newer, buggy, does not support legacy, isn't portable, potential lock in source. Large monolithic program with binary interfaces and inerds versus human readable output and structure of the old system. Wow it's got something there. My response isn't to parent but in agreement and against those that thought these large binary systems were a good idea for a KISS system.

Re:Why, oh why?

[sjames]

And if he were to post an actual explanation here, it would be worth a few bazillion times more than an AC not actually making an argument.

Re:Why, oh why?

[celle]

"I killed pulseaudio so that everything would use ALSA."

    The second biggest was when I dump both and went back to OSS. On Linux and FreeBSD.

Re:Why, oh why?

[jcdr]

The /proc interface is a mess from the format point of view: there is no standard; each file can use his own formatting.
The /sys interface is a bit better, but not everything is into it, and the "cross linked tree" structure can be difficult to handle.

You can see the kernel as a process. Or you can see the various kernel threads as processes. Don't be limited by a such pointless wording issue. There always was a big requirement for communication between parts of the kernel and some applications. The "everything is a file" was a really good design decision that proved to be adequate in a lot of situations. But there is more and more others situations that need features that the "everything is a file" design can't provides efficiently. IPC is one of them.

Just look at the numbers of IPC that exists and there evolution to realize that a simple file is clearly not an appropriate solution. Now try to count how many formats are used for communication with the Linux kernel. There is certainly an advantage to reduce the number of them if a common protocol can handle them in a good way.

Re: Why, oh why?

[Sri Ramkrishna]

Sure, glad I could help. :)

Re:Why, oh why?

[Sique]

"Faster boots"

Drop an SSD in the box. Problem non-existent.

Spoken like one who never has seen more than his desktop PC.

There are systems which don't have any HD that can be sped up by replacing it with an SSD. Flash based appliances come to mind. They surely can make use of faster boot times. There are systems whose storage is on a multi terabyte NAS, which can't be replaced by an SSD (or do you volunteer to foot the bill?). There are systems which are just virtual machines, and whose HDs are wherever the virtual filesystems are placed. I am working with systems, which run several servers as separate virtual machines in QEMU because of real time issues, and being able to short the time for a restart of those machines really helps.

You are not the navel of the universe, and if you can speed up boot times just by replacing your HD with an SSD, it's fine. But it's only relevant for you. It's not a solution for anyone else.

Re:Why, oh why?

[Sri Ramkrishna]

I think Steve has other things to worry about. Anyways, Linux is evolving away from typical Unix mentality. We'll see how things come along.

Re:Why, oh why?

[Sri Ramkrishna]

So you are jumping ship to Windows then?

Re:Why, oh why?

[Sri Ramkrishna]

Actually XP was a significant improvement over NT considering how many million LOC that was changed. Everybody expected it to fall over. But it didn't.

Re:Why, oh why?

[Sri Ramkrishna]

Or maybe, LInux is being used in ways that it was not intended (eg embedded devices) and it requires capabilities since it's being shipped in products. Linux is not just some sysadmin tool now. It's everywhere now, in your bluray,, stereo, phones, cars, and all of them require changes. Do you really want your stereo to take a long time to boot up when we could use a parallelizing boot start up that will make the customer experience better?

Re:Why, oh why?

[epyT-R]

Hm ok. That's why I chose linux for desktop use, as it's the focus of most of the OSS desktop projects.

Re:Why, oh why?

[epyT-R]

My only experience with freebsd was an ancient version 2.2.6, which I ran before switching to linux (I think to run a quake server). Obviously things have changed a lot since then. It ran well from what I remember, but it had very limited support for linux binaries as I couldn't get it to run the server, even with compat-linux installed.

Re:Why, oh why?

[dpilot]

Gentoo is currently pushing over to systemd. About a month ago they set stable keywords for gnome-3.8 and systemd, so that pretty much everyone who uses any gnome software, not just the gnome desktop, got pushed to systemd as well.

There is not any official word, but that was what happened. It's still possible to run an OpenRC system, but it takes a fair amount of work. The forums still have systemd migration problems, a month later.

There was an item on the Gentoo Bugzilla for upstart, but that was recently reclassified as "won't work on", with the reasoning, "because now we have systemd."

There's still Slackware. I haven't moved yet, but I'm thinking...

Re: Why, oh why?

[epyT-R]

At least 3 and 3.5 offer you the source at all.This ensures that if/when things get bad enough, it will be forked.. However, if the OS is locked down, it won't matter what userland is open as it will be impossible to run self-compiled binaries without expensive licenses or unreliable software vulnerabilities.

Re:Why, oh why?

[kenshin33]

Well, he did say "switched to arch from fedora", Linux user was a fair assumption, hence gentoo (which if I remember correctly can run a *BSD kernel).
As to why would he wants to? I don't know (and I don't care). It was a simple suggestion.

Re:Why, oh why?

[kenshin33]

to each his own :). Isaid gentoo b/c, I use it (I don't even remember since when), still no systemd forced down my throat (KDE4 seems to not depend heavily on it, and frankly don't care for the desktop env, the only utility it has -for me- is keeping multiple windows open on the same screen, -heavy terminal user-)

Re:Why, oh why?

[kenshin33]

I didn't know, I removed everything gnome 2 years ago. I switched full time to kde (always had both installed). If and when kde will require that too, I'll switch to something else (enlightenment may be, since it was my 1st choice years ago).

Re:Why, oh why?

[Anonymous Coward]

This trend of "let's make a new system to replace the old mechanism and put it in kernel/make it convoluted and difficult to fix without a reboot" disturbs me.

dbus, I can kind of understand, being a part of a distro. It's important for many GUI desktops, and It's been a decade or more in the making. Also, IPC is kind of nice from an integrated environment point of view.

However, it's got a number of serious drawbacks:
* it's not commonly understood
* it's not well documented, from an administrative perspective
* when behaving problematically, has negative performance/stability impact on more than one thing
* when implemented in kernel, its stability is paramount to the whole of the system. This is part of the reason why NFS has remained fairly static for decades - it's in-kernel and a lot of things depend on it's reliable functionality. What happens when you'e got a deadlocking thread waiting for kdbus?
DBUS performance improvements are

WHen you consider that almost eerything in a modern distro is managed/controlled through dbus and systemd (or upstart) these days... how competent is the average admin? I don't know either of these systems well, but I'm better than most - and I'd still consider myself fairly lost due to the complexity.

Re:Why, oh why?

[Anonymous Coward]

Well, the biggest audio performance boost I had was when I killed ALSA and switched to Pulseaudio...

Re:Why, oh why?

[sjames]

You must really hate audio. That or you're deaf.

Re:Why, oh why?

[Anonymous Coward]

Whatever else, systemd goes against the UNIX principle of having lots of small pieces that each do one simple thing and do it well.

And the big trouble is that there is no convincing Lennart Poettering that this is a bad thing. I am *extremely* distrustful of him.

If nothing else, I see putting D-Bus into the kernel as a way to wrest a bit of the functionality he assimilated away from him. It is getting harder and harder to build a systemd-free system. This move by the kernel developers would seem to make the world a bit more safe.

Re:Why, oh why?

[Anonymous Coward]

Unlike, for example, udev which has made about a half-dozen hard backwards-compatibility breaking changes in the past year or so.

Ah, this wouldn't be any of the idiotic stuff that Kai Sievers is doing at the behest of LP? *Predictable* network interface names? They very language they use is Orwellian. The whole udev business has been nightmarish.

Re:Why, oh why?

[ArsonSmith]

http://xkcd.com/927/

Re:Why, oh why?

[Anonymous Coward]

Started using FreeBSD after using OpenSUSE for a few years.

I'll take OpenSUSE any day, felt like I stepped back into the 1990s.

Re: Why, oh why?

[armanox]

It doesn't work for most of the i8xx chips, and this is a well known flaw. Marked as won't fix since they've the chips is too old to care about. It broke when they changed the driver to support KMS.

FGLRX doesn't have a legacy driver that works with newer kernels. Radeon works well for a lot of things, but simply doesn't (or didn't when I cared) work as well (I think it may have been power management? Did they ever fix that? I remember the last time I used it (more recent card, HD 5770 and then on HD 7750) power management simply was non existent and the fans ran at 100%). Regardless, I don't still work at that position, and have to use Windows on the issued laptop (which has FirePro graphics...more AMD joy).

Re: Why, oh why?

[armanox]

Sandboxing isn't a bad thing. A lot of commercial software for Linux does this (I think that's what we install to /opt for....) to insure that the needed libraries are present - it's also what allows them to run correctly on newer Linux installs. But, people forget that, and then complain when $application doesn't run after the system has been updated.

Re:Why, oh why?

[armanox]

GNOME 3 and KDE 4 have been interesting journeys. And like most software, it was not very good in the early phase. GNOME 3 is getting better, just not my preferred cup of tea. KDE 4 is getting a little crazy and starting to taste like the lemon in the tea is sour.

I too would like to know what's been abandoned. GTK 2.x can be installed along 3.x without any conflict (in my experience). As far as moving to Qt, I know the LXDE project decided to move to Qt and merge with RazorQt, but beyond that I have no idea.

And Sri, since you are involved with the GNOME project, I want to take a minute and thank you for responding to (and putting up with) the comments and remarks from us. I don't reject everything you guys do, but I'm not the biggest fan either. With that said, I am not doing development work, but do understand what goes into it (have done dev work in the past when I was a contractor). I do hope to see my doubts proven wrong about the future of Linux in general. Until then, I'll keep vocal.

Re:Why, oh why?

[Anonymous Coward]

What we need is multicast unix sockets. We have stream and packet unix sockets, but to implement dbus or many other things efficiently (without a userland process to simply copy/splice packets N times) we need a unix socket implementation that delivers packets or streams to all processes that have the socket open for reading.

This is conceptually simple, in line with unix methodology, means the message bus can simply be part of the filesystem, rather than a weird oddity, and isn't big or complex to implement.

Of course, it does raise semantic questions: what happens when a reader doesn't clear it's read buffer, do we block writers, or do we reclaim the buffer, and in the reclaiming case, do we discard early or late packets. In the stream case it is particularly problematic, perhaps deliver an IO error to the process and let it decide how it wants to proceed. In counter argument, these problems all exist with existing multicast/broadcast socket APIs like UDP, so the solution is probably already available.

-puddingpimp

Re:Why, oh why?

[Anonymous Coward]

Greg KH is the biggest douchebag loser on the planet. Nobody knows less about unix design principles than Greg KH.

Re:Why, oh why?

[kernelpanicked]

I'm just gonna leave this here.

https://plus.google.com/111049168280159033135/posts/4KJxFY8VvT1

Re: Why, oh why?

[Anonymous Coward]

No, their sandbox approach is different.

They plan to have the program including all libraries and ressources be delivered as a package.

This program get installed in say /Application with all libs and its further ressources.

This idea is mot new because Apple has a similar approach. But at the end I don't belive that this increases security. After all it's a security issue.

Imagine you have 20 Apps installed. A mixture of Gtk1, Gtk2, Fltk, Qt3, Qt4 etc. Some drliver threir own libpng version, other Apps may deliver something different.

On a normal system as we know. As soon as a library is known to have problems, we can rely on the distro to deliver a fix as rpm or deb anytime soon. The issue is no more for all of your Apps.

But with the sandboxing thing chances are big, that your Software may or may not receive necessary updates. Since you don't really know what kind of libs your sandboxed App really uses, you may end up keeping the security hole forever.

Again Gnome enters a NIH path here.

Re:Why, oh why?

[Barsteward]

why don't you use "http://www.linuxfromscratch.org/"

Re:Why, oh why?

[Barsteward]

You could also post an explanation for your stance

Re:Why, oh why?

[serviscope_minor]

I think you may have replied to the wrong post. None of your points answer the question which is why these things can't be done in userland.

Re:Why, oh why?

[Barsteward]

Can you post a rationale as to why not? I'm interested to find out why you think it should not be included. Until then it sort of sounds like "we didn;t need it in Linux 1.0, why do we need it now".

Re:Why, oh why?

[sjames]

My stance is what does it do that a unix socket and/or netlink can't do for me now?

Throw in a dash of XKCD 927

Re:Why, oh why?

[Barsteward]

You could say the same for watches, cars, planes etc. things move on and usually forward. These sort of criticisms through lots of these postings say more about the posters being stuck in his/her comfort zone and getting older.

I don;t think i've read a reasonable post saying why its a good or bad idea, just a load of opinions that aren't backed up.

Re:Why, oh why?

[Barsteward]

http://www.linuxfromscratch.org/ will make you happy

Re:Why, oh why?

[sjames]

The principle of parsimony as applied to software. The Linux kernel has always been served well by the principle of keeping things in userspace when they can be in userspace. The kernel is not a place where you want to expand the attack surface unless there is a very compelling reason to do so.

Given that, it really is more a question of "what can DBUS do for me" and "Why does it need to live in the kernel to do that".

In the case of the many services the Linux kernel includes that something like Minix doesn't, the reason was performance and stability. Those proved to be good reasons. Even there, Linux eventually grew support for Filesystems in USErspace. Yes, FUSE does sometimes remind us of the stability argument for filesystems in the kernel.

Re:Why, oh why?

[Barsteward]

KDBUS only works within the local machine whereas the other systems talk to other machines. So maybe it makes sense not to mix the messaging, Andriod may also take it on board and drop their specific system

Re:Why, oh why?

[dpilot]

By the way, it took me about a week to work up the proper package.mask file, but I'm running OK without systemd now.

What's annoying is that I kind of like what systemd is doing, I just really dislike the way it's packaged, and the way they're forcing it down everyone's throats.

Re: Why, oh why?

[Anonymous Coward]

LXDE moved to Qt
Unity moved to Qt
OpenShot moved to Qt
Wireshark moved to Qt
Subsurface moved to Qt

Last one is a project from Linus Torvalds. This might give a hint to his desktop preference.

About Gtk2 sure you can install Gtk2 programs nicely aside of Gtk3 but that's not the point. The point is, that only a small number of programs got ported from Gtk2 to Gtk3 so far. That's because their developers either switched from Gtk to Qt entirely or abandoned the program and switched to another system (The guys behind planner for example).

Re:Why, oh why?

[jcdr]

Exactly. A new standard is not the solution.
Putting DBUS in the kernel has the merit of making an existing good and long established standard available to a wider range of communication demand.

Re: Why, oh why?

[Anonymous Coward]

That's "ditto", not "Dido" -- Dido (pr. "die-dough") was the founder and first Queen of Carthage, loved by Aeneas in Virgil's "Aeneid", whereas "ditto" is the (Tuscan dialect) Italian word meaning "said", or "as said above".

Re: Why, oh why?

[Anonymous Coward]

Proof? I find that most of the Linux community of developers are college kids with time on their hands and are not based on any real requirements. Case in point is KDBUS, it's not required by system engineers, administrators or network specialists. Instead it is required to help transitions within desktop environments.

Re:Why, oh why?

[Anonymous Coward]

The Linux kernel is bloated because of its monolithic design, not by the number of drivers that can be optionally compiled into the kernel.

Re:Why, oh why?

[Anonymous Coward]

PulseAudio is the best Linux audio subsystem, it just took 2 years after Poettering left the project to make it usable. Similarly I consider the initial stated goals of systemd to be good, on the other hand the current goals of "let's make everyone use GNOME" and "let's fuck up the kernel, too" is not to my liking, and recalling how it went with PA it's probalby safe to conclude that Poettering sucks a lot when it comes to implementing stuff.
And avahi sort of works, too, except the bits that don't and the general uselessness of it and the days when it doesn't feel like working.

Re: Why, oh why?

[jcdr]

Sorry but your "finding" really don't match with the reality: http://lwn.net/Articles/551969/

Re:Why, oh why?

[Anonymous Coward]

> +Lennart Poettering 's post on systemd/kdbus and what not has caused some
> consternation with the slashdot community. Apparently, they are quite angry
> that we are adding a message bus to the kernel. They have all weighed in and
> determined that a message bus is not necessary, cuz you know they are all
> experts.

No of course only your likes are the true experts there are. Everyone else is plain stupid.

> +Lennart Poettering they are sysadmins who hate that their little world is all broken.
> I must admit I think I'm enjoying trolling a little too much there.

So why do you spent your time on /. then if we can't take anything from your "advocating" any serious ?

> Haha, yeah seriously. It's why I like to hang out there. Also, the admins hate GNOME,
> and never posts anything unless it is controversial. They used the GNOME 1 logo for 12
> years despite repeated attempts asking them to change it. I think they finally changed it
> when GNOME 3 came out.

For someone rambling the hell out of /. you seem to feel quite comfortable here.

> wow, people are threatening to ditch Linux for Windows + Powershell. One guy claims the
> U.S. DOE will start moving away from Linux. It's like the same argument people use for
> GNOME 3 applied to Linux distros. Nice.

Take care, we watch you closer than you might imagine!

Re:Why, oh why?

[Anonymous Coward]

Missing the reference:
https://plus.google.com/115250422803614415116/posts/A7hV12Zo4g8

Re:Why, oh why?

[Anonymous Coward]

JACK doesn't skip back and forth between jackd and clients all the time. Every time a connection is changed the clients are sorted topologically, and then they are activated in that topological order by writing to and waiting on pipes. This works very well because every client is expected to do some processing during every cycle. In D-Bus, on the other hand, every RPC call over the bus requires that you first switch to the D-Bus daemon which dispatches the call to the right client and then switch to that client. By moving the bus to the kernel you can get away with half the number of context switches.

Re: Why, oh why?

[Anonymous Coward]

Linking to an article that only describes KDBUS does not serve as proof of developers being mostly trained engineers nor does it serve as a compelling justification for KDBUS. It just demonstrates that you are capable of making a link.

Re:Why, oh why?

[jcdr]

Take a look at the reality:

linux$ for i in $(find ./ -mindepth 1 -maxdepth 1 -type d); do r=$(find ./$i -type f -iname "*.c" -print0 | wc -c --files0-from=- | tail -1 | cu)); printf "%16d\t%s\n" $r $i; done | sort -rn
              176570632 ./drivers
                39285154 ./arch
                25360678 ./fs
                16726520 ./sound
                16270981 ./net
                  4178246 ./kernel
                  2149028 ./mm
                  1321702 ./security
                  1196376 ./crypto
                  1138780 ./tools
                  1061679 ./lib
                    789517 ./scripts
                    518658 ./block
                    224637 ./Documentation
                    185020 ./ipc
                    132264 ./virt
                      73918 ./init
                      42353 ./samples
                      12747 ./usr
                        6731 ./firmware
                              0 ./.tmp_versions
                              0 ./include
                              0 ./.git

The fact that modules are optional make the Linux kernel no so monolithic. It also use a lot of kernel threads that can be more or less see as services in a microkernel architecture. You can argue that is't not as fun as a microkernel, but if you want to do with microkernel services all what Linux do, you will probably end up with the same order of code quantity.

Re:Why, oh why?

[Bill_the_Engineer]

During the Automotive Linux Summit Greg Kroah-Hartman talked about the progress of kdbus.

He did a really poor job justifying the need for kdbus since he talked about QNX type messaging on Linux and how that was already provided by the SIMPL API in which Greg said "works well". Within that same article it is mentioned that the speed increase to D-BUS could be accomplished without moving it to the kernel. He did say that being in the kernel allowed for the order of messages to be guaranteed but it's debatable if message ordering is justification enough.

I don't really see this as something to get too upset about. Like most experimental things within the kernel, you can simply choose to recompile the kernel without kdbus. If Red Hat can live with the additional overhead within kernel space (even with the use of bloom filters to help with message classification and delivery) and support it then it probably won't make much of a negative impact. Red Hat is Gnome based and their architectural decisions are biased towards it anyways.

Re:Why, oh why?

[sjames]

Neither unix sockets nor netlink talk to other machines.

Re: Why, oh why?

[Sri Ramkrishna]

NIH indicates there was a solution before in the desktop/kernel space that met their needs. Even if you have a security hole, the whole point is that it is sandboxed. This puts the onus on the application writer to fix the problem not the distro. The distro is not a scalable solution.

Re:Why, oh why?

[x_t0ken_407]

To qualify this, I had been an avid Arch user since about '09-'10. Loved it's minimalism and the rc.conf file. Loved how (similar to FreeBSD) I only installed what I needed, and all apps were the vanilla upstream version.

One day, I found myself in need of a quick install to my gaming PC which had been running W7 exclusively -- i.e., get it into a condition where they could do the basics (web, email, etc.). I had the latest (at the time) Fedora iso and figured I'd just get that installed really quick so that the user could be back up ASAP (I normally recommend Mandriva/Mageia to newcomers). Upon attempting to complete some menial task, I realized that the entire underlying system had changed. I couldn't 'chkconfig -- list' , I couldn't 'service [svc] restart'. I got pissed. I then recalled why I stopped using Fedora in the first play a couple years previously: shit changes too damn much. I found myself trying to quickly learn systemd to get this system operable for the moment, but then as soon as I had the time, I reinstalled with Arch which I figured would ALWAYS hold themselves to the higher (IMHO) standard and the KISS/Unix philosophy. Not 2 months after the above adventure, I learned about the Arch dev's planned init obselecense in favor of systemd. There were HUGE arguments on the mailing lists because of the decision, and -- while I'm very open-minded and would be willing to try new things given (a) adequate reasoning behind the decision for the new "thing" and (b) I'm grateful for the time/effort put in by the devs -- I was VERY put off by the Arch devs stance of "this is what it is, no discussion, if you don't like it then fuck off". When they began censoring dissenting opinions, I knew it was time to "vote" with my feet and go to a system that fits my needs -- sadly, Arch no longer fit that.

And I'm by no means a zealot and though I advocate Linux and *BSD, I'm of the opinion that people should use what works best for them, be that Windows, Ubuntu, OSX or anything else (3 of my personally most-hated OS's). Though I'll suggest that Linux can do anything those can and more, I'll never try to convince someone that they should use X operating system just because everyone is different and has specific things they like in a system, and it'll almost assuredly be different than what I like.

Gentoo does in fact seem like something I'd like to work with and I've had the desire to retry an install (my only attempt was way back when I was still a newcomer to linux...needless to say I was overwhelmed), and I had a co-worker who advocated and swore by it. I've always found it to be a Linux for BSD users, haha -- if I'm not mistaken, a lot of it's philosophy was based on FreeBSD, yes?

Re:Why, oh why?

[x_t0ken_407]

My understanding is that KDE will not ever require systemd (I forget where, but I saw a discussion on this by the devs). I think their stance was that they'll always strive to be cross-platform.

Re:Why, oh why?

[x_t0ken_407]

How up-to-date are the apps? Comparable to FreeBSD? I always thought about giving another *BSD a shot, but FreeBSD has always been rock-solid for me.

Re:Why, oh why?

[cerberusss]

IPC is between processes, not between a process and the kernel.

What a weird thing to say. Kernel support has been present since the early (SysV) days of IPC. Do you think that was wrong?

Re:Why, oh why?

[dpilot]

http://lists.freedesktop.org/archives/systemd-devel/2012-August/006066.html

"Yes, udev on non-systemd systems is in our eyes a dead end, in case you haven't noticed it yet. I am looking forward to the day when we can drop that support entirely."

Is it possible to be udev-free with current kernels? Gentoo did fork eudev a while back, but at the moment it appears that Gentoo is solidly into the systemd camp, so I don't know what the fate of eudev will be. Static /dev was a pain, too.

Re:Why, oh why?

[Anonymous Coward]

maybe this "Anonymous Coward" is g-k-h himself ??

Re:Why, oh why?

[sjames]

He would still be arguing from authority unless he gave an actual justification for his view.

Re:Why, oh why?

[cupantae]

The explanation linked by the ArchWiki article on systemd is very good:
Read this forum post.

As an Arch user, I hated systemd at first, for much the same reasons as already stated: the confusing and opaque nature of debugging. I'm now a convert, and I have been ever since I worked out how to do everything I used to be able to do. I now believe people's resistance is just growing pains. Give it a shot; it's easy and good.

Re:Why, oh why?

[x_t0ken_407]

I still use Arch on my laptop, so I've given it a shot. Even so, I still prefer the old rc.conf configuration and plaintext log files to systemd.

Re:Why, oh why?

[multi io]

The /proc interface is a mess from the format point of view: there is no standard; each file can use his own formatting.

That doesn't matter much in this case; the /proc filesystem is very hardware-dependent and highly system-specific anyway, and the files are mostly read-only. There's generally exactly one program or library/API that reads a particular /proc file, and that program/API is how everything else in the system gets that piece of information; this is not like generic "configuration files" in userspace which would potentially be read AND WRITTEN by dozens of processes.

Re:Why, oh why?

[multi io]

IPC is between processes, not between a process and the kernel.

What a weird thing to say. Kernel support has been present since the early (SysV) days of IPC. Do you think that was wrong?

The kernel provides the IPC mechanisms, but they're mostly used for communication between (userspace) processes, not between processes and the kernel.

Re:Why, oh why?

[jcdr]

Sorry but I strongly disagree with you point of view.

A lot of networks settings for example are still into /proc/net. There are not hardware dependent and a lot of them can be acceded in write mode. A lot of different programs or library use them, especially if you build routers like I have do in a early workplace. Just look at how many API and codes exists to simply do a DNS query...

The /proc interface will stay almost forever because it is too deeply part of the UNIX history, but it really a mess after decades of erratic evolution, especially in the Linux kernel that initially put almost anything into it before trying others ways.

But?!

[Billly Gates]

Then I would end up with a copy of Fedora??

More Bloat ?

[fluffy99]

Why is this NOT another example of kernel bloat, and the opposite direcion they should be heading (ie getting user stuff out of the kernel)? Seems like the primary use of D-BUS is for the desktop components, which already abuse/overuse inter-process communication. The "huge performance improvement" is only for those processes that shouldn't be abusing this anyway.

Re:More Bloat ?

[Anonymous Coward]

Seems like the primary use of D-BUS is for the desktop components,

Desktop Bus - I think there's a clue in the name.

which already abuse/overuse inter-process communication.

It's wasted on my desktop, I use the shell as a filemanager and login to a mail server over ssh to get my email. Seems dbus, ssh_agent and other bullshit should always be optional even on the desktop.

The "huge performance improvement" is only for those processes that shouldn't be abusing this anyway.

In typical "because fuck you!" style; Systemd relies on dbus for ipc and on ipc for halt, reboot etc. Can someone please step up and write a sane rc.d based init system so we can consign Systemd to the trashcan of history.

Re:More Bloat ?

[bheading]

Agreed. And look who's behind it - Poettering. Run for your lives!

Re: More Bloat ?

[Anonymous Coward]

I don't like the behaviour and social limitations of Poettering.

Go to youtube and search for 'datenwolf'. You see how insulting Poettering hijacked the speach of that poor guy.

Later on he came up totally drunk, keeping a bottle of alcoholics in his hand and pissing off the audience.

Sorry! I don't want software written by said person. Even if it would start solving starving in the world.

Re:More Bloat ?

[SumDog]

I like Gentoo's OpenRC. Much better than SystemD.

Re:More Bloat ?

[Anonymous Coward]

Switch to a lower runlevel and back, and see how not so great open-rc is.

Re:More Bloat ?

[profplump]

"sane" and "rc.d" are mutually exclusive requirements. Maybe systemd is not the answer, but we know from decades of experience how bad rc.d is.

Re: More Bloat ?

[Anonymous Coward]

You would have saved a lot of these 'decades' if you had spent '1 hour' reading the docs, man, howtos properly. Halfknowledge is usually the real PENCAK here.

Re:More Bloat ?

[sjames]

I find ssh_agent very useful. That's why I stuck it in my .bashrc like a sane person. There's no need for a bunch of unremovable crap when a couple lines in a script can take care of it for people who want it.

Re:More Bloat ?

[fnj]

Can someone please step up and write a sane rc.d based init system so we can consign Systemd to the trashcan of history.

Seriously? BSD has had such a system forever. Linux used to have a "sane" init scripts system (admittedly for some subjective definition of "sane") until very recently. Debian's system used clean Bourne shell compatible scripts. This meant /bin/sh could be a symlink to /bin/dash. Dash is a very lightweight shell without all the Bash overhead. It is about 1/10 the size of Bash. Bash is an excellent interactive shell, and a very valuable scripting shell, but Dash is excellent to have where you don't need a vast profusion of features but you are interested in performance.

Here we learn that most of the performance benefit seen in Ubuntu 6.10 was due, not to Upstart, but simply by switching from Bash to Dash in the init scripts.

Redhat decided it was "too hard" to make their init scripts Bourne shell clean. They all reference /bin/sh in the shebang line, but they lie. They rely on Bash features. As a result, rather than do what Debian showed could readily be done, Redhat established and has adopted Systemd as the Only Supported Init System.

Now that Debian is caving in to systemd, it seems safe to say we can forget the fantasy of Systemd being relegated to any kind of "trashcan". Quite the contrary, as far as linux is concerned, it is the init script system that will be trashcanned.

There are honest pros and cons for the move. The pros are pretty compelling (and I say that as a holdout from the beginning). Linux is in many ways about monolithic solutions. This is just one of those ways.

For those who have doubts, not just about Systemd but about other monolithic consolidations and discarding many time tested and good working systems, there is still a refuge: BSD. That may change, but for now BSD is not jumping on all this stuff (quoting the AC near the top: Wayland, Gnome3, Pulseaudio, Systemd, Journald, "Alienating [subsuming] Udev"). BSD is still all about the Unix Philosophy, as expressed by Mike Gancarz.

It is really an embarrassment of riches that BOTH Linux and BSD are prospering as freely available systems.

Re: More Bloat ?

[Sri Ramkrishna]

You should see what happens when Linus is in your talk. Same damn thing, albeit without the drinking. The guy was all over X guys over some stuff he had a pet peeve about.

Re:More Bloat ?

[Anonymous Coward]

There are honest pros and cons for the move. The pros are pretty compelling (and I say that as a holdout from the beginning).

It's not that I don't see any of the pros. Systemd transcends any pros with the shocking attitude of it's developers, poor design and ever-expanding scope.

For those who have doubts, not just about Systemd but about other monolithic consolidations and discarding many time tested and good working systems, there is still a refuge: BSD.

Unless you're stuck with linux for other reasons... eg: hardware support. I'd switch to FBSD if I could, more likely I'll end up running slackware or gentoo.

Re:More Bloat ?

[jcdr]

Seems like the primary use of D-BUS is for the desktop components, which already abuse/overuse inter-process communication.

DBUS is already used on a number of embedded projects since many years.

Re:More Bloat ?

[jcdr]

Good luck if you try for example to use Bluetooth or Avahi without D-BUS...

Re:More Bloat ?

[Anonymous Coward]

Good luck if you try for example to use Bluetooth or Avahi without D-BUS...

Bluetooth is disabled on every device I own and I do not personally own a printer or a scanner.

Re: More Bloat ?

[Anonymous Coward]

It was not 'my' talk. It was the talk of a guy called datenwolf. I stepped over that video because I was pointed towards it by someone else. About Linus Torvalds. You truly don't want to compare Torvalds with Poettering do you ? The one brought us Linux and the other crap! And yes being drunk vs. not being drunk gives a different perspective towards the situation. Don't forget! It's people, users and admins like us who made Linux mainstream by using the word! We can quickly change that!

Re:More Bloat ?

[salahx]

hHe short version: http://lwn.net/Articles/551969/

At first, this sounds like the kernel developers have raided LP's "private stash", but it turns out the reason for kdbus is preceeds it - in fact in even preceeds d-bus itself. Specifcally, kdbus is intended to be a alternative version of Android's binder. Android doesn't use d-bus, because it didn't exist (or was too immature) back when it was concieved. While binder is in the staging tree, it'll never be part of the kernel proper for various - some fixable, other unfixable. Binder is not just a hard pill to swallow for the kernel developer, its a spiked ball the size of a fist in a bottle labelled "NOT TO BE TAKEN ORALLY".

There's a NEED for something like kdbus independt of systemd. We needs a new IPC type, like domain sockets, except with reliable multicast and filtering. Linux domain sockets do not support multicast, much elss reliable multicast. Approaches to add this have been tried: Both by directly adding multicast to domain sockets or by adding an ew address family (AF_DBUS), but patches adding that to unix domain sockets have been rejected, as has AF_DBUS.

No one suggesting putting the entire dbus-daemonm and protocol in the kernel with kernel XML parser (and so dbus-daemon will still be needed for authentication and the inital connection setup, but then steps out of the way after that), kdbus is "just enough" to implement an accelerated and robust message bus.

Re: More Bloat ?

[Sri Ramkrishna]

I am just saying that this behavior is not surprising in FOSS

Re:More Bloat ?

[Anonymous Coward]

Greg K-H is more involved than Lennart.

Re:More Bloat ?

[celle]

"There's a NEED for something like kdbus independt of systemd. We needs a new IPC type, like domain sockets, except with reliable multicast and filtering. Linux domain sockets do not support multicast, much elss reliable multicast. Approaches to add this have been tried: Both by directly adding multicast to domain sockets or by adding an ew address family (AF_DBUS), but patches adding that to unix domain sockets have been rejected, as has AF_DBUS."

        Contaminating Unix wide standards with Linux specific shit isn't a good idea, especially for the rest that don't want it and have no use for it. See the GCC and the Linux specific junk in the C/C++ standards. Nothing but headaches.

Re:More Bloat ?

[drinkypoo]

Contaminating Unix wide standards with Linux specific shit isn't a good idea, especially for the rest that don't want it and have no use for it.

You propose that Linux avoid progress. Your proposal has been rejected. Eventually, all the proprietary Unixes alive today will die and there will be only Linux, *BSD, and perhaps any other Unixlikes which will be invented between now and then and which don't suck.

Re:More Bloat ?

[Anonymous Coward]

That's surely because it has so much feature that almost no one defend it in the current debian debate.

Re:More Bloat ?

[Anonymous Coward]

Dash is horrible.

The idea is great, but it isn't 100% compatible with bash and can cause random and hard to fathom errors in scripts which otherwise work fine elsewhere.

In fact, things like Dash make the Linux landscape even more fragmented and make it yet harder to write and properly deploy applications across the various distributions.

Re:More Bloat ?

[loonycyborg]

Yes. Many complain about 'shocking attitude' of systemd developers. I tried to test it by checking original statements and didn't find anything shocking. They're about as professional as any other project's developers. So this is yet another lie it seems.. I wish there was less pointless trolling and more productive work.

Re: More Bloat ?

[Anonymous Coward]

http://www.youtube.com/watch?v=ZTdUmlGxVo0

I'm glad to help you out!

Re:More Bloat ?

[ald_a]

Indeed. No one in the unix world should care about a fast boot (why do you need to reboot your machine in the first place). I guess Redhat guys (especially Lennart), has lots of spare time in his hands and manages to bloat on the least problematic part of a distribution. Did any of you guys had problems with systemv?
Why tie Gnome, dbus etc to systemd? You can't nowadays install Gnome without systemd. I find this approach a shameful thing in the Linux history.

Just my 2 cents.

Re:More Bloat ?

[Anonymous Coward]

Granted this AC does not know much about Android history at Google but D-Bus has been around for years and it is basically toolkit agnostic version of KDE's DCOP which goes back to a time when google was not a verb, so it is exceptionally unlikely that Android could be older than D-Bus.

Re:More Bloat ?

[Anonymous Coward]

Now that Debian is caving in to systemd, it seems safe to say we can forget the fantasy of Systemd being relegated to any kind of "trashcan". Quite the contrary, as far as linux is concerned, it is the init script system that will be trashcanned.

Forcing users to trash System V init can be perceived as a betrayal by those who rely on it. I'm not sure it's worth losing server installations in the name of an unconfirmed gain of speed on some laptops in some specific circumstances.

Re:More Bloat ?

[fnj]

AC is an ignorant child, but it's worth pointing out the truth of it for other readers.

Dash is Posix 1003.2 compliant. It minimally extends the Bourne shell, the brilliant honorary patriarch of all shells. Regarding it as contributing to fragmentation amounts to clinical insanity, or pure ignorance. On the other hand you could make a case that Bash does so contribute with all its extensions achieved through much bloat, but I DON'T make that case.

If you cannot write an at least Posix clean shell script, if not Bourne shell clean, you are worthless as anything more than a pushbutton admin.

The one criticism of Bash that I do have is that you cannot optionally set it to flag all extension use as a warning or error. As a result we have a world full of scripts with a shebang line of /bin/sh, which cannot run properly unless /bin/sh is a symlink to Bash. The least service a script writer can do to the user is either (1) make the shebang line /usr/bin/env bash, or (2) with the shebang line /bin/sh, make sure and test that the script is Posix clean.

So this is the thing killing portability

[Improv]

The corruption of GNOME and other opensource projects by tying it specifically to Linux comes with this; it represents giving up on being cross-platform, giving up on the BSDs and other Unices, and giving up on openness. No thanks.

Re:So this is the thing killing portability

[Anonymous Coward]

Openness means targeting multiple platforms and not that the code is visible?

Re:So this is the thing killing portability

[AceJohnny]

Portability also means giving up on system-specific optimizations and features. Some people have decided that Linux's market share means it's time to bank on those optimizations. Why not?

Re:So this is the thing killing portability

[olau]

You, sir, are a confused person. The protocol is open and free for any other OS to implement, and will remain so.

If the BSDs are left in the dust, it's because they're lacking the manpower to do the things a new GUI needs. This was not a big problem for GNOME 2, which is architecturally more than a decade old. But things have changed.

I can understand if people disagree with the path the GNOME developers have chosen because it does not fit with their ideals - but you have to understand that these developers are not your serfs you can command. There are still plenty of GUI environments with modest requirements of the OS, and while they may not do the same things you can choose from any of them as you wish. So quit the whining.

Re:So this is the thing killing portability

[Anonymous Coward]

Knowingly excluding other platforms is the issue. Building software that is intimately tied to something as massive as Linux kernel compiled with some very new features enabled is... many bad things, but not open, especially when there are known license incompatibility issues preventing open sharing of code.

Re:So this is the thing killing portability

[Jah-Wren Ryel]

you have to understand that these developers are not your serfs you can command

Ugh, I hate that sort of extremist straw-man. The developers are working on public projects, that means they are subject to both public praise and public criticism. It is a package deal.

Re:So this is the thing killing portability

[Improv]

Then we should turn away from GNOME3. Because they're taking compatibility lightly. Because they're wrongheaded. We should make sure that no distros ship GNOME3 or systemd as default. Sure, they're not serfs, they're just people promoting an inferiour solution that damages Unix.

Re:So this is the thing killing portability

[Flammon]

There's already a D-Bus implementation available on BSD and other Unices. The API is documented and anyone has the freedom to implement it any way they want, userspace, kernelspace or outerspace.

I fail to see how one more implementation, more specfically the Linux kernel one, has anything to do with giving up on anything.

Re: So this is the thing killing portability

[Anonymous Coward]

90% of the 'decade' old Gnome (lets say GTK+) software still uses this old framework. New Versions either switched to Qt or their developers simply abandoned their project and moved to OSX.

Why should BSD implement something they don't have too ?

Re:So this is the thing killing portability

[Sri Ramkrishna]

Linux is not Unix. It has gone way off the POSIX standard for some time now.

Re:So this is the thing killing portability

[fnj]

I don't see giving up on openness, but yes, it represents a cavalier kiss-off to BSD. Developer privilege. And it is user privilege to turn one's back on this.

Re:So this is the thing killing portability

[Sri Ramkrishna]

What will you do?

Re:So this is the thing killing portability

[DeSigna]

What?

D-Bus is still portable across multiple free Unices and even Windows. The standalone daemon isn't going away anytime soon, and I can't see the multitude of projects depending on it giving up cross-platform compatibility.

In-kernel IPC reduces context switching and other related overheads. I'm not sure exactly how much of a performance gain this gives D-Bus clients and the system as a whole but if someone wants to spend their Christmas playing around and seeing if something is better then great! And that's part of the benefit of OSS.

Re:So this is the thing killing portability

[jcdr]

You forgot that Linux was created precisely because there was no truly open UNIX running on a PC a his time. Even 386BSD arrived after Linux started to gain a growing community. The Linux community always tried a lot of different approach, and this is the reason why it is do dominant today.

But I agree that Linux is more and more a norm by itself and that his UNIX part is slowly mutating into a simple compatibility interface layer. I am not even surprised about that since UNIX was created at his time for hardware and application that are really out of the focus of the today market needs. The fact that the UNIX API last so long prove that it was a very good design, but this design don't include today hardware and application that was just pure fiction when it was created.

Re:So this is the thing killing portability

[celle]

"The protocol is open and free for any other OS to implement, and will remain so."

        But who says they want to or should have to deal with it. Just because it's there doesn't mean anyone wants it.

"If the BSDs are left in the dust, it's because they're lacking the manpower to do the things a new GUI needs. This was not a big problem for GNOME 2, which is architecturally more than a decade old. But things have changed."

        A new GUI? A new GUI, a new pretty to go with all the pretty we already have collected over the last twenty years that does the same fucking thing! It's just reinventing the wheel as superficially as possible for a completely superficial culture. If there's a god, save us from a new GUI that's the same as the old GUI.

      And as for the BSD being left in the dust you might want to look at your critical infrastructure.

Re:So this is the thing killing portability

[celle]

"Linux is not Unix."

      Yep, Linux is Open source Windows and getting about as ugly.

Re:So this is the thing killing portability

[celle]

"But I agree that Linux is more and more a norm by itself and that his UNIX part is slowly mutating into a simple compatibility interface layer. I am not even surprised about that since UNIX was created at his time for hardware and application that are really out of the focus of the today market needs. The fact that the UNIX API last so long prove that it was a very good design, but this design don't include today hardware and application that was just pure fiction when it was created."

      In other words, Linux isn't being engineered anymore, it's being driven by the masses.

Re:So this is the thing killing portability

[jcdr]

In other words, Linux isn't being engineered anymore, it's being driven by the masses.

You can use your own conclusion, but Linux was always driven by the masses of engineers that work on it. There is no other kernel project with so much authors. And this is precisely what make it so successful.

Now if you think that Linux is not a good engineering work, a lot of peoples will be more than happy to learn from you how to make it even better.

Re:So this is the thing killing portability

[rubycodez]

Linux is the standard, the UNIX(tm) are dying off.

Re:So this is the thing killing portability

[Anonymous Coward]

When 1 person do the job and the other do nothing, I do not call that a deal. Redefining the user/developer relation as being a exchange is just wrong. Developers ( to the largest possible sense, ie including translators, documentation writer, artists, etc ) are the one that make something, users are just receivers of a gift from others and therefor are in debt. So no, giving some praise is no way to erase that debt, as uncomfortable this situation is for more people. Complaining publicly about something you didn't paid for ( either by your money or by your time ) is just making people looking like spoiled brat.

Re:So this is the thing killing portability

[Barsteward]

" A new GUI? A new GUI, a new pretty to go with all the pretty we already have collected over the last twenty years that does the same fucking thing! It's just reinventing the wheel as superficially as possible for a completely superficial culture. "

Get over it, there is only ever going to be small changes to a GUI, there isn't really anywhere else for it to go unless they can plug the computer into your brain and the GUI becomes controlled by your thoughts. I think you have unrealistic ideals on this point

" If there's a god," - no such luck

Re:So this is the thing killing portability

[Barsteward]

"Now if you think that Linux is not a good engineering work, a lot of peoples will be more than happy to learn from you how to make it even better."

I'm afraid thats the problem with armchair critics, they snipe from the safety of the sidelines

Re: So this is the thing killing portability

[Anonymous Coward]

We didn't paid for it. That's right. But we didn't ask for it either. Specially didn't we ask for a total change of the unix ideology. People who write code that have such drastical impact on everyones day to day usage are simply writing code for the wrong system and ideology.

Re:So this is the thing killing portability

[fa2k]

anyone has the freedom to implement it any way they want, userspace, kernelspace or [the Cloud].

FTFY...shudder

Re:So this is the thing killing portability

[jcdr]

Sorry if it's hurt your sensibility: this was not my intention.

I thought it was a correct response to the "Linux isn't being engineered anymore" statement.

Re:So this is the thing killing portability

[Urkki]

What?

D-Bus is still portable across multiple free Unices and even Windows. The standalone daemon isn't going away anytime soon, and I can't see the multitude of projects depending on it giving up cross-platform compatibility.

"D-Bus Is portable", but seems headed down the road of practical unportability (barring complete rewrite and parallel maintenance of critical parts of a complex software stack). This seems to be a package deal, systemd + kernel DBus. Seems very much like Embrace, Extend, Extinguish: Integrate to Linux kernel, create growing ecosystem which depends on the new features of the Kernel version of DBus, abandon non-Linux kernel versions of DBus.

I truly hope I am wrong, but for now I will steer clear of systemd and any Linux distro which is going to use it. For me Linux comes with a bit of ideological baggage (you know, openness, freedom), and I'll not touch this particular bit of it until I am comfortable it is not going to shove something down my throat. And if it turns out to be difficult, then that more-or-less proves that my concern was valid.

(Yes, I'm the AC above.)

Re:So this is the thing killing portability

[Barsteward]

i was sort of agreeing with you not criticizing your comment

Re:So this is the thing killing portability

[Sri Ramkrishna]

Indeed, and it is making it's own reality.

Re:So this is the thing killing portability

[rubycodez]

and another thing, BSD is true Unix, though it is not Unix(tm). Unix(tm) is just some needlessly complicated system V's that promote vendor lock-in, by vendors who hijacked the Unix name.

Re:So this is the thing killing portability

[Anonymous Coward]

You, sir, are a confused person. The protocol is open and free for any other OS to implement, and will remain so.

The dbus mess is a protocol? Looks more like a tar pit. A huge amount of unnecessary complexity coupled with wheel reinvention, poor functionality, poor organization and poor documentation. Where is the message directory? The basic man pages pointing at useful, systematic information? The interoperability with other systems? The management of race conditions? The handling of idempotency? The basic visibility for debugging? The absence of NIH syndrome?

In other words, the walk, not the talk.

Listen to A.S.T.

[Bram Stolk]

Andrew S. Tanenbaum had a point about Linux not being micro kernel.
This is getting crazy: moving perfectly fine userland systems to the kernel.
Isn't the kernel large enough already?

Re:Listen to A.S.T.

[Anonymous Coward]

Please not use the words "fine" and "dbus" in one sentence without a negation. Thanks.

Re:Listen to A.S.T.

[Anonymous Coward]

Andrew S. Tanenbaum had a point about Linux not being micro kernel.
This is getting crazy: moving perfectly fine userland systems to the kernel.
Isn't the kernel large enough already?

That word does not mean what you think it means. In fact, kernel dbus is probably the most microkernel-ish feature I've seen added to the Linux kernel (although I haven't been paying close attention).

A microkernel is defined as a kernel composed of a large number of very loosely coupled modules, with an absolute minimum of functionality in the modules that are loaded initially or by the bootloader. Because of this, microkernels tend to have slightly greater overhead (both processing and memory) than comparable monolithic kernels, while (ideally) making up for this in flexibility and ease of debugging. Modularity in ring 0 is a double-edged sword: there are few protections against screwing everything up in a monolithic system (although Linux is now more like a hybrid, with an emphasis on supporting both static and dynamic modules, and it's been decades since a single minor change in some static module has caused some unrelated module to do something silly like scribble all over my disk), but it's almost always easier and faster to write non-modular systems in ring 0 (particularly early in the process, when many of the basic facilities need to be implemented and debugged for the first time -- it's extremely difficult to debug module loading in a microkernel when something like printing messages to the screen are in a separate module). In a sense, the microkernel-vs-monolithic debate mirrors object orientation vs procedural programming debates of the past (and both are fairly moot -- it's a decision about which much ink and many pixels have been spilled, and in the end, the decision is one that probably should be based upon the requirements for the particular project. An atmel device with 500 bytes of ram doesn't need a microkernel; a system intended for something fairly exotic like transparent heterogenous distributed computing can benefit greatly from it).

As for whether or not this is a good idea -- I'm in agreement that it's a bad idea, but primarily because of poor past experience with userland dbus implementations. I've used many distributions over the past fifteen years, and I've never had dbus work properly out of the box on any system that wasn't either debian-based or red hat based (and most of the distros I use on a regular basis are neither). If the developers working on top-10 distributions can't get it working properly and consistently and only the top two distributions can (for the sake of argument, I'm considering all debian-derivatives to be debian and all red hat derivatives to be red hat), then it's something that I don't trust to work in any kind of fringe situation, and it's not something I'd trust in kernel space except in the most well-tested situations (say, running a ten year old stable implementation on ten year old best-selling consumer hardware after five or six years of heavy automated testing). Much like some other systems being pushed by canonical (PulseAudio, systemd), dbus seems like it was released far too early and really isn't ready for prime time. Back in 2003, I'd expect and tolerate this kind of cavalier behavior from mainline distributions (remember Fedora Core 2's problems with ejecting CDs and then keeping them registered as mounted?), but Linux is now a perfectly reasonable desktop OS for most situations and enterprise-grade linux is big business, so shipping with completely broken non-solutions to already-solved problems (PulseAudio, which completely randomizes mixer settings on startup, etc.) seems unforgivably irresponsible.

Re:Listen to A.S.T.

[sirambrose]

I agree that Linux isn't a microkernel, but I don't think adding an IPC framework like KDBUS to Linux makes it bloated compared to a microkernel. I believe that an IPC system is the one thing that all microkernels include. Including an IPC framework in the kernel should help move other functionality from the kernel to standalone user space process that expose services over IPC.

Re:Listen to A.S.T.

[Bram Stolk]

That word does not mean what you think it means. In fact, kernel dbus is probably the most microkernel-ish feature I've seen added to the Linux kernel (although I haven't been paying close attention).

From wikipedia:
Traditional operating system functions, such as device drivers, protocol stacks and file systems, are removed from the microkernel to run in user space.

Re:Listen to A.S.T.

[Guy Harris]

That word does not mean what you think it means.

Nor does it mean what you think it means.

A microkernel is defined as a kernel composed of a large number of very loosely coupled modules, with an absolute minimum of functionality in the modules that are loaded initially or by the bootloader.

If by "kernel" you mean code running in kernel space, so that the modules run in privileged mode, that's a kernel with loadable modules, and is not necessarily a microkernel. Bram Stolk's response has a better definition of a microkernel.

Half-decade of stable Linux desktop ahead?

[Anonymous Coward]

I have a feeling I'll stay away from this systemd related stuff for a while. There's something fishy about it all.

Some non-Unity variant of Ubuntu 14.04 LTS is looking mighty tempting until the dust settles and sanity prevails, hopefully by 2018. I also have a feeling that will be the Linux distro to stabilize on for real work. Unless Canonical manages to screw up badly with it, or fold (or just stop support) earlier than promised.

104 minutes?

[Anonymous Coward]

Why has my dbus-system process used 104 minutes of CPU time since late november, less than a month?

My Squeeze system is used for web browsing, coding, and a little virtualbox. Oh, and sniffing packets when I'm wondering just WTF is lighting up my interface.

Frankly my dear, I don't see the point.

PS. Killed dbus-system and don't want to restart it.

Re:104 minutes?

[jcdr]

You maybe have a service sending a lot of DBUS messages, because usually a dbus-daemon is very very low in processing time.

root# uptime
  00:18:50 up 17 days, 10:15, 9 users, load average: 0.25, 0.35, 0.39
root# ps -C dbus-daemon fw
    PID TTY STAT TIME COMMAND
  4616 ? Ss 0:12 /usr/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session
  2508 ? Ss 0:04 /usr/bin/dbus-daemon --system

Re:104 minutes?

[PlusFiveTroll]

strace -p $PID_OF_DBUS_DAEMON

As for your network, it's probably something related to this http://avahi.org/

Re:104 minutes?

[MikeBabcock]

Diagnosing such issues is a pain though; and one of the reasons I dislike dbus :/

Re:104 minutes?

[jcdr]

There is DBUS tools to inspect the messages bus. Probably that your issue will be nothing different with an other IPC.

Re:104 minutes?

[MikeBabcock]

Lets just leave it at there's a reason people have had to write things like this:
http://www.webos-internals.org/wiki/Introspecting_Dbus

ps avx; /var/log/*, ipcs and netstat -apn are all much cleaner.

Re:104 minutes?

[jcdr]

Standard package of dbus should already contain the dbus-monitor and dbus-send commands.
If you want an easy tool, try D-Feet https://wiki.gnome.org/action/show/Apps/DFeet?action=show&redirect=DFeet.

ps and netstat only show the current state. You need very different others tools to modify the state or to dynamically monitor the state transitions. From this point of vire, DBus if far more generic, coherent and cleaner than a lot of others tools.

Too much navel gazing

[Sri Ramkrishna]

Too much navel gazing about change. Here is the reason behind kdbus. Primarily it's for application sandboxing and making sure that a bad actor does not do something bad to something else. As GNU/Linux gets more popular, we want to be able to make sure that we can contain bad actors as much as possible. It's also a step in the direction to have a universal app spec instead of having to have each distro package the same damn app. I miean, how much duplicate work do you want to do? It makes it easier for people who write apps to have GNU/Linux as a target instead of having to pick the most popular distro at that point of time.

http://lwn.net/Articles/551969/

Linus is okay with it. Have to worry about Al Viro. :-)

Here is an updated talk by Greg K-H that he gave on KDbus, he posted this about 3 days ago. https://github.com/gregkh/presentation-kdbus

Let's stop all the FUD, and educate yourself on the reasons behind on this.

Re:Too much navel gazing

[Anonymous Coward]

> Here is an updated talk by Greg K-H that he gave on KDbus, he posted this about 3 days ago. https://github.com/gregkh/presentation-kdbus

Last update time on that repo is 7 months ago. ( https://github.com/gregkh/presentation-kdbus/commits/master ) Did you fail to update your copy-pasted talking points?

Re:Too much navel gazing

[celle]

" It's also a step in the direction to have a universal app spec instead of having to have each distro package the same damn app."

        So linux standard base is dead, right?

Re:Too much navel gazing

[Sri Ramkrishna]

Or it could be modified to include this. Nothing says the standard has to remain the same for all of eternity.

Re:Too much navel gazing

[Anonymous Coward]

Let's stop all the FUD, and educate yourself on the reasons behind on this.

Heh, look at your address bar. Good luck!

why not use binder

[GodWasAnAlien]

why not give up on dbus, and just use binder, which is already supported in the kernel?

Personally, I _do not want_ this.

While, we are at it, I do not want do-everything daemons like upstart or systemd. These monolithic programs of undefined scope are poor examples of software engineering, and not needed.

Re:why not use binder

[Anonymous Coward]

While, we are at it, I do not want do-everything daemons like upstart or systemd. These monolithic programs of undefined scope are poor examples of software engineering, and not needed.

What? They are the core Service Host Daemon of the operating system.

Re:why not use binder

[mab]

Binder is "weird", Kroah-Hartman said. It came from BeOS and its developers were from academia. It was developed and used on systems without the System V IPC APIs available and, via Palm and Danger, came to Android. It is "kind of like D-Bus", and some (including him) would argue that Android should have used D-Bus, but it didn't. It has a large user-space library that must be used to perform IPC with binder.

Binder has a number of serious security issues when used outside of an Android environment, he said, so he stressed that it should never be used by other Linux-based systems.

http://lwn.net/Articles/551969/

Re:why not use binder

[Ash Vince]

Binder is "weird", Kroah-Hartman said. It came from BeOS and its developers were from academia. It was developed and used on systems without the System V IPC APIs available and, via Palm and Danger, came to Android. It is "kind of like D-Bus", and some (including him) would argue that Android should have used D-Bus, but it didn't. It has a large user-space library that must be used to perform IPC with binder.

Binder has a number of serious security issues when used outside of an Android environment, he said, so he stressed that it should never be used by other Linux-based systems.

http://lwn.net/Articles/551969/

What does he know anyway. If he knew more about kernel development he would be more offensive like Linus :)

Please please send Lennart to China

[Anonymous Coward]

So he can do his damage somewhere more helpful.

Every subsystem he writes (eg. systemd, pulseaudio) is a complete disaster for everyone else.

The stupid thing is

[markhahn]

The really really stupid thing is that desktop isn't even the reason why Linux. Obviously no server needs dbus let alone kdbus, and plenty of desktops don't either. Yes, it's amusing that I get a popup when I plug in a USB stick, but is that essential functionality? Sure, some very simple form of event multicast would be good, but is this it?

Everything LP touches seems to epitomize rebellion against, or ignorance of, the *nix/OSS philosophy (you know, modularity, loosely joined, liberal-in-what-you-accept, etc). systemd is the USSR of rc systems. pulse only remains because apps can still bypass it.

Re:The stupid thing is

[Anonymous Coward]

The really really stupid thing is that desktop isn't even the reason why Linux.

Granted, this sentence no verb either.

Re:The stupid thing is

[Anonymous Coward]

ha. thats what I thought too. I guess this is just more important for something like a cell phone or similar device.

Re:The stupid thing is

[Anonymous Coward]

The biggest dbus consumer is Nepomuk, but the actual incarnation of Nepomuk is going to be dumped with KDE 4.13. Its replacement is going to be Baloo, basically a supercharged Tracker compatible with the parts of Nepomuk that were actually used by KDE apps.

Watch KDE 4.13.

Start working on HURD

[Anonymous Coward]

If you don't like how Linux is evolving, you can always help with GNU HURD. It is an opportunity to mold that system in the way you see fit.

Re:Start working on HURD

[rubycodez]

Linux exists soley because HURD has been such a dismal failure, the FSF can't manage something as complicated as the building of a kernel

Re:Start working on HURD

[unixisc]

HURD needs to be redone from scratch by a totally different team using a forked Minix3 as their basis, and building all the HURD servers on top of it. Main work would be the driver support

Re: Start working on HURD

[Anonymous Coward]

The question is:

In what direction is Linux evolving ?

The second question is:

If it evolves into some junk ass hybrid OS, then can this be seen as 'we are not following the unix ideology' ?

This gets us to the last question:

People that don't agree with the unix ideology and therefore turn Linux into some MacOS Clone, don't they think that they are on the wrong system / writing code for the wrong system ?

Re:Start working on HURD

[staalmannen]

I would rather see it based on Genode OS and the L4 microkernel

Re:Start working on HURD

[unixisc]

L4 was already tried. Reason I suggested Minix is that it is already designed around Unix - not sure about Genode or L4.

Re:Start working on HURD

[rubycodez]

don't insult the Minix man and team, Minix is a fully functional operating system that can run real world software, for example Apache server with Perl or Python wares

A team that needs an OS to "build their OS" to run on top of it doesn't know how to make an OS

Re:Start working on HURD

[Anonymous Coward]

And how a isolated individual could make it in 1991?

re: Note that I'm not condemning this per se

[codeusirae]

"Note that I'm not condemning this per se"

It's understandable why you would want to remain anonymous ...

Dido?

[jabberw0k]

Dido, the British singer-songwriter ("White Flag," "Life for Rent")? -- or did you mean, "ditto"

parse TFA

[mynamestolen]

can someone please parse the English for me (first line of TFA): "Open-source developers this week achieved a pleasant late Christmas present for Fedora users of having a working system with using the in-development Linux kernel DBus implementation (KDBUS) paired with the latest systemd code can now yield a booting system."

As a naive user, I'd be wary if they can't even write in English.

another asshole talking shit

[Anonymous Coward]

Bitch and moan all you want, nobody developing these systems gives a fuck, you're just another asshole with an opinion.

Vote with your dollars, or vote with your code.

waking up requires special cases, so does moving

[dutchwhizzman]

Modern systems often aren't a single purpose hardware server any more. Mobile devices that have to switch on services like GPS, several networking modems, voice over IP, hotplug hardware and start/stop associated services and such will make you have to run numerous daemons that control just restarting the one small group of services and hardware for every corner case you can imagine if you keep using RC scripts.

Even servers often have nested dependencies these days. You'd want the system to restart a failing middleware application in the correct sequence after you've fixed the filesystem on the storage that ran out of space that caused it to remount r/o on all your web server platform VMs. Try doing a bunch of init.d scripts for that. Either you custom write a script to do it remotely just for your app, or you have the systemd-like control that will just figure out what to do all by itself.

Yes, it adds complexity to very simple single use systems, but it makes dealing with all the glue you have to do to get dependencies on other services and corner cases so much easier. I used to think it was a solution looking for a problem too, until I found out that I could now stop worrying about getting my systems up again after I just solved the single cause of all the problems that got them down in the middle of the night.

Re:waking up requires special cases, so does movin

[sjames]

Same sequence as start for a runlevel, only do restart instead of start.

Avahi?

[Anonymous Coward]

I luckily managed to excise Avahi off my systems long time ago. Actually, even before the Second Poetteringware (aka pulseaudio) started to make a splash.

I just went: "my database chatting around the net saying 'hi, I'm a database. I can be contacted at foo:bar'. What can possibly go wrong?".

Out with it. Only later, pulseaudio time, I went "ah, so that's the same Avahi guy? Out with it!"

My system is now Avahi-free, pulseaudio-free and -- yes! no dbus daemon. Firefox complains, but that's what /dev/null is for. Emacs used to complain (yes!), but Emacs is important enough to me that I compiled it off source.

Re:Avahi?

[jcdr]

I actually found Avahi extremely well implemented. It work exactly as expected and I never have identified any problem with it.

I am afraid that the future will make your dbus-free system more and more challenging. I do a lot of embedded system and the dbus-deamon is so critically important that nothing will work without it.

Re:waking up requires special cases, so does movin

[Anonymous Coward]

On what distribution are you running these systemd-managed services?

Re:waking up requires special cases, so does movin

[sjames]

Sorry to double reply, but systemd would be a lot more acceptable if it and it's project leaders would be just a bit more conservative (especially in dependencies) and a bit more open to porting to non-Linux systems. As it stands, I hope that failing prompts Debian to pick upstart.

Since rc scripts are currently universal, it makes sense to consider them a gold standard even after moving to an alternative init. In other words, any new init needs to consider support for scripts dropped into init.d and linked in rc[1-5].d to be first class citizens. Ideally, it would auto-generate init.d scripts so that legacy scripts using /etc/init.d/service [start|stop|status] would continue to just work. As opposed to the current case where that is considered to be a 'problem' that needs some sort of remedy.

That compatability should be retained until nobody is using rc scripts anymore (read as "for years to come").

Right now, systemd feels like it will have all of the charm of Gnome3, complete with it's "our way or screw you" attitude that has people avoiding it in droves. Init is too important to hand over to that.

Getting to know the BSD user community

[bain_online]

I guess i stlll don't know who the other two people are.

Re:Getting to know the BSD user community

[fisted]

Well that'd be me, and your mum. I talked her into BSD the other day.

Boot times

[Larry_Dillon]

You're absolutely correct that Windows presents the Desktop before the system is actually ready to do anything. It gives the illusion of faster booting.

Re:Boot times

[Anonymous Coward]

I saw a presentation on fast booting at an industry meeting (they were trying to sell everyone overpriced computers). The guy was claiming it was done booting when the login screen came up. He then talked for a few minutes and then logged in and said "see how it is ready to work," and opened Microsoft Word (which opened so quick, I suspected that because that is the demo they always do, readyboost or the like already loaded it into memory). So I asked if I could interact with it and he agreed. Before he could interject, I closed Word and restarted the computer. The login screen came up in a couple of seconds and I logged in. The spinning circle came up and it circled for a minute, then showed the desktop. I then clicked the button for Excel and then the one for Word. Word open instantly but Excel took a few minutes. Once it did, the guy was in literal disbelief that it took so long but I guess it is a liability for them to know how or why things actually work.

Re:waking up requires special cases, so does movin

[Anonymous Coward]

http://lists.debian.org/debian-ctte/2013/12/msg00070.html

"At the same time we will no longer support dbus-daemon for the system. This will add a hard dependency of systemd on a very new kernel version. However, to make this palatable we will try hard to keep kdbus.ko compilable out-of-tree and easily backportable"

Quote from Lennart Poettering! systemd will become a HARD dependency on newer Linux Kernels!

Re:waking up requires special cases, so does movin

[Anonymous Coward]

You got that quite backwards.

Systemd will have a hard dep on a very new kernel version and will not work with any older ones.