Seriously, I find this a big problem: Firebird has never (apart from a short time in February (I think) for the nightly builds) released a tarball of the source used to make either (a) the stable releases or (b) the nightly builds.
Grabbing code from CVS really isn't the same, since it's changing all the time - at the very least the stable releases should have a snapshot of the relevant parts of the CVS tree at the time the binaries were compiled. And AFAIK you can't use CVS with a proxy server...
Wow! You really don't like the nvidia drivers, do you?? What card were you using? I personally have an ancient TNT2 M64, which performs just fine with all the different incarnations of the commercial drivers (I think X has hung twice in about four years, and this probably wasn't any fault of nvidia's). In fact, the most recent versions seem to have increased my 3D fps by about 10% - it's nice to see that the drivers are becomming more efficient, rather than less so.
I'd be interested to know whether there are problems with newer nvidia cards with these drivers (since I'm considering upgrading my system)? Or are you just an exception?
As I see it, many would like to keep the learning curve very, very steep and high to maintain their exclusivity and "leetness" if you will.
No, I think it's more like "if it works for me, that's good enough" in many situations. Nobody's paying opensource programmers to make things nice and user friendly, after all!!
I always thought that it would have been a better to line to say that they were using humans for processing power (a beowulf cluster of billions of humans brains).
And it would have been an almost poetic role reversal - not humans using machines to do their complex calculations, but machines using humans...
Eh? Latest firebird nightlies render the page just fine... *shrug*...
But I agree with your comments otherwise - it was posted anonymously, so there can't be any suggestions of karma whoring. And mirroring the text can't be bad (well, except in a copyright sense:)
Would be interesting to see ROX get a little more attention in the world of window managers / desktop
It's funny, but a lot of the software I now routinely use I first heard of through slashdot, including ROX about a year ago. I still think ROX has a bit of a way to go, though, since the copy file/move file/delete/rename/etc dialogue boxes are a bit unfriendly (they're barely more than a interface to sh). But in terms of speed it blows konqueror and nautillus out of the water (except maybe with the new list display, which I find very slow when viewing a directory with a large number of files) And once you reconfigure the ugly default icons it doesn't look half bad, either.
That is just plain bullshit. No audio codec is going to relieve fatigue. Even if you do believe it.
Heh, you obviously never read this article on slashdot, then:)
Seriously, if the poster encoded mp3's with Lame's default options then I wouldn't be surprised if he noticed a difference: lame's default model chops out high frequencies, but the higher the bandwidth the higher the cut-off is placed. Thus a 320kbps mp3 has much more information in the 16kHz -> 22kHz range than a 128kbps mp3 (which has bugger all). And there's a school of thought that claims that those high frequencies (which you supposedly can't hear) still effect your perception of sound.
If you can strip out the network part of X and increase the speed, DO IT.
A simple question: does the network protocol of X reduce the speed of X when client and server are on the same machine? I've never seen anything to substantiate this assumption that a lot of people seem to make.
Built so many layers. We have the linux kernel, then X, then kde, then evolution, then its themes. And each click or window moving transcends into ALL these layers with risks and bugs collected over.
Ummmm... correct me if I'm wrong, but don't you have exactly the same thing in Windows? (only there's no choice so you don't think about the different components) - eg, we have the Windows kernel, then the Windows windowing system, then the Windows toolkit, etc, etc. And since you can use gtk+ on Windows, and every office release Microsoft seems to make their own toolkit, I'm guessing that the Windows toolkit, at least, is not built into the kernel...
The bulk of users are still paying Microsoft $100 every two years and sticking with Windows. We did something wrong somewhere.
Not at all. A lot of users like their computers to be "dumbed down" such that they feel "safe" when using it. They don't want to be able to tweak settings because they're too scared of doing something wrong and somehow destroying their system. Hell, a lot of people are scared of Windows! But linux and its component software was never written for people like that, and that's the big difference between the OS's. For most people Windows is the better OS, but that doesn't mean that linux did anything wrong - only that it was written for a different user group.
(remember, World Domination (TM) is not always a good thing...)
X + twm loads quick even on my old AMD K6-2 450 MHz. Not that I use twm, but I have tried it to see how fast it is in comparison to KDE/Gnome.
You might be interested in combining IceWM with ROX to get a good looking "desktop environment" without the bloat. (You will have to play around with text config files for IceWM, though, which is not everyone's cup of tea)... but I actually find IceWM runs faster than twm or fvwm* - and it has many of the features of KDE.
Um. Yeah. Let's scrap X and using something completely incompatible. Furthermore, let's scrap gtk+ and qt instead of porting them! So almost every single application with a gui ever written now doesn't work in your new system. No GIMP, no mplayer, no XMMS, no mozilla/firebird, no konqueror, no evolution, no anything... well, not unless you fork them and rewrite them to work with your new system.
In reality, I think you'll find that we're fairly much stuck with X. And while ever there's gtk+ and qt, we're fairly much stuck with two major competing toolkits. The problem is, I don't think you can have the freedom of open source on the one hand, and at the same time somehow expect everyone to use a single toolkit and not have someone decide to develop their own. In fact, even if you write a whole new graphical windowing system from scratch I'll bet someone will write an alternative tool kit. Or more likely will port gtk and/or qt over to your new windowing system so that all their favorite apps work again.
And as far as X goes... what I'd really like to see in terms of criticism would be something more than sweeping statements. You claim "x is just pretty goddamn slow all-around", yet on my ageing hardware, X, as judged through XFree86, seems to perform more than fine. I don't notice it being any slower than windows on the same machine. Do you have any concrete examples to demonstrate the problems with X? I'm genuinely curious here!
Well, you're thinking in command line, so it seems hard to do in a gui, but your problem is wanting to specify everything all at once, up front: In a gui, you start program foo; open some_file; pick some_options; write to some_other_file. Which sounds like more steps. And it is if you know program foo by heart; Otherwise, it's that some_options step that's crucial.
Well, the some_options documentation is generally solved by "foo --help" (on a good CLI app:), but I can see your point - CLIs are not for new/inexperienced users. And I agree - they are a "power user" thing and not user-friendly. But the big advantage of CLIs is that it's so easy to run batch commands from the shell on a CLI program.
Note, btw, that I never said that CLI's were the One-True-Path that all applications should follow, rather my point was that CLI's do have their place and removing them from a system is not necessarily a forward step.
Well, what you are suggesting above is pretty much just a misunderstanding of what a GUI is. You'd do all those steps with stuff like "open file", "select options", "press OK", "save". Or something similar.
Sure, but it's a hell of a lot slower and requires fiddling with the mouse and the keyboard, which is cumbersome. And as you mention, I can't do batch processing with a "while $i in *.bar..."
The biggest drawback compared to CLI is that you can't pipe stuff.
Funnily enough, the Unix Haters thinks that pipes are a joke. Which is one of the reasons I've never really respected that book:)
"CLIs may not be intuitive, but they are powerful in that they can run commands with various changable options."
Which is somehow impossible with a gui?
Not impossible, but a lot more difficult in my experience! I can't see any way to do this without the whole create-a-shortcut-and-change-the-command-line-with in -the-shortcut proceedure in Windows (which is just using a command line anyway!)... but I'm probably wrong here. Is there an equivalent way of running
Yeah, whenever I debug a program, and it stops at an exception, poping up the relevant source file, the values of local variables, and the complete call stack onto my screen automatically, I'm just begging to be back on a text only terminal...
[removes foot from mouth]... OK, that was pretty stupid of me. I just normally program in perl (for which I do use the CLI to debug)...
Ehhhh, I'm not so sure about that. The organization of files and directories is essentially the same either way, and I find it easier to navigate within a terminal window than with a graphical browser.
I actually use ROX as my file manager, which integrates very nicely with the command line (very simple to switch between xterms and file manager windows, and you can keyboard/tab navigate to different directories similar to the command line too). Personally I find it easier to drag and drop groups of unrelated files than to do multiple move commands, for example. My main requirement is that a file manager should be small and fast - before I found ROX I was using the CLI for all file management. (although these days ROX seems to be getting a bit bloated and slow itself, sadly, and I'm using an older version in consequence)
Hmmm... I just spent last week reading the Unix Hater's book (print edition) and I really wasn't very impressed - many of their quibles are not applicable in 2003, however much they may have been present in 1994. Sure, some of what they say is fair enough, but most is just laughable.
A) Cryptic Command Names. Still there in Linux
This point is fair enough, although it doesn't worry me at all. A name's a name - once you know it, what does it matter?
B) "Unix was like Homer, handed down as oral wisdom."
Man, this is so true. I got most of my UNIX knowledge passed down to me by upperclassmen and professors. It is amazing how much training it takes in UNIX to do something simple in Windows. For example, recursively searching through a subtree for some text in a file.
Your example is a rather odd one to pick! I find the grep command extremely fast and easy to use - the equivalent in windows (AFAIK, correct me if I'm wrong) would be to open the find file dialogue, browse to the relevant folder, enter the search terms and click the find button - a clumsy combination of text and mouse that is tedious and slow - to the point that I usually don't bother. I'd take grep anyday! I can't think of anything that's faster in windows than in a modern linux distro, although I'm sure there must be something!
C) Terminal Insanity. Still there in many ways. VT100 pops up its ugly head decades after it should have been killed.
I guess this would be a fair comment to make, although I've personally never noticed any problems with linux terminal emulation - it works fine for me and I've never had issues with this.
D) The X-Windows Disaster. X-Windows is what first made me question UNIX's superiority. Dang X sucks. Bad. What a mess! "Motif Self-Abuse Kit" made me laugh because my brief experience programming Motif was one of the worst in my life. It was a mess of void pointers and pointers to functions that was an absolute pain to program.
X is a lot better nine years on, and I can't help wondering if everyone who writes "X sucks" is still using a 3.x version or lower. Sure there are some problems with X (the monolithic nature of it is one that comes to mind) but in practise I find it highly stable and fast (and I use X 4.3.0 with a Pentium 120 and a 500 MHz Celeron so if there were speed issues I think I'd be aware of them!) And motif programming??? Sure, everyone programs in motif these days! GTK and QT are dead, long live motif! (yes, it may well have been a nightmare, but I've programmed in linux for three years and never had to worry about motif - please update your argument!)
E) Make "Unfortunately, in their zeal to be general, many Unix tools forget about the quick and easy part."
CLIs in general are *not* intuitive. I mean think about it the current metaphors that the GUIs use. You want to move a file in the real work.. you grab it and put it in another folder. You dont say "move this file to there".
Qualification: a while a CLI can manage files, its major function is not as a file manager.
CLIs may not be intuitive, but they are powerful in that they can run commands with various changable options. And they make debugging/testing programs a lot easier.
What CLI's are not good for is general file management, which is one reason why modern linux distros come with GUI file managers and why I use one for managing my files. But if anyone removed the terminals and shells from my computer I'd go insane - I'm always cursing the CLI (or what passes for it) in Win2K at work and wishing there was a decent implementation of BASH for windows...
GUIs are good for simple tasks you don't do very often. The command line and scripting languages have the power to automate and achieve complex tasks.
Yes, you're right. Only I've never heard anyone who's not a geek praise the command line. Most users complain that "you have to remember all these complicated commands"... and you'd have to admit that for a new user a command line has a steeper learning curve - especially when they don't know about tab-completion and command history.
Part of the problem is that Microsoft never had a decent command-line shell... hell, they still don't even after decades of DOS! In Windows, Microsoft has always presented the command-line to users as a frightening thing that they don't want to go near to save themselves; is it any wonder that a new linux user like the anonymous parent poster thinks the same way?
I think most users simply want a nice little icon they can click on the panel to start their favourite web browser or word-processor, and that's about it. They're not going to worry about writing little shell scripts, and they're certainly not going to run batch comands! And even if it's about three hundred times slower to extract a tarball with a GUI than with the command line, that never seems to bother them.
I'm sorry, but IMHO this refigerated-microwave thing has to take out the LG-Internet-Refrigerator-Award for the most stupid application of technology.
I mean, if I want to heat up a meal in a microwave it takes all of two minutes; if I want to defrost meat it takes at most five minutes. So what am I going to do - stop the car *two minutes* away from home and call up my microwave just so I can have that hot meal waiting for me when I come in the door??
My only real complaint about it is that it is still so slow to load (on Linux, anyway - dunno about the winbloze version).
As of 1.0.1 the windows version took just as long... (dunno about the new beta)... I realise that OOo needs to load a whole toolkit, etc, but surely it's getting on the bloat side when in Linux I can start MS Word 97 using wine and it loads faster than native OOo! This is a big problem, IMO - an app that takes around a minute to load just reeks of inefficient programming and clumsiness. The snapiness of MS Office is very impressive.
But apart from that there's still some major issues in OOo 1.0.2 that I doubt have been fixed in the beta (haven't noticed anything about these in the changelogs, but I could be wrong): these are
a) Decent graph support: Excel is the default graphing software of millions (sad but true), and OOo's graphing capabilities can't stand up to it (they're useless for anything other than the simplest graphs - no error bars, etc)
b) BibTeX and/or Endnote bibliography support. If you want word-processing software to be universally accepted, make it so that it is accepted in universities. And this means the ability to use a bibliographic database! This is a vital aspect that has always been missing in OOo, and considering that it already has db support, it surely would not be too hard to add this in.
That's probably it. If OOo ditched two-thirds of the bloat, turned the ugly monolithic thing into separate apps that loaded faster and incorporated those two changes, I think a lot of MS Office users would consider switching.
gVIM is available on windows (not to mention just about every other platform...) and when combined with Cream makes a highly usable text editor that's excellent for writing anything from html to programming.
Slashdot Mirror
Seriously, I find this a big problem: Firebird has never (apart from a short time in February (I think) for the nightly builds) released a tarball of the source used to make either (a) the stable releases or (b) the nightly builds.
Grabbing code from CVS really isn't the same, since it's changing all the time - at the very least the stable releases should have a snapshot of the relevant parts of the CVS tree at the time the binaries were compiled. And AFAIK you can't use CVS with a proxy server ...
I'd be interested to know whether there are problems with newer nvidia cards with these drivers (since I'm considering upgrading my system)? Or are you just an exception?
No, I think it's more like "if it works for me, that's good enough" in many situations. Nobody's paying opensource programmers to make things nice and user friendly, after all!!
What's the difference between encap and GNU Stow? Quickly glancing at encap's web page they seem very similar.
Regardless, you might find the following bash alias useful:
alias ./configure='./configure --prefix=/usr/local/stow/$( echo `pwd` | sed -e s#.*/##g)'
:)
(just replace "stow" with "encap", I guess
And it would have been an almost poetic role reversal - not humans using machines to do their complex calculations, but machines using humans ...
But I agree with your comments otherwise - it was posted anonymously, so there can't be any suggestions of karma whoring. And mirroring the text can't be bad (well, except in a copyright sense :)
Does anyone know how to disable this prompt in mozilla without downloading/installing/disabling flash??
It's funny, but a lot of the software I now routinely use I first heard of through slashdot, including ROX about a year ago. I still think ROX has a bit of a way to go, though, since the copy file/move file/delete/rename/etc dialogue boxes are a bit unfriendly (they're barely more than a interface to sh). But in terms of speed it blows konqueror and nautillus out of the water (except maybe with the new list display, which I find very slow when viewing a directory with a large number of files) And once you reconfigure the ugly default icons it doesn't look half bad, either.
Heh, you obviously never read this article on slashdot, then :)
Seriously, if the poster encoded mp3's with Lame's default options then I wouldn't be surprised if he noticed a difference: lame's default model chops out high frequencies, but the higher the bandwidth the higher the cut-off is placed. Thus a 320kbps mp3 has much more information in the 16kHz -> 22kHz range than a 128kbps mp3 (which has bugger all). And there's a school of thought that claims that those high frequencies (which you supposedly can't hear) still effect your perception of sound.
It saves you money :)
(Note: I was once hardcore pro-mac. I like to think of myself as reformed now. ;)
A simple question: does the network protocol of X reduce the speed of X when client and server are on the same machine? I've never seen anything to substantiate this assumption that a lot of people seem to make.
Ummmm ... correct me if I'm wrong, but don't you have exactly the same thing in Windows? (only there's no choice so you don't think about the different components) - eg, we have the Windows kernel, then the Windows windowing system, then the Windows toolkit, etc, etc. And since you can use gtk+ on Windows, and every office release Microsoft seems to make their own toolkit, I'm guessing that the Windows toolkit, at least, is not built into the kernel ...
The bulk of users are still paying Microsoft $100 every two years and sticking with Windows. We did something wrong somewhere.
Not at all. A lot of users like their computers to be "dumbed down" such that they feel "safe" when using it. They don't want to be able to tweak settings because they're too scared of doing something wrong and somehow destroying their system. Hell, a lot of people are scared of Windows! But linux and its component software was never written for people like that, and that's the big difference between the OS's. For most people Windows is the better OS, but that doesn't mean that linux did anything wrong - only that it was written for a different user group.
(remember, World Domination (TM) is not always a good thing ...)
You might be interested in combining IceWM with ROX to get a good looking "desktop environment" without the bloat. (You will have to play around with text config files for IceWM, though, which is not everyone's cup of tea) ... but I actually find IceWM runs faster than twm or fvwm* - and it has many of the features of KDE.
In reality, I think you'll find that we're fairly much stuck with X. And while ever there's gtk+ and qt, we're fairly much stuck with two major competing toolkits. The problem is, I don't think you can have the freedom of open source on the one hand, and at the same time somehow expect everyone to use a single toolkit and not have someone decide to develop their own. In fact, even if you write a whole new graphical windowing system from scratch I'll bet someone will write an alternative tool kit. Or more likely will port gtk and/or qt over to your new windowing system so that all their favorite apps work again.
And as far as X goes ... what I'd really like to see in terms of criticism would be something more than sweeping statements. You claim "x is just pretty goddamn slow all-around", yet on my ageing hardware, X, as judged through XFree86, seems to perform more than fine. I don't notice it being any slower than windows on the same machine. Do you have any concrete examples to demonstrate the problems with X? I'm genuinely curious here!
Well, the some_options documentation is generally solved by "foo --help" (on a good CLI app :), but I can see your point - CLIs are not for new/inexperienced users. And I agree - they are a "power user" thing and not user-friendly. But the big advantage of CLIs is that it's so easy to run batch commands from the shell on a CLI program.
Note, btw, that I never said that CLI's were the One-True-Path that all applications should follow, rather my point was that CLI's do have their place and removing them from a system is not necessarily a forward step.
Sure, but it's a hell of a lot slower and requires fiddling with the mouse and the keyboard, which is cumbersome. And as you mention, I can't do batch processing with a "while $i in *.bar ..."
The biggest drawback compared to CLI is that you can't pipe stuff.
Funnily enough, the Unix Haters thinks that pipes are a joke. Which is one of the reasons I've never really respected that book :)
"CLIs may not be intuitive, but they are powerful in that they can run commands with various changable options."
Which is somehow impossible with a gui?
Not impossible, but a lot more difficult in my experience! I can't see any way to do this without the whole create-a-shortcut-and-change-the-command-line-with in -the-shortcut proceedure in Windows (which is just using a command line anyway!) ... but I'm probably wrong here. Is there an equivalent way of running
foo --some_options --input=some_file --output=some_other_file?
Yeah, whenever I debug a program, and it stops at an exception, poping up the relevant source file, the values of local variables, and the complete call stack onto my screen automatically, I'm just begging to be back on a text only terminal...
[removes foot from mouth] ... OK, that was pretty stupid of me. I just normally program in perl (for which I do use the CLI to debug) ...
Yes, most of the time I do realise this ... I haven't had enough sleep and I've been defending XFree86 recently :)
Ehhhh, I'm not so sure about that. The organization of files and directories is essentially the same either way, and I find it easier to navigate within a terminal window than with a graphical browser.
I actually use ROX as my file manager, which integrates very nicely with the command line (very simple to switch between xterms and file manager windows, and you can keyboard/tab navigate to different directories similar to the command line too). Personally I find it easier to drag and drop groups of unrelated files than to do multiple move commands, for example. My main requirement is that a file manager should be small and fast - before I found ROX I was using the CLI for all file management. (although these days ROX seems to be getting a bit bloated and slow itself, sadly, and I'm using an older version in consequence)
Hmmm ... I just spent last week reading the Unix Hater's book (print edition) and I really wasn't very impressed - many of their quibles are not applicable in 2003, however much they may have been present in 1994. Sure, some of what they say is fair enough, but most is just laughable.
This point is fair enough, although it doesn't worry me at all. A name's a name - once you know it, what does it matter?
Man, this is so true. I got most of my UNIX knowledge passed down to me by upperclassmen and professors. It is amazing how much training it takes in UNIX to do something simple in Windows. For example, recursively searching through a subtree for some text in a file.
Your example is a rather odd one to pick! I find the grep command extremely fast and easy to use - the equivalent in windows (AFAIK, correct me if I'm wrong) would be to open the find file dialogue, browse to the relevant folder, enter the search terms and click the find button - a clumsy combination of text and mouse that is tedious and slow - to the point that I usually don't bother. I'd take grep anyday! I can't think of anything that's faster in windows than in a modern linux distro, although I'm sure there must be something!
I guess this would be a fair comment to make, although I've personally never noticed any problems with linux terminal emulation - it works fine for me and I've never had issues with this.
X is a lot better nine years on, and I can't help wondering if everyone who writes "X sucks" is still using a 3.x version or lower. Sure there are some problems with X (the monolithic nature of it is one that comes to mind) but in practise I find it highly stable and fast (and I use X 4.3.0 with a Pentium 120 and a 500 MHz Celeron so if there were speed issues I think I'd be aware of them!) And motif programming??? Sure, everyone programs in motif these days! GTK and QT are dead, long live motif! (yes, it may well have been a nightmare, but I've programmed in linux for three years and never had to worry about motif - please update your argument!)
Maybe. I can see your point here.
Qualification: a while a CLI can manage files, its major function is not as a file manager.
CLIs may not be intuitive, but they are powerful in that they can run commands with various changable options. And they make debugging/testing programs a lot easier.
What CLI's are not good for is general file management, which is one reason why modern linux distros come with GUI file managers and why I use one for managing my files. But if anyone removed the terminals and shells from my computer I'd go insane - I'm always cursing the CLI (or what passes for it) in Win2K at work and wishing there was a decent implementation of BASH for windows ...
GUIs are good for simple tasks you don't do very often. The command line and scripting languages have the power to automate and achieve complex tasks.
Yes, you're right. Only I've never heard anyone who's not a geek praise the command line. Most users complain that "you have to remember all these complicated commands" ... and you'd have to admit that for a new user a command line has a steeper learning curve - especially when they don't know about tab-completion and command history.
Part of the problem is that Microsoft never had a decent command-line shell ... hell, they still don't even after decades of DOS! In Windows, Microsoft has always presented the command-line to users as a frightening thing that they don't want to go near to save themselves; is it any wonder that a new linux user like the anonymous parent poster thinks the same way?
I think most users simply want a nice little icon they can click on the panel to start their favourite web browser or word-processor, and that's about it. They're not going to worry about writing little shell scripts, and they're certainly not going to run batch comands! And even if it's about three hundred times slower to extract a tarball with a GUI than with the command line, that never seems to bother them.
I mean, if I want to heat up a meal in a microwave it takes all of two minutes; if I want to defrost meat it takes at most five minutes. So what am I going to do - stop the car *two minutes* away from home and call up my microwave just so I can have that hot meal waiting for me when I come in the door??
I think not ...
As of 1.0.1 the windows version took just as long ... (dunno about the new beta) ... I realise that OOo needs to load a whole toolkit, etc, but surely it's getting on the bloat side when in Linux I can start MS Word 97 using wine and it loads faster than native OOo! This is a big problem, IMO - an app that takes around a minute to load just reeks of inefficient programming and clumsiness. The snapiness of MS Office is very impressive.
But apart from that there's still some major issues in OOo 1.0.2 that I doubt have been fixed in the beta (haven't noticed anything about these in the changelogs, but I could be wrong): these are
a) Decent graph support: Excel is the default graphing software of millions (sad but true), and OOo's graphing capabilities can't stand up to it (they're useless for anything other than the simplest graphs - no error bars, etc)
b) BibTeX and/or Endnote bibliography support. If you want word-processing software to be universally accepted, make it so that it is accepted in universities. And this means the ability to use a bibliographic database! This is a vital aspect that has always been missing in OOo, and considering that it already has db support, it surely would not be too hard to add this in.
That's probably it. If OOo ditched two-thirds of the bloat, turned the ugly monolithic thing into separate apps that loaded faster and incorporated those two changes, I think a lot of MS Office users would consider switching.
gVIM is available on windows (not to mention just about every other platform ...) and when combined with Cream makes a highly usable text editor that's excellent for writing anything from html to programming.
At least, it's far superior to notepad :)