Comment by AceJohnny2 | Hacker News Reader

Comment by AceJohnny2 | Hacker News Reader

I've been having similar issues and thoughts. I'm not a greybeard by any reasonable measure, having started using Slackware in '99-'00, quickly switched to Debian, and never looked back.

I think it all stems from D-Bus, which has become the primary mechanism of command and control on desktop Linux. To address the OP's initial issue of user mounting disks, it's managed via Udisks, which is mostly accessible via D-Bus.

I have trouble reconciling Unix's notion of "everything is a file" and how a modern Linux desktop operates via D-Bus. Don't get me wrong, I think D-Bus very powerful and flexible. I just wish it was easier to explore and test via file-based tools. Maybe a FUSE layer?

Anyhow, if the OP thinks that Linux was once "clean, logical, well put-together, and organized", I can only laugh at his rose-colored glasses. Linux is and always was a cobbled-together mess of orthogonal paradigms (no better illustrated than by the design philosophy clash of XWindows vs Unix). Maybe earlier Linux was simpler because it was still playing catch-up with other Unix clones out there. Nowadays it's leading the pack in innovation, and so things are changing, and fast. I don't know if documentation really is worse now that it used to be, I'm afraid to fall in the same nostalgia fallacy.

Ultimately, I see this rant as nothing other than "things are different now and I'm scared and confused". Not that I don't sympathize, being in roughly the same place. However, I decided I can't stop technology, and sucked it up and sharpened my google-fu.

Yep. D-Bus feels, honestly, like someone looked at every RPC mechanism ever invented and decided to pile all their bad parts into one thing. It's not discoverable, it has a frustrating permission system, its interface definition is incredibly verbose with a very low information density, etc.

Of course, the fact that you need a full DE to easily mount a usb stick as a non-privileged user means the whole thing is already failing hard. This is not how this should work.

You can just use udiskie (https://pypi.python.org/pypi/udiskie) to automatically mount exernal drives, even if you're not running a DE.

> Of course, the fact that you need a full DE to easily mount a usb stick as a non-privileged user means the whole thing is already failing hard. This is not how this should work.

This is not true. I use udiskctl (and thus the udisks2-polkit-dbus based machinery) to mount pendrives in a vty on a regular basis.

As a bonus, it asks for my password (the user one, not the root one) if i'm in an ssh terminal instead of a vty, and by configuring polkit i can have it allow me (only this particular user) to put a certain HDD to sleep (and no other actions like giving rights on the block device would do) without root password.

As best i understand, dbus came about as an attempt at making the KDE only dcop into something that could be used across DEs. This to improve interoperability between them.

dcop worked beautifully; the only problem was that the gnome team had religious objections to depending on C++. It was never intended to be a system-level thing though, and that's where a lot of the problems come from; within a desktop session dbus actually works pretty well.

> Yep. D-Bus feels, honestly, like someone looked at every RPC mechanism ever invented and decided to pile all their bad parts into one thing.

You must have mixed up D-Bus with CORBA.

> It's not discoverable

Try installing "d-feet", it's a nice GUI that will show you everything that's listening on the bus and what objects and interfaces it supports.

File-based tools is an interesting question. D-Bus is hierarchical, but it's also strongly typed, so you'd have to encode stuff as text, and when you get the serialization wrong, write(2) can't give you a useful error message. But maybe it'd be useful for reading and monitoring.... imagine if you could `sudo tail -f /dbus/org/freedesktop/UDisks2/Manager` or something, and see all calls to it.

I've been using D-Feet and dbus-monitor, which seem to be solid enough. D-Bus does have extensive introspection.

But yeah, in general the state of D-Bus tooling is miserable. Part of it is how verbose it is — which is fine for compiled software, but for interactive use, it really makes you miss the "creat" and "umount" school of thought. Part of it is that there aren't great introspection tools at the command line.

The only D-Bus tool that is nice in the command line is qdbus, and that stems from Qt. I wonder why the original D-Bus writers could not write a decent enough command line tool for it.

Try mdbus2 - https://github.com/freesmartphone/mdbus - it's also in Debian/Ubuntu repos.

It's a little tool that works really well with dbus services that properly implement introspection. We used it extensively on Openmoko phones to play with our middleware (or when GUI was broken ;) )

Has commandline completion and history! This is nice. Thanks, will give this a try. :-)

Thanks. It's quite qood. Handy.

