| |||||||||||||
The case for the /usr mergeThe case for the /usr mergePosted Jan 27, 2012 23:59 UTC (Fri) by gb (subscriber, #58328)In reply to: The case for the /usr merge by misc Parent article: The case for the /usr merge
Network manager and dbus guys: One of aspects of this tools that they keep integrating into my favorite applications. In 2005, my mail application didn't need a 'X session' and export $(dbus-launch) and somehow worked in ssh -X session. It also didn't need to know about network manager connection state which magically wrong too often.
dbus: My ideal were fine systems without "system wide message bus" and related program interdepedency (now all programs are on single bus which one need other? who knows... you mailer doesn't work? check network-manager!). I am not a big specialist in it, but it seems that d-bus has very limited applicability (low-bandwidth transfers), but seem used as panacea everywhere. Dbus services seem special harm. I need to learn it othervise it would be security concern (something starts somewhere at random time - is it really so nice?). As i see it, system should have single point for starting services, not separate init.d and some black d-box.
Of course 'not upgrading' is never an option because i want and must have new features of rest of system - support for new hardware, new editors, new secutiry updates, new architectures, new videos, new internet browsers. Once i saw in openmoko list hardcore guy who really not upgrading, and using some VAX system with original software, his problems with ftp were nice example of 'non-upgrade' path.
(Log in to post comments)
The case for the /usr merge Posted Jan 28, 2012 0:34 UTC (Sat) by Kit (guest, #55925) [Link]
Applications adding stupid restrictions/requirements is the application's fault. Applications have been doing stupid things based on what they ASSUME is the state of the network since long before Network Manager (and really, a NM like service is the only reasonable solution for any mobile system).
>As i see it, system should have single point for starting services,
So now you're wanting systemd? The old init systems are most certainly not capable of that!
>Dbus services seem special harm. I need to learn it othervise it would
>I am not a big specialist in it, but it seems that d-bus has very
The case for the /usr merge Posted Jan 29, 2012 11:44 UTC (Sun) by k8to (subscriber, #15413) [Link]
Like it or not, the common programming patterns and libraries around dbus are pretty fragile. It's very common for dbus programs to fail to operate correctly if dbus isn't already running when they start up. It's common for them to fail to establish communication with launched subprocesses.
Essentially, the filesystem, pipes, sockets are pretty safe to assume to be always present, and you can develop against them without fear (though please handle the errors). With dbus, you have to handle a number of additional cases, and it seems more difficult than real programmers are going to do in reality.
For that problem alone, I question the value of having dbus at all.
Then there are the security concerns.. but that's the topic for another day.
The case for the /usr merge Posted Jan 29, 2012 21:48 UTC (Sun) by paulj (subscriber, #341) [Link]
A good example of fragile DBus programming patterns is systemd. Guess what happens if early boot goes wrong (e.g. cryptsetup fails on some not-very-important filesystem) and you get dumped to a rescue shell and you try use systemctl? A nice "Can't connect to message-bus" type of error.
Why on earth is systemctl not talking *directly* to systemd??
The case for the /usr merge Posted Jan 30, 2012 0:11 UTC (Mon) by mezcalero (subscriber, #45103) [Link]
This is simply not true. systemd speaks the D-Bus protocol without relying on the D-Bus daemon. One of the nice things about systemd is that is is fully introspectable even if the only processes running are systemd itself and a bash. For example, boot into emergency mode by passing "emergency" on the kernel cmdline, and you'll see that "systemctl" works just fine even though no processes between PID 1 and bash are around.
Don't spread obvious falsehoods, please!
The case for the /usr merge Posted Jan 30, 2012 1:35 UTC (Mon) by slashdot (guest, #22014) [Link]
paulj seemed to speak from experience though, so maybe (some past version of?) systemctl first tries to talk via dbus, but doesn't always properly fallback to direct communication when that fails?
The case for the /usr merge Posted Jan 30, 2012 12:20 UTC (Mon) by paulj (subscriber, #341) [Link]
Systemctl gives DBus connection errors in certain situations. And, other than to those quite familiar with systemd, it's NOT an obvious falsehood. I know you get a lot of uncalled-for personal crap from snipers, but does it help for you to respond to other people in a bordering-on-insulting fashion?
Here's what I was going by:
https://picasaweb.google.com/114169232705420738100/System...
I'm not sure, but there's probably some combination of a couple of silly little bugs here:
a) If emergency mode had root mounted RO (I'm not sure if that happened at shutdown or at beginning of emergency mode): Going to emergency mode with root RO when some ancillary fs has failed to mount (I don't remember what old initscripts did, but I think they first mounted / RW before mounting rest?)
b) Shutdown having become fragile in the face of a RO /. I've had old init + initscripts in a similar situation, & services would fail to stop, but init would eventually reboot anyway. A fragile reboot can be a huge problem if you're remote and have no physical access to the power/reset buttons.
c) A slightly misleading or confusing error message from systemctl.
d) Unrelated to my original post, but also evident in those photos: Parallel jobs stomp over the tty with output. Particularly confusing if you've missed the fact you're supposed to type in a passphrase. (This possibly isn't a little bug, in terms of fixing it).
Bugs, which will be fixed no doubt, I'm sure. Also, just because a messenger doesn't have a perfectly set-out message, doesn't mean the messenger should then be shot.
The case for the /usr merge Posted Jan 30, 2012 16:55 UTC (Mon) by michich (subscriber, #17902) [Link]
If you can find a sequence of steps to reproduce the problem reliably, please file a bug in Bugzilla.
But... the second screenshot shows 2.6.34.7-66.fc13. Are you really running Fedora 16 on a kernel from Fedora 13?
The case for the /usr merge Posted Jan 29, 2012 21:24 UTC (Sun) by speedster1 (subscriber, #8143) [Link]
> Of course 'not upgrading' is never an option because i want and must have new features of rest of system - support for new hardware, new editors, new secutiry updates, new architectures, new videos, new internet browsers.
It sounds like you are not using one of the Linux distributions best suited to your needs. Distributions such as debian and gentoo are well suited for an experienced user, such as yourself, who does not want to trade extra integration and automation for additional complexity. With one of those more flexible distros, it is easy to set up a useful desktop system without gconf, network manager or dbus, and without getting stuck on old versions of software. At this moment, I happen to be doing a gentoo install without any of those packages.
|
|||||||||||||