KDBUS Is Indeed Going Back To The Drawing Board

[unixfan2001]

Have you ever used debian xfce? With current hardware it is working fast enough for desktop use even in 15 usd quadcore orange pi board. Gnome and Kde need wayland and kdbus, it is easy to blame X if their software is resource hog and slow. If you compare debian xfce to windows, xfce is very fast. I see wayland and kdbus is a way towards The Poetterisation of GNU/Linux



that means non working systems and is a waste of work, for example pulseaudio with games and bluetooth file transfer.

Clear proof that you have absolutely no clue what you're talking about.

Even a simple setup without any desktop environment and a lightweight window manager can suffer from tearing and performance regressions under X11.
The design of X11 is old and flawed. Even a composite manager can't always keep resize or move operations from becoming jerky.
Developers have to deal with dozens of extensions and the codebase is riddled with bugs and all sorts of security holes.

As for that idiotic "Poetterisation of GNU/Linux":

You're free to go back to using legacy UNIX.
Whether you admit it or not, changes are necessary in order to make GNU/Linux fit for the modern desktop.

And btw: Just because a certain design feature pops up in Windows or Mac OS X doesn't mean that feature is inherently bad and shouldn't be implemented as part of the GNU/Linux desktop stack.

[SystemCrasher]

Have you ever used debian xfce?

I've been using various distros. And if you want to hear my opinion, Debian is good distro overall, but graphic stack isn't its strongest point for sure. When it comes to x86(-64), usual GPUs, and using releases, for example, MESA and kernel in debian are just horribly outdated. So in my configuration it would be barely able to light up my GPU using open drivers, if at all. And if it would start, I have to grab stopwatch to see how many seconds it would take to see infamous "ring X stalled for Y milliseconds", etc. Especially if I would dare to run anything 3D based. Even something not really demanding, like WebGL or some fairly modest games like Xonotic. This could be dealt with, but takes a lot of manual actions and potentially troublesome actions like switching to testing or unstable and using less retarded versions of software. One of reasons why I prefer xubuntu is there is recent kernel and MESA out of the box. So it would be "quite okay" out of the box, and "not bad" after upgrading it further from repos like Oibaf PPA or Paulo-Diaz PPA. Which have nearly most reasonable build configurations for graphic stack. Including video decode acceleration, opencl parts and so on. It is end of 2015, after all. And not everybody happy with VGA or similar framebuffer things 100% of time. Sometimes I could want something beyond that.

Then, take a look on video in youtube, for example. Can you play, say, 1080P? Wihout swearing on CPU load caused by Xorg? And what about tearing? Wanna some good test case where tearing gets rather obious. Somehow, 1080p isnt uncommon these days. In fact I have 2560x1600 screen. This means two times more pixels. Twice as much data to chew on. Somehow, xorg is quite bad at it.

With current hardware it is working fast enough for desktop use even in 15 usd quadcore orange pi board.

Uhm, don't you mind I'm having fun with similar boards for fun and profit? I can build my custom boot loader and mainline kernel and then assemble my very own, task specific rootfs using debootstrap. Then putting all this together to system image, and making it doing something useful, often in fully automatic manner. Do you still want to tell me something new about Debian? Feel free to try

Debian does not needs advertisement. When I need to implement custom system for commercial use, debian is just great. They are really careful about licensing crap, patents and somesuch. So while they are not best of the best in anything, they are wonderful as core base, suitable for taking it, handling rough edges myself and turning it into great, task-specific system. It takes efforts though. And I think it is okay to charge my customers for it. Of course they can do system integration on their own, if they think they can do it better, faster and cheaper.

Gnome and Kde need wayland and kdbus, it is easy to blame X if their software is resource hog and slow.

I think I want it too. Overall I like idea making it like KDBUS on kernel side and SD-BUS lib as usermode. It would be logical, it could be fast, it does not requires dbus daemon doing some things better suited for kernel side, like rights separation and enforcement. And overall it would be more or less like file syscalls in kernel and file functions in libc. IMHO it is really good idea to make bus one of rather basic core OS services similar to file operations.

Just as "optional" as procfs or sysfs. Sure, you can build your kernel without procfs and sysfs support. Feel free to boot with it and take a look what it takes. I would be okay if system bus would turn into something similar. In fact I think it have to be one of core services since it allows to make various ways in fairly logical and convenient ways, especially if one gets it right. That's why I warmly welcome "technical excellence". Now it is proper point of space and time to review how D-BUS has been working and fix its shortcomings rather just set them in stone. And I would gladly call bus from something like sb-bus lib even from fairly low level programs it it makes overall design more elegant and saves me a day from reinventing wheel myself.

If you compare debian xfce to windows, xfce is very fast.

Really depends what you compare. Boot time? Ok, my ubuntu and debian systems are beating windows by 3x-4x shorter boot times after I started to use systemd. Windows users are waiting for ~minute to boot. I do it in about ~15 seconds on slow notebook HDD, and mere 5 seconds on SSD (in fact BIOS takes more time than whole OS boot XD).

I see wayland and kdbus is a way towards The Poetterisation of GNU/Linux

Somehow I got fond of how Poettering tools are working. These solve shitload of hard engineering challenges rather than pretending they do not exist.

Say, I have device. I have critical service(s). This service is essence of device existence. If this service fails to start or hangs, whole point of device existence is void. This is just a plain useless brick, user just does not needs this crap without my service doing some core logic. Mission failed. I'm getting complaints. Does not sounds tasty, right?

So how systemd handles it?
* It can measure startup time of service.
-- Should service stuck on start, action could be taken. It is embedded, there could be no user to press "reset" or go console.
-- It takes only few lines of code and configuration. Service can explicitly announce systemd it considers start complete. There is API, dammit.
-- It would not get tricked by "obvious" crap. Imagine you've been waiting for 30 seconds. Then ntpd comes and adjusts clocks. Sounds interesting, yeah? So most naive approach can have random failures which can be hard to pinpoint. There're plenty of such pitfalls in system programming.

* It could also detect if service has crashed.
* it can also check if service alive. There is watchdod API.
-- Should process lock up, it would miss its watchdog servicing deadline, action could be taken.
-- Systemd can also service hardware (or kernel-side) watchdog. Should systemd itself fail to operate, system would get reboot.
-- This results in sharing single HW watchdog across process tree in logical way. I appreciate it.

At least user do not have to mess with system recovery. Somehow Poettering had fairly good idea of how autonomous systems are supposed to work.

* If I have lightweight service which fiddles with external events, and there is some heavy background worker, systemd can set up limits, priorities, schedulers, SECCOMP filters, user/group, etc.
-- Only takes few config commands. Have fun coding same sequence yourself, etc...