Debiam lost its way. Bugfixes get burried into political bullshit far too frequently. I have issues with Ubuntu but I dont have the time or the patience to support the crap reasons why they for instance keep an outdated intel driver in their distrib ("the serial number of the new one does not look like a stable release". Nevermind that it solves many bugs) or decide that mounting a USB drive is a privileged operation.

I may try Arch, I heard a lot of good from it, but from people who have more time on their hands than me. Right now it is Ubuntu for me and it is working fairly well.

I found Arch to be surprisingly untime-consuming. I was expecting more of a Gentoo-like experience, but it tends to just stay out of the way for me.

I started using Arch after a new built computer couldn't install using an ubuntu disk. After the initial setup work (~ 1 hour as I wasn't familiar with it, though the documentation is great[0]) everything Just Worked™ and I've installed it on every system since.

I've had the occasional small technical hitch but the forums[1] are some of the most helpful I've found and that in combination with the standard google-fu/stack exchange approach has made quick work of any bugs I've had.

My favourite thing about Arch however is the AUR[2] which makes installing any small command line tool that you just heard of (on hacker news) as effortless as installing a supported package, even though they're unsupported (officially) they most often work and I rarely find something that doesn't already have an AUR package to build it.

N.B. if anyone wonders, the only other distros I've played around with are ubuntu, debian, and open suse (and I've actually liked them all). So I don't have too much comparison.

[0] https://wiki.archlinux.org/index.php/beginners%27_guide

[1] https://bbs.archlinux.org/

[2] https://aur.archlinux.org/

> Debian lost its way. Bugfixes get burried into political bullshit far too frequently.

You know, that's funny. Debian has neven been as pragmatic and apolitical as it's now. Bugfixes never had so little red tape. And yes, they often get lost in political discussion; it's just your memories that are too rose-colored.

(By the way, I'm a happy Debian user. Wouldn't switch to any other main distro, altough a few niche ones look promissing.)

Haha! Man, you've never been happy with any Linux distro, or even OS for that matter! (and no, your usual answer is wrong; if you have a problem with everything else, maybe the problem isn't with everything else).

I'm surprised about your issue with the Intel driver, which I've found to be quite stable on Linux, but then I don't do any 3D in Linux. Is this on your System76 laptop? As for mounting a USB drive, that's patently false, see my comment above. Nowadays you can either use udisks, udiskctl (depending on which version distro you're using), or even good old pmount.

I also contest your comment about how political bullshit overruns Debian and Ubuntu. If you think it's different or even worse than before, you're falling for nostalgia :)

I mean, I sympathise with your issues, and I understand the frustration of having to fight something that you'd expect to just work, ("it's 2015 for fuck's sake! Why am I still dealing with this bullshit!?"). Of course, you're doing much more cutting edge stuff with 3D and computer vision, so you're probably tickling the bleeding edge of driver support in Linux. Nevertheless, you've had this class of complaint for 15 years. Haven't you bitten the bullet yet? :)

It is the ThinkPenguin, yes. I bought it at an extra and with an underwhelming GPU exactly because it is designed to work nice on linux and only has devices that work with open-source drivers. Yet, the GPU fails under debian. After hours of tinkering and googling, I concluded I have the same issue as this guy: http://blogs.fsfe.org/the_unconventional/2014/11/12/debian-x...

Add to that that the basic install does not allow USB to be automounted by a user. I did manage to get this one to work after a wasted hour or two, but I don't consider it normal that this is not default behavior or at least very easy to configure. In 2015.

Both these things worked flawlessly out of the box on a Ubuntu with KDE.

As for nostalgia, I actually do not remember stumbling on a case like the intel GPU before: "We are holding bugfixes because we don't like the name of Intel's package". Actually, every time I try to go back to debian, I arrive with a ton of motivation thinking "this time I am going to look deep into the issues and solve them!". This particular issue had no good solution: it would have required me to install the intel driver and accept that my system would probably break at the next big update.

I am used to the old proprietary vs open debate and the horror of binary blobs. Here it is not the case.

DBus (And modules that plug into it i.e. Bluez) actually need much better docs. It would ease a lot of things out.

Which in turn requires someone to actually write them. Which is a problem ALL open source software faces. Freedesktop are better then most at it.

pretty much. When things are exposed as files, programs and users are playing in the same sandbox.

The user can then at any moment emulate the actions of a programs towards those files, and look at when it breaks. And this while only using the barest of CLI tools, rather than having to aim something like GDB or strace at the process and hope to catch the tentacle flailing.

Reply on news.ycombinator.com