> Except that FC really *isn't* like 7. I've been > finding all *kinds* of glitches, huccups, and > burps in FC 1.
And in what way is this NOT like RedHat 7? I'd say FC 1 was considerably LESS buggy than many "official" RedHat x.0 releases. 6.0 was so awful it almost made me switch distro. RedHat 7 (the first one with the infamous inofficial 2.96 gcc, in case anyone doesn't remember) was a complete bugstrosity, although updates stabilized it quite well within a few months of release. The number of RedHat Linux releases that were _not_ buggy horrors before the first deluge of post-release updates were in my experience only 6.2, 7.3 and 9.
FC1 should be compared to other RedHat x.0 releases, and at least in my experience, compared to gems like 6.0 or 7.0, i have to say FC1 compares quite favorably.
Don't get me wrong - I like and use RedHat. I'm only pointing out that the "regular" RedHat Linux releases have often been quite bleeding-edge and buggy, just like Fedora is now. Just like Alan Cox stated above.
Hmmm... I think you're wrong here. The surface of the sun (the part we actually see) is only around 6000C, whereas an exploding nuclear bomb is several _million_ degrees. It should have the brightness of the exposed _core_ of the sun.
Of course it depends on what you mean with "brightness". A million LEDs may put out more visible-light photons than a camera flash, but I think we can both agree on which one will leave the biggest blotch on your retina.
Don't forget that with a fission bomb, you're actually releasing stored-up excess energy from an ancient supernova explosion.;)
I realize that my post was possibly a bit unclear, since you apparently misunderstood most of it. Either that, or your reading comprehension sucks. Or a combination of both. The "misinformed" was in relation to your ignorance about _Linux_, not Solaris. I definitely should have started it out with "Here we go with the misinformed Solaris-advocates" not "Solaris-advocacy". And even that skews the meaning somewhat, since it's not your information about Solaris I'm questioning, its your misinformation about Linux, in relation to Solaris. I have run into far too many people who push Solaris over Linux, and who have the most bizarre ideas about what Linux lacks in comparison to Solaris. A bunch of the things you brought up have also been echoed by them. That's why I wondered if the misinformation about Linux was fed to Solaris admins/developers by SUN, through courses and similar - since the Solaris-advocates so often get the exact same things wrong about Linux.
The things that I claim require a reboot (in Solaris) however, were taken out of a SUN manual. I checked right before i posted, because I haven't worked with Solaris 9, and hence, I wanted to see if things had changed since 7 or 8. They hadn't.
I refer you to: http://docs.sun.com/db/doc/806-7009/6jftnqsj7 ?a=vi ew
Only one of the parameters are marked as Dynamic: yes. The rest are Dynamic: no, meaning, according to an earlier section of the same manual "Boot-time initialization only". If this is incorrect, I suggest you write SUN and tell them their manuals about their own operating system is either wrong, or unclear.
As for me agreeing with you, I agreed with you on only about only two things, proc, and devfs. In the rest of my post i was correcting your factual errors about Linux, and hence disagreeing with the percieved advantages you were claiming for Solaris.
And finally, as for this: > Stop being a jerk.
I can only say, if you want civil responses, don't start your own posts out with stuff like:
> This week's meeting of the Linux Mutual Admiration and Masturbation Society kicks off with
And here we go with the woefully mis-informed Solaris-advocacy again.
> I can make changes in the running kernel (instead of rebooting).
What "changes" are you talking about here? Modules in linux can be loaded and unloaded without rebooting, and that most definitely is "making changes in a running kernel".
> I can set control variables for the kernel on future reboots (instead of recompiling the entire thing).
Ok, here's the thing that really irks me. Where do you people GET this idiocy from? Does SUN feed you this BS at courses or something? You can set control variables in Linux on future reboots. Just edit/etc/sysctl.conf. However, in Linux, all these control variables can also be set _without_ even rebooting. And this is the real riot: you can set plenty of control variables in Linux without a reboot which in Solaris REQUIRE a reboot. Just issue "sysctl -p", and the new values in your sysctl.conf will be effective immediately. It's a hell of a lot nicer (my opinion, of course) than having to fire up the kernel debugger (*shudder*) to change dynamic variables, like you have to do in Solaris. To give an example, in Solaris SysV Shared Memory parameters are not dynamic and can only be changed by editing/etc/system and then doing a reboot. In linux, these are tunable on the fly.
And here follows more displays of fascinating ignorance/misinformation:
> Individual kernel modules can have their own read-on-module-load-by-the-kernel config file; in Linux the only general way of tweaking modules' control values is by editing the source./etc/modules.conf will set your read-on-module-load-by-kernel control values. No recompiles needed here either.
No argument about the mess that is/proc, except to say that/proc is a sometimes _useful_ mess sinnce it allows for tuning things on the fly that Solaris will only allow you to change with a reboot... like the abovementioned SysV shared memory settings.
No argument about devfs either. This most definitely IS something that solaris does better, and where Linux is catching up.
My own general impression from working with Linux and Solaris both, however, is that Solaris may be better in a few, small, specific areas mostly relating to really huge boxes, but that Linux stomps big time over Solaris in most areas, including areas where pure ignorance makes Solaris-advocates believe Solaris is superior.
*BLEEEET*. Wrong. Actually, _because_ of Disney, these books won't be in the public domain for almost another 50 years... They were the ones who lobbyed to have the period before something falls into the public domain extended to 70 years, to protect themselves from having characters like Mickey Mouse and Donald Duck become "public property."
> "Hollywood can never render Ford turning in to an infinite number of penguins better than you can in your head," as he put it.
Although it will no doubt make me smile just a little bit extra to know that those infinite number of penguins will have been rendered by a finite-but-large number of linux-boxes. I wonder if the animators will make the rendered penguins look just a little bit more like Tux, than a realistic penguin...
Why review only the beta version?
on
Mplayer Revisited
·
· Score: 5, Informative
MPlayer 0.92 is the current stable release where everything works as expected.
MPlayer 1.0-pre1 has some nice new stuff, but even though it has one thing (support for input from v4l devices with hardware MJPEG support) which I've wanted ofr a long time, the current pre-release is much too flakey for me to use, and I've gone back to 0.92.
MPlayer 1.0-pre1 is for writing bug-reports, not reviews.
Unless Mr. Barr had a conscious or subconscious WISH to find things that didn't work right, i don't see why he wrote his review for the pre1 version.
> Huh? You've found a place where "on call" means something else?
Yes. Where I work now, the guys in support have at least four hours after a call comes in before they have to be actively working on the problem. That gives plenty of time to go home from wherever you are, take a shower, grab your laptop, get to the office and start working. I, thank god, no longer work in support. No on-call whatsoever, and no overtime. Happy happy, joy joy.:)
Having worked at IGS some years ago, I can tell that at least where I was, we were _brutally_ understaffed and overworked in the second level support unit. People kept quitting, yet IGS kept taking new customers, without hiring any new techs to replace the ones that left. Projects were also often taken into production in horrific and unfinished state, leaving the support teams the unenviable task to finish the project while simultaneously handling operations and customer fault reports. The last month I worked there I had a crapload of overtime, and over 200 hours on call. On call didn't just mean having your phone on, it meant being at most 15 minutes away from my laptop and a phone jack so I could dial in and start working on the problem. It basically made me unable to leave my apartment. I have a friend who still works there, and apparently things are much better now, but I can only say the last year I worked at IGS was the most soul-corroding experience of my working life.
> Keck has two telescopes to do interferometry. That gives it one axis to resolve.
I am aware of this, hence my use of "fully operational". The _completed_ Keck interferometer is going to have six telescopes, and resolve on more than just one axis, although the other four telescopes will be not be as big as the two that are currently in operation. I guess since Mars is plenty bright, the CHARA array on Mount Wilson might be a closer fit in this case.
As to your last comment, the point is that a space-based interferometry array can be made much larger than any single big mirror you could build, let alone launch into orbit. Last I looked, NASA's plan for the Terrestial Planet Imager is a large, space-based optical interferometry array, and the project which I was "hoping to live to see", in my original post. I don't think they even have a time estimate for that one. The Space Interferometry Mission, on the other hand, is planned for 2009, but it is not meant for imaging, even if I understand it is meant to do some experiments with rotational synthesis imaging, for "proof of concept" and to gather information to help build future, bigger space-based interferometry arrays, like the Terrestrial Planet Imager.
I'd love to see how the images the Keck observatory, with its adaptive optics and 10-meter mirrors, and how they would stack up against the hubble images.
Better yet, the images they could produce if the Keck optical interferometer was fully operational. I know taking pictures of things inside our solar system definitely is not what they're aiming for with the interferometer, but it would still be very interesting to see if a ground based "virtual 85-meter mirror" could produce better results than an orbital telescope like hubble.
And STILL better - a space-based optical interferometry array! Imagine images of planets in OTHER solar systems with resolutions similar to the Mars pictures we're marveling at today... Interferometry is cool. I just hope I live to see a really big optical interferometer in orbit, and the images it will be able to snap.
Of course its possible. There's been at least 3 "linux" worms that I can remember: ramen, slapper and lion. AFAIK, slapper was the one that had the worst spread, with something like 20000 systems infected, if i remember right.
Its highly unlikely, however, that you would be able to write a worm today that would be able to infect "workstation" linux systems, since modern linux distros tend to have firewalling turned on out of the box, few services running as root, and no server services running by default. If you're fast, and a new remote-root hole is discovered in apache/SSL, that would be your best bet for making a worm with any spread at all, but I very much doubt you'll be able to get even as wide a spread as Slapper again.
If you want to try for a linux equivalent to something like Blaster, which could infect essentially ANY NT-based windows system connected to the net and not behind a firewall, you're SOL, however.
> Nautilus takes an ungodly amount of memory to run
Takes a little over 8 megs on my machine normally. I managed to force it up to 14 by opening multiple folders, some with photo collections with thumbnailing on. Hardly an "ungodly amount", considering the circumstances.
> It can't seem to associate file type with applications consistently
Never seen that problem.
> It has that annoying "feature" where any time I insert removable media, it opens a window of the media automatically.
Not even a nautilus setting. Turn it off in Preferences->CD Properties
> You close it and it still takes up the same ungodly amount of memory
I would assume this is because it keeps information about the folders in memory, to make re-opening them fast and snappy. As stated, i don't agree with your definition of "ungodly amount", but it might be a good idea to make folder caching behavior tunable. Good luck trying to get that idea past Havoc Pennington and his Anit-Option Jihad, though...:(
I have my own gripes with Nautilus in its current state, mainly:
1. Still too damn slow when opening new folders.
2. Needs a fast, light and compact list view, not the "for $file in *;do stat $file;file $file;du $file;thumbnail $file;if [ -d $file];then ls $file|wc -l;fi;done" circus that seems to be going on in the current list view.
3. Inconsistent behavior between side pane tree-view and main view (no context menu on folders in the side pane, for example).
I'm not sure whether this will make me pay more heed to RMS's warnings, but I do agree McVoy is being seriously stupid with this attitude. Statements like the above is pouring gasoline on the fire, and he's managing to make the hardcore Free Software folks _angry_ enough to put a serious, focused effort into creating an equal or better product than BitKeeper as fast as they can. When that happens, BitMover's business is going to take a serious hit.
> and the white dwarf will never explode as supernova.
Well, that depends. If the white dwarf is close enough to the Chandrasekhar limit, and somehow manages to accrete enough matter to actually pass it, it would go supernova. Becoming overwheight can be dangerous even for old, retired stars. Marlon Brando should take notice:)
I agree the Gimp has some UI defects, but I think I might be able to help with some of the specific problems you mention.
First, for your corrective rotation example, have you tried setting the "tool paradigm" to corrective, rather than traditional? It tends to make the process you describe (if i understood your example correctly) very fast and simple.
> * I sometimes accidentally tear off a menu instead of hitting the first menu item
Tear-off menus are a GTK+ option, which you can disable. However, see my little tip at the bottom of this post.
> * There is no shortcut to accept a dialog (like Enter,) so I have to use my trackpoint, which is very slow.
This is odd. Enter works for accepting dialogs on my system.
> * Since there are so many windows it's difficult to tab back and forth between other programs (I lose GIMP windows) > * Photoshop keeps common tool options (like brushes, opacity, feather, etc) in a small "always there" bar at the top of the screen.
Both of these are (partially) fixable by using the stacking controls in your window manager. Not all window managers have manual stacking controls however, Metacity being one of them. However if you use a non-crippled WM like Sawfish, try setting the tools window to "upper layer", and it will float on top and you won't lose it.
Tip: Tear-off menus + manual stacking controls can be very useful. Try it:)
Eastwood is twelve years older than Ford. Look at what he was doing in the early 1990's for a fair comparison, not what he's doing now. Eastwood was only marginally younger than Ford is now when he did his last Dirty Harry movie. Not to mention The Unforgiven and In the Line of Fire, both in which Eastwood certainly acknowledges his characters' age, but still kicks serious ass.
Trying out for the Most Sensational Darwin Award Ever, are we? I mean... you wouldn't just ensure that you could never pass on your genes, but your actual DNA and even the base elements its made up from would largely be removed from the planet earth! Now that's what I call a _thorough_ Darwin. Go for it! 8)
MPlayer's gui has a widget for fullscreen. It's also available as a menu choice in the menu you get when right-clicking the video window, while using the gui version. I don't know how to get more intuitive than that.
XFS is unstable? That's the first time I've heard that said about XFS. Are you speaking from personal experience, or just quoting what you've heard? If the former, I would like to hear what the problem was, since I use xfs on production systems, and would like to be aware of any potential pitfalls. My own personal experience with XFS so far has been stellar. It also reportedly scales better on SMP than any other available linux filesystem, which should have made it possibly the best alternative in the 8-way test, though I've never personally run it on anything with more than 2 cpu's, so i can't vouch for that. Reiserfs, on the other hand, is the only linux FS which i have repeatedly had problems with. I've had fs corruption resulting in loss of data several times, although that was quite a few kernel releases ago. Fairly recently, however, I had a kernel crash in reiserfs when a timeout on a SCSI command caused a SCSI bus reset. This is the ONLY time I have ever seen a "production" linux kernel crash on a server.
Slashdot Mirror
> Except that FC really *isn't* like 7. I've been
> finding all *kinds* of glitches, huccups, and
> burps in FC 1.
And in what way is this NOT like RedHat 7? I'd say FC 1 was considerably LESS buggy than many "official" RedHat x.0 releases. 6.0 was so awful it almost made me switch distro. RedHat 7 (the first one with the infamous inofficial 2.96 gcc, in case anyone doesn't remember) was a complete bugstrosity, although updates stabilized it quite well within a few months of release. The number of RedHat Linux releases that were _not_ buggy horrors before the first deluge of post-release updates were in my experience only 6.2, 7.3 and 9.
FC1 should be compared to other RedHat x.0 releases, and at least in my experience, compared to gems like 6.0 or 7.0, i have to say FC1 compares quite favorably.
Don't get me wrong - I like and use RedHat. I'm only pointing out that the "regular" RedHat Linux releases have often been quite bleeding-edge and buggy, just like Fedora is now. Just like Alan Cox stated above.
Hmmm... I think you're wrong here. The surface of the sun (the part we actually see) is only around 6000C, whereas an exploding nuclear bomb is several _million_ degrees. It should have the brightness of the exposed _core_ of the sun.
;)
Of course it depends on what you mean with "brightness". A million LEDs may put out more visible-light photons than a camera flash, but I think we can both agree on which one will leave the biggest blotch on your retina.
Don't forget that with a fission bomb, you're actually releasing stored-up excess energy from an ancient supernova explosion.
I realize that my post was possibly a bit unclear, since you apparently misunderstood most of it. Either that, or your reading comprehension sucks. Or a combination of both. The "misinformed" was in relation to your ignorance about _Linux_, not Solaris.
7 ?a=vi ew
I definitely should have started it out with "Here we go with the misinformed Solaris-advocates" not "Solaris-advocacy". And even that skews the meaning somewhat, since it's not your information about Solaris I'm questioning, its your misinformation about Linux, in relation to Solaris. I have run into far too many people who push Solaris over Linux, and who have the most bizarre ideas about what Linux lacks in comparison to Solaris. A bunch of the things you brought up have also been echoed by them. That's why I wondered if the misinformation about Linux was fed to Solaris admins/developers by SUN, through courses and similar - since the Solaris-advocates so often get the exact same things wrong about Linux.
The things that I claim require a reboot (in Solaris) however, were taken out of a SUN manual. I checked right before i posted, because I haven't worked with Solaris 9, and hence, I wanted to see if things had changed since 7 or 8. They hadn't.
I refer you to:
http://docs.sun.com/db/doc/806-7009/6jftnqsj
Only one of the parameters are marked as Dynamic: yes. The rest are Dynamic: no, meaning, according to an earlier section of the same manual "Boot-time initialization only". If this is incorrect, I suggest you write SUN and tell them their manuals about their own operating system is either wrong, or unclear.
As for me agreeing with you, I agreed with you on only about only two things, proc, and devfs. In the rest of my post i was correcting your factual errors about Linux, and hence disagreeing with the percieved advantages you were claiming for Solaris.
And finally, as for this:
> Stop being a jerk.
I can only say, if you want civil responses, don't start your own posts out with stuff like:
> This week's meeting of the Linux Mutual Admiration and Masturbation Society kicks off with
And here we go with the woefully mis-informed Solaris-advocacy again.
/etc/sysctl.conf. However, in Linux, all these control variables can also be set _without_ even rebooting. And this is the real riot: you can set plenty of control variables in Linux without a reboot which in Solaris REQUIRE a reboot. Just issue "sysctl -p", and the new values in your sysctl.conf will be effective immediately. It's a hell of a lot nicer (my opinion, of course) than having to fire up the kernel debugger (*shudder*) to change dynamic variables, like you have to do in Solaris. To give an example, in Solaris SysV Shared Memory parameters are not dynamic and can only be changed by editing /etc/system and then doing a reboot. In linux, these are tunable on the fly.
/etc/modules.conf will set your read-on-module-load-by-kernel control values. No recompiles needed here either.
/proc, except to say that /proc is a sometimes _useful_ mess sinnce it allows for tuning things on the fly that Solaris will only allow you to change with a reboot... like the abovementioned SysV shared memory settings.
> I can make changes in the running kernel (instead of rebooting).
What "changes" are you talking about here? Modules in linux can be loaded and unloaded without rebooting, and that most definitely is "making changes in a running kernel".
> I can set control variables for the kernel on future reboots (instead of recompiling the entire thing).
Ok, here's the thing that really irks me. Where do you people GET this idiocy from? Does SUN feed you this BS at courses or something? You can set control variables in Linux on future reboots. Just edit
And here follows more displays of fascinating ignorance/misinformation:
> Individual kernel modules can have their own read-on-module-load-by-the-kernel config file; in Linux the only general way of tweaking modules' control values is by editing the source.
No argument about the mess that is
No argument about devfs either. This most definitely IS something that solaris does better, and where Linux is catching up.
My own general impression from working with Linux and Solaris both, however, is that Solaris may be better in a few, small, specific areas mostly relating to really huge boxes, but that Linux stomps big time over Solaris in most areas, including areas where pure ignorance makes Solaris-advocates believe Solaris is superior.
*BLEEEET*. Wrong. Actually, _because_ of Disney, these books won't be in the public domain for almost another 50 years... They were the ones who lobbyed to have the period before something falls into the public domain extended to 70 years, to protect themselves from having characters like Mickey Mouse and Donald Duck become "public property."
All i can say is "ouch". It even had the word "lump" in it.
"Ode to a lump of female republican i found in my bed one midsummer morning."
> "Hollywood can never render Ford turning in to an infinite number of penguins better than you can in your head," as he put it.
Although it will no doubt make me smile just a little bit extra to know that those infinite number of penguins will have been rendered by a finite-but-large number of linux-boxes. I wonder if the animators will make the rendered penguins look just a little bit more like Tux, than a realistic penguin...
MPlayer 0.92 is the current stable release where everything works as expected.
MPlayer 1.0-pre1 has some nice new stuff, but even though it has one thing (support for input from v4l devices with hardware MJPEG support) which I've wanted ofr a long time, the current pre-release is much too flakey for me to use, and I've gone back to 0.92.
MPlayer 1.0-pre1 is for writing bug-reports, not reviews.
Unless Mr. Barr had a conscious or subconscious WISH to find things that didn't work right, i don't see why he wrote his review for the pre1 version.
...about being self-employed must be that your boss will follow you around everywhere, and know even your innermost thoughts. No privacy whatsoever.
> Huh? You've found a place where "on call" means something else?
:)
Yes. Where I work now, the guys in support have at least four hours after a call comes in before they have to be actively working on the problem. That gives plenty of time to go home from wherever you are, take a shower, grab your laptop, get to the office and start working. I, thank god, no longer work in support. No on-call whatsoever, and no overtime. Happy happy, joy joy.
Aaah... I hereby welcome to the IBM veterans' club ;)
Big Blue flashback! Big Blue flashback! AAAAAAAHHHH!
Having worked at IGS some years ago, I can tell that at least where I was, we were _brutally_ understaffed and overworked in the second level support unit. People kept quitting, yet IGS kept taking new customers, without hiring any new techs to replace the ones that left.
Projects were also often taken into production in horrific and unfinished state, leaving the support teams the unenviable task to finish the project while simultaneously handling operations and customer fault reports.
The last month I worked there I had a crapload of overtime, and over 200 hours on call. On call didn't just mean having your phone on, it meant being at most 15 minutes away from my laptop and a phone jack so I could dial in and start working on the problem. It basically made me unable to leave my apartment.
I have a friend who still works there, and apparently things are much better now, but I can only say the last year I worked at IGS was the most soul-corroding experience of my working life.
> Keck has two telescopes to do interferometry. That gives it one axis to resolve.
I am aware of this, hence my use of "fully operational". The _completed_ Keck interferometer is going to have six telescopes, and resolve on more than just one axis, although the other four telescopes will be not be as big as the two that are currently in operation.
I guess since Mars is plenty bright, the CHARA array on Mount Wilson might be a closer fit in this case.
As to your last comment, the point is that a space-based interferometry array can be made much larger than any single big mirror you could build, let alone launch into orbit. Last I looked, NASA's plan for the Terrestial Planet Imager is a large, space-based optical interferometry array, and the project which I was "hoping to live to see", in my original post. I don't think they even have a time estimate for that one.
The Space Interferometry Mission, on the other hand, is planned for 2009, but it is not meant for imaging, even if I understand it is meant to do some experiments with rotational synthesis imaging, for "proof of concept" and to gather information to help build future, bigger space-based interferometry arrays, like the Terrestrial Planet Imager.
I'd love to see how the images the Keck observatory, with its adaptive optics and 10-meter mirrors, and how they would stack up against the hubble images.
:)
Better yet, the images they could produce if the Keck optical interferometer was fully operational. I know taking pictures of things inside our solar system definitely is not what they're aiming for with the interferometer, but it would still be very interesting to see if a ground based "virtual 85-meter mirror" could produce better results than an orbital telescope like hubble.
And STILL better - a space-based optical interferometry array! Imagine images of planets in OTHER solar systems with resolutions similar to the Mars pictures we're marveling at today... Interferometry is cool. I just hope I live to see a really big optical interferometer in orbit, and the images it will be able to snap.
Better stop now, starting to ramble...
Of course its possible. There's been at least 3 "linux" worms that I can remember: ramen, slapper and lion. AFAIK, slapper was the one that had the worst spread, with something like 20000 systems infected, if i remember right.
Its highly unlikely, however, that you would be able to write a worm today that would be able to infect "workstation" linux systems, since modern linux distros tend to have firewalling turned on out of the box, few services running as root, and no server services running by default. If you're fast, and a new remote-root hole is discovered in apache/SSL, that would be your best bet for making a worm with any spread at all, but I very much doubt you'll be able to get even as wide a spread as Slapper again.
If you want to try for a linux equivalent to something like Blaster, which could infect essentially ANY NT-based windows system connected to the net and not behind a firewall, you're SOL, however.
Simple - change from the default windowmanager Metacity to one that isn't lobotomized. Sawfish or IceWM are the ones to look for.
I do hear the latest versions of metacity have finally gotten a "stay on top" option. Did Havoc find a severed horse's head in his bed or something?
> Nautilus takes an ungodly amount of memory to run
:(
Takes a little over 8 megs on my machine normally. I managed to force it up to 14 by opening multiple folders, some with photo collections with thumbnailing on. Hardly an "ungodly amount", considering the circumstances.
> It can't seem to associate file type with applications consistently
Never seen that problem.
> It has that annoying "feature" where any time I insert removable media, it opens a window of the media automatically.
Not even a nautilus setting. Turn it off in Preferences->CD Properties
> You close it and it still takes up the same ungodly amount of memory
I would assume this is because it keeps information about the folders in memory, to make re-opening them fast and snappy. As stated, i don't agree with your definition of "ungodly amount", but it might be a good idea to make folder caching behavior tunable. Good luck trying to get that idea past Havoc Pennington and his Anit-Option Jihad, though...
I have my own gripes with Nautilus in its current state, mainly:
1. Still too damn slow when opening new folders.
2. Needs a fast, light and compact list view, not the "for $file in *;do stat $file;file $file;du $file;thumbnail $file;if [ -d $file];then ls $file|wc -l;fi;done" circus that seems to be going on in the current list view.
3. Inconsistent behavior between side pane tree-view and main view (no context menu on folders in the side pane, for example).
I'm not sure whether this will make me pay more heed to RMS's warnings, but I do agree McVoy is being seriously stupid with this attitude. Statements like the above is pouring gasoline on the fire, and he's managing to make the hardcore Free Software folks _angry_ enough to put a serious, focused effort into creating an equal or better product than BitKeeper as fast as they can. When that happens, BitMover's business is going to take a serious hit.
> and the white dwarf will never explode as supernova.
:)
Well, that depends. If the white dwarf is close enough to the Chandrasekhar limit, and somehow manages to accrete enough matter to actually pass it, it would go supernova. Becoming overwheight can be dangerous even for old, retired stars.
Marlon Brando should take notice
The Altix itself is a big 64-CPU NUMA machine, but as far as I can tell, this is a cluster of four Altixes...
I agree the Gimp has some UI defects, but I think I might be able to help with some of the specific problems you mention.
:)
First, for your corrective rotation example, have you tried setting the "tool paradigm" to corrective, rather than traditional? It tends to make the process you describe (if i understood your example correctly) very fast and simple.
> * I sometimes accidentally tear off a menu instead of hitting the first menu item
Tear-off menus are a GTK+ option, which you can disable. However, see my little tip at the bottom of this post.
> * There is no shortcut to accept a dialog (like Enter,) so I have to use my trackpoint, which is very slow.
This is odd. Enter works for accepting dialogs on my system.
> * Since there are so many windows it's difficult to tab back and forth between other programs (I lose GIMP windows)
> * Photoshop keeps common tool options (like brushes, opacity, feather, etc) in a small "always there" bar at the top of the screen.
Both of these are (partially) fixable by using the stacking controls in your window manager. Not all window managers have manual stacking controls however, Metacity being one of them. However if you use a non-crippled WM like Sawfish, try setting the tools window to "upper layer", and it will float on top and you won't lose it.
Tip: Tear-off menus + manual stacking controls can be very useful. Try it
Eastwood is twelve years older than Ford. Look at what he was doing in the early 1990's for a fair comparison, not what he's doing now. Eastwood was only marginally younger than Ford is now when he did his last Dirty Harry movie. Not to mention The Unforgiven and In the Line of Fire, both in which Eastwood certainly acknowledges his characters' age, but still kicks serious ass.
Trying out for the Most Sensational Darwin Award Ever, are we? I mean... you wouldn't just ensure that you could never pass on your genes, but your actual DNA and even the base elements its made up from would largely be removed from the planet earth! Now that's what I call a _thorough_ Darwin.
Go for it! 8)
MPlayer's gui has a widget for fullscreen. It's also available as a menu choice in the menu you get when right-clicking the video window, while using the gui version. I don't know how to get more intuitive than that.
XFS is unstable? That's the first time I've heard that said about XFS. Are you speaking from personal experience, or just quoting what you've heard? If the former, I would like to hear what the problem was, since I use xfs on production systems, and would like to be aware of any potential pitfalls.
My own personal experience with XFS so far has been stellar. It also reportedly scales better on SMP than any other available linux filesystem, which should have made it possibly the best alternative in the 8-way test, though I've never personally run it on anything with more than 2 cpu's, so i can't vouch for that.
Reiserfs, on the other hand, is the only linux FS which i have repeatedly had problems with. I've had fs corruption resulting in loss of data several times, although that was quite a few kernel releases ago.
Fairly recently, however, I had a kernel crash in reiserfs when a timeout on a SCSI command caused a SCSI bus reset. This is the ONLY time I have ever seen a "production" linux kernel crash on a server.