* If I need boot ordering, it is simple and straightforward to do in systemd. Even if I need, say, generate config or runtime data for some program, it is easy to ensure my program starts BEFORE another. Without touching package or configs of that program (which is critical if you plan to install upgrades, since various packages have their own idea if they are going to overwrite config or not, etc).

* Systemd is aware there could be logs BEFORE logger service has even started. Nobody else gives a fuck, to the best of my knowledge...
* Systemd could log something, even if you're really poor embedded guy who do not haves writeable rootfs at boot. It can log to kmsg instead.
* And if something goes wrong, program return code and error message is actually getting logged.
* It can separate my programs to containers.
* Thanks to cgroups systemd always knows who has started some crap. You can't fool it easily, even nasty crap like double-forking to lose parent process is not going to work.

So if you think I dream to go use sysv init crap, ignoring timeouts and lockups, return codes, output messages, or coding rather complicated system level software with many pitfalls to handle this, scratching my head about who has started process or why it failed to start - haha, plain fucking wrong! It is finally time to make system management logical.

that means non working systems and is a waste of work, for example pulseaudio with games and bluetooth file transfer.

Oh, somehow, my systems are working and I'm actually fond of some systemd features. Maybe it's not about systemd? And, uhm, take a look how various BSDs would copy-paste this idea, it would just take 'em some 10 extra years, as usually. High-end commercial unix systems like AIX or Solaris had similar facilities for many years already, etc. Am I really supposed to miss crappy and bugged bunch of scripts which were never bothering self even to log error message or return code, etc? Haha, nope, let this horrible crap to burn in hell. Its the only fate this crap deserves.

....and for those who were up for libs, interfaces, and so on...
There are some fancy rants. Library intefaces included.

If someone does not knows, Charles Bloom is one of high-profile gurus in data compression, known for various algos & improvements, etc. And so, he rants a lot. While some rants are pretty usual, one of rants proven to be kinda interesting: 09-19-15 | Library Writing Realizations. That's a very interesting opinion on how (not to) write libs . And I would agree like 80% of these ideas.

[anda_skoa]

Uhm, well, when I need bus, I generally want to either throw some notification, call someone, or receive events of my interest, or maybe provide option to call some things "remotely". Reassemblying messages myself .. erm, well, sure, sometimes I could want to fiddle with raw ethernet frames, reassemble bus messages, etc.

Exactly!

You wouldn't use libcrafter to manually construct TCP packets when you need to send data over the network.
So no point in using a low level message construction library when you actually want to call methods in another process.

And inability to do it could be rather frustrating. But most of time I rather want "connect and transfer data" or even "fetch that URL". Without taking care how exactly TCP/IP fiddles with raw ethernet frames. Same idea goes for buses as well.

Exactly!

Hence not using API at the message construction level but something that provides the layer that one wants to use.

Nobody with the above goal ever uses libdbus, it is used by people who's goal is to create and parse messages.
Vice versa nobody with the goal of explicit message handling uses a high-level API and tries to work against it.

In first place, if I want just to use d-bus, it not necessarily means I always want lowest possible level. Just like my wish to read from file does not means I want to open /dev/sda, parse filesystem, find that file, parse fileystem structures further to decode extents location, read and reassemble it and finally get my data. Most of time I would want read() and sometimes I could be ok with doing SQL query via libsqlite, etc. And it is kinda wrong to assume I shouldn't be able to do so in reasonable ways.

Exactly!

Which is why you would use the correct API for the task at hand.
You wouldn't read from /dev/sda and then complain that it was too low level. That wouldn't make any sense.
Same for D-Bus. Nobody uses libdbus for method calling and then complains about it being too low level. Wouldn't make any sense either.

So, things like systemd or, say, network-manager's core part had no truly appealing ways to use dbus.

No idea about systemd, but NetworkManager uses libdbus-glib on my system (according to ldd).
Quite a common choice for an older GObject based program, a new one would likely use GBus.

Some programs worked it around, but many servces devs just disregarded dbus, preferring various awkward homegrown incompatible "solutions", hacking desired intefaces out of signals, sockets, or whatever crap they managed to invent.

Yes, unfortunately a lot of service developers are still stuck in the mental model of only having to cater to sysadmins, while modern systems have programs dealing with configuration and thus require some machine-to-machine communication mechanism, with proper priviledge separation, etc.
Which is what D-Bus provides and is being used for a lot, but some of the older service projects have not updated their thinking yet :-/

Where one have to have explicit a priori knowledge of all conventions, data formats, who exactly is connected and going to use it, and other purely technical cruft. Major step back compared to system bus, right?

Absolutely!

Say, what most logical thing to do when battery is getting low? Someone like kernel can throw warning to bus, and it can do it even if system is quite busy, or low on resources, etc. Then, say, power manager can try to reduce power consumption. Connection manager can reconsider connectivity options in favor of least power hungry ones. Background services can reconsider what they do and defer heavy activity implying heavy network traffic, major CPU usage or disk activity. So disk indexing can get lost, background downloads would not happen, and so on. Wait, I've seen something like this somewhere. And it worked reasonably.

Exactly!
D-Bus was a real game changer for process-to-process communication.

No, I don't. And actually I guess I'm rather up for calling it directly from my programs, it would allow me to make minimal changes to system level software, yet to be able to use system bus and take advantages of it, rather than keeping reinventing the wheels.

Right, so it is definitely a library intended to be used by program developers, not developers of D-Bus integration of application development frameworks.
Which of course puts it into a different category than libdbus, which is intended to be used by the latter and never used by any sensible representative of the former group.

Cheers,
_

[SystemCrasher]

You wouldn't use libcrafter to manually construct TCP packets when you need to send data over the network.
So no point in using a low level message construction library when you actually want to call methods in another process.

And, somehow, it seems before Poettering there was no appealing dbus library for C programmers doing low/medium level code which is program rather than library. Which is really odd, but...

Hence not using API at the message construction level but something that provides the layer that one wants to use.

And TBH I do not really get why there was no sane lib suitable for C programs before Poettering bothered self to do it. Somehow I've got impression Poettering isn't bad at solving long standnig issues.

Nobody with the above goal ever uses libdbus,

Sure, but what else one supposed to use if they were coding some small system-level service in C? Now I can imagine sd-bus lib would do the trick. But it only appeared recently and probably subject to change.

No idea about systemd, but NetworkManager uses libdbus-glib on my system (according to ldd).

Speaking for myself I do not like glib dependency. Glib is large and heavy gnomish lib and pulling it as dependency for system-level programs and somesuch is not welcome. And I think that's why many programs avoided dbus to the date, reinventing the wheel instead. There was no appealing way to use dbus... well, before Poettering. Though he also comes with disadvantage of being non-portable.

