This time Eduardo turns to issues more related to hardware. First we’ll see how to enable removable drives in a Slack installation, with especial attention to floppies; and then Eduardo will examine how to setup new hardware, using a scanner as an example, since its setup was tricky. Read the whole adventure at OfB.biz. My Take: Honestly, I hope someone could come up with an administrative GUI for DevFS & uDev so users can set permissions on device nodes without having their heads explode.
Stealth Desktop Part IV: Removable Drives and Scanners
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
well, the point of udev is that you shouldn’t *have* to set permissions on devices…
in the future I’d imagine permissions will be merged into security settings, for e.g. on Mandrake you’ll get different device permissions depending on the security level you pick. But if you get the wrong permissions on simple devices by default the default needs fixing, we don’t need to build a GUI to change ’em.
ooh, but of course, then you’d have to PATCH something! And I forgot patches are always bad.
The article’s a bit misinformed. Mandrake hasn’t used supermount since 9.2, it’s magicdev now. And floppies are handled the way the author suggests anyway, unless you mount them sync. All the operations you do on a mounted floppy are just done in memory or swap then synchronised to the disk when you unmount it…
>well, the point of udev is that you shouldn’t *have* to set permissions on devices…
Have you ever heard of udev.rules and udev.permissions? There ARE permission rules on udev as well. For example, my distro of choice, ArchLinux, it doesn’t allow users to use usb devices, or even optical devices or even audio! The user has to go through the pain and setup everything himself. That’s a complete pain, for an otherwise fine distribution. You see, the defaults of udev and devfs are not very user friendly, and distros like slackware, debian or arch, prefer to keep the defaults, rather than tweak everything like mdk or fedora do. Thing is, I prefer these distros over Mdk/Fedora/Suse for other reasons, so I am simply looking into evolving them by at least having a gui tool that would list in human form devices and permissions and allow the administrator (most of the time, the same person as the main user of the computer) to set these up painlessly. This IS needed, because not everyone uses Fedora or mdk.
yes, I know about them. I’ve debugged them (did you know the default permissions for /dev/input are too broad and stop you using USB joysticks properly?). They should still be something for the system to set up properly and not for the user to mess with though, really.
So let me get this straight. You hate patching *so much* that you think it’s a BETTER idea to create a GUI solely to work around bad defaults than simply to patch the bad defaults?
Eugenia, why the heck don’t you use KDE? They’ve got lots of bad defaults, and GUIs for EVERYTHING…
Adam, don’t get in my nerves and don’t take me for an idiot. Of course and I want them to fix their bad defaults, problem is, THEY WON’T (trust me, I tried to convience them). So, instead of having myself fixing them on my local installations each time I install a distro and take much of my time trying to re-remember everything, I would much prefer to have an easy to use GUI for it. It won’t fix the problem in its root, but it will fix MY problem each time I have to deal with that cr*p.
I’m not taking you for an idiot, I just think your blind total opposition to distros patching anything is absurd. Surely you can see that this is as clear-cut a situation as can be where by *far* the most sensible solution is for the distro simply to patch the program? Patch some good permissions into udev, the problem goes away.
Sure, if the distro is absolutely going to refuse to ever patch anything at all from default, maybe the distro needs to write itself a GUI to configure it. But I don’t think that’s part of the Slackware approach either, is it? And I don’t think any other project is going to help out, because they can see it’s a damn sight more sensible to fricking patch udev.
…and take much of my time trying to re-remember everything, I would much prefer to have an easy to use GUI for it…
this point Eugenia is making is even more general: I think that gui for most commonly changed settings is useful in that it helps memorization. I see it everyday when I administer computers where I work. Everytime I have to help a user solve an uncommon problem on his pc I wander around the gui until the right place pops in my mind. If the problem is on a linux box I just directly jump to Google. Many times I actually already faced the problem but that right setting in that configuration file just doesn’t stick into my brain, so that I have to re-refind the place where I read the solution…
I find that Debian has the right tool but package mantainers seldom us it. I am talking about the configuration gui that sometime pops up at the end of a package istalation. For example for the xserver package through this gui you can set its nice value. When I switched between kernel 2.4 to 2.6 I just had to fire up gkdebconf find the package and change the settings instead of remembering were the f@!k is the file to be edited. Unfortunately most times packages just don’t use this tool and spit out default settings that would drive Eugenia crazy ;-)…
just my 2 cents..
cheers
Hi,
Hmmm, don’t mean to interject in an otherwise fine ‘discussion’ (*grin*), but I think I’d have to put my support behind Adam for this one.
The fact that Slackware/Arch etc. doesn’t patch stuff (for me) is a good thing. It makes things a lot easier to compile down the track, you can actually follow advice in man-pages/docs/mailing lists without ugly hacks, and it’s cleaner to maintain and troubleshoot.
Going to all the trouble of creating a nice pretty GUI just to change a couple of options in a text file is a waste of time, IMHO. Just patch it, or whip out vi and change it yourself like Adam suggests.
You said “having myself fixing them on my local installations each time I install a distro and take much of my time trying to re-remember everything”.
Well, perhaps I’m pedantic and anal, but I usually like to keep a notebook of all the changes I make to my system – it’s usually quite a good idea for emergencies, to replay stuff. OK, if you’re lazy, just create diffs, and save them on a floppy disk. And seriously, how often do you install a new distro? (OK, ok, you’re the editor of osnews…I see the irony) For me, not more than say, twice a month – and most of the time, they use different configs anyway (eg QNX, Plan9 etc.) – so it’s not that big a deal.
After all, Slackware is meant to follow the KISS principle
I agree – I wish there was a udev for dummies somewhere. I’m trying to learn how to use it and I find it a tad confusing, trying to setup devices, learning what they need to be named, etc. A gui might make it more intuitive.
If your distro doesn’t meet your needs, then why not change distros? If the ArchLinux project refuses to fix something that’s obviously broken, then how can it be your distro of choice?
The problem is than no distro meets the average user’s needs. Fedora breaks this, Mdk breaks that, Debian/Gentoo/Slackware is for weenix weenies, etc. There is no distro that does not suffer from the same old Unix cluster-fuck syndrome.
> Of course and I want them to fix their bad defaults,
> problem is, THEY WON’T
… unless you care to explain in detail why the current
default is worse than your proposal. That might not be easy and it might not always be successful (usually it worked for me …) but that’s the way it works 🙂
> (trust me, I tried to convience them).
> So, instead of having myself fixing them on my local
> installations each time I install a distro and take
> much of my time trying to re-remember everything,
No need to re-remember. Just put your .kde-tree with your favourite settings into /var/lib/kde-profiles/eugenia, add
[Directories-eugeniasprofile]
ProfileDescription=Eugenias profile
ProfileInstallUser=root
prefixes=/var/lib/kde-profile/eugeniasprofile
[Directories]
userProfileMapFile=/etc/kde-user-profile
to /etc/kderc (or /etc/kde3rc in case you are using SUSE)
and add
[General]
groups=osnews
[Groups]
osnews=eugeniasprofile
or just
[Users]
eugenia=eugeniasprofile
to /etc/kde-user-profile. Adding those two files together with the /var/lib/kdeprofiles/eugenia-tree to a tarball and untarring that tarball on your favourite distribution of the day should be easy as pie. Using Kiosk-Mode together with profiles you can customize your KDE and strip it down to your needs. If you create a great unique profile with great defaults and offer it for download you have all my praying that it might become incredible popular 🙂
There’s plenty of documentation for KIOSK-Mode available:
http://webcvs.kde.org/kdelibs/kdecore/README.kiosk?rev=1.55&view=ma…
http://people.fruitsalad.org/phil/kde/userguide-tng/user-profiles.h…
http://enterprise.kde.org/articles/Kiosk_customization.pdf
http://www.novell.com/documentation/nld/index.html?page=/documentat…
> I would much prefer to have an easy to use GUI for it.
Yea that would be nice 🙂
What about writing some kind of KDE-GUI which makes the whole stuff that I described here ready and appealing for the enduser?
Greetings,
Torsten Rahn
dohh, I thought you were ranting about KDE defaults … until I reread the thread. I guess I need some more sleep 🙂 So …
Sorry for my Off-topic Kiosk-posting and I hope it was inspiring for some of you anyways 🙂 .
its a inspiration all right, this is why its nice to have configs be in human readable text files. when your about to upgrade you copy them over to some kind of storage media. that way you can either copy them back wholesale or use them for refrence when doing changes to the new system. kinda like the notebook (in fact a old sysadmin trick) that victor hooi talks about keeping.
allso, i think eugenia have the wrong mindset about the distros she uses. slack, arch and similar ar for those that likes to thinker, not the for os x for x86 crowd. useing one of them and you should expect the need to change defaults as they are most likely set with a paranoid mindset. its not without reason that i see slack being presented to people that wants to learn by getting their hands dirty while setting up a useable system. and mandrake, fedora or suse to people that just want a useable desktop system out of the box. slack and its compadres are often just linux-from-scratch with a basic installer on top.
eugenia, why dont you start your own distro? take what you think is the best options and go from there. i think its the only way you get a distro that you will be happy with…
Good article. I haven’t seen many articles that advertise MToolsFM. It’s nice that KDE and Gnome develop better tools and techniques for managing removable media and other devices, but at the moment I’m quite happy using the more lightweight X environments and managing my floppies and vfat formatted usb memory disks with MToolsFM.
OT I know, but after being very vocal about Slackware being your distro of choice in the past. Why the switch to Arch?
Et least in Gentoo or Debian, if you want a user to be able to produce e.g. audio, then you add them to the audio group and they’re able to access the audio devices. Not sure if that’s user-friendly or not (if not come up with something constructive) but it does the job for me. Since i run udev/dbus on a test-desktop, i haven’t run into any permission troubles so i guess (!) they’re integrated in that system though i haven’t looked at it it or so.
Yep. It also integrates nice into XFce4’s floppy mount utility.
how much ‘odd’ hardware have you tried? IME the udev default perms *aren’t* perfect yet (don’t know how far debian patches them, though). from mdk cooker recently, we’ve come across issues with usb joysticks, bluetooth and firewire (udev doesn’t create the raw devices for firewire when it should), off the top of my head. ah well, it’ll get better.