Distribution-friendly tactics in the desktop wars
Distribution-friendly tactics in the desktop wars
Posted Apr 10, 2016 3:22 UTC (Sun) by flussence (guest, #85566)In reply to: Distribution-friendly tactics in the desktop wars by hitmark
Parent article: Distribution-friendly tactics in the desktop wars
There's no garbage collector for projects that get ejected from the “ooh shiny” rewrite treadmill; they accumulate like radioactive waste as dependencies of other code. If you're lucky the new shiny will be backwards-compatible ad infinitum, or even coexist side-by-side with the old stinky, and you only suffer the standard costs that a total rewrite from scratch always inflicts.
But sometimes you get unlucky and RedHat decides You Will Use ude^Wsystemd-udevd now, not HAL, and all those DRMed movies you bought online no longer work. (What, people *used* our old stinky library? How dare they! systemd-udevd has always been a critical part of every distro's boot, how else are they going to load bus1.ko when it's needed by PID1?)
To drag this tangent back in a more topical direction: I predict that Qt4-libQt3support.so will outlive $kde5¹-kdelibs4support on most distros.
¹ -- shorthand for whatever KDE3+2 currently identifies as.
Posted Apr 11, 2016 14:29 UTC (Mon)
by tao (subscriber, #17563)
[Link] (7 responses)
Face it, sometimes it takes multiple iterations to come upon a good solution.
systemd (combined with udev), by the looks of it, is that good solution.
Posted Apr 12, 2016 2:25 UTC (Tue)
by hitmark (guest, #34609)
[Link] (6 responses)
Note that at the kernel level, there is a whole lot of fretting about getting the interface right. Because Torvalds will hold everyone to maintaining that interface once it had been ntroduced to the world.
By contrast, logind didn't carry over the consolekit interface. Instead the consolekit2 devs are busy chasing the logind tail by trying to maintain interface compatibility.
This while at its most basic level, X11 still behaves at it did when released. If you wrote a straight xlib back then, it would likely still work today.
Posted Apr 12, 2016 12:33 UTC (Tue)
by tao (subscriber, #17563)
[Link] (5 responses)
Posted Apr 12, 2016 16:27 UTC (Tue)
by hitmark (guest, #34609)
[Link]
And consolekit2 is not on top of anything. It is a fork of the consolekit code that tries to offer an alternative implementation of the logind dbus interface alongside the consolekit interface.
Posted Apr 12, 2016 20:55 UTC (Tue)
by dlang (guest, #313)
[Link] (3 responses)
but will this really matter if everyone runs an X server on top of Wayland so that they can continue to run apps that don't choose to lock themselves to Wayland?
Posted Apr 12, 2016 21:00 UTC (Tue)
by rahulsundaram (subscriber, #21946)
[Link] (2 responses)
Applications themselves typically don't care about whether they are running or top of X or Wayland or XWayland.
Posted Apr 12, 2016 22:16 UTC (Tue)
by dlang (guest, #313)
[Link] (1 responses)
that depends entirely on the graphics calls they make. If they use some library that abstracts it away, then they may not care (unless they were statically linked with the X version of the library), but if they use something that doesn't jump on the fad to re-write all graphics stuff, it very definitely cares.
Posted Apr 12, 2016 23:05 UTC (Tue)
by rahulsundaram (subscriber, #21946)
[Link]
Umm, that's what typically means here.
Distribution-friendly tactics in the desktop wars
Distribution-friendly tactics in the desktop wars
Distribution-friendly tactics in the desktop wars
Distribution-friendly tactics in the desktop wars
Distribution-friendly tactics in the desktop wars
Distribution-friendly tactics in the desktop wars
Distribution-friendly tactics in the desktop wars
Distribution-friendly tactics in the desktop wars