Quite a common choice for an older GObject based program, a new one would likely use GBus.

Cool, but when I write system level stuff, its some plain C programs, preferrably small and simple, to keep things manageable, fast, reliable predictable, easy to debug and lightweight overall. Glib and other gnome cruft is last thing I want here.

[...]Which is what D-Bus provides and is being used for a lot, but some of the older service projects have not updated their thinking yet :-/

Because there was no appealing implementation for some use cases. Not like if each and every small C program is going to be fond of glib, GObject things and somesuch. These are ok if one writes desktop GTK+ app, etc. I can estimate they'll rather could be fond of things like sd-bus lib. I can foresee quite many spitting on "non portable" programs from BSD and Solaris sides and then these are likely to reimplement equivalent interface, one way or another.

D-Bus was a real game changer for process-to-process communication.

But only partially, and I think it can be seriously improved if it done right, using appropriate layering. And somehow, kdbus, sd-bus and somesuch are looking like a part of initiative to make it this way. And IMHO it would be nice if kdbus would be rethought compared to plain dbus during this process. To get rid of shortcomings and issues rather than setting 'em in stone and make it far better overall. And that's where I like kernel way of doing things. It always worked good for me. Linux kernel is my favorite software. It impressively big, yet it neither awfully bugged, nor horribly unstable. And performs very well in most scenarios I face. So speaking for myself I would trust them in matters of technical excellence and doing things right. Somehow, I can't tell the very same about things related to DBUS. I do not recognize them as something superior. Buses were known before them, and their implementation is mediocre in terms of "technical excellence". So they only different by the fact Linux desktops have somewhat adopted it. Because there was no better implementations anyway, and bus is rather interesting conception and it is probably wrong to completely ignore it.

Right, so it is definitely a library intended to be used by program developers, not developers of D-Bus integration of application development frameworks.

At the end of day, programs are supposed to use libs. And there was no appealing lib to use dbus for certain range of programs. Somehow, these programs are rather important and actually having dbus interface to these isn't exactly bad.

Say, take a look how everybody manages system accounts these days. One have to take a look to /etc/passwd, etc. Then it proven passwd is bad for security, because everyone can read it, and passwords were moved to shadow, etc. And so on. And editing user is hardly can be called convenient since you have to parse files, change them in the middle, and so on. So even if you want to update user a but... uhm, well, its quite an issue in terms of programming. There are some dbus services trying to make it better. But these are really desktop-centric and heavy. And nobody is going to use these on servers or in embedded. It does not means they do not need to update users easily. It means implementation is way too desktop centric. Most servers and embedded are virtually not using d-bus at all. Because its way too heavy and desktop centric.

I think it should be "system bus". Not anyhow tied to DEs. But rather some basic core OS-level facility, easily accessible from absolutely all levels, ranging from kernel to enterprise software.

Which of course puts it into a different category than libdbus, which is intended to be used by the latter and never used by any sensible representative of the former group

TBH, I usually need libs to actually call them, rather than to reimplement libs on top of them. So I think there was major omission from d-bus side for quite a while. Poettering going to fix it, but at the price: it going to be non-portable, at least initially. This could be less issue for some low level components which could be system dependent on their own, but overall its better to have it cross-platform and that's where d-bus had noteworthy omission.

[anda_skoa]

And, somehow, it seems before Poettering there was no appealing dbus library for C programmers doing low/medium level code which is program rather than library. Which is really odd, but...

Odd indeed.
Makes one wonder if Lennard is the only C developer capable of doing what dozends of developers on other languages were able to do or if those otehr C developers with the same skill just liked doing everything manually.

And TBH I do not really get why there was no sane lib suitable for C programs before Poettering bothered self to do it.

And I agree again.
Even C# had a suitable implementation.
One possible guess is that C developers just don't like libraries or don't want to make libraries that are useful for other developer.

Sure, but what else one supposed to use if they were coding some small system-level service in C?

One example would have been to write a C API for application developers once instead of having every developer write adapter code.
Or do that Lennard did, write a new library from scratch.

One of these approaches was done for all other languages, what makes C developers less cooperative, less inclined to solve a problem once, less motivated to create a solution usable by others?

Now I can imagine sd-bus lib would do the trick. But it only appeared recently and probably subject to change.

Quite a shame for all the system service developers that it took a desktop developer moving into that space to get some library done, no?

At the end of day, programs are supposed to use libs. And there was no appealing lib to use dbus for certain range of programs. Somehow, these programs are rather important and actually having dbus interface to these isn't exactly bad.

And misteriously no developer on these range of programs either capable or willing to provide such a lib until a GNOME developer came around.

I think it should be "system bus". Not anyhow tied to DEs.

There must be some misunderstanding.
Neither the system bus, nor the session bus, nor the new user bus (as provided by systemd) is tied to any DE.

TBH, I usually need libs to actually call them, rather than to reimplement libs on top of them.

Sure, but that was true for libdbus as well. The early library developers needed something to call instead of having to implement the protocol stuff themselves. And application developers just called the application facing libraries.

So I think there was major omission from d-bus side for quite a while.

An omission of C based developers not wanting to use desktop oriented libraries.
There are D-Bus libraries for languages not very widely used for desktop applications such as Java, written by a single developer who wanted to use D-Bus from Java.
Yet no C developer wanting to use D-Bus arrived at the idea to write a library for it?

I mean there is even one for C#!
Are there truely fewer people writing system service in C than there are C# developers on Linux?

Cheers,
_

[SystemCrasher]

Odd indeed. Makes one wonder if Lennard is the only C developer capable of doing what dozends of developers on other languages were able to do or if those otehr C developers with the same skill just liked doing everything manually.

Maybe Poettering got in right place at right time to recognize bus could be fairly useful thing, even in system services. He is quite active user of dbus and I guess he had a lot of pain dealing with existing solutions, this probably prompted him to do a better solution.

Also, C devs tend to understand inner working of computer systems, so they do not have troubles to reinvent the wheel. Though I think it's still generally better to grab one design and improve it 10 times rather than spend same time to get 10 half-baked designs. Yet, sometimes one had to invent new design. If you have got car design, putting efforts to transform it to airplane is a waste. Design from scratch would be better idea. In real world, programmers are plagued by NIH syndrome, which can contribute.

[quote]Even C# had a suitable implementation.[/quite] Hmm, I've been unaware of it. Probably because I do not care about C#.

One possible guess is that C developers just don't like libraries or don't want to make libraries that are useful for other developer.

