What CmdrTaco said about file ratios is pretty accurate. I ran a BBS for several years and found this to be true.
It was also true for Post/Call ratios when implemented on some boards (ie, not letting the user play LORD until he has reached a Post/call ratio of 1, or whatever). This basically created a message base full of crappy 1-line posts (also true on some web-based forums where users with X posts are rewarded with a special 'ranking').
Probably not a direct response to Kylix -- I understand Borland is probably paying Trolltech quite a bit to take the Qt commercial license fees off the hands of Kylix owners.
Interesting read. Admidditedly, I'm not a kernel expert, but from everything I've heard 2.4 should be much faster in terms of speed and scalability (partly from Linus himself, along with reading kernel traffic).
I wasn't aware of the VFS situation, and I'm suprised that no specification was written for it (and no test suites were written for it?) -- but I'm not in a position to necessarily criticize them for that as I don't know all the facts.
This document is a mixed bag, with some parts being better than others. Here are some issues I found with it:
"After getting a Linux CD, you'll probably be up and running within an hour. In the olden days, this has been true, and Linux can be made hard to install."
Not to be a grammar nazi here (we have someone at slashdot filling that position already), but "this" is unclear, and may confuse some people about the facts, as it implies that being up and running within an hour was only true in the olden days.
"Linux is well over twice as fast as NT"
Generalizations like this should have no place in a document of this type, especially considering you don't back this statement up with any data. Statements like these should be what your document is fighting against. Specifically, twice as fast at what? While it's probably true that Linux 2.4 is significantly better than NT at several tasks, there are definitely situations where NT beats Linux 2.2.
That's nonsense. GUIs are not about simplifying common operations. There's NO RULE that says you have to sacrifice power when writing GUI applications. It is this very attitude that keeps me working in a CLI most of the time.
Yeah, I know you can come up with some drag and popup system to handle appends. But that's not the point. You can't handle every possible command, so it would be nice to have something there for people who know what they're doing. It *IS* possible to get the benefits of a GUI and the efficiency of a CLI in one if they had this.
What if I want to remove all mp3's in the current directory? Watch me do it faster with "rm *.mp3" than you can with the mouse. And like I said, you always have the option to open up an xterm and do it, but that's an unnecessary step in my opinion.
And of course, in the "Beginner" mode of Nautilus they wouldn't have to see the shell -- perhaps Expert mode only.
I haven't tried the preview release yet because I'm at work and can't, but hopefully someone familiar enough with Nautilus can answer this.
Is there any support or capability to do complex shell operations in Nautilus? For example, in the CLI you can append two text files by typing:
% cat file1 >> file2
This is great -- appending files with very little effort, something probably not possible in Windows Explorer. Now, what I'm wondering is, how could this be done in Nautilus? Rather than trying to think up of some GUI analogy for this _specific_ operation, I think it would be best to have some kind of "shell command prompt" sitting below the GUI file listing -- where commands entered would execute with respect to the current directory in Nautilus. The listing would usually need to be refreshed after execution, too.
There's endless possibilities to this, like selecting the file icon and having it paste to the text input box, or having it pass the selected files as parameters. I can't be the first/only one who has thought of this, and I would be suprised if Nautilus didn't already support something like this. Basically, this type of thing would be preffered over opening a new xterm, cd'ing to the right directory, and doing what you want.
So is it already there with a certain option enabled, or does the capability exist through some customization/component building?
Sorry, I really don't feel like explaining it all:) But, go to Technocrat and search for the semi-recent story on it.
Basically, it's similar to the KDE/Qt situation. Lots of KDE code is GPLed, but it depends on Qt, whose license is incompatible with the GPL. Thus, distributing the two together violates the GPL (I guess). In the GPL there is some vagueness that creates debate.
Also, at first Galeon included some Mozilla header files, which was definitely a problem. Since then, we've stopped doing that of course.
Much of Galeon's elegance is because of the gtkmozembed widget. Very little of it would be possible without Mozilla.
Getting Galeon to work will improve in the future. There are plans to package a "embed" package of Mozilla that includes just the gtk widget and required files. Early versions are already appearing in the nightly directories on the Mozilla ftp site. The package is much smaller, and works fine.
You are right, although it wasn't just the gtkmozembed header files either, it was much more complicated than that.
As it turns out, RMS himself helped us out and determined that we indeed would need to add a clause to the Galeon license for allowing us to link to the MPLed code. Without it, Helix Code and Debian probably wouldn't be able to distribute Galeon (for similar reasons why Debian doesn't include KDE). This kinda sucked, so we do plan to add the clause which will fix everything.
However, once this change occurs, we will no longer need it -- it will definitely make things more simple, though. We probably have Chris Blizzard to thank for this (in part).
Most importantly, it will better prevent duplicated efforts to have a GPLed rendering component in the future. And yes, this would have become an issue sooner or later.
Galeon 0.7.1 seems to work with M17. The only change I've noticed: the scrollbar is no longer the gnome one, it is the mozilla one (from the default skin). Does gtkmozembed mean 'embed gnome into mozilla'?
Well, assuming you mean Gtk+ scrollbar and not Gnome scrollbar, I've heard it may no longer be possible to support anything other than the XUL one. gtkmozembed just provides mozilla in a gtk widget.
We get those same type of requests everyday on the mailing list, so we added them to a temporary FAQ. We don't support them yet because they weren't possible with the gtkmozembed API at the time. It's not as trivial as you would expect at all.
Cheerleading? Perhaps you should check the latest Spec99 results. Quite impressive, disk I/O suckage notwithstanding.
Actually, as I understand it from following the LKML, the I/O performance varies from development kernel to development kernel and they're still tracking issues down (ie, someone reports 200% improvement on one kernel, but says it's worse in another.. really amazing actually).
Slashdot Mirror
What CmdrTaco said about file ratios is pretty accurate. I ran a BBS for several years and found this to be true.
It was also true for Post/Call ratios when implemented on some boards (ie, not letting the user play LORD until he has reached a Post/call ratio of 1, or whatever). This basically created a message base full of crappy 1-line posts (also true on some web-based forums where users with X posts are rewarded with a special 'ranking').
If they used the euro period for thousands in 205540, why did they not use the comma for 2.5 million?
Probably not a direct response to Kylix -- I understand Borland is probably paying Trolltech quite a bit to take the Qt commercial license fees off the hands of Kylix owners.
Interesting read. Admidditedly, I'm not a kernel expert, but from everything I've heard 2.4 should be much faster in terms of speed and scalability (partly from Linus himself, along with reading kernel traffic).
I wasn't aware of the VFS situation, and I'm suprised that no specification was written for it (and no test suites were written for it?) -- but I'm not in a position to necessarily criticize them for that as I don't know all the facts.
Also, in a document like this, you probably shouldn't keep referring to yourself (e.g, "I like ...")
:)
The GUI/desktop myth section needs a lot of cleaning up.
Just more constructive criticism
"After getting a Linux CD, you'll probably be up and running within an hour. In the olden days, this has been true, and Linux can be made hard to install."
Not to be a grammar nazi here (we have someone at slashdot filling that position already), but "this" is unclear, and may confuse some people about the facts, as it implies that being up and running within an hour was only true in the olden days.
"Linux is well over twice as fast as NT"
Generalizations like this should have no place in a document of this type, especially considering you don't back this statement up with any data. Statements like these should be what your document is fighting against. Specifically, twice as fast at what? While it's probably true that Linux 2.4 is significantly better than NT at several tasks, there are definitely situations where NT beats Linux 2.2.
Haven't finished reading the rest of it yet.
They do, it's used extensively in preview releases of Evolution and Nautilus. Bonobo components already exist for software like EOG.
he was joking... you know, pretending as if he believed it weren't to be an animated movie. it was pretty funny -- too bad you didnt catch it.
BTW, LabVIEW 6.0 was just released this week, and it has been available for Linux since 5.0. See http://www.ni.com/linux.
I program in LabVIEW almost exclusively for my job, though I still prefer text-based languages.
That's nonsense. GUIs are not about simplifying common operations. There's NO RULE that says you have to sacrifice power when writing GUI applications. It is this very attitude that keeps me working in a CLI most of the time.
Yeah, I know you can come up with some drag and popup system to handle appends. But that's not the point. You can't handle every possible command, so it would be nice to have something there for people who know what they're doing. It *IS* possible to get the benefits of a GUI and the efficiency of a CLI in one if they had this.
What if I want to remove all mp3's in the current directory? Watch me do it faster with "rm *.mp3" than you can with the mouse. And like I said, you always have the option to open up an xterm and do it, but that's an unnecessary step in my opinion.
And of course, in the "Beginner" mode of Nautilus they wouldn't have to see the shell -- perhaps Expert mode only.
I haven't tried the preview release yet because I'm at work and can't, but hopefully someone familiar enough with Nautilus can answer this.
Is there any support or capability to do complex shell operations in Nautilus? For example, in the CLI you can append two text files by typing:
% cat file1 >> file2
This is great -- appending files with very little effort, something probably not possible in Windows Explorer. Now, what I'm wondering is, how could this be done in Nautilus? Rather than trying to think up of some GUI analogy for this _specific_ operation, I think it would be best to have some kind of "shell command prompt" sitting below the GUI file listing -- where commands entered would execute with respect to the current directory in Nautilus. The listing would usually need to be refreshed after execution, too.
There's endless possibilities to this, like selecting the file icon and having it paste to the text input box, or having it pass the selected files as parameters. I can't be the first/only one who has thought of this, and I would be suprised if Nautilus didn't already support something like this. Basically, this type of thing would be preffered over opening a new xterm, cd'ing to the right directory, and doing what you want.
So is it already there with a certain option enabled, or does the capability exist through some customization/component building?
haha, i must admit - the trolls on this article are much more clever than the usuals.
Sorry, I really don't feel like explaining it all :) But, go to Technocrat and search for the semi-recent story on it.
Basically, it's similar to the KDE/Qt situation. Lots of KDE code is GPLed, but it depends on Qt, whose license is incompatible with the GPL. Thus, distributing the two together violates the GPL (I guess). In the GPL there is some vagueness that creates debate.
Also, at first Galeon included some Mozilla header files, which was definitely a problem. Since then, we've stopped doing that of course.
Nautilus can still use Gtkhtml
As for the memory, don't be deceived by the amplified amount displayed by ps due to threads. Count just one thread.
Much of Galeon's elegance is because of the gtkmozembed widget. Very little of it would be possible without Mozilla.
Getting Galeon to work will improve in the future. There are plans to package a "embed" package of Mozilla that includes just the gtk widget and required files. Early versions are already appearing in the nightly directories on the Mozilla ftp site. The package is much smaller, and works fine.
You are right, although it wasn't just the gtkmozembed header files either, it was much more complicated than that.
As it turns out, RMS himself helped us out and determined that we indeed would need to add a clause to the Galeon license for allowing us to link to the MPLed code. Without it, Helix Code and Debian probably wouldn't be able to distribute Galeon (for similar reasons why Debian doesn't include KDE). This kinda sucked, so we do plan to add the clause which will fix everything.
However, once this change occurs, we will no longer need it -- it will definitely make things more simple, though. We probably have Chris Blizzard to thank for this (in part).
Yes, definitely.
Most importantly, it will better prevent duplicated efforts to have a GPLed rendering component in the future. And yes, this would have become an issue sooner or later.
Other than variable name choosing and source code comments, probably nothing.
of course
Wow, thanks for all that. Text is much nicer.
Galeon 0.7.1 seems to work with M17. The only change I've noticed: the scrollbar is no longer the gnome one, it is the mozilla one (from the default skin). Does gtkmozembed mean 'embed gnome into mozilla'?
Well, assuming you mean Gtk+ scrollbar and not Gnome scrollbar, I've heard it may no longer be possible to support anything other than the XUL one. gtkmozembed just provides mozilla in a gtk widget.
No, Galeon depends on gnome libs
We get those same type of requests everyday on the mailing list, so we added them to a temporary FAQ. We don't support them yet because they weren't possible with the gtkmozembed API at the time. It's not as trivial as you would expect at all.
Cheerleading? Perhaps you should check the latest Spec99 results. Quite impressive, disk I/O suckage notwithstanding.
Actually, as I understand it from following the LKML, the I/O performance varies from development kernel to development kernel and they're still tracking issues down (ie, someone reports 200% improvement on one kernel, but says it's worse in another.. really amazing actually).