Slashdot Mirror
Worst Linux Annoyances?
greenrd writes "Ever spent hours trying (and failing) to get a printer driver to work on Linux? Struggled to configure something ever-so-slightly out-of-the-ordinary? What have been your biggest annoyances when using Linux? Three O'Reilly authors are compiling a book on Linux annoyances - and their suggested solutions - and they've started a mailing list here. I can't help but think, though, that such a book will be dated quite quickly. Sure, some problems do languish unfixed for years - but equally, I suspect many of the problems will be fixed before, or soon after, the book's publication date. Still, increased visibility might motivate developers to create fixes or workarounds for some of the problems, so maybe this is an ideal opportunity to get your pet peeve finally addressed!"
By far, hunting down layer after layer of dependency while trying to install software, only to meet conflicts is my biggest problem.
I am running RH8, and an somewhat of a linux newbie, but i have speant hours trying to get the right versions of software installed, often with two four levels of dependency, (ie Software i want needs x, which needs y, which needs z, which needs a...). I recently installed apt, which made it a bit easier for software it indexes.
Windows software downloads can be big and bloated with DLLs but they generally work out of the box.
paul reinheimer
Not being able to unmount a removable storage device (CD, my digital camera, whatever) because some process had the bright idea of keeping an open file on it, or hanging around with it as its cwd. Nautilus used to be especially bad in this regard.
The most annoying thing about Linux is that people compare it to Windows and point out the differences as "annoying".
Different can be better, but yes, there may be a learning curve... and that can be annoying for some.
Cripes...
If you ignore the other uses of a tool, does that make the tool less useful, or you less useful?
Anyhting having to do with USB or Firewire support
I can't help but think, though, that such a book will be dated quite quickly.
If I wrote the book, that'd be exactely what I want. If the book's outdated, it means it has brought all those problems to the attention, and that proper solutions were made. What more can you wish?
this sig has intentionally been left blank
Why cant everyone pick a fricking filesystem layout and KEEP IT FRICKING THAT WAY?
Redhat thinks that apache and KDE's developers are idiots so they move the default install, Mandrake has things in different locations, SuSE,Debian,Slackware.... they all think they know where it is supposed to be.
All it does is piss off the Linux user.
This is one of the biggest problems. Leave where things go ALONE!
Do not look at laser with remaining good eye.
The default font (at least every time I installed X) is always *tiny* on my screen. No matter how hard I tried, when I changed settings, it never seemed to work.
"I turn away with fright and horror from the lamentable evil of functions which do not have derivatives."
is vendor supported drivers.
Printing, video drivers, sound drivers, etc are ALL significantly easier to setup and use under windows. This is reality because windows controls 90%+ of the desktop market.
Until Linux has the ease of use with devices that both windows and macs enjoy, drivers will be my largest annoyance.
BTW I've been using linux since '95 and it has come a very long way, but it has a lot left to be desired.
Why can't rpm figure out the next arg is a file (not a package with an illegal package name ending in .rpm) and assume the -p flag?
Why can't cdrecord by default create a sane ISO if the request specifies a directory or file which doesn't look like an ISO?
etc.
Sure, let someone override this behaviour if they give the special flag after RTFM, I propose --literal. I am tempted to implement this using a bunch of perl wrappers.
Isn't something from the OS itself, but the "1337" attitude from the users. "Use a different distro!", "RTFM!", "l4m3r!"
I don't know where you've been looking, but I never see any of that. Not even here. And really, if you are told to RTFM, perhaps you really should have. Very few people want to provide a free helpdesk for people who can't be bothered reading the manual. Most people consider themselves to be worth more than a bit of paper.
How about, instead of asking "how to", you read the manual, and if that confuses you, ask about the bit that confuses you. If you don't know where the documentation is, ask for that. Ask questions the smart way.
And this isn't an annoyance that's limited to Linux -- I deal with it in Windows from time to time. When I hit eject, I want the damn media NOW. Both Linux and Windows will bitch in their own special way about open files or locked files or stupid processes... it's beyond me why someone can't code up an intelligent solution that will close all read handles, and close all write handles with some message along the lines of "Completing write in /dev/cdrw0, please stand by" (of course this wouldn't apply to regular CD-ROMs).
Anyway, the whole point of this rant is that there should be something more elegant than having to manually kill proc's by PID. I don't think Grandma's gonna ever use Linux if she has to do that kinda stuff.
I heard one guy state that "When you're 80% done with a project, you've probably only spent 20% of the time that it takes to complete it with splendor".
I think that Linux is there, it's 80%. Things just don't work out of the box, and they should if we wish to hope to compete with Windows or Mac OS X. Try daisy chaining external firewire drives on RH 9, it just doesn't work. Try changing network profiles smoothly with RH 9/XD 2 - it just does not work. And get your funky i18n characters to display properly in RH 8 and later - it's not as easy as selecting a country during the install process. These are supposedly not rocket science issues, it's finish, it's what makes the difference to the average user, it's the difference between 80% and 100%.
Linux has not really evolved beyond the 80% during the past 3-4 years. Sure, we've gotten GNOME2, KDE3 and so forth, but these still lack the same finish as their predecessors did.
I'm beyond wanting to fiddle with my desktop PC, which is why, after 5 years of using Linux on the desktop, I'm switching from Linux to Mac OS X once the next powerbook update occurs.
Unable to read configuration file '/bigassraid/htdig//conf/14229.conf'
Geocrawler error message.
Trying to understand Linux as a "Windows substitute" is a doomed prospect. Their differences aren't just a matter of tradeoffs: they are radically different kinds of system, much as an MP3 player is different from a turntable. If you found two people arguing over whether an MP3 player or a turntable was "better" -- or a turntable user saying that MP3 players were "annoying" due to the lack of an RPM control -- you would of course recognize this as nonsense.
An example of this sort of difference between Linux and Windows is the difference in the handling of drives. Windows uses drive letters; Linux uses mount points in a single filesystem. While there may be advantages to each, they are more a design difference than a set of tradeoffs. Another example is the difference in balance between CLI and GUI. Windows (or, moreso, Macintosh) users who come to Linux looking for that kind of carefully tuned GUI are likely to be disappointed -- and pushing the KDE control panels on them as "almost as good" is inviting their disappointment. There is a difference in design intention between GUI-focused and CLI-focused systems. The new user just has to un-learn old assumptions, just as the turntable user needs not to be looking for an RPM switch if he wants to become familiar with the MP3 player.
Things I would describe as "Linux annoyances" are points which remain difficult, problematic, or simply grating even for the already-familiar Linux user. Many of these will sound entirely foreign to the Linux novice or non-user, since they are matters that only occur to the already-familiar. These are points which seem out of place, or insufficiently regular or predictable, even to the expert.
Some examples of what I mean:
The parent contains an insight that many Linux hackers simply don't get. It's better to have some process generate a thousand I/O errors than to have a computer that is not responsive to user input.
Having to use a command-line utility to track down and kill apps that are accessing a given device is a complete *failure* of the OS to just do what the end-user wants it to do. In the case of a disk eject, the OS needs to forcibly unmount the disk and allow the user to eject, and it should be the responsibility of any programs to gracefully fail, or even better, handle the error, if they really needed to access that disk.
It should never be the user's responsibility to clean up other programs so that the system can perform a task the user requested. When the user makes certain requests of the system, such as those of the "give me my disk" variety, the system should be expected to bend over backwards for the user, not the other way around. Anything less should be considered a severe usability bug.
The foul language used by the parent detracts from his argument, however in this case it can be forgiven due to the extreme annoyance of this bug^H^H^H feature.
The preceding comments reflect the author's personal opinion and are public domain, unless explicitly stated otherwise.
Not far off the mark. Although I'm a geek myself, it does seem strange that many in the GNU/Linux community automatically assume that everybody else is the same way. It's a total lack of vision on the part of those who are all too consumed by computing.
I mean, really what is computing about? (Not just GNU/Linux) it's a means to an end, NOT the end itself. Computers are really interesting, and that's how I earn my daily bread. I even like them just because they are, not necessarily because of the benefits that they bring to people. Still, I have to acknowledge that the majority of computer users only bother with them because they allow the user to do specific things, like balance their checkbook, order books online, or curse clippy with all the vitriol in their hearts.
The people involved in the GNU/Linux community are smart, and intense. Probably too intense. For all of the hacker humor that's out there, it's often suprising just how seriously people take things.
-- Truth goes out the door when rumor comes innuendo. -- Groucho Marx
Copy and paste doesn't work consistently, and when it does, it often behaves in nonsensical ways.
I feel that world domination will come when the following "Just Works" for every Linux user:
- You can copy text from any application that can supply text into any other text application that can receive text. Many Linux applications can't copy and paste between each other, or if they can at all, you can only do it in one direction.
- You can copy some text from any application, close the window to get it out of the way, because you don't need it anymore, then paste the text into any other application
- You can copy some text in any application, activate the window of any other application, select the text you want to replace, then paste the text you copied first, thereby deleting the second text which you had selected and replacing it.
This last thing I try to do quite a lot to paste a new URL into the URL textbox of a web browser, so I can replace the old URL with the new URL I want to visit. However, in X11, highlighting some text makes it "the selection", so a paste will just paste in the text I'd selected, which was the text I wanted to replace.All of these things have consistently worked flawlessly in every version of Mac OS and Windows I've ever used. Note that my first Mac ran System 5 and my first Windows box ran Windows 3.1. Yes, I am an old man.
I've been using Linux since I first installed Yggdrasil Plug-n-Play and I've never been able to get this to work right.
Consider how frequently office workers in a business need to copy and paste text, and consider that this is my main frustration, even though I am an experienced Linux user. I nearly had my Windows-loving wife talked into trying out Linux, but when I explained this problem to her, she said she wasn't even willing to give Linux a chance.
And yes, I understand one reason this doesn't work in X11 is that the fact that this network-transparent GUI sometimes has to work on X terminals with limited memory, so you can't provide a dedicated memory buffer for a clipboard like on Windows or the Mac. But my friend, the PC I'm typing this on has 512 megabytes of RAM, and frankly I rarely if ever run X over a network, so I don't see this as a valid excuse anymore.
It's enough to make you chew your own foot off.
Request your free CD of my piano music.
You've got to be kidding. It happens all the time here. If someone asks a question about moving from Win to Linux, he will get flamed with comments like "if you don't know what distro to get [or whatever simple question was asked], Linux is not for you."
It will rise much more quickly to the top of a developer's TODO list.
It will be much more appreciated if the user with the problem has thought the thing through, rather than just complaining.
It is basic to the spirit of Open Source, where people contribute .
Selfishness has no value here. Ayn Rand would die of hunger in the Open Source world.
The multiline strings suddenly being illegal in gcc 3.3.x are annoying too. Much code still uses multiline strings. Yes I know about ANSI concatenation, but I'm not talking about my code here, I'm talking about the heaps of OPC (other peoples's code) out there. Many wasted moments were filles cleaning up other people's mess. Oh well, not really a linux issue, but a gcc one, but what the heck.
The Linux VM swaps an awful lot when it really shouldn't. Well, it doesn't suck as much as it used to, It used to be a whole lot worse, but it still sucks. I have quite a bit of memory in my machine. I bought the extra mem just to avoid the godawful paging to disk. Linux somehow still sees fit to page to disk. Yes I could turn off swapping, but I just want to be safe instead of sorry. The OOM killer isn't very nice to your processes when you run out of mem or swap.
Linuxisms in code. Programmers that write very cool software (e.g. KDE) but fall into the GNU libc-extension and Linux-only features traps, and thereby making their code instantly unportable. Linuxisms are the bane of my (and others') existance when porting stuff porportedly written for linux to another OS. Instead of a straightforward recompile, I have to monkey around to beat all the linuxisms out of the code to get it to function well on other systems. Examples include /proc abuse, library/system calls only available to Linux, assuming the env is little-endian, alignment assumptions, filesystem feature assumptions, and wearing 32-bit blinds. Not really a linux system annoyance, but more a Linux-attitude-towards-other-systems and brainfarted programmer annoyance, but hey, we're on a roll here.
Bash-isms. Yes, I know the venerable bourne-again shell is the "default" bourne type shell in Linux. It's actually quite featurefull, and can do a heap more stuff than the normal POSIX bourne shell can do. Linux coders seem to thing *all* systems use bash as their bourne shell and write their supposedly bourne shell scripts with bash extensions. For someone using systems like the BSD's, IRIX and whetever doesn't ave bash as their default shell it's mightily irritating. Also the linux bash shebang cancer is an annoyance. If you absolutely must have bash, use env(1) to find bash, instead of hardcoding it into your shebang. Else, just stay away from those bourne again extensions. Use the korn shell if you must.
GNU's rabidness against man(1). GNU has deemed the info(1) documentation the "standard". info(1) sucks. It's counterintuitive, bloated, and redundant. It has absolutely no advantage over HTML, SGML or even LaTeX docs. And the man(1) system is nice and lean for a quick reference. For some reason, GNU wants to stamp out man(1). Luckily, many linux developers still embrace the man(1) system and still write manual pages (bless their little souls). But to find any useful docs about say gnu autoconf, you have to interface with that monstrosity that is info(1).
That's it for a while. I'll think up some more concrete really linux application related ones and post them to the list if I have time. FOr now, this is just a small list of some tings I find annoying about Linux and GNU.
Some time ago i DLed Slackware 7 (or whatever, im a Linux noob) from the Swedish University Network and installed it. It was not the first time i installed linux so i had some clues on how to get a window manager, sound and the internet connection running. But to my frustration the resolution was always off somehow and everything farked up. SO, i return to my filthy imperialistic pigdog Windows and ICQ my Linux-geek friend. Guess what? Couldnt fix it. After a few weeks in windows, i hear the distro on the SUNet was corrupted and averyone downloading the ISO had problems with X-resolution. The bottomline? Peer-to-peer support is way too hostile in the linux community. Go ahead and tell me i shouldnt run linux if i cant get it running in 10 minutes. I still think the community could use some more happy faces and a friendlier attitude towards noobs like me.
Ok, im gonna duck now and try to keep myself from catching fire.
You cant fight in here, its a war room!
There is something to what the original poster said.
Many, many existing Linux users have volumes of existing scripts that were written to expect certain behavior from commands.
If you fidget with commands break all of those scripts in hopes of gaining Windows users, you will severly break the working environments of the existing Linux users in ways which may take years to repair. More importantly, most of these are the same people doing most Linux application and driver development.
It's the classic "make it so that even a fool can use it and only a fool..."
You see: you "fix" a whole bunch of silly RTFM problems all over Linux, so that the "obvious" (to a Windows user) behavior occurs. You gain a whole bunch of happy Windows users who don't want to learn about "old fashioned" ways of doing things. But you break a whole bunch of older scripts, methods, and tools in the process. Congratulations, you've just lost a huge portion of the original Linux community (esp. the development community) to *BSD, where Unix is still Unix.
You're back where you started. All the interesting development is now happening on BSD because the active technical community now lives in BSDland. But BSD is still Unix-y and so you're back to whining "Why do I have to RTFM? Why can't you *BSD people make this stuff easy and do things the obvious way? How do you ever expect to get any of us Windows or Linux users?"
The answer is simple. Unix developers want Unix. Windows users considering a switch should come to Unix for Unix, not for a cheaper Windows.
My own $HOME/bin directory contains 214 scripts, some of them very long and not seen by human eyes in years. All of them use piles of shell tools. If Linux breaks them, I'm outta here. I don't have time to rewrite and/or debug all of them from beginning to end in some kind of "It's the New Linux!" audit.
STOP . AMERICA . NOW
That's the trouble. Linux often seems to have two levels of operation: omniscient programmer and absolute moron. While I've always been a big Gnome fan, the latest push is to dumb down the default interface to the point of being suitable mostly for users at the "gee, where do I launch The Internet?" level and requiring hacking xml files to reconfigure things to make it work the way you want it to (because everyone knows that options are confusing, right? we can't give users who can't grok xml the ability to modify the way their programs work in non-trivial ways, they'd be completely overwhelmed!). File-roller is somewhat slow, its interface gets in the way, and it doesn't have enough of a range of abilities to be able to replace learning all the CLI archive commands for anyone but beginning users. Why can't GUIs and command-line commands be at least somewhat targeted to the users who generally know what they're doing but aren't programmers and can't remember all of the command line options for hundreds of programs?
That's against the point of such command-line programs.
Many UNIX command-line tools are meant to do one job, and do it well. There's no reason for tar to know about compression formats -- what about UU-encoded stuff? Should tar have to know about ARJ, LHA, ZIP, gzip, various encoding formats (BASE64, etc.), and other issues?
This isn't an RTFM thing -- you don't really want to be using tar or rpm or cdrecord in the first place, because these are programs which are meant to do things very literally, without room for misinterpretation.
Strict behavior is better than undefined behavior.
The ideal solution is NOT for GNU to add all sorts of heuristics into tar to figure out what you want it to do -- that addresses the wrong problem. The ideal solution is to have front-end programs which invoke tar, gunzip, rpm, cdrecord, and such. Perhaps a "suggest" script could invoke "file" to determine what the file contains, and suggest things to do with the file based upon its contents.
Simplicity is key to having bug-free programs. Let front-ends handle dealing with people who don't want to learn how to get a specific program to do a specific task for which it was designed.
Besides, what is the best default action for tar? To uncompress an archive? To list the contents? To add files to it? What if the user specifies two tar files on the command line? Does tar add the second to the first? The first to the second? Does it list them both? Does it create a third with the merged contents of the two on standard output?
It sounds to me like tar should have command-line options to let the user tell it EXACTLY what to do, so the user isn't surprised by something unexpected happening.
Oh, wait, it already does.
Somebody get that guy an ambulance!
You only call that sane behavior because that's the behavior you're used to.
Unix commandline apps assume that you know what you're doing, and do *exactly* what you tell them to do. This behavior is very useful in scripts or graphical frontends, because you know exactly what they will do. And this is the correct behavior because these apps are meant to target users who know exactly what they're doing.
The less technical people should use graphical desktop apps. They make sure (more or less) that the user won't make big mistakes, like Windows. Those users wouldn't use commandline apps in the first place. So why modify commandline apps to target them if they won't use the apps anyway? It's not worth losing the scripting flexibility.
Don't use rm, hit the Delete key in Konqueror or Nautilus. Don't use tar, use File Roller or KArchive. They're easier to use *and* won't let you make stupid mistakes.
"My personal pet peeve? why is it that with >75% of apps that I download as source have either configure scripts that simply don't work, or include code that doesn't compile."
Then you must be running some weird or outdated distro. 90% of all source code here compiles and installs out-of-the-box.