Wrong. Most C programs are using libs - it makes writing program faster. Yet, it's not mandatory. C is unique. It allows one to have, say, "no runtime at all". Or "no dynamic memory allocation". So one can go write, say, boot loader. Or microcontorller firmware. It going to be predictable. Wouldn't it suck if airbag would fail to deploy when driver needs it most? Because of "out of memory" or "GC kicked in and delayed everything"? General purpose systems are less demanding. Yet, if I write service dealing with external world events, I can't pause world, so it better to be fast and low-latency. That's what makes C a good choice. You can take a look how Java devs are writing games. Then many of them struggle with lag spikes so hard it turns out their best friend suddenly happens to be their worst foe as well. Once you can't get rid of GC, whole program turns onto landmine and you never know where it going to lag. Hopefully it explains why gamedevs demand native code. These grandmasters of programming are using C++, where they can both use high-level features and enjoy by predictability similar to C. It takes a lot to get there, but then they able to make wonders nobody else can.

And, hmm, virtually all libs are written in C, some few are in C++, usually exposing plain C interface which can be hooked up everywhere. So if C devs would really dislike libs... I'm not sure what high level languages would use in this case. Most high level languages aren't exactly good for creating reusable libs, especially ones you can hook to any language.

One example would have been to write a C API for application developers once instead of having every developer write adapter code.

Most C programs are ok with calling libs, unless they seek for something special. E.g. for some simple libs it can be good idea to be "pure math", making no memory allocations or calls to external functions, so they can be hooked virtually anywhere (e.g. in microcontrollers). And something like crypto could be like this. I.e. encryption algo on its own is not supposed to deal with files and it could be okay to preallocate all structures it needs statically. But at the end of day, most C programs are doing lib calls and in best case programmer just writes code to glue things together, like everywhere else. So C considered like "medium level" language or so. E.g. while you can do tricks only available in assembly language as another option, some people like Gnome are clearly turning C into high-level flavor. So it could be kinda different . Somehow, d-bus devs proven to be an exception, doing only lowest level lib which isn't great for use in programs and some high level things which are ok for desktop things, but poorly fit for system services. Sure, those who writes services weren't fond of it. And it probably contributed to situation.

Or do that Lennard did, write a new library from scratch.

And somehow he got a good point in doing so, creating lib which isn't like any pre-existing ones. So it's not even reinventing the wheel. As far as I understand, sd-bus lib can hook to kdbus and use it directly. At the end of day it starting to look like the rest of kernel to usermode interfaces and it seems far more reasonable implementation than what dbus happen to be today. And yeah, I like kernel ways of doing things, so IMHO kernel devs are damn reasonable in their wishes.

One of these approaches was done for all other languages, what makes C developers less cooperative, less inclined to solve a problem once, less motivated to create a solution usable by others?

I do not think it describes things correctly. Probably most devs just got idea they can live without bus. Sure, those who can live without ANY runtime and libs and even use static memory allocation can live without bus. And if we'll assume there would only be libdbus and something glib-based, somene like me would be unhappy with lib interface after looking on libdbus and not in mood to bring all huge dependencies like glib and higher levels take into some small system-level program. And writing own lib takes some efforts. And maintaining it also would take some efforts. So many C devs could consider they're better without bus, because disadvantages it takes can outweigh benefits. But after looking on sd-bus lib I'm getting clear idea it could be useful for me AND it could both come with reasonable dependencies and sane API interface. And somehow, I have reasons to believe if devs care about adoption of their things, they better have to take it into account. But since everybody had chance to write better library... uhm, its wrong to blame d-bus devs alone.

Quite a shame for all the system service developers that it took a desktop developer moving into that space to get some library done, no?

One who writes PID 1 isn't a "desktop developer" . This task is clearly essence of system programming. Though system programming is somewhat vague term and there is further refinement. E.g. programming kernel is somewhat different from writing user-mode programs, even low level ones. And programming microcontroller is somewhat differs from both. But whatever, if one writes something like systemd, its clearly system programmer, who is doomed to know a lot about inner system working and should be able to handle quite a number of rough edges and tricky sequences. Even mere handling of timeout is not as simple as just taking a look on usual wallclocks. What would happen if ntpd comes and adjusts it? Most high-level devs do not care. And even if app I use once a month would eventually backfire, I would swear, but restarting it and so on wouldn't be a major trouble. But if all core services would start backfiring at random, system would turn unreliable and troublesome.

And misteriously no developer on these range of programs either capable or willing to provide such a lib until a GNOME developer came around.

I wouldn't call Poettering a GNOME developer. He is "systemd developer" in first place.

Then, if we take a look on system init things, ideas behind systemd aren't anyhow new. Proprietary unix systems have used similar approaches for a while. Bus isn't a new invention either. Actually, most of cool new inventions are just happen to be carefully rethought things from ancient times. In Linux world, it was upstart who pioneered different approach to system initialization and startup. They also fiddled a bit with dbus. However, they failed to make it comprehensible, design had some nasty shortcomings, and it even failed to persuade most maintainers to switch to upstart from sysv init. This negated many goodies it had and made system administration a mixed, dual-headed experience. But RH6 used it, proving there is strong demand to get rid of sysv init. Somehow, Poettering haven't invented fundamentally new things. But he managed to get all pieces together and get it right. Something that has been miserably failed by his predecessors.

So if we narrow down requirements to "works in Linux" and "lacks glaring shortcomings in design", systemd happens to me nearly the best. Sure, Solaris had SMF for ages. But I do not need Solaris, it does not fits my tasks and vendorlocked to single vendor, and there is virtually no community capable of system programming either, so it not going to change. And then SMF seems to be overgrown enterprise thing coming with XML and database, sync'd with XML, because plain XML parsing is way too slow, so there is database to keep parsed representation, and some things to keep it in sync. No, thanks, I'm really better just changing text configs and using filesystem as fast low level "database" (which it happens to be). Since filesystem is special kind of database, if retrieval of small file takes fundamentally longer, it seems one just have got their filesystem or data formats screwed up so hard they need weird workarounds.

Neither the system bus, nor the session bus, nor the new user bus (as provided by systemd) is tied to any DE.

And if I'll be calling it from things like sd-bus, it is also not tied to crapload of dependencies. Nor it pain to use like libdbus. So from programming point of view I would prefer to see sdbus api getting across systems one way or another. Though I bet systemd/poettering haters would interfere really hardly, just to figure out many programs gone using these apis anyway so they either have to lack many programs or have to reimplement such apis one way or another. One can have some rough preview how it could happen, taking a look on DRM/KMS adoption. Basicaly, BSD zealots yelled it's not needed, WORKSFORME, and so on. Until driver devs just switched to KMS/DRM, declared UMS obsolete and eventually ditched it. Then there was just 2 options left: write GPU drivers on their own, or expose required interfaces. Somehow, while there was some uproar, as we can see, BSDs mostly gone KMS this day. Not sure about Solaris though, since I do not know anyone who uses it as desktop. And at the end of day, DRM/KMS which isn't even xorg-centric on its own is IMHO a noteworthy improvement and attempt to make things at least a bit less chaotic than they used to be. It seems even good and useful inventions can face resistance, and relatively radical changes like Poettering does tend to cause whole hellstorm.

