SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
With Udisks2 being added to Slackware to I wanted to know what this new package brings. It looks like another gnome POS tainting my system.
Quote:
Udisks2 is emerging, and while this could have been good news for Linux, it is instead a prime example of how Linux is in decline.
Author David Zeuthen explains his reasons for rewriting udisks here. To put it simply, it’s all about Gnome. It appears that increasingly udisks is becoming an internal Gnome component and less a universal Linux tool, certainly not command-line friendly. That means there is no real replacement for hal without adopting almost complete desktop environments. This is not a good state of affairs for Linux development. I haven’t tried it yet, but it will be interesting to see what a mess udisks2 makes of systems which aren’t running Gnome, since the udisks2 author seems to barely consider such use, and even works against it. udisks v1 certainly proved difficult enough with many non-Gnome users having endless polkit and consolekit issues. Rather than addressing this, udisks v2 aims to worsen it.
Quote:
Want to write a quick script to mount a device? Forget it, according to David Zeuthen – that’s not to be done in Linux. While this update may make Gnome’s Disks utility prettier, it undermines the core philosophy of Linux, which is that programs interoperate using simple command line interfaces and text streams. Apparently, the vision here is to make it as closed and convoluted as Windows.
I haven’t tried it yet, but it will be interesting to see what a mess udisks2 makes of systems which aren’t running Gnome
In short: I haven't tried it yet but it *should* be bad.
IMNSHO, it would be more constructive to try it yourself on a system which is not running Gnome, as for instance Slackware-current, and tell us about your own experience than quote people who didn't even dare to try it.
The focus has been mainly to get Gnome literally a required component of a Linux distribution since so many distributions have either eradicated it or have started using it as their primary desktop environment.
Not only that but to wipe out any traces of any ability to work with BSD based or UNIX based components and recreate all tools to be specifically Linux.
I wouldn't be surprised if Red Hat wants to takeover Linux and recreate it not as a kernel for GNU based distributions, but as a true Linux OS.
Patrick has however stated Slackware has some options to avoid the inevitable, but exactly what they are is still under lock and key, but it deals with BSD based system tools.
Perhaps I'm a bit naive on this, but who died and made David Zeuthen god for this type of technology in Linux? Can there be another alternative than udisks2 that can be used for those that don't want gnome running on their system? Or is that exactly what the BSD system mentioned in another post will do?
Patrick has however stated Slackware has some options to avoid the inevitable, but exactly what they are is still under lock and key, but it deals with BSD based system tools.
That was simply an offhand comment after perhaps one too many Pabst Blue Ribbons. If I knew anything, I'd tell you. The plan is as it always has been -- try to keep forging a path ahead, and don't build bridges until we've arrived at a river.
Let's just hope they didn't shorten the road on things. God forbid we take a good breath, turn around, and the inevitable nightmare is starring us in the face.
I've been reading on various package websites that hardly anyone is in favor of udisks2's implementation.
For those interested here's a good read into how bad things with udisks2 are:
Always interesting to see how much Linux developers will screw around with simple and easy to use systems just to mess up as much as possible and over-complicate the system.
You'd think these guys worked for Microsoft or something.
Can there be another alternative than udisks2 that can be used for those that don't want gnome running on their system?
yes, there is one, from Ignorant Guru himself: it's called udevil and, besides being still in alpha stage, I'm using it happily together with Spacefm on my laptop.
That was simply an offhand comment after perhaps one too many Pabst Blue Ribbons. If I knew anything, I'd tell you. The plan is as it always has been -- try to keep forging a path ahead, and don't build bridges until we've arrived at a river.
And they keep saying Slackware development process isn't transparent
Thanks Ponce, both of those look like they might go well with my dwm/dmenu setup. Will give 'em a try.
To made things easier for anybody who wants to try it, I have the slackbuilds (also one for an updated spacefm) available on my repository for -current
Quote:
Originally Posted by BlackRider
I think the author of udevil does say his software is not an udisks replacement.
I have understood exactly the opposite, even the syntax is compatible (also with udisks2).
To play devil's advocate, which is probably foolish given I don't really get what's happening under the hood, Zeuthen talks about problems with scripts:
Quote:
[1] : History lesson: before we had udevd(8), the kernel forked /sbin/hotplug for every hotplug event. And /sbin/hotplug, being a shell script and all, itself forked another ten shell scripts or so in /etc/hotplug.d/and these forked other shell-scripts and... the result was that hotplugging a USB hub full of devices could easily take minutes because tens of thousands of /bin/sh-instances were forked. Awesometown. Today udevd(8) does the same in less than a second without forking a lot of extraneous processes.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.