I used to be able to say Linux was clean, logical, well put-together, and organized.
I don't think this was ever really the case, but I do think software is evolving to meet the list of constantly updating use cases.
Of course managing one network interface with all your peripherals connected at startup required less complexity. But if your target audience also has use cases of wanting their USB drive to "just work" when plugged in, being able to connect to a new wifi access point under their normal user, etc., you will want some extra layers of abstraction that aren't available if you limit yourself to FDs and Unix-style permissions.
In addition, some software is cross-platform and doesn't always care about maintaining consistency with the conventions on a single platform.
There are cases where you want to be notified when an event occurs or the success of your application's action (in more detail than the error codes from a write(2) to a FD).
You can solve the problem by using socket FDs, but you have to roll your own format for registration, communication, error checking, making sure the appropriate applications can read, etc.
I think many developers would prefer using DBus as an abstraction for these types of problems.
Why not a library that speaks a simple[1] line based protocol over pipes and/or sockets? Or even just plain old files?
That's how unix used to work before the desktop people took over.
[1] Yes, DBus is "sort of" line based. But from all I've heard it's the opposite of simple and... well, let's just say people don't seem to have much good to say about it.
It's true that DBus is somewhat of a complex solution if you have a simple enough use case, and I think most of the criticism is the documentation rather than the design (or, rather, criticism of the design is mostly that it isn't Unix-like).
But having a daemon that relays your messages to other applications based on a standardized protocol has some merit of its own, even if it isn't strictly Unix-like.
I might have some bias, since I think the Unix-way is oversimplified for some problems, even though there are often ways to make it work.
I agree, and I'm not opposed to the idea of a daemon.
DBus just seems to be (from my perception) rather poorly designed on every level. And the more pervasive it becomes the more of its bad design bleeds into more or less unrelated other software packages.
the Unix-way is oversimplified for some problems
The unix-way of course has limits, but it's usually worth to explore it as far as possible and only then divert to more baroque designs.
In the majority of cases you'll find that pure, file-based approaches are a lot more elegant, efficient, discoverable and debuggable than the alternatives (see e.g. qmail vs postfix, or runit).
There's a lot to be said for being able to use the standard unix cutlery to inspect and interact with the guts of your application.
Imagine DBus was just a directory with one or two files per pid. Imagine you could read past messages with 'cat', follow them with 'tail' and inject new ones with 'echo'.
I think the only thing really missing from the "file descriptor" model is revoke() - and that's been the case from very early on (hang-up for tty devices works like a device-specific revoke()).
revoke() is potentially harmful, since an application not written to check the error code after each interaction with each file descriptor will break when one of its file descriptors is revoke()'ed out from under it.
Why not instead use fuser(1) to find programs using the file descriptor you want closed, and then take program-specific actions (kill(1), restart, signal) to ensure that they sanely release the descriptor?
Any interaction with a file descriptor can already fail (eg. pretty much anything can potentially give you EIO).
Using fuser() in that way is racy, and how is kill() any better than returning a possibly-ignored error anyway? You can't do program-specific actions because the point is to enforce "You did have permission to open that, but now you don't and you aren't allowed to keep using it".
We may be talking about different things but why would you need to close an fd "externally" when (at least for pipes and sockets) there is someone on the other side who can just close it regularly?
revoke() would be useful for things like device nodes (and even regular files) - consider "you can open the sound device while you are logged in locally, but you can't keep using it after you've logged off".
Maybe I was lucky in my choice of Linux distro but I never had problems with WiFi or plugging in USB drives since I started with Ubuntu 8.04. All I can say is that I was surprised about how a drive becomes available much faster than on Windows. That was the case with XP and still is the case with Win 8.
Could you give some examples of USB drives not working or new networks not found? Thanks.
I meant that when a user plugs a USB they probably want an immediate popup on the desktop and the ability to manage the files on the drive, or that they want to be able to see the wireless networks and configure them without switching to the root user, or even shutdown the computer with a button on the desktop.
The way this is done is with a message bus and other subsystems (there were consolekit, networkmanager, ...), and these don't really match the "Unix-way" of doing things. Though I don't consider this to be a big issue, some people do.
If you have a minimal distro and install a very basic environment, you'll often have to set up these to work if you want some of the above features. Ubuntu will already have all this set up though.
Ok, I understood why I was puzzled. Ubuntu opens a file manager window whenever I plug in a USB drive and it tells me about available WiFi networks. XFCE on my netbook does the same. Probably some other distro is more silent about those events.
Indeed, ever since I've been using Linux (mid-90's) I've heard that Linux was a big mess of heterogeneous stuff held together with duct tape while FreeBSD was a clean, logical and organized.
I've tried FreeBSD several times but at the end of the day features and compatibility beat clean and logical.
Compatibility? Yes, FreeBSD doesn't support the latest laptop stuff yet (like 802.11ac), and doesn't include the driver for the Wi-Fi adapter in MacBooks (because that driver is a piece of crap). But a lot of hardware is supported.
Features? Well, FreeBSD has a lot of them (big ones: ZFS + DTrace + Jails + pf) and they work great out of the box!
It doesn't have a driver for the last two releases of intel CPUs integrated graphics. Both linux and OpenBSD have fully open source drivers for this.
It's unfathomable that this ultra common hardware is unsupported, until you consider that even most FreeBSD devs don't run it on their laptops, they run MacOS with FreeBSD in a vm / via ssh, because it's not up to the job.
It's at least 5 years behind Linux, probably more.
I don't think this was ever really the case, but I do think software is evolving to meet the list of constantly updating use cases.
Of course managing one network interface with all your peripherals connected at startup required less complexity. But if your target audience also has use cases of wanting their USB drive to "just work" when plugged in, being able to connect to a new wifi access point under their normal user, etc., you will want some extra layers of abstraction that aren't available if you limit yourself to FDs and Unix-style permissions.
In addition, some software is cross-platform and doesn't always care about maintaining consistency with the conventions on a single platform.