Now tell me one made from scratch. One with graphics and gameplay from post-1995.
The problem is twofold: 1) gameart creators (graphics artists, musicians, storywriters..) are usually not idealististic at all and work for cash only. The rookies do work for free, but well.. they are rookies. And usually, coders make awful designers and artists.
2) Unlike the typical *NIX opensource coder, game-dev hobbyists have close ties to commercial games. Often, they are (or were) avid gamers, inspired by games they played. In fact, many famous game designers started this way. In Linux, there are NO commercial games (well, almost none).
The Linux world just isn't attractive to game makers. The best thing that happens right now are ports. But something like Half-Life 2 for Linux? Forget it.
I look forward to UT2007, though. AFAIK it will have a Linux client.
No, the more important question is WHEN this card will be available, and which features it will have. I absolutely need OpenGL 2.0 functionality for my stuff (yes, also for games, but I use Windows when I wanna play something). Does OpenGraphics have it? No? Then I stick with my gf6600. I would welcome opensource nvidia drivers from the manufacturer, but this is never gonna happen.
A learned skill? Yes. But the real problem we are talking about is accessibility.
An example: the command line has awesome usability. The things I can do with this tool are numerous. Also, it matches the way people think: in verbs.
But the command line has TERRIBLE accessibility. awk, sed, etc. are very useful command-line tools, but as a beginner, it is extremely hard to get a clue how they work. "find../foo -name 'c1.t*' -exec rm {} \;" is quite logical once you grasp how find works. But until then - what?
This is where typical GUIs shine. I can try things in Photoshop, they are VISIBLE, they are THERE (try to find this-one-obscure-command in/usr/bin). "I want to find something to turn my pic into a pointilism-like image, lets see... ah, in Filters there is something called Boxify, lets try this..." Try this with the command line.
The PS UI can be used as a sandbox environment for experimenting with the features, because it has two things the command-line interface lacks: much better accessibility, and an undo feature. As a golden rule, EVERYTHING should be reversible unless it is physically impossible, and irreversible actions should pop up a big fat WARNING (this is where popups actually belong).
Generally, I propose two improvements for the command line: - Undo functionality. - Quick online help of fundamentals. The joe editor is a very good example. In the upper right corner, there is written "Ctrl-K H for help". After pressing this, a quick help appears in the upper portion of the screen, describing all basic keystrokes. This reflects the PS UI; now, the commands are VISIBLE, they are THERE.
Also, WIMP interfaces do have their place. WIMP and command line are not mutually exclusive. Graphics-intensive apps like 3D modelers absolutely NEED the mouse, and there a WIMP interface makes sense. Since the mouse pointer is in motion anyway, the buttons are easy and quick to access. But with an editor, things are different. In an editor, the keyboard dominates, and having to move the hand to the mouse and the mouse pointer to the "save" button is an unnecessary delay. Just like everything else, WIMP is the right tool for the right job - not for everything. Same applies to the command line.
From what you write, I extrapolate that you live in the US. I live in Austria, and this may explain our different views. In Austria, the situation is considerably better, but of course not immune. Also, the gas prices here are much higher than in the US, largely because of taxes.
The current high oil prices (which are falling right now) were at an all-time high largely because of the iran crisis. This is a politically caused high, similar to the crisis in the 70s. This in fact is the best thing that could happen: it spawned and renewed interests in alternatives and oil independency all around the world (even in the US). Alternatives to oil are no longer a tree-hugger thing; its hard business now, with Shell, BP, Exxon etc. investing billions into it (think about it; they are energy companies, not simply oil ones, its in their best interest to remain competitive). I actually met some teams from Shell and BP once, doing research in alternatives, better EI/ER in ethanol etc.
Our best chance is for alternatives to become its own market - and this has happened. Of course current alternative energy technologies have too small energy densities to fully supplant coal, oil and uranium as energy sources in the near future, but I am fairly positive about this (fortunately, all have a positive EI/ER ratio now - not big, but positive).
I am also fairly positive about supercapacitors and fusion. Yes, I know the 50-year-saying in fusion, but despite this naysaying, this field actually made great progress. Right now the big deal is not to get a sustained reaction, neither is it to get a positive EI/ER. Its the materials. The high energy neutrons radiate and ultimately destroy the walls.
As for supercapacitors, time will tell. I see the MIT project as quite promising though.
As for the plastics thing, your source only says that the light fractions are used for their production. It does not mention the %. Also, as I mentioned before, with another primary energy source established, thermal depolymerization is an option for plastics. (Same for deoxidization of metals.) Also, I think you misunderstood me - I meant that the fact that oil is used as an energy source is not the reason why it is used in plastics production (it is the reason why it is used in cars, for example).
The ideal thing would be to establish electricity both for stationary and mobile uses. Since electricity is so versatile, such an union would make it easy to switch both for transportation and conventional electricity usage. Car manufacturers see the electric car as the future (actually, hydrogen cars are electric cars with a fuel cell). I agree on hydrogen being inefficient in a mobile environment. I would rather see metal-air-batteries or supercapacitors/improved batteries in each car. If all car engines are electrical, it is easy to switch sources.
The other things that MUST be reached are a population growth slowdown and an increased awareness for minimizing energy usage. It is simply ridiculous that fat guys drive 400m from their flat to their favourite pub. In cities, most car drivings are actually a waste of gasoline.
I dont think all is lost. No, it will not be smooth. It will also hit the poor hardest (as usual unfortunately).
About industrialism: I see it going away anyway. Society is switching, leaving the 20th century industrialism behind. Things get cheaper, more streamlined, automatized, leading to major changes in the meaning of having a job. The current high prices for energy, food etc. are stopping the consumerism. Fewer people buy yet another laptop, yet another PC etc. I don't see a fallback to earlier ages though; consider the many experiments in china with the green, self-sustaining cities. Good thing for slashdotters: I think IT is here to stay;) It is just much more efficient to have information go via the Internet than via paper or copper phone cables (which are replaced by fiber optic ones, thus saving copper). It also allows teleworking, thus saving transportation c
The crucial point is whether or not a country achieves a sustainable state. You know, relying on renewable energy, fusion alone - in short: ensuring a reliable primary energy source. Once this happens, civilization is here to stay.
I see your view as an extreme fatalistic one - which is good, since it provides one with clear goals and visions.
But you are wrong on one thing: fusion CAN make your meds, fertilise your crops, and wash your hair. The entire oil problem centers around oil as a primary energy source. Fusion and alternatives would become the new primary source. Once this is done, the entire issue is solved. Oil can be synthesized, which is necessary for asphalt & plastics - here we have no difficulties, since oil is NOT used in asphalt & plastics because of it being an energy source. (BTW, it is already possible to create plastics without oil, using algae as basic components instead.) Deoxidization is also a non-issue with enough primary energy (and not as fatal as you think; most fresh minings are oxidized already.) Establish primary energy supply, and you succeed.
I tell you what I think will happen: alternative energies, regionalized energy production, ecologically neutral cities designed for walking & biking will boom. Cars will be used less (no point to drive much in a city anyway) and move to ethanol, liquified coal, hydrogen, or even batteries/supercapacitors. Yes, the transition phase will be hard. Population growth will slow down, if not stop. But the outcome could actually be BETTER than today's world.
I hardly believe you will change your opinion, and I am not asking you to do so. However, understand that extreme fatalism is rarely constructive - and if there is one thing we DON'T need right now, its people giving up.
Um, no. Hydrocarbons as a component are not the problems. H. as energy source are. Oil is basically stored solar energy. If we have replacements for the primary energy source (like solar energy, wind, geothermal, maybe even fusion someday) hydrocarbons can be created synthetically if needed (but even when Oil is useless as an energy source, it will be still around).
In fact, this is the future almost all car manufacturers envision: the electric car. Why?
First, because electrical engines have a huge torque compared to combustion engines. Some engines don't need any transmission at all! This is especially useful in cities; you don't have to keep the engine running. (Here, lots of gasoline are wasted.)
Second, electricity can come from lots of sources, thus boosting flexibility and solving supply problems (electricity can be transported much easier than oil, and can be generated locally). With supercapacitors, electric cars would see their last problem solved: energy storage.
Amen to this statement about Vista. It brings little new and exciting stuff (Aeroglass -> OSX/Xgl). For me, the only reason would be because the work requires it, or because I want to develop with DX10 (which is quite well done).
Blackcomb and Singularity, on the other hand, are interesting. The Singularity approach for bypassing the usual microkernel troubles is quite interesting. I would love to see a lean Windows with exactly zero legacy code in the system, all legacy stuff moved to a virtualized environment, a system (not kernel!) API (fully documented), and a virtual machine (.net) built above it.
The best thing would be a Windows with Unix infrastructure, that is, combine the clear cut with a shift, like Apple did with OSX.
The person's work performance improves because of multithreading, yes. But the person is usually not included in this equation. For the person, the computer is a black box. This thread is about the black box, not about the things outside using it. And in the blackbox, you improved responsiveness, not performance. The file manager reacts even though its scanning thousands of files? Improved responsiveness.
1) Backwards compatibility. Can't live with it, can't live without it. 2) Vista cannot be compared to Linux, but to distros. So, I would rather compare it with SuSE 10, or Ubuntu Dapper/Edgy.
If they had chosen an OPEN standard, defined by independant third parties that allow free competition things would have been better.
You mean like UNIX?
You know, back then, in the days of the Unix wars, everyone expected Unix to rule the desktop in the future. But since your nice independent parties were too much involved in their constant bickering, no coherent standardized Unix desktop ever appeared. Instead, you had many platforms, and had to support all of them. An incoherent mess, as user- & desktop-unfriendly as it can possibly be. Microsoft was just lucky - their competitors were busy whacking each others' head off. They practically gave the Microsoft/IBM union carte blanche to rule the desktop. Yes, there were Apple, Amiga, etc. but they all lacked the power IBM had, and Microsoft used for its own growth.
Now, Linux is in danger of repeating this mistake by the constant infighting between GNOME, KDE, different distros, wannabe Linux elitists and Desktoplinux-advocates. In short: the Linux world is an incoherent mess. LSB is a good idea, Freedesktop is a good idae. Lets hope it ends in a better way this time.
*sigh*.... In total, Linux isn't free for companies. First, switching the entire infrastructure from Windows to Linux can be very expensive, especially if there is no prior experience with Linux. Second, it is easy to get Linux geeks, but good Linux admins are hard to find. Third, you really call the ubuntu forums "professional support"? Direct support from the developers, guaranteed by contract, *that* is professional support. If your machines suddenly stop working, you would start a thread in the ubuntu forums and hope for an answer in the next days? Do you have any idea how expensive this can be for the company?
There are reasons why companies let others (like IBM) run their IT departments. Think about it.
Here we see the problems with measuring performance and distinguishing it from responsiveness - sometimes it is very hard to do. The blocking IO almost always harms responsiveness, not performance. A file manager scanning thousands of files for thumbnails generation has responsiveness problems if this is done without multithreading.
In fact, I would see responsiveness as the bigger problem nowadays. It affects the user directly (for example, the file manager not reacting to any kind of input while scanning a large directory) and is ignored too often.
Well, thats usually not the definition of performance when it comes to stuff like multithreading.
How many 8x8 DCT blocks the CPU can inverse-transform in a second - this is performance. Multithreading won't help here. (But this task is easily parallelizable, so multi-core CPUs are a big win here!)
Why is it so hard to get developers to write decent multi-threaded code? It's not that hard, and using threads properly can almost always improve performance and/or responsiveness on single proc/core machines to boot.
Because it IS harder. It introduces new pitfalls (deadlocks, livelocks, race conditions), debugging is harder (gdb with multithreaded programs.. brrr), old paradigma have to be thrown overboard (and new ones introduced, such as task- or stream-based processing). Also, threads NEVER improve performance on a single-core machine. They do help with responsiveness, however. If you want performance boosts, use a multicore machine.
Re:But does it have a useable file-save dialogue?
on
GNOME 2.16 Released
·
· Score: 1
If putting directories first is an absolute requirement, then the best answer is to just display "reading..." or something like that, until the stat() is done and the display can be shown then. It should accept user input (ie typing) during this time, and if they go to another directory or close the file chooser, it should abort the current stat() pass and start over.
Correctly. Progressive display of the directory contents has too much disadvantages. The "Reading...." indicator might take a while to vanish, but considering the immense bottlenecks in Gnome stuff, I'd see this as rather irrelevant.
Re:But does it have a useable file-save dialogue?
on
GNOME 2.16 Released
·
· Score: 1
Oh yes. Display the filename ONLY. Now THAT is user-friendly. What next? Omit filenames, use inodes only?
If you had a clue, you knew that separating directories and files PRECEDES Windows. Heck, even AmigaOS 1.0 did it. And it has proven itself to be a smart thing to do.
Hell, I can scan/usr/bin with readdir() and stat(), sort it, and display the results orders of magnitude faster than the GNOME/Gtk selectors do.
Actually, that's the primary widget I was thinking about when I said that Qt is a PITA to work with. Up through Qt3 (last year!), you couldn't have a tree ("list", in Qt terms, even though it *is* a tree) with items unless you created QListViewItems for each one. In order to write a tree that doesn't need to be filled on startup (like the files in a filesystem), you need to go through a funky dance of adding dummy nodes, and removing them on expansion events... it's a big mess. Gtk+ has, since 2.0, supported custom tree models.
Well, then you did something wrong. I used Qt3 Treeviews for a long time, and I found them MUCH easier to use than the Gtk thing. Simply add Listviewitems to other Listviewitems, and you have your subnodes of the tree. Makes SENSE, doesn't it? Also, I don't have to remove nodes for expanding/contracting....
GtkTreeView, OTOH, is a HUGE mess. I have to write TONS of code just for a simple listview, it is bloated, error-prone, and as unintuitive as a treeview can get (the docs didn't help much in this regard).
GTK+ binds events by a string: their event name. Qt binds by a string also: the C++ signature. There are a few memory-management issues that bindings inherit from C++ as well. This means, even if you're using bindings for Qt, you're seeing C++ all day. I've never gotten PyGTK to segfault, but it's a common occurrence with PyQt.
Again, I don't know about the Python ports, BUT in C++ I never managed to crash Qt (and sometimes I made mistakes I was amazed that they didn't caused Qt to crash). Gtk+, however, crashed often.
First of all, GTK+ seems fully documented to me. If there's any part that isn't documented, I haven't run across it, nor can I seem to find it today.
Perfect example: try to write a textview with autoscroll enabled (for example, for a chat client). This turns out to be quite difficult, because there is NO documentation as how to achieve this. There are Cursors, Markers, nothing makes sense (what whas that about Gtk being intuitive again?). I got away with a strange hack that sometimes works, sometimes doesn't. Ah, and the Gtk folks at GIMPnet didn't know a solution either.
While searching for a solution, I stumbled upon many functions that are present in the reference, but have NO description whatsoever. Kinda bad, isn't it? In the Qt docs I have example usages for many widgets at the beginning of the widget documentation page (example: http://doc.trolltech.com/4.0/qtabwidget.html ). I have yet to find something comparable in the Gtk docs.
That seems to be their excuse for a lot of things. And their answer to a lot of things is "well just use C++ like us".
Yeah, well, I would like to see them frop moc and use either Glib signals, libsigc++ ones or (preferably) the boost ones.
I absolutely prefer the Qt API to the Gtk one. Gtk has a very unintuitive, messy API (just think of the GtkTreeView horror). But Qt's greatest advantage is the vastly superior documentation (entire sections of Gtk are simply NOT DOCUMENTED). Gtkmm is not bad, but in C++ land, Qt is superior. Can't say the same in other languages, though. (I also imagine that Qt bindings are harder to write than Gtk ones.)
What I don't like about Qt is moc. Not because it "pollutes C++", but because its cumbersome to include in build scripts.
I actually used alt-tab for a while. It is not as comfortable as it sounds, sometimes you miss the alt key and just hit tab (can happen when typing very fast), and the optical change gets disturbing after a while. In contrast, the F5 keypress you mentioned in VC is very nice.
I'll try SciTE now, as mentioned by another slashdotter.
Ever heard of developers that don't use make, and use scons/cmake/etc. instead? I don't think so. Did you even READ the text, and noted that I don't use vim? I don't think so. Is it smart to enforce a very different (vim-like) editing style just to be able to develop without constant flow interruption? I don't think so.
Slashdot Mirror
Here is a nice one for this Vastu person:
http://www.somethingawful.com/jeffk/
But what if the Boss has the CTO Cloak Of Invulnerability?
The only thing I can think of is to cast Summon Chick to distract him...
Now excuse me, I have only 7 HPs and desperately need a +5 Banana Of Healing.
Now tell me one made from scratch. One with graphics and gameplay from post-1995.
The problem is twofold: 1) gameart creators (graphics artists, musicians, storywriters..) are usually not idealististic at all and work for cash only. The rookies do work for free, but well.. they are rookies. And usually, coders make awful designers and artists.
2) Unlike the typical *NIX opensource coder, game-dev hobbyists have close ties to commercial games. Often, they are (or were) avid gamers, inspired by games they played. In fact, many famous game designers started this way. In Linux, there are NO commercial games (well, almost none).
The Linux world just isn't attractive to game makers. The best thing that happens right now are ports. But something like Half-Life 2 for Linux? Forget it.
I look forward to UT2007, though. AFAIK it will have a Linux client.
No, the more important question is WHEN this card will be available, and which features it will have. I absolutely need OpenGL 2.0 functionality for my stuff (yes, also for games, but I use Windows when I wanna play something). Does OpenGraphics have it? No? Then I stick with my gf6600. I would welcome opensource nvidia drivers from the manufacturer, but this is never gonna happen.
A learned skill? Yes. But the real problem we are talking about is accessibility.
../foo -name 'c1.t*' -exec rm {} \;" is quite logical once you grasp how find works. But until then - what?
/usr/bin). "I want to find something to turn my pic into a pointilism-like image, lets see... ah, in Filters there is something called Boxify, lets try this..." Try this with the command line.
An example: the command line has awesome usability. The things I can do with this tool are numerous. Also, it matches the way people think: in verbs.
But the command line has TERRIBLE accessibility. awk, sed, etc. are very useful command-line tools, but as a beginner, it is extremely hard to get a clue how they work. "find
This is where typical GUIs shine. I can try things in Photoshop, they are VISIBLE, they are THERE (try to find this-one-obscure-command in
The PS UI can be used as a sandbox environment for experimenting with the features, because it has two things the command-line interface lacks: much better accessibility, and an undo feature. As a golden rule, EVERYTHING should be reversible unless it is physically impossible, and irreversible actions should pop up a big fat WARNING (this is where popups actually belong).
Generally, I propose two improvements for the command line:
- Undo functionality.
- Quick online help of fundamentals. The joe editor is a very good example. In the upper right corner, there is written "Ctrl-K H for help". After pressing this, a quick help appears in the upper portion of the screen, describing all basic keystrokes. This reflects the PS UI; now, the commands are VISIBLE, they are THERE.
Also, WIMP interfaces do have their place. WIMP and command line are not mutually exclusive. Graphics-intensive apps like 3D modelers absolutely NEED the mouse, and there a WIMP interface makes sense. Since the mouse pointer is in motion anyway, the buttons are easy and quick to access. But with an editor, things are different. In an editor, the keyboard dominates, and having to move the hand to the mouse and the mouse pointer to the "save" button is an unnecessary delay. Just like everything else, WIMP is the right tool for the right job - not for everything. Same applies to the command line.
From what you write, I extrapolate that you live in the US. I live in Austria, and this may explain our different views. In Austria, the situation is considerably better, but of course not immune. Also, the gas prices here are much higher than in the US, largely because of taxes.
;) It is just much more efficient to have information go via the Internet than via paper or copper phone cables (which are replaced by fiber optic ones, thus saving copper). It also allows teleworking, thus saving transportation c
The current high oil prices (which are falling right now) were at an all-time high largely because of the iran crisis. This is a politically caused high, similar to the crisis in the 70s. This in fact is the best thing that could happen: it spawned and renewed interests in alternatives and oil independency all around the world (even in the US). Alternatives to oil are no longer a tree-hugger thing; its hard business now, with Shell, BP, Exxon etc. investing billions into it (think about it; they are energy companies, not simply oil ones, its in their best interest to remain competitive). I actually met some teams from Shell and BP once, doing research in alternatives, better EI/ER in ethanol etc.
Our best chance is for alternatives to become its own market - and this has happened. Of course current alternative energy technologies have too small energy densities to fully supplant coal, oil and uranium as energy sources in the near future, but I am fairly positive about this (fortunately, all have a positive EI/ER ratio now - not big, but positive).
I am also fairly positive about supercapacitors and fusion. Yes, I know the 50-year-saying in fusion, but despite this naysaying, this field actually made great progress. Right now the big deal is not to get a sustained reaction, neither is it to get a positive EI/ER. Its the materials. The high energy neutrons radiate and ultimately destroy the walls.
As for supercapacitors, time will tell. I see the MIT project as quite promising though.
As for the plastics thing, your source only says that the light fractions are used for their production. It does not mention the %. Also, as I mentioned before, with another primary energy source established, thermal depolymerization is an option for plastics. (Same for deoxidization of metals.) Also, I think you misunderstood me - I meant that the fact that oil is used as an energy source is not the reason why it is used in plastics production (it is the reason why it is used in cars, for example).
The ideal thing would be to establish electricity both for stationary and mobile uses. Since electricity is so versatile, such an union would make it easy to switch both for transportation and conventional electricity usage. Car manufacturers see the electric car as the future (actually, hydrogen cars are electric cars with a fuel cell). I agree on hydrogen being inefficient in a mobile environment. I would rather see metal-air-batteries or supercapacitors/improved batteries in each car. If all car engines are electrical, it is easy to switch sources.
The other things that MUST be reached are a population growth slowdown and an increased awareness for minimizing energy usage. It is simply ridiculous that fat guys drive 400m from their flat to their favourite pub. In cities, most car drivings are actually a waste of gasoline.
I dont think all is lost. No, it will not be smooth. It will also hit the poor hardest (as usual unfortunately).
About industrialism: I see it going away anyway. Society is switching, leaving the 20th century industrialism behind. Things get cheaper, more streamlined, automatized, leading to major changes in the meaning of having a job. The current high prices for energy, food etc. are stopping the consumerism. Fewer people buy yet another laptop, yet another PC etc. I don't see a fallback to earlier ages though; consider the many experiments in china with the green, self-sustaining cities. Good thing for slashdotters: I think IT is here to stay
The crucial point is whether or not a country achieves a sustainable state. You know, relying on renewable energy, fusion alone - in short: ensuring a reliable primary energy source. Once this happens, civilization is here to stay.
I see your view as an extreme fatalistic one - which is good, since it provides one with clear goals and visions.
But you are wrong on one thing: fusion CAN make your meds, fertilise your crops, and wash your hair. The entire oil problem centers around oil as a primary energy source. Fusion and alternatives would become the new primary source. Once this is done, the entire issue is solved. Oil can be synthesized, which is necessary for asphalt & plastics - here we have no difficulties, since oil is NOT used in asphalt & plastics because of it being an energy source. (BTW, it is already possible to create plastics without oil, using algae as basic components instead.) Deoxidization is also a non-issue with enough primary energy (and not as fatal as you think; most fresh minings are oxidized already.) Establish primary energy supply, and you succeed.
I tell you what I think will happen: alternative energies, regionalized energy production, ecologically neutral cities designed for walking & biking will boom. Cars will be used less (no point to drive much in a city anyway) and move to ethanol, liquified coal, hydrogen, or even batteries/supercapacitors. Yes, the transition phase will be hard. Population growth will slow down, if not stop. But the outcome could actually be BETTER than today's world.
I hardly believe you will change your opinion, and I am not asking you to do so. However, understand that extreme fatalism is rarely constructive - and if there is one thing we DON'T need right now, its people giving up.
Um, no.
Hydrocarbons as a component are not the problems. H. as energy source are. Oil is basically stored solar energy. If we have replacements for the primary energy source (like solar energy, wind, geothermal, maybe even fusion someday) hydrocarbons can be created synthetically if needed (but even when Oil is useless as an energy source, it will be still around).
In fact, this is the future almost all car manufacturers envision: the electric car. Why?
First, because electrical engines have a huge torque compared to combustion engines. Some engines don't need any transmission at all! This is especially useful in cities; you don't have to keep the engine running. (Here, lots of gasoline are wasted.)
Second, electricity can come from lots of sources, thus boosting flexibility and solving supply problems (electricity can be transported much easier than oil, and can be generated locally). With supercapacitors, electric cars would see their last problem solved: energy storage.
Amen to this statement about Vista. It brings little new and exciting stuff (Aeroglass -> OSX/Xgl). For me, the only reason would be because the work requires it, or because I want to develop with DX10 (which is quite well done).
Blackcomb and Singularity, on the other hand, are interesting. The Singularity approach for bypassing the usual microkernel troubles is quite interesting. I would love to see a lean Windows with exactly zero legacy code in the system, all legacy stuff moved to a virtualized environment, a system (not kernel!) API (fully documented), and a virtual machine (.net) built above it.
The best thing would be a Windows with Unix infrastructure, that is, combine the clear cut with a shift, like Apple did with OSX.
The person's work performance improves because of multithreading, yes. But the person is usually not included in this equation. For the person, the computer is a black box. This thread is about the black box, not about the things outside using it. And in the blackbox, you improved responsiveness, not performance. The file manager reacts even though its scanning thousands of files? Improved responsiveness.
1) Backwards compatibility. Can't live with it, can't live without it.
2) Vista cannot be compared to Linux, but to distros. So, I would rather compare it with SuSE 10, or Ubuntu Dapper/Edgy.
If they had chosen an OPEN standard, defined by independant third parties that allow free competition things would have been better.
You mean like UNIX?
You know, back then, in the days of the Unix wars, everyone expected Unix to rule the desktop in the future. But since your nice independent parties were too much involved in their constant bickering, no coherent standardized Unix desktop ever appeared. Instead, you had many platforms, and had to support all of them. An incoherent mess, as user- & desktop-unfriendly as it can possibly be. Microsoft was just lucky - their competitors were busy whacking each others' head off. They practically gave the Microsoft/IBM union carte blanche to rule the desktop. Yes, there were Apple, Amiga, etc. but they all lacked the power IBM had, and Microsoft used for its own growth.
Now, Linux is in danger of repeating this mistake by the constant infighting between GNOME, KDE, different distros, wannabe Linux elitists and Desktoplinux-advocates. In short: the Linux world is an incoherent mess. LSB is a good idea, Freedesktop is a good idae. Lets hope it ends in a better way this time.
*sigh*....
In total, Linux isn't free for companies. First, switching the entire infrastructure from Windows to Linux can be very expensive, especially if there is no prior experience with Linux. Second, it is easy to get Linux geeks, but good Linux admins are hard to find. Third, you really call the ubuntu forums "professional support"? Direct support from the developers, guaranteed by contract, *that* is professional support. If your machines suddenly stop working, you would start a thread in the ubuntu forums and hope for an answer in the next days? Do you have any idea how expensive this can be for the company?
There are reasons why companies let others (like IBM) run their IT departments. Think about it.
Here we see the problems with measuring performance and distinguishing it from responsiveness - sometimes it is very hard to do. The blocking IO almost always harms responsiveness, not performance. A file manager scanning thousands of files for thumbnails generation has responsiveness problems if this is done without multithreading.
In fact, I would see responsiveness as the bigger problem nowadays. It affects the user directly (for example, the file manager not reacting to any kind of input while scanning a large directory) and is ignored too often.
Well, thats usually not the definition of performance when it comes to stuff like multithreading.
How many 8x8 DCT blocks the CPU can inverse-transform in a second - this is performance.
Multithreading won't help here. (But this task is easily parallelizable, so multi-core CPUs are a big win here!)
Why is it so hard to get developers to write decent multi-threaded code? It's not that hard, and using threads properly can almost always improve performance and/or responsiveness on single proc/core machines to boot.
Because it IS harder. It introduces new pitfalls (deadlocks, livelocks, race conditions), debugging is harder (gdb with multithreaded programs.. brrr), old paradigma have to be thrown overboard (and new ones introduced, such as task- or stream-based processing). Also, threads NEVER improve performance on a single-core machine. They do help with responsiveness, however. If you want performance boosts, use a multicore machine.
If putting directories first is an absolute requirement, then the best answer is to just display "reading..." or something like that, until the stat() is done and the display can be shown then. It should accept user input (ie typing) during this time, and if they go to another directory or close the file chooser, it should abort the current stat() pass and start over.
Correctly. Progressive display of the directory contents has too much disadvantages. The "Reading...." indicator might take a while to vanish, but considering the immense bottlenecks in Gnome stuff, I'd see this as rather irrelevant.
Oh yes. Display the filename ONLY. Now THAT is user-friendly.
/usr/bin with readdir() and stat(), sort it, and display the results orders of magnitude faster than the GNOME/Gtk selectors do.
What next? Omit filenames, use inodes only?
If you had a clue, you knew that separating directories and files PRECEDES Windows. Heck, even AmigaOS 1.0 did it. And it has proven itself to be a smart thing to do.
Hell, I can scan
Actually, that's the primary widget I was thinking about when I said that Qt is a PITA to work with. Up through Qt3 (last year!), you couldn't have a tree ("list", in Qt terms, even though it *is* a tree) with items unless you created QListViewItems for each one. In order to write a tree that doesn't need to be filled on startup (like the files in a filesystem), you need to go through a funky dance of adding dummy nodes, and removing them on expansion events ... it's a big mess. Gtk+ has, since 2.0, supported custom tree models.
Well, then you did something wrong. I used Qt3 Treeviews for a long time, and I found them MUCH easier to use than the Gtk thing. Simply add Listviewitems to other Listviewitems, and you have your subnodes of the tree. Makes SENSE, doesn't it? Also, I don't have to remove nodes for expanding/contracting....
GtkTreeView, OTOH, is a HUGE mess. I have to write TONS of code just for a simple listview, it is bloated, error-prone, and as unintuitive as a treeview can get (the docs didn't help much in this regard).
GTK+ binds events by a string: their event name. Qt binds by a string also: the C++ signature. There are a few memory-management issues that bindings inherit from C++ as well. This means, even if you're using bindings for Qt, you're seeing C++ all day. I've never gotten PyGTK to segfault, but it's a common occurrence with PyQt.
Again, I don't know about the Python ports, BUT in C++ I never managed to crash Qt (and sometimes I made mistakes I was amazed that they didn't caused Qt to crash). Gtk+, however, crashed often.
First of all, GTK+ seems fully documented to me. If there's any part that isn't documented, I haven't run across it, nor can I seem to find it today.
Perfect example: try to write a textview with autoscroll enabled (for example, for a chat client). This turns out to be quite difficult, because there is NO documentation as how to achieve this. There are Cursors, Markers, nothing makes sense (what whas that about Gtk being intuitive again?). I got away with a strange hack that sometimes works, sometimes doesn't. Ah, and the Gtk folks at GIMPnet didn't know a solution either.
While searching for a solution, I stumbled upon many functions that are present in the reference, but have NO description whatsoever. Kinda bad, isn't it? In the Qt docs I have example usages for many widgets at the beginning of the widget documentation page (example: http://doc.trolltech.com/4.0/qtabwidget.html ). I have yet to find something comparable in the Gtk docs.
That seems to be their excuse for a lot of things. And their answer to a lot of things is "well just use C++ like us".
Yeah, well, I would like to see them frop moc and use either Glib signals, libsigc++ ones or (preferably) the boost ones.
Well, Demolition Man introduced The Three Seashells.
Now I just have to find out how to use them.
I always wondered why the Gnomes prefer EoG over GQview. The latter is so much better, its a shame they kicked it out.
I absolutely prefer the Qt API to the Gtk one. Gtk has a very unintuitive, messy API (just think of the GtkTreeView horror). But Qt's greatest advantage is the vastly superior documentation (entire sections of Gtk are simply NOT DOCUMENTED). Gtkmm is not bad, but in C++ land, Qt is superior. Can't say the same in other languages, though. (I also imagine that Qt bindings are harder to write than Gtk ones.)
What I don't like about Qt is moc. Not because it "pollutes C++", but because its cumbersome to include in build scripts.
I actually used alt-tab for a while. It is not as comfortable as it sounds, sometimes you miss the alt key and just hit tab (can happen when typing very fast), and the optical change gets disturbing after a while. In contrast, the F5 keypress you mentioned in VC is very nice.
I'll try SciTE now, as mentioned by another slashdotter.
Ever heard of developers that don't use make, and use scons/cmake/etc. instead?
I don't think so.
Did you even READ the text, and noted that I don't use vim?
I don't think so.
Is it smart to enforce a very different (vim-like) editing style just to be able to develop without constant flow interruption?
I don't think so.
Just a couple of sentences after this one I mention the problem with typing make.