SlackwareThis Forum is for the discussion of Slackware Linux.
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.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
I understand it helps automate things a little better. But there's something about it I don't like. I expect it's the complexity that it seems to come with. XML based config files don't help to endear it to me either. It doesn't seem very KISS.
What do you all think? I'm quite happy to be corrected.
Personally I like it, and I think it should be included. Not that I use it all the time, but slackware would be missing something without it. Besides not every slackware user is a hardcode slacker. My girlfriend find the automounting very practical. (So do I so I don't have to mount her mp3 player, or external harddrive all the time :P). Anyway, it's well tested and it works pretty well as far as I know. But I think it should be included in such a way that it can be removed. I *think* that this won't be the case with SW13.0, as far as I understood the integration with kde and hal, but to be honest, I dont know :P
Can't find much info on libudev. Ubuntu seems to be only using it for the fn key and power management. I assume they're using hal for automounting, still. Like Dinithion I mainly like hal for automounting. I wouldn't be adverse to a more udev approach, though, as I get along better with udev. I understand hal uses udev to get info about the hw events. I wouldn't mind just cutting out hal altogether.
I still find HAL, udev and anything requiring XML configuration files instead of plain text to be unnecessarily aggravating and annoying. And I think some of the ideas behind devicekit are insane. But then most of the stuff coming out of Freedesktop.org these days seems to smack of dumbing down and reinventing the wheel at least.
Last edited by Eternal_Newbie; 08-09-2009 at 09:58 AM.
Reason: Freedesktop, not opendesktop
hal and udev are both evil, as well as 'unslackish'! Oh wait, I forgot that we are past slack-11.0 now... Funny how things become un-evil once they are included in slack -what's next?
Some of us have stayed true to our convictions. Slackware's adoption not withstanding, I still dislike aspects of them both.
I don't have a problem with the mechanism of the kernel sending a event to a daemon to create the necessary device nodes, but my fear for udev is that with the complicated interaction of its many rules files and helper scripts it has the potential to end up a bit of an unintelligible tangle.
I actually thought devfs was a good and clean solution to dynamic device node management and I'd have much preferred that they continued to improve on that than change to the udev scheme.
I also share Eternal Newbie's distaste for anything XML.
-- Distaste for the XML file format of HAL conf files. They're horribly overcomplicated IMHO.
-- Potential entanglement of all the HAL, udev, and whatever daemons & processes may be in play.
It took me long enough to get really comfortable with UDEV. I actually like it now, since I know how to use it to my advantage. Why does there need to be such a complicated dependency just to automount some media, or use a mouse or keyboard? Phooey..
So far, I dislike HAL, and I don't need it. As someone mentioned, it should IMHO not be a dependency (on Slack-13) but an optional component.
Plus (since I'm ranting a little) why does everything related to HAL need tohave such a long stupid name with freedesktop.org in it? Like "<org.freedesktop.hal.fdi.keyboard.broken.not.useful.true.if.sunday.past.noon>"
I second and third GazL and Eternal_Newbie. Part of my prepping comps
on this LAN for Slackware-13.0 is learning HOW-TO disable HAL and udev.
They're definitely not the Tried-and-True-Slackware-Philosophy (TM)
but some Johnny-Come-Lately ideas.
A couple of years ago I started running KDE to be able to help people
after building a box and doing an install with KDE so they would feel
'comfortable' coming from the Windows world. All that's happened is it
has made me think I've gone back to Windows with KDE in Slackware.
The default KDE desktop in -current looks so much Vista it's nauseating.
I'm not a Windows-wannabe, nor do I expect such behavior out of
anything to do with a Linux OS -- especially Slackware.
Having things stuffed up with HAL such as mounting my flash drive and
every file as ALL CAPS has definitely beeen a step backwards in it's
development. I hope Pat reads enough opinions of Slackers, and if it's
at all possible, something changes in the HAL/udev mess.
These and other irrational changes to KDE have run me back to Fluxbox,
which is anything but a Windows-wannabe.
I don't have any complaints about HAL and udev. For one thing it isn't too difficult to disable them. It did take me some time to get everything working the way I wanted with HAL and udev but a few of the features are helpful.
It seems to me that KDE is trying to emulate both OS X and Vista. That's not necessarily a bad thing as long as things settle down long enough for the bugs to be fixed and design flaws to be corrected.
I don't have the same frustration with KDE as I do with Vista. Vista seems to make everything more difficult for me, and I can't seem to change it. KDE has a few rough edges but most of them can be dealt with by changing settings or adding things to menus, the desktop, tool bars, etc. The big difference is that one can change KDE a lot more than the few choices in Vista. Windows XP had a few more configurable things such as the folder toolbar and a start menu that would actually keep things in the order that you put them. Windows 7 seems mostly like Vista with new colors.
KDE is having some growing pains but I'm willing to hang in there until 4.3 gets more stable. Then I will decide if I want to stick with KDE or look at other choices. Meanwhile Slackware gives me something that I can rely on even if I am looking forward to improvements in the user interface for KDE. Not all progress goes directly forward. Sometimes things go back a step before surging onward. At least with Slackware one can avoid stumbling.
I think it is inevitable that something like HAL/udev will come along to allow automounting.I don't see any reason why it shouldn't be included in SW and xml is the way that many applications are using to store data these days.
I like having persistent names for my devices, so I don't have a problem with udev. HAL on the other hand, I don't like. There's no need for my devices to be automounted.. for whatever reason, I prefer to do manually. I think I remember that when HAL was first introduced in a new release, I got quite frustrated because I wasn't able to mount CDs in the terminal. I must say, I don't really know how HAL or udev actually work, but again, on the surface, I don't like HAL.