An omission of C based developers not wanting to use desktop oriented libraries.

There is nothing wrong in rejecting unsuitable tools. Just like it isn't best idea to write enterprise CRM in plain C, desktop libs are not suitable for writing low level system level things either. So I do not get why its wrong to reject them. What is really wrong is the fact it took so long for proper tools to appear. And even then sd-bus is only exists on Linux, so there is room to improve.

Yet no C developer wanting to use D-Bus arrived at the idea to write a library for it?

I guess most Java devs are bad in understanding inner working of computers and core/efficient algos, which are actually making computers what they are. So for them it could be major challenge to do something like this. Ask Java dev to write efficient b-tree or hash table implementation, without relying on built-in runtime features. Then ask C dev to do the same. Repeat several times to get idea about probabilities. You see, some people are better at reinventing the wheels .

Are there truely fewer people writing system service in C than there are C# developers on Linux?

Highly unlikely. I do not even have C# in my system. But if I would try to get rid of C code... uhm, there will be nothing to boot and I would end up without OS at all.

[anda_skoa]

And, hmm, virtually all libs are written in C, some few are in C++, usually exposing plain C interface which can be hooked up everywhere. So if C devs would really dislike libs...

Yes, I explicitly wrote "one possibl guess" since I didn't find that likely myself.

So maybe a better guess is that developers of system level software don't like libs or don't like to share work by creating libs useful to others.

There must be a reason why basically every end user application developer, desktop and text console, has had libraries for D-Bus but system program developers did not until a desktop developer move to writing system level software.

Maybe system level developers just care about their own specific thing and do not care to contribute solutions usable by others like normal application developers do.

Again, just a guess, we will never know why developer across several languages sometimes single handedly wrote D-Bus libraries for themselved and others while none of the system developers were willing to do the same (not even for themselves, let alone in a form usable for others).

I do not think it describes things correctly. Probably most devs just got idea they can live without bus.

Sure, it is definitely a contributing factor that a lot of service developers are stuck in the 20th century and don't even know that configuration might need to change during runtime.

And writing own lib takes some efforts. And maintaining it also would take some efforts.

Of course.
But maintaining a shared solution together is often less work than maintaining one's own solution alone.

An investment that application developers seem to be willing to take, but somehow system service developers seem to shy away from.
In the case of D-Bus, likely, as you have pointed out, because they have not arrived in the post-static world yet and did not consider runtime accessibility necessary.

But since everybody had chance to write better library... uhm, its wrong to blame d-bus devs alone.

Exactly.

One who writes PID 1 isn't a "desktop developer"

Lennart was an active FOSS contributor way before he started working on systemd.

I wouldn't call Poettering a GNOME developer.

Well, he does: "I am GNOME" http://0pointer.net/blog/projects/gnome3.html

He is "systemd developer" in first place.

Yes, right now.
Doesn't invalidate all his contributions to the many other projects he has worked on.

What is really wrong is the fact it took so long for proper tools to appear. And even then sd-bus is only exists on Linux, so there is room to improve.

Exactly.
It is stll puzzling me that up until now nobody in the system programming community had enough need to interface with D-Bus to develop a library.

I guess most Java devs are bad in understanding inner working of computers and core/efficient algos

Yet one of them single handedly was able to write proper D-Bus support while none of the system level developers even attempted that before a former desktop developer did it for them.

It doesn't really help if ever person in a group is a low level guru if none of them thinks working together on some common code could be benefitial for everyone.

Highly unlikely. I do not even have C# in my system. But if I would try to get rid of C code... uhm, there will be nothing to boot and I would end up without OS at all.

And yet the D-Bus implementation for C# was one of the early fully custom written ones, available for years before a new member to the system level development community decided it would be nice to have one for their use case as well.

So even if we go with the theory that most system level programmers just didn't see a need for D-Bus, there should have been at least a few and even those few should have been more than the Linux C# community, no?

Cheers,
_

[SystemCrasher]

So maybe a better guess is that developers of system level software don't like libs or don't like to share work by creating libs useful to others.

Since there are plenty of various low level opensource softwares these days, I'm in mood to consider dbus being some unfortunate exception, not norm.

There must be a reason why basically every end user application developer, desktop and text console, has had libraries for D-Bus but system program developers did not until a desktop developer move to writing system level software.

I guess it comes to origins. KDE3 haven't used dbus. They had "DCOP" to do something similar. It was not compatible, basically each DE did what they want. NIH at full swing & DE-only things.

Later, FreeDesktopOrg standards appeared, KDE4 ditched dcop in favor of dbus, some services adopted dbus and it started to make sense as something more generic, not just "part of Gnome desktop". I guess the fact dbus appeared as DE feature hindered it adoption at lower levels. If I do not write Gnome application, I do not want Gnome Desktop Bus, obviously. That's how stereotypes appear. And it's also about infamous "rampant layering violation". The whole point of kdbus is to fix layering violation. On it's own bus haves no reasons to be "desktop" bus. IMHO it makes more sense to have "system bus" as universal system wide facility.

Maybe system level developers just care about their own specific thing and do not care to contribute solutions usable by others like normal application developers do.

Apps are usually not reusable on their own. Because they are not libs. Only few apps bother self to expose external apis. Not to mention it could be odd to call app instead of lib/framework. However, when it comes to buses, these are somewhat unique: I see there're some valid cases to do so, even for applications. Basically, when using bus you just do not care who exposed some stuff, was it low level service or app. So it is possible to replace various parts in flexible ways, hooking part which works best in particular scenario. I think this is quite an improvement.

Again, just a guess, we will never know why developer across several languages sometimes single handedly wrote D-Bus libraries for themselved and others while none of the system developers were willing to do the same (not even for themselves, let alone in a form usable for others).

I guess they were doing more "desktop" things so they cared more about it, while low level devs got stereotype it is DESKTOP bus, so they are out. They are not coding DESKTOP apps...

Sure, it is definitely a contributing factor that a lot of service developers are stuck in the 20th century and don't even know that configuration might need to change during runtime.

I would somewhat agree on that. Some oldschool devs got stuck with really ancient use cases, they fail to get idea these days you can easily grab couple of computers, put them into pocket and move them to another location. Facing unique challenges, like "airplane mode", "battery low" (and just "battery mode"), rapidly changing network connectivity, etc.

