After all, no hacker wants to idle away his time polishing the mundane details of a user interface. I sure as hell don't want to
Speak for yourself. I know many hackers who care a lot about their software, and want to polish it to perfection, in all aspects including the UI.
Besides, the idea that only Apple can do good UI is bunk. MacOS X is riddled with stupid usability problems, trivial example: dragging the CD to the trash can in order to eject it. Woo, intuitive. How about the font panel with the invisible, hidden by default preview pane that you have to Just Know About to use.
The whole UI thing is like a lot of things 10% truth and 90% urban myth.
Apple wanted to use a mature kernel for their OS. So they used it. As a mark of respect and good faith to the Open Source community whose work they used, they decided to release the changes they made (which they were not obliged to) back to the community.
I once read an interview with Hubbard, one of the former top coders on the FreeBSD project. He revealed some interesting things, for instance:
* The only code FreeBSD got out of Apple were some minor bugfixes/style changes and some test cases.
* He waited for Apple to offer him a job, and when they didn't he had to go ask (beg?) himself.
* The FreeBSD/PPC port barely boots, and is not really usable.
I don't think FreeBSD got a great deal out of that, really.
* I use 'free' in quotes, lowercase, because I highly disagree with the FSF's definition of 'free'. Particularly because the only license which meets that description is not a license at all - it's called Public Domain.
A common misconception. That's like claiming the only form of political freedom is anarchy - clearly the interests of a free people are best served by living under the rule of law, rather than there being no restrictions on what one can do at all.
Windows and MacOS do have these problems, just not to the same extent. Typically there is not a culture of code sharing on these platforms. That makes code reuse more unusual than on Linux.
Generally apps only use what the OS provides them, then rely on installers to fill in the missing pieces if for instance you need a component that didn't ship with Windows 98 - unfortunately that has traditionally led to DLL hell.
You get features for that though. For instance, glibc 2.3 introduced thread local locale models, a very useful feature to have. They don't introduce new stuff into glibc just to piss you off you know.
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.
Eeep! Man, when I compare an out of the box RH9 install with my first, which was a SuSE 7.2, not all that long ago now, the differences are amazing. The GUI (well,gnome2) isn't massively confusing. The fonts are pretty. The desktop is double buffered and the widgets look nice. My hardware worked out of the box, instantly. I never did anything i18n wise, but the chinese spam i gets renders just right. Copy and paste basically works now, as long as you stick to text. You can resize the desktop on the fly, the login screens don't suck anymore....
I think you underestimate the progress that's been made in such a short period of time.
Why are you installing X manually? Isn't that what distros are for?
If you're putting together your own system, I don't think you can really complain about stuff like that....
If you mean "I install Red Hat in a really high resolution and the fonts were too small" then you can simply go to the fonts control panel and boost the sizes - I'm pretty sure Windows is the same.
Anybody who thinks they deserve unending, 24 hour support without showing any gratitude is a zealot in my book. Do you get ever helpful, unending support for Windows and all its software only moments away? I think not.
Some people expect the world, and when people point out how unreasonable that is, decide to shoot the messenger rather than deal with the problem. Nobody has any sympathy for them.
For the majority of computer users Linux is a hassle to use. Until the ease of use gets to the level of Windows then Linux will never make a huge dent in the desktop market.
Of course it will, but it will be the corporate desktop market where people don't attempt to throw Linux on old or broken hardware, and where people are on hand to help with the transition.
1) The non-obvious way in which you have to enable DMA mode for good performance, typically off in most distros, how you switch it on varies between them.
2) The fact that mplayer and Xine have UIs from hell. I use mplayer, but I had to figure out "mplayer -dvd 1" by trial and error, basically. The 1 is for chapter, I think. Not to mention the way you specify crop rectangles manually.
Fortunately the UI situation will be hopefully fixed by Totem, a really delightful video player. At the moment it's kind of screwed by a bug in XFree, but that is fixed in the next revisions of all the major distros. It's also a Gnome app, so I suspect some distros that have a policy of KDE only will miss out, as far as I'm aware there is nothing that quite matches up to Totem out there.
It's based on Xine or GStreamer, take your pick. The Xine version is currently more featureful, but the GStreamer backend is catching up fast, and hopefully Totem will be in gnome 2.6
Re:The main difference between Linux and Windows
on
Worst Linux Annoyances?
·
· Score: 4, Interesting
Until Linux has the ease of use with devices that both windows and macs enjoy, drivers will be my largest annoyance.
I'd quibble with the idea that macs enjoy good hardware support. They generally don't, but because nobody tries installing MacOS on 5 year old machines they found in the closet "just to try it out" it doesn't have to jump through the hoops that Linux is expected to.
I read all the responses to this post, and they are all basically "Use distro/OS Foo, and all your problems will go away" or alternatively "This is what apt is for"
I find it rather funny that so many people recommended apt when the author made it clear that they were already using it.
My personal view on this is that the model in which software developers only make available a source tarball and leave packaging to others is inherantly flawed. Packaging and making your software easy to install is as much a part of writing quality software as producing documentation and testing is. It makes just as little sense to leave packaging to third parties as leaving documentation to third parties does, or leaving development of the website to third parties.
The main problem that causes dependency hell is pretty clearly that the programs that resolve dependencies cannot always locate a suitable package to meet the dependency, or alternative suitable packages do exist but metadata mismatches prevent the connection from being made.
One of the reasons for that is that there is no way for developers to produce packages that can install on many forms of Linux. While the source code as a lowest common denominator is required for platforms that are not binary compatible like Linux/FreeBSD/Solaris, generally Linux distributions are binary compatible so there is no need for nonsense like a separate package for every version of every distro.
I also believe it's not feasible for a single (or even a group) of 3rd party repositories to package every piece of software somebody might ever want. Even in extremely large repositories like Debians, the software you want is sometimes missing, sometimes out of date. The effort required to maintain it all is enormous.
Eventually a decentralised model will fall into place, of this I am sure. Thomas Leonard already pointed out the excellent work him and his team are doing with Zero Install, and of course I pimp my project in my sig.
But basically, what both these projects have implicitly agreed upon is that the current model is fundamentally broken - it will take time to shift the inertia of the status quo unfortunately.
I don't think you'll find any other pre-1985 GUIs that perform event handling the way Windows does it (whether you like their solution or not). I'd say that alone makes it an original implementation, and would make a reasonable patent.
Windows message passing and routing is just an implementation of message passing and routing. There's nothing innovative about that, and I can tell you if they managed to patent this they would go after bigger fish than Wine.
Well, I guarantee you that if someone created a Macintosh API emulator, they'd get their ass sued off
Well, MacOnLinux seems to be doing OK. And anyway, just because a company might sue somebody for building an emulator doesn't mean the law agrees with them.
What is native? Something that uses GTK as its widget toolkit? But then KDE users would get annoyed. What about if it used Qt? Oh wait - both those toolkits are cross platform.
What if it used POSIX system calls directly? What difference would that make? The difference between calling HeapAlloc and malloc is really not significant.
Basically, what is and isn't native on Linux is an extremely blurred distinction and the vast majority of people using Linux for getting work done, don't actually care.
There is nothing innovative in the Windows APIs. Even the more windows specific stuff like DCOM has plenty of prior art available.
Considering Microsoft has made moves against Wine before (copyrighted header files springs to mind) but have never mentioned patents, I am 100% confident that they cannot shut it down via that route.
In the unlikely event that they may have patents on the API implementations, Wine would do what every open source project does in such a scenario and work around them or get them invalidated. The chances of them having a patent that is required to implement an API is practically nil and has never been encountered in 10 years of reverse engineering Windows. The DMCA causes more problems.
People throw around the bogey man of patents whenever big corporates are involved. "Just you wait and see, they'll never survive". Too bad that it's grounded more in paranoia than reality.
(a) have some software layer that can use windows.dlls in linux, just like Wine. Software will be significantly slower, however.
There is no speed penalty to using MS native code on Linux, whether it's via Wine or Mono. When to use, or not to use, native code is an interesting topic in its own right, but speed rarely plays a part in it.
The first thing you have to understand is that glibc is a special library - it is enormous, it cannot be usefully upgraded by users, and it uses symbol versioning.
The last thing is why RPMs will sometimes bomb with errors about glibc. Rather than rename the entire library (btw, glibc is far more than just libc.so.6), they essentially rename the individual function, then the linker transparently selects the latest version when you compile. That is why the only version of libc.so you will ever see is.so.6
As developers usually use the latest version of a distro available, and users often do not (think users who got their distros off dial up, bought them, or got them from a book) this places us in a problematic situation.
The solution is for apps to be compiled in such a a way that they don't use modern symbol versions. Unfortunately at the moment that's very hard to do. Fortunately, me and FooBarWidget have been researching the problem for some time now, and have a variety of ways to make compiling against older libc symvers very easy. This does mean giving up some nice features, like the thread-local locale model, but delaying the adoption of these technologies for a year or two is an adequate price to pay for greater compatability.
Once we've done some tests to find out which approach is best, expect to see guides on how to do this with tools to make it easy over at autopackage.org
That leads to the second problem with RPMs, namely that they are usually specific to a particular distribution. That means that all too often, there is no RPM for your distro, or it's out of date (that applies to debian/gentoo as well btw).
Once you eliminate glibc from the equation, the rest is primarily a matter of metadata. The most common incompatability is typically dependency naming, and sometimes the prefix used to install to.
You see users helping OTHER USERS with Windows-- e.g. "Yeah, you just have to click on X, then click Y and you're done". You'd never see that with Linux.
You've clearly never used IRC tech support. It's not uncommon for people to appear in #linuxhelp and ask questions about their Windows problems, often with some lame connection to Linux like "There's a Linux computer on the network" or "This problem doesn't happen in Linux". When it's pointed out to them that this channel is not #windowshelp, I've often seen them say things like
"Well I tried in #windows but it was dead, and anyway the Linux tech support channels are always way better on any network I've found".
So, I don't know where you get the idea that users don't help other users with Linux, because I see it happen every day.
but anyone who is used to Windows freeware and shareware knows that their interfaces are typically as high-quality as any other commercial application.
Huh? There are legions of piss poor UIs in Windows freeware programs designed by people without a clue. The difference is that the Windows software scene is so large that chances are good that somebody, somewhere has been able to write a program that does roughly what you want, without a sucky UI (sometimes).
Of course, even commercial software has very bad UI sometimes. Parts of Windows or Office have to be seen to be believed - randomly reinventing parts of the widget toolkit, yo.
I don't understand why it's so hard for free software to have good interfaces.
Yawn. It's not. There are equally lots of good free software programs with nice UIs. You don't like the Xine interface? Use Totem. Problem solved.
Like most things, you just have to shop around, instead of pointlessly throwing around stereotypes.
Which is the main thing that KDE has going it for -- it is infinitely customizable, yet the customization ability doesn't get in the way of ease of use.
Eh? KDEs own usability project has found that this isn't really the case. I often work the IRC tech support channels, if I had a penny for every time I'd been asked where a certain setting was in the KDE control centre (because they couldn't find it), I'd be a rich man.
Also, the default KDE style, Keramik, is very nice and usable, I recommend sticking with it
Blaaat. There was a thread on the kde-usabiltiy mailing list a few weeks ago now (?) about Keramik and how the usability team know it sucks from an ease of use perspective but it's a problem for the art team. They are actively seeking to tone it down, because it's so bombastic it gets in the way of actual usability.
Yes if you get OO to work for them it is great, however they are confused why it takes longer to boot.
It takes longer to boot because in the name of portability it replicates stuff already available in the OS, and because it hasn't been optimized well yet. Even the next version boots significantly quicker.
Ms can tweak the OS to make their own software more desirable, it is called system hooks
I call your bluff. Do you have any evidence of that, or are you just assuming?
Here's an interesting experiment. Install Office, delete Windows and reinstall it. Run Word. Note how fast it starts up, despite having all its registry entries deleted.
Here's another interesting experiment. Load up Word under Wine. Note that it starts in roughly the same amount of time as on Windows. Hunt through the Wine sources, looking for Word-specific hooks. Actually, don't bother, I can tell you there aren't any.
Office is fast because Microsoft know how to write fast code and optimize their own software for their own OS. I've not seen any evidence that Office or IE cheats in any way. If you wanted, you could write COM objects that provide similar integration into Windows but for Mozilla and Gecko. I still think it'd be slower though. That's just the price of portability.
Slashdot Mirror
Speak for yourself. I know many hackers who care a lot about their software, and want to polish it to perfection, in all aspects including the UI.
Besides, the idea that only Apple can do good UI is bunk. MacOS X is riddled with stupid usability problems, trivial example: dragging the CD to the trash can in order to eject it. Woo, intuitive. How about the font panel with the invisible, hidden by default preview pane that you have to Just Know About to use.
The whole UI thing is like a lot of things 10% truth and 90% urban myth.
Using free software in your products is not the same as being a part of the movement.
I once read an interview with Hubbard, one of the former top coders on the FreeBSD project. He revealed some interesting things, for instance:
* The only code FreeBSD got out of Apple were some minor bugfixes/style changes and some test cases.
* He waited for Apple to offer him a job, and when they didn't he had to go ask (beg?) himself.
* The FreeBSD/PPC port barely boots, and is not really usable.
I don't think FreeBSD got a great deal out of that, really.
* I use 'free' in quotes, lowercase, because I highly disagree with the FSF's definition of 'free'. Particularly because the only license which meets that description is not a license at all - it's called Public Domain.
A common misconception. That's like claiming the only form of political freedom is anarchy - clearly the interests of a free people are best served by living under the rule of law, rather than there being no restrictions on what one can do at all.
Generally apps only use what the OS provides them, then rely on installers to fill in the missing pieces if for instance you need a component that didn't ship with Windows 98 - unfortunately that has traditionally led to DLL hell.
You get features for that though. For instance, glibc 2.3 introduced thread local locale models, a very useful feature to have. They don't introduce new stuff into glibc just to piss you off you know.
Meanwhile, remember that it's all free. People who bitch about free stuff don't get much sympathy.
I expect things will sort themselves out at some point, don't worry about it. A strong dep resolution framework is needed first though.
Eeep! Man, when I compare an out of the box RH9 install with my first, which was a SuSE 7.2, not all that long ago now, the differences are amazing. The GUI (well,gnome2) isn't massively confusing. The fonts are pretty. The desktop is double buffered and the widgets look nice. My hardware worked out of the box, instantly. I never did anything i18n wise, but the chinese spam i gets renders just right. Copy and paste basically works now, as long as you stick to text. You can resize the desktop on the fly, the login screens don't suck anymore....
I think you underestimate the progress that's been made in such a short period of time.
If you're putting together your own system, I don't think you can really complain about stuff like that....
If you mean "I install Red Hat in a really high resolution and the fonts were too small" then you can simply go to the fonts control panel and boost the sizes - I'm pretty sure Windows is the same.
Some people expect the world, and when people point out how unreasonable that is, decide to shoot the messenger rather than deal with the problem. Nobody has any sympathy for them.
Of course it will, but it will be the corporate desktop market where people don't attempt to throw Linux on old or broken hardware, and where people are on hand to help with the transition.
1) The non-obvious way in which you have to enable DMA mode for good performance, typically off in most distros, how you switch it on varies between them.
2) The fact that mplayer and Xine have UIs from hell. I use mplayer, but I had to figure out "mplayer -dvd 1" by trial and error, basically. The 1 is for chapter, I think. Not to mention the way you specify crop rectangles manually.
Fortunately the UI situation will be hopefully fixed by Totem, a really delightful video player. At the moment it's kind of screwed by a bug in XFree, but that is fixed in the next revisions of all the major distros. It's also a Gnome app, so I suspect some distros that have a policy of KDE only will miss out, as far as I'm aware there is nothing that quite matches up to Totem out there.
It's based on Xine or GStreamer, take your pick. The Xine version is currently more featureful, but the GStreamer backend is catching up fast, and hopefully Totem will be in gnome 2.6
I'd quibble with the idea that macs enjoy good hardware support. They generally don't, but because nobody tries installing MacOS on 5 year old machines they found in the closet "just to try it out" it doesn't have to jump through the hoops that Linux is expected to.
I find it rather funny that so many people recommended apt when the author made it clear that they were already using it.
My personal view on this is that the model in which software developers only make available a source tarball and leave packaging to others is inherantly flawed. Packaging and making your software easy to install is as much a part of writing quality software as producing documentation and testing is. It makes just as little sense to leave packaging to third parties as leaving documentation to third parties does, or leaving development of the website to third parties.
The main problem that causes dependency hell is pretty clearly that the programs that resolve dependencies cannot always locate a suitable package to meet the dependency, or alternative suitable packages do exist but metadata mismatches prevent the connection from being made.
One of the reasons for that is that there is no way for developers to produce packages that can install on many forms of Linux. While the source code as a lowest common denominator is required for platforms that are not binary compatible like Linux/FreeBSD/Solaris, generally Linux distributions are binary compatible so there is no need for nonsense like a separate package for every version of every distro.
I also believe it's not feasible for a single (or even a group) of 3rd party repositories to package every piece of software somebody might ever want. Even in extremely large repositories like Debians, the software you want is sometimes missing, sometimes out of date. The effort required to maintain it all is enormous.
Eventually a decentralised model will fall into place, of this I am sure. Thomas Leonard already pointed out the excellent work him and his team are doing with Zero Install, and of course I pimp my project in my sig.
But basically, what both these projects have implicitly agreed upon is that the current model is fundamentally broken - it will take time to shift the inertia of the status quo unfortunately.
Windows message passing and routing is just an implementation of message passing and routing. There's nothing innovative about that, and I can tell you if they managed to patent this they would go after bigger fish than Wine.
Well, I guarantee you that if someone created a Macintosh API emulator, they'd get their ass sued off
Well, MacOnLinux seems to be doing OK. And anyway, just because a company might sue somebody for building an emulator doesn't mean the law agrees with them.
What if it used POSIX system calls directly? What difference would that make? The difference between calling HeapAlloc and malloc is really not significant.
Basically, what is and isn't native on Linux is an extremely blurred distinction and the vast majority of people using Linux for getting work done, don't actually care.
Considering Microsoft has made moves against Wine before (copyrighted header files springs to mind) but have never mentioned patents, I am 100% confident that they cannot shut it down via that route.
In the unlikely event that they may have patents on the API implementations, Wine would do what every open source project does in such a scenario and work around them or get them invalidated. The chances of them having a patent that is required to implement an API is practically nil and has never been encountered in 10 years of reverse engineering Windows. The DMCA causes more problems.
People throw around the bogey man of patents whenever big corporates are involved. "Just you wait and see, they'll never survive". Too bad that it's grounded more in paranoia than reality.
There is no speed penalty to using MS native code on Linux, whether it's via Wine or Mono. When to use, or not to use, native code is an interesting topic in its own right, but speed rarely plays a part in it.
You can download it for free, you just need to look harder.
They've allowed Wine. Why? Because they have no choice in the matter.
The first thing you have to understand is that glibc is a special library - it is enormous, it cannot be usefully upgraded by users, and it uses symbol versioning.
The last thing is why RPMs will sometimes bomb with errors about glibc. Rather than rename the entire library (btw, glibc is far more than just libc.so.6), they essentially rename the individual function, then the linker transparently selects the latest version when you compile. That is why the only version of libc.so you will ever see is .so.6
As developers usually use the latest version of a distro available, and users often do not (think users who got their distros off dial up, bought them, or got them from a book) this places us in a problematic situation.
The solution is for apps to be compiled in such a a way that they don't use modern symbol versions. Unfortunately at the moment that's very hard to do. Fortunately, me and FooBarWidget have been researching the problem for some time now, and have a variety of ways to make compiling against older libc symvers very easy. This does mean giving up some nice features, like the thread-local locale model, but delaying the adoption of these technologies for a year or two is an adequate price to pay for greater compatability.
Once we've done some tests to find out which approach is best, expect to see guides on how to do this with tools to make it easy over at autopackage.org
That leads to the second problem with RPMs, namely that they are usually specific to a particular distribution. That means that all too often, there is no RPM for your distro, or it's out of date (that applies to debian/gentoo as well btw).
Once you eliminate glibc from the equation, the rest is primarily a matter of metadata. The most common incompatability is typically dependency naming, and sometimes the prefix used to install to.
You've clearly never used IRC tech support. It's not uncommon for people to appear in #linuxhelp and ask questions about their Windows problems, often with some lame connection to Linux like "There's a Linux computer on the network" or "This problem doesn't happen in Linux". When it's pointed out to them that this channel is not #windowshelp, I've often seen them say things like
"Well I tried in #windows but it was dead, and anyway the Linux tech support channels are always way better on any network I've found".
So, I don't know where you get the idea that users don't help other users with Linux, because I see it happen every day.
Huh? There are legions of piss poor UIs in Windows freeware programs designed by people without a clue. The difference is that the Windows software scene is so large that chances are good that somebody, somewhere has been able to write a program that does roughly what you want, without a sucky UI (sometimes).
Of course, even commercial software has very bad UI sometimes. Parts of Windows or Office have to be seen to be believed - randomly reinventing parts of the widget toolkit, yo.
I don't understand why it's so hard for free software to have good interfaces.
Yawn. It's not. There are equally lots of good free software programs with nice UIs. You don't like the Xine interface? Use Totem. Problem solved.
Like most things, you just have to shop around, instead of pointlessly throwing around stereotypes.
Eh? KDEs own usability project has found that this isn't really the case. I often work the IRC tech support channels, if I had a penny for every time I'd been asked where a certain setting was in the KDE control centre (because they couldn't find it), I'd be a rich man.
Also, the default KDE style, Keramik, is very nice and usable, I recommend sticking with it
Blaaat. There was a thread on the kde-usabiltiy mailing list a few weeks ago now (?) about Keramik and how the usability team know it sucks from an ease of use perspective but it's a problem for the art team. They are actively seeking to tone it down, because it's so bombastic it gets in the way of actual usability.
It takes longer to boot because in the name of portability it replicates stuff already available in the OS, and because it hasn't been optimized well yet. Even the next version boots significantly quicker.
Ms can tweak the OS to make their own software more desirable, it is called system hooks
I call your bluff. Do you have any evidence of that, or are you just assuming?
Here's an interesting experiment. Install Office, delete Windows and reinstall it. Run Word. Note how fast it starts up, despite having all its registry entries deleted.
Here's another interesting experiment. Load up Word under Wine. Note that it starts in roughly the same amount of time as on Windows. Hunt through the Wine sources, looking for Word-specific hooks. Actually, don't bother, I can tell you there aren't any.
Office is fast because Microsoft know how to write fast code and optimize their own software for their own OS. I've not seen any evidence that Office or IE cheats in any way. If you wanted, you could write COM objects that provide similar integration into Windows but for Mozilla and Gecko. I still think it'd be slower though. That's just the price of portability.