FWIW, Gnome is pretty consistent now: more than Vista, maybe less than OS X.
The Gnome HIG (Human Interface Guidelines), http://library.gnome.org/devel/hig-book/stable/ , is followed very, very closely. If your app violates the HIG you'll get a stream of annoying bugs filed about it. If you start up Ubuntu it's quite hard to find any non-HIG programs.
KDE have something similar I think, though I don't follow KDE development closely.
If you want to argue for a much lower standard, ok, but understand that isn't good science, that's pseudoscience.
It depends on the sort of science. In something like Physics you can get a very high level of proof, in something like climatology or medicine you can't because the systems are just too complex.
For example, consider smoking. Does smoking cause lung cancer? This is question of vital interest with large economic consequences, but one which can't easily be proved in the way you're demanding. Someone smokes, twenty years later they get lung cancer, how do you absolutely demonstrate that the cancer was caused by the cigarettes? You have to do very large scale studies over many decades, control for as many factors as you can and produce what you hope is an impressive confidence interval. That's the best you can do.
The smoking/cancer link has probably now achieved proof status (though you can still find people arguing about the data). When will CO2 warming get there? It's at the 90% point, according to the IPCC.
The Guardian is saying that O2 are installing EDGE for xmas:
The iPhone does not use 3G technology, but a variant of the existing wireless technology called Edge. So far in the UK, only Orange has installed this technology into its network - but O2 is expected to roll out Edge technology in time for Christmas, and also, it is thought, in time for the iPhone. Last night O2 said officially that it had not signed a contract with Apple.
The other operators, however, say that upgrading to the new high-speed data service needed for the iPhone is not expensive, as it is merely a software upgrade; it does not need a full-scale refit of existing wireless networks, unlike the switch to 3G, which has cost the industry billions of pounds.
Programs run quickly under efence, but sadly memory use will balloon. It (I hope I have this right) puts each malloc into a separate page with guards either end. So every tiny strdup() will use some huge amount of your address space. It's not practical for anything bigger than rather small.
valgrind takes the opposite approach: it does all the checking in software, so it runs slowly (about 1/20th of real speed, the last time I measured it), but is much more modest in the amount of RAM it needs (though it still needs a lot).
This is one area where every developer really needs 64-bit processor. I have 8GB in my desktop machine now and I can run even the largest project I work on with full memory checks. It's wonderful.
I fail to see how downlading and building a few libs on windows is any more difficult that the same task on *nix,
Here's an example: I wrote a HOWTO for my pet project explaining how to set up a build environment for it on windows: http://www.vips.ecs.soton.ac.uk/index.php?title=Bu ild_on_windows. That's about a day's work for an experienced developer. Much longer if you didn't have the HOWTO to follow.
The same setup is a couple of clicks and less than a minute on a system with a nice package manager.
apt-get and friends are far, far better than Window's add/remove system. They track dependencies, so when you install "rails", for example, it will automatically install apache, mysql, ruby, all the various connectors, configure them and link them all together. This is especially useful for development. Setting up a complex build environment on Windows can be nightmarish. My project uses 10 - 15 sub-libraries and downloading working and compatible versions of all the dependencies can take a whole day. This is a one-click operation with a package manager.
They all handle updates as well, so you have a central place to keep all your entire system patched. For example, when a vulnerability is discovered in a core library (libz, or linpng have been recent examples), you need to go through your system checkiing that every application which uses one of these libraries is updated. This is almost impossible on Windows, but automatic on systems with package managers.
I had a keyboard fail on an HP laptop about two years ago and they made me remove linux and put XP back before they'd fix it. Nice to hear they were better about it with you.
X11 goes up to 16 bits per channel RGB, but no one really uses it. You're right, superbright displays that can actually show all those bits need to become cheap before this is more than a curiosity.
I remember seeing a 12 bits per channel CRT at SPIE in 1996. There was no obvious improvement, even on their demo images. It's just too hard to (1) get noise down enough that the bits become significant, and then (2) get the display bright enough that a human observer under reasonable conditions can see the extra detail.
The big issue was memory use: at least for the version I adapted, it needs 20x as much memory to run as the size of the image you want to process. So a 3k x 3k 8-bit RGB image needs 1GB of RAM. I blame CImg (I think). It needs reimplementing in a more practical image processing library. The results are nice though, if you play with the parameters a bit.
gimp2.4 (due out RSN, it's in final polishing) has colour management (import, export, preview, working space, etc). Gimp has been able to read RAWs for years via dcraw.
Once 2.4 is out of the door they'll start to integrate GEGL. The first GEGL Gimp will just be using it for adjustment layers, but a version or two after that will be fully gegl'd and should do 16 bits. Of course they've been promising 16 bits for years:-( but the momentum does seem to be back again.
However, what you and the GP seem to be missing, is that EVEN WITH Quartz Extreme it is NOT using 3D acceleration to speed up the 2D vector drawing engine. It is ONLY USING 3D TEXTURES from the GPU Via OpenGL to COMPOSE the Screen, so that the Window Textures are mapped to a Polygon and rendered with the Video Card directly via OpenGL.
This is STILL Just a BITMAP Composer, using OpenGL to store and render Textures on a simple Polygon surface for each Window.
Sorry, you're wrong. You're thinking of Quartz Extreme, since then apple has introduced Quartz 2D Extreme (what a terrible name). Here's (for example) an ars article:
You're right that they have different architectures. The mac is still 2D bitmaps (though drawing is GPU-accelerated), whereas vista has gone for a more ambitious display list thing. It'll be interesting to see how they match up over the next few years.
There is a difference between using 3D textures for window composition and actually using functions of the 3D library for accelerating the drawing inside an application and the desktop.
Actually, GP is correct, QuartzGL, which uses the GPU to render the desktop (not just composite) was in 10.4. It even renders font glyphs on the GPU. Not enabled by default, but I guess it should be in 10.5.
There's also CoreImage, a nifty GPU-accelerated 2D image processing API, in there. It runs chains of simple filters at video speeds. Not widely used yet AFAIK.
So I agree: an Opteron beats a Core Duo by about a factor of two. I blame a combination of gcc, the extra regsiters in 64-bit mode and AMD's better FPU.
The Wii has an optional always-on mode, WiiConnect24. It does things in standby like pick up your wii messages, update the weather forecast channel, etc. etc.
Don't know what the PS3 always-on means though. No doubt it'll use many more watts.
Well, 1.4x - 1.8x slower for text drawing with a set of mysterious patches. I'm sure performance will improve further once the patches are committed and tuned a bit more.
It might be "standard behavior" but the system does NOT tell the user that such a feature exists in the first place!
What I mean is: you can always do this, anywhere. It's one of the features of lists in GTK. Any time you see a list of things, you can type to pick one. It's expected behaviour and shouldn't need explaining.
Anyway, the filechooser now has a location box so you can also type in that (and even copy/paste! heh).
Slashdot Mirror
KDE 3.x and GNOME use almost exactly the same amount of memory.
http://spooky-possum.org/cgi-bin/pyblosxom.cgi/kdevsgnome.html
(don't have one, won't get one, but I did flip though the manual)
FWIW, Gnome is pretty consistent now: more than Vista, maybe less than OS X.
The Gnome HIG (Human Interface Guidelines), http://library.gnome.org/devel/hig-book/stable/ , is followed very, very closely. If your app violates the HIG you'll get a stream of annoying bugs filed about it. If you start up Ubuntu it's quite hard to find any non-HIG programs.
KDE have something similar I think, though I don't follow KDE development closely.
It depends on the sort of science. In something like Physics you can get a very high level of proof, in something like climatology or medicine you can't because the systems are just too complex.
For example, consider smoking. Does smoking cause lung cancer? This is question of vital interest with large economic consequences, but one which can't easily be proved in the way you're demanding. Someone smokes, twenty years later they get lung cancer, how do you absolutely demonstrate that the cancer was caused by the cigarettes? You have to do very large scale studies over many decades, control for as many factors as you can and produce what you hope is an impressive confidence interval. That's the best you can do.
The smoking/cancer link has probably now achieved proof status (though you can still find people arguing about the data). When will CO2 warming get there? It's at the 90% point, according to the IPCC.
Programs run quickly under efence, but sadly memory use will balloon. It (I hope I have this right) puts each malloc into a separate page with guards either end. So every tiny strdup() will use some huge amount of your address space. It's not practical for anything bigger than rather small.
valgrind takes the opposite approach: it does all the checking in software, so it runs slowly (about 1/20th of real speed, the last time I measured it), but is much more modest in the amount of RAM it needs (though it still needs a lot).
This is one area where every developer really needs 64-bit processor. I have 8GB in my desktop machine now and I can run even the largest project I work on with full memory checks. It's wonderful.
Here's an example: I wrote a HOWTO for my pet project explaining how to set up a build environment for it on windows: http://www.vips.ecs.soton.ac.uk/index.php?title=Bu ild_on_windows. That's about a day's work for an experienced developer. Much longer if you didn't have the HOWTO to follow.
The same setup is a couple of clicks and less than a minute on a system with a nice package manager.
They all handle updates as well, so you have a central place to keep all your entire system patched. For example, when a vulnerability is discovered in a core library (libz, or linpng have been recent examples), you need to go through your system checkiing that every application which uses one of these libraries is updated. This is almost impossible on Windows, but automatic on systems with package managers.
I had a keyboard fail on an HP laptop about two years ago and they made me remove linux and put XP back before they'd fix it. Nice to hear they were better about it with you.
I remember seeing a 12 bits per channel CRT at SPIE in 1996. There was no obvious improvement, even on their demo images. It's just too hard to (1) get noise down enough that the bits become significant, and then (2) get the display bright enough that a human observer under reasonable conditions can see the extra detail.
CImg does not support chaining (as fasr as I know), so it will be a relatively heavy memory user.
I hacked it into my image processing library a year or so ago:
http://www.vips.ecs.soton.ac.uk/index.php?title=GR EYCstoration
The big issue was memory use: at least for the version I adapted, it needs 20x as much memory to run as the size of the image you want to process. So a 3k x 3k 8-bit RGB image needs 1GB of RAM. I blame CImg (I think). It needs reimplementing in a more practical image processing library. The results are nice though, if you play with the parameters a bit.
Once 2.4 is out of the door they'll start to integrate GEGL. The first GEGL Gimp will just be using it for adjustment layers, but a version or two after that will be fully gegl'd and should do 16 bits. Of course they've been promising 16 bits for years :-( but the momentum does seem to be back again.
This is STILL Just a BITMAP Composer, using OpenGL to store and render Textures on a simple Polygon surface for each Window.
Sorry, you're wrong. You're thinking of Quartz Extreme, since then apple has introduced Quartz 2D Extreme (what a terrible name). Here's (for example) an ars article:
http://arstechnica.com/reviews/os/macosx-10.4.ars/ 14
OS X 10.4 renders 2D vectors with the GPU.
You're right that they have different architectures. The mac is still 2D bitmaps (though drawing is GPU-accelerated), whereas vista has gone for a more ambitious display list thing. It'll be interesting to see how they match up over the next few years.
Actually, GP is correct, QuartzGL, which uses the GPU to render the desktop (not just composite) was in 10.4. It even renders font glyphs on the GPU. Not enabled by default, but I guess it should be in 10.5.
There's also CoreImage, a nifty GPU-accelerated 2D image processing API, in there. It runs chains of simple filters at video speeds. Not widely used yet AFAIK.
I have some benchmarks too:
e nchmarks
http://www.vips.ecs.soton.ac.uk/index.php?title=B
Again, plain C code, no SSE/whatever. It is threaded, which makes it slightly different. The source is there too.
Results:
Opteron 850, 2.4 GHz, 4 CPUs, 4.5s
Opteron 254, 2.7 GHz, 2 CPUs, 6.9s
P4 Xeon (64 bit), 3.6 GHz, 2 CPUs (4 threads), 7s
Core Duo, 2.0 GHz, 2 CPUs, 18.1s
P4 Xeon (32 bit), 3.0 GHz, 2 CPUs (4 threads), 19.7s
P4 (Dell desktop), 2.4 GHz, 1 CPU, 36.6s
PM (HP laptop), 1.8 GHz, 1 CPU, 58.5s
So I agree: an Opteron beats a Core Duo by about a factor of two. I blame a combination of gcc, the extra regsiters in 64-bit mode and AMD's better FPU.
Don't know what the PS3 always-on means though. No doubt it'll use many more watts.
Here's an update written by a GNOME person:
e vsgnome.html
http://spooky-possum.org/cgi-bin/pyblosxom.cgi/kd
tldr: they have (essentially) the same memory requirements.
Well, 1.4x - 1.8x slower for text drawing with a set of mysterious patches. I'm sure performance will improve further once the patches are committed and tuned a bit more.
http://mail.gnome.org/archives/performance-list/20 06-December/msg00006.html
My nokia (the cheapest you can get, 1101?) has this. Quite handy, as you say.
What I mean is: you can always do this, anywhere. It's one of the features of lists in GTK. Any time you see a list of things, you can type to pick one. It's expected behaviour and shouldn't need explaining.
Anyway, the filechooser now has a location box so you can also type in that (and even copy/paste! heh).
Except that you can type in any GTK list or tree view? It's standard behaviour for all widgets.
XGL works OK on my ATI laptop. It did take a bit of annoying fiddling to get it started six months ago, I imagine it's easier now.
The Eft file selector has a visible location box.