But there is dark side of the moon. If program can be reconfigured during run time... on other hand it makes things more complicated. There is more code. Program grows larger, runs slower, takes a plenty of memory, wastes more power. Then, more code means more bugs. Program starts to randomly crash/misbehave. And there is plenty of security issues. Also, oldschool gurus also usually better in code quality, so if they are doing simple and easy programs, these also tend to be rock-solid. Good luck to hack djbdns or qmail, even if they're in "unsafe" C. Most break-ins happen via web apps, even if they are using "safe" languages. And e.g. Mozilla devs managed to create impressive uber-critical 0day in their "secure" PDF viewer by using just sandboxed JS. While actually trying to make security even better, which is really ironic. It seems making things more complicated does not makes security better on its own, it rather just increases attack surface.

But maintaining a shared solution together is often less work than maintaining one's own solution alone.

That's why opensource is here. And as I can see, it works on all levels. There is already some open hardware, open boot loaders, open kernels, open c libraries, open compilers, and ... uhm, well, everything. Up to open CRMs and so on.

An investment that application developers seem to be willing to take, but somehow system service developers seem to shy away from.

Application devs are rarely writting libs. They are writing apps. That's why they are app devs in first place . Else we would call 'em lib devs, or something.

In the case of D-Bus, likely, as you have pointed out, because they have not arrived in the post-static world yet and did not consider runtime accessibility necessary.

I guess it partially contributed as well, system bus can clearly help a lot when you deal with dynamic, changing world. And since computers are used here and there, we better to accept world as it is, rather than try to dumb it down to narrow 80s-90s use cases. Yet, some oldschoolers could be stubborn enough :P.

Lennart was an active FOSS contributor way before he started working on systemd.

And it seems this allowed him to take a look on various things at different angles. So he can actually take best from several worlds. What a sneaky guy. But whatever, if he can code pid #1, it takes a deep knowledge of system internals. So he is a system programmer any day.

And you see, he knows Linux good enough to use its unique features. Like cgroups. I guess many admins got fed up looking on all these processes attributed to PID=1, even if init never started them. It is bad when you can't get idea what's going on and why. And somehow, there is no standard way to track process origins. By doing things like two fork()'s one can completely lose track of its starting PPID, so PID=1 is assigned as parent of process. Even if init never started this process. Somehow, it has been ignored for years. Isn't it a shame everyone except Poettering were running from challenging tasks for so many years like scaredy cats, considering this "okay"? Clearly, sometimes it is time to revist some things and reconsider how it should happen.

Well, he does: "I am GNOME"

And Linus Torvalds coded some GTK app for divers. Is he a GTK+ apps dev? Maybe. But we know him better for different things like writing Linux kernel and being epic project manager of his kernel team. And so, I do know Poettering as systemd dev and PulseAudio creator. Also sd-bus lib. These are low- or mid-level things, and system software.

Doesn't invalidate all his contributions to the many other projects he has worked on.

Right, but he clearly did his best in systemd and pulse audio. So I would consider him system programmer rather than anything else. Programmers can posess many skills, C is versatile thing as well. So it can easily happen someone writes microcontroller firmware in C, to get data from some sensor. And then writes PC side program using GTK+, to get these data into their PC. Listing everything what skilled programmer can do could be time consuming. So I would somewhat simplify it and only name most noteworthy skills and achievements.

Why systemd is noteworthy? It changed ways we are managing our systems and solved plenty of long standing challenges. Why pulseaudio is noteworthy? It allows to do what has been hard or painful to do before it. Creating far more advanced sound configurations. Take a look on what Nokia did in their Linux devices, like N900, etc. Out of all classic Linux things, only PulseAudio can handle configuration where you have loudspeakers and earphone, as well as you can have bluetooth handsfree or user can attach headphones. And music player supposed to have different volume setting than ringtone, and player is better to shut up when there is incoming call. And good luck to handle it witout pulseaudio.... sure, some entirely new things like Android can do it on their own. But more classic Linux stack would struggle really hard to do something like this without pulse audio. Somehow, as we can see, even usual Linux can do it. If you manage to get it right. And so, who yells pulse audio is not needed? Those nuts who uses computers like if it is 90s. And failing to get idea smartphone is also a computer. Beating my 10 years desktop to the dust. And it is clearly one of use cases for Linux. In fact, quite a major use case

It is stll puzzling me that up until now nobody in the system programming community had enough need to interface with D-Bus to develop a library.

I guess part of puzzle is the fact it has been advertised as "desktop" bus initially.

Yet one of them single handedly was able to write proper D-Bus support while none of the system level developers even attempted that before a former desktop developer did it for them.

Uhm, Linus coded whole kernel singlehanded, in first place. Then others joined and whole development process turned into a real powerhouse. Showing these greedy proprietary corps how to do it right . But it does not means everyone can do the same. It takes some unique set of skills and talents to get there. Sure, almost every CS student can write simlpe task switcher, eventually capable turning into OS kernel, if they are going to spend more efforts on it. But only few humans on the whole planet can turn crappy task switcher into epic project which drastically reshaping future. One have to be lucky and do it right, at right time and space. And then somehow manage not to screw it up. In fact Torvalds can easily happen to be best project manager in the world. And in fact there is no need to challenge that. It is better to try various things and get idea what you like, so you can be at least well above average in doing so.

It doesn't really help if ever person in a group is a low level guru if none of them thinks working together on some common code could be benefitial for everyone.

Actually, building a working team is very tricky process, and just bringing bunch of gurus together could FAIL. That's what played a bad joke on so many proprietary companies, who thought it is enough to hire best programmers around. But in case of opensource, it happens in native way. People are chewing together on some tasks they pick up for fun and profit and they join projects because they like it and/or because they are interested in outcome of these efforts.

So even if we go with the theory that most system level programmers just didn't see a need for D-Bus, there should have been at least a few and even those few should have been more than the Linux C# community, no?

Well, I'm not really sure about it. C# is not suitable for low level things, so C# devs are doomed to implement higher level things. So they inherently had more reasons to care about "desktop" buses. And in system level things you usually do not want anything "desktop" related at all. To get better idea: take a look: Poettering cares about being "OOM safe" (as well as libdbus). Otoh most apps devs do not care about such things. Except everything else, their code is far less reliable and would usually crash or backfire on slightest deviations from ideal scenario. So high level things are usually fragile and bugged. OTOH system components are supposed to be diehard and stable things, staying alive and doing their tasks no matter what.

[anda_skoa]

I guess the fact dbus appeared as DE feature hindered it adoption at lower levels. If I do not write Gnome application, I do not want Gnome Desktop Bus, obviously.

But it was never the "Gnome Desktop Bus". GNOME used CORBA before.

On it's own bus haves no reasons to be "desktop" bus. IMHO it makes more sense to have "system bus" as universal system wide facility.

There is more than one bus.
The system bus already is a universal system wide facility. It is started by init as part of the system startup, way before any desktop related things are launched. It even got "system" as it bus name!

How anyone can arrive at the conclusion that it is for desktop is beyond my me.

Apps are usually not reusable on their own. Because they are not libs. Only few apps bother self to expose external apis. Not to mention it could be odd to call app instead of lib/framework.

Yes and that is not what I meant.
Applications often share common needs and while each application developer could reimplement the necessary functionality over and over again on their own, they usually tend to create libraries for that.
But as we've discovered that seems to be more pervasive with developers of user facing applications, system level developers seem to prefer to reimplement instead of sharing.

However, when it comes to buses, these are somewhat unique: I see there're some valid cases to do so, even for applications. Basically, when using bus you just do not care who exposed some stuff, was it low level service or app. So it is possible to replace various parts in flexible ways, hooking part which works best in particular scenario. I think this is quite an improvement.

Exactly!
When DCOP was introduced at KDE that almost instantly "exploded" the whole application cooperation ecosystem. This tremendous success then triggered the idea to broaden that with a more generic solution: D-Bus.
More generic in several ways: more transport neutral so that it was not tied to X11, usable from many languages, and, additional to the bus for desktop applications, a bus for communication with and between system services.

I guess they were doing more "desktop" things so they cared more about it, while low level devs got stereotype it is DESKTOP bus, so they are out. They are not coding DESKTOP apps...

That looks to have happend, but I am still puzzled as to why.
All indicators, e.g. the bus name, the way it is provided, etc., they all make it pretty obvious that it is a system feature, not related to DESKTOP at all.
One would assume that a developer creating system software would recognize system software, but apparently they don't.

I would somewhat agree on that. Some oldschool devs got stuck with really ancient use cases, they fail to get idea these days you can easily grab couple of computers, put them into pocket and move them to another location. Facing unique challenges, like "airplane mode", "battery low" (and just "battery mode"), rapidly changing network connectivity, etc.

Yepp, exactly!

But there is dark side of the moon. If program can be reconfigured during run time... on other hand it makes things more complicated.

Right, but an evolving world requires software to evolve, even if that means more complexity.
No point in becoming obsolete just because "it used to work" hinders the willingness to change.

Application devs are rarely writting libs. They are writing apps. That's why they are app devs in first place . Else we would call 'em lib devs, or something.

Hmm, it might depend on the size of the community they are working within.
More isolated developers might indeed not work on any libs, but developers associated with larger communities often do.

Maybe that is the deciding factor: if you only have one product there is less incentive to make part of the code reusable, but if you have more, even if not much related, there will always be something to share.

Cheers,
_

[SystemCrasher]

But it was never the "Gnome Desktop Bus". GNOME used CORBA before.

Formally its true, but Gnome2 and KDE3 were coexisting at roughly same timeframe. Gnome2 used dbus, kde3 used DCOP. I'm not great at "archeology" and only used Gnome2 and KDE3, missing earlier versions. From what I've seen, Gnome 2 has been the only major dbus user around. Over time, dbus got used by some components, most notably, NetworkManager. Which isn't what I would call low level, but its service isn't very high level either. But still, NM usually seen on desktop systems, even if it could work for some server setups. Somehow, when kde4 has been developed they decided to go for dbus and XFCE followed same direction. Yet, except few medium-level servces mostly targeting DEs, like polkit and NM I can't readily remember services using buses. And in fact dbus as more or less clear winner has settled only after kde4 has arrived, where devs finally managed to settle down on something common and some specs appeared, like freedesktop notifications and somesuch. That's where it more or less took its shape but still looked biased towards DEs rather than anything else. E.g. there was (and still) quite few reasons to use dbus on, say, server.

There is more than one bus.
The system bus already is a universal system wide facility. It is started by init as part of the system startup

That's not how you become REAL system bus. First, dbus is fairly optional even in case of systemd. Real system bus supposed to be "almost mandatory" like procfs or sysfs except smallest emdedded systems where code size is paramount. This implies very narrow set of dependencies, requirements about high reliability and so on. Second, there're very few programs which make sense e.g. on server or in embedded which are actually using dbus. Third, I think kernel should both be able to use it and probably have to be entity who brings it up, though maybe on request from usermode, like it happens to procfs.

If you ever seen things like ioctl() you can get it isn't exactly best usermode to kernel API. E.g. you can issue any IOCTL. But you have no idea if someone implements certain ioctl and what it expects as arguments. At most you can get idea call has failed. There is no good way to list available ioctls. To degree nobody can document their complete list. LOL. Nor you can easily get idea of proper call prtotype. That's where kernel devs may want to rethink stuff in their own domain and seriously reconsider some ways of doing things. Bus solves most of these issues, dammit. Though it subject to more overhead/latency, but still, I bet there is plenty room for improvement.

Furthermore, I think it would be logical if it would be kernel itself who informs user mode about some particular system wide changes or responds to requests leading to system wide changes. That's what I would expect from REAL system bus.

way before any desktop related things are launched. It even got "system" as it bus name!

And somehow this name is somewhat misleading. It gives rough idea what it supposed to be, but actual implementation is hard to be called like this.

How anyone can arrive at the conclusion that it is for desktop is beyond my me.

If you need a screwdriver, you do not look in the box full of hammers and it rather surprising when you figure out there was good screwdriver. I'm not going to use glib in system stuff. And libdbus isn't really appealing unless you're up for creating toolkit on top of it. Which is neither part of my plan, nor a most common way to use lib in program. Poettering seen both worlds and so he can take best of both, being able to show neat tricks to both system devs and app devs, this is relatively uncommon .

Applications often share common needs and while each application developer could reimplement the necessary functionality over and over again on their own, they usually tend to create libraries for that.

Imho it is debatable. For me it seems writing libs happens to be somewhat special kind of expertise. E.g. I can't readily tell which apps zlib authors wrote, same goes for libpng. Yet these are exceptionally widespread libs. Deflate is easily most common data compression format in the world, you can encounter it virtually everywhere. Most *nix programs doing something with images would also use libpng one way or another. Maybe what you told is more true for UI libs and somesuch though. It seems terms "library" is too generic and serves as umbrella for many subflavours of libs, which could be quite different as well. I'm ok about calling zlib from low level system stuff. But not ok about calling parts of Qt. They are way too different.

But as we've discovered that seems to be more pervasive with developers of user facing applications, system level developers seem to prefer to reimplement instead of sharing.

TBH I would consider overall code reuse around opensource ecosystem quite good. Even Linux kernel got some libs to reduce code redundancy. It can even expose some sensible parts to user-mode. E.g. it implements plenty of compression/encryption/CRC/hashing algos. These implementations are usually high-quality (kernel mode is unforgiving) and fast (it tends to be heavily used and slow kernels are bad). So user mode things could sometimes want to use it as well.

And overall, C could be relatively high level. How about writing, say, PNG file in just couple lines? Just include lodepng.h "library" (which is not even library in usual sense). And boom, you can dump array of pixels as png file, in 2-4 code lines. Doesn't sounds low level, eh? That's what one can get if they're ok with code reuse.

When DCOP was introduced at KDE that almost instantly "exploded" the whole application cooperation ecosystem.

...but only in KDE, and dbus has been like this but on Gnome side. Probably that's why quite many people considered dbus to be desktop-bus, mostly meant for gnome's internal needs rather than something else. And to me it seems dbus devs weren't too eager to address needs of people beyond DEs, otherwise they would likely expose their creation via something similar to sd-bus.

This tremendous success then triggered the idea to broaden that with a more generic solution: D-Bus.

From what I remember, dbus and dcop coexisted in Gnome 2 and KDE 3 more or less at the very same time. Then dbus got some use in things like NM and KDE devs were probably in mood to use NM, since it looks appealing for desktop usage scenarios. Just try to scan wi-fi APs around and connect WPA2-protected AP without using NM to get idea why it so appealing .

More generic in several ways: more transport neutral so that it was not tied to X11, usable from many languages, and, additional to the bus for desktop applications, a bus for communication with and between system services.

And overall idea is not bad. But it seems there could be next phase, bus can be further "un-desktopified", etc :P. So it can be much faster, usable on all levels and not coming with plenty of dependencies or pain in the rear as the only choices of programming it. And I guess there is no even need for separate daemon managing bus. This looks like a hack or so.

All indicators, e.g. the bus name, the way it is provided, etc., they all make it pretty obvious that it is a system feature, not related to DESKTOP at all.

Still, overall design is quite bloated, not really convenient for lower levels and also exposes low performance - you may want to read LKML to get idea. Interestingly, context switches aren't most pressing issue for dbus, it spends most time in its own code. So just going kernel without changing rest of design a lot just going to be really unrewarding thing. If you need for speed, you take a look around and getting idea what slows you down most. And trying to axe it out. Kernel is in right place to do many bus related things, but in terms of performance, dbus devs reasoning has been way below the floor. That's what they've been told in LKML. And K-H is wise & oldschool enough to get idea it's not so untrue and there is valid point. I guess that's why he is back to drawing board. There also seems to be entirely new "bus one" thing which is "system experiment" at this point but may eventually grow up to some serious system bus, being redesigned from scratch in more sane ways.

One would assume that a developer creating system software would recognize system software, but apparently they don't.

Because it does not looks like a system software. It is not enough to aggressively pretend you're system software. You have to actually be system software to get recognized as such. This implies certain design decisions and engineering patterns, certain properties, etc. Which are missing in dbus to the date. At most, dbus is half-way there.

Right, but an evolving world requires software to evolve, even if that means more complexity.

Real gurus are those who can implement "complex" things as simple as possible (but not more simple than that). This ensures it going to be enjoyable, fast, relatively bug-free design. Those who throw in extra complexity for no good reasons are just incompetent (or noobs).

Take a look on openssl. Horrible api, many vulns, nearly impossible to get it right due to way too much options, legacy code, overcomplicated protocol, and many combinations are just totally insecure. And you have to be expert in crypto to understand it. Huge code, so big it is nearly impossible to audit. Configuring options in secure way is rocket science. Furthermore, you never know what your peer on other side of wire can do. When one establish TLS connection in their app, do they have even slightest idea which CAs are trusted at this moment? And hence who can intercept connection at will. Not to mention it slow and very hard to get it actually secure.

And now take a look on tweetnacl lib from DJB and overall NaCl api to get idea how you can do same things in drastically different ways. Very best of modern crypto in mere 100 tweets? I've even chopped it down to half and now I have decent public key crypto even on my microcontrollers. Yes, stripped down version fits mere 3.5Kb of ARM code. Simplest uC I have comes with 16Kb, so I have 12.5Kb left for other code, which is not bad. And it costs less than dollar. And it also like RSA-2048 in terms of security but much faster, much smaller code, and best of all: reasonable API where you have no place to shoot your own legs. No legacy insecure options. Trivial usage. There is no room for fail. And so even small microcontroller reading sensor can now throw data to the air in well protected fashion, without rogue hackers being able to dump data or overtake control. Of course it rocks on larger PCs as well, being a really good for network crypto. You do not even have to start session in some cases. And public keys are short enough to be sent over SMS or written on piece of paper. Not something RSA-2048 can afford .

No point in becoming obsolete just because "it used to work" hinders the willingness to change.

Yet, no point of breaking working things either. "Becoming obsolete" is relative term. Appearance of airplanes haven't made trains or cars obsolete. It just some new, different option with completely different tradeoffs. Flying DeLorean can be cool, but at current level of techs it fails to be practical. You can bolt jet engines to the car, and probably can get it aroborne, but... we lack Mr. Fusion part yet. So it going to be noisy and fuel-hungry. Being very expensive to maintain and impractical. It works the very same way in software engineering as well. Dbus lacks their Mr.Fusion part, which would make flights affordable. Yet.

Hmm, it might depend on the size of the community they are working within.
More isolated developers might indeed not work on any libs, but developers associated with larger communities often do.

Yet, isolated devs have compelling reasons to use libs: their resources are utterly limited. Code reuse alows to achieve goals faster. In fact, by using libs you can get things done fast even in C, making it similar to high-level languages. Yet, lack of care about dependencies would bring all disadvantages of high level languages: large, poorly predictable code base, which falls apart on any occasion, exposes plenty of bugs, misbehaves and puts limits on how one does various things. Yes, you can write awful bloatware in C, even if it takes more efforts.

As for libs, code reuse in turn warmly welcomes to be less isolated: world is really better if you can get upstream hearing you and aware your ways of using their code. Overall, it seems open processes are spinning up and taking over the world. I think it just right thing to do. Speaking for myself, I fail to see bright future of proprietary software.

Maybe that is the deciding factor: if you only have one product there is less incentive to make part of the code reusable, but if you have more, even if not much related, there will always be something to share.

MAYBE some devs are like this. But I do think it is wrong. Speaking for myself, now I can assemble custom, task specific devices doing fairly complicated things. Even singlehanded. In very reasonable timeframes. Linux and software around it made it possible, giving whole new degree of freedom. And it would be stupid and shortsighted to disregard upstreams. Its their work what allows to fly high. That's where it happens to be some room for cooperation. Even hardcore competitors can have some common needs, so even competing companies collaborating on things like Linux kernel. They wouldn't get far without good OS kernel. Whatever, world is much better this way.