I did my own experiments, comparing Kubuntu, Ubuntu and Xubuntu. Same result--KDE is already less bloaty than GNOME. XFCE is less bloaty than both of them, of course.
And I'm currently running GNOME, but planning to switch back to KDE now that Mono is part of GNOME.
Those that are so resistant to change will eventually be filtered out of the gene pool, having been replaced by those who can look at alternatives to what they are doing, do some research, and make a choice as to which is better.
The 8088 was 16bit internal but 8bit external [...] They were looking at the 68k at the same time [...]
Which is another way of saying that the 8088 sucked compared to the competition, the 32/16 bit 68k. Maybe they measured the suck in $, maybe in power, maybe in bus width, who knows? Point is, x86 wasn't picked because it was good.
OK, parent is the first post I've seen that explains the real reason why the x86 has become basically the only instruction set in mainstream computing.
There's no technical advantage to x86. In fact, IBM picked it specifically because it sucked--they didn't want the PC to compete with their professional workstations. Grafted on sets of extensions (SSE, MMX etc) have just made x86 more baroque over the years, and backward compatibility requirements have prevented cleaning away crap like segmented memory.
However, once a big enough chunk of the market got behind x86, it became impossible for any other design to keep up in R&D across all segments (mobile, desktop, server etc). Intel collects truckloads of cash, so they can spend more on engineering and make up for x86's deficiencies. IBM can compete with Intel, but even IBM decided it wasn't financially viable to be competitive in all segments, and basically dropped desktop PowerPC to focus on embedded (game consoles) and servers, hence Apple's switch to Intel. Similarly, AMD can compete, but only in desktop and servers. VIA compete, but only in embedded and low-end desktop.
The interesting question is whether the same thing will happen with operating systems. We're now basically down to Windows and Unix, plus a few niche OSs for embedded systems and high end servers. Microsoft finds itself in the awkward position of having to compete against most of the rest of the computing industry, including Sun, IBM, Apple, HP... At the same time they have certainly the biggest--and likely the cruftiest--codebase in the history of computing.
Ten years ago they were able to deliver technology before the competition, albeit not original technology--DDE and OLE shipped in usable form before the Publish-and-subscribe and OpenDoc they were copied from. Now things are different, Microsoft is struggling to keep up with Apple. It seems they can't copy Apple's new technology as fast as Apple can invent more new stuff. And at the same time, they're trying to fight two more wars in the embedded space with Xbox and Windows CE. Hence 5 years between desktop OS releases, while Apple has a release every 18 months.
Well, yes, there are always going to be the envelope-pushing games that need the extra few percent speed of C or C++. However, that doesn't explain why the other 95% of games don't make more use of other languages. Given that you can write something like Quake 2 in Java and have it run plenty fast enough on today's common hardware, that covers the speed needs of a hell of a lot of games.
Perhaps if game developers made more use of better languages, the frequency of games in development hell would be reduced. Perhaps we'd also lower development costs for the non-envelope-pushing games and get more inventive original games.
The problem is that like most things in programming language design, there's a tradeoff. Insisting on static method signature checking at compile time, for example, means you can't dynamically extend objects at run time without a lot of awkwardness.
I'm an American who has lived in a number of cities around the UK, and I have never heard of the word "fanny" referring to anything other than one's ass. It most certainly does not refer to a woman's vulva nor vagina.
You're wrong. I refer you to Roger's Profanisaurus, as compiled from the pages of Viz Comic, surely the definitive word on UK vulgarity.
My biggest gripe with these things is that they appear not to last as long as advertized. I had one that lasted one day! About half of them only last a year or so.
Well, if we're doing anecdotage, I'm still using CFL bulbs I bought in 1997. Maybe your light fittings have dodgy switches that bounce a lot, or your electricity supply is full of spikes?
...an accident from running a red light is more likely to cause serious injury than an accident from being rear-ended.
Not if you're driving a Ford.
(The Pinto, Crown Vic and Mustang have all had major safety issues regarding rear collisions and gasoline being spewed into the passenger compartment.)
Yes, I understand what "has an ordering but no equality" means. I wasn't questioning the usefulness of the notion, I was asking what you would expect the language to do when you try to compare two objects for equality and they don't have an equality defined, since apparently throwing an exception is unacceptable.
Presumably you're one of those "static type system" people? So you'd want a compile time error?
There are lots of games other than those two written in Java.
I imagine that most games are still written in C/C++ for a number of reasons:
1. C/C++ is what the developers know.
2. Toolkits and engines (RenderWare, Havok, PS2 dev kit etc) are mostly built for C/C++.
3. Java's suitability for games is a somewhat recent development, and it'll take a while to catch on.
4. Myths that Java can't run fast enough for games.
Lisp has the same problems. Hence although it has been used for games and real-time programs for years, it's still a minority language for the problem area. (Random examples of mainstream games written in Lisp: Jak and Daxter series on PS2, "Abuse" for PC. Random examples of real time systems written in Lisp: NASA Deep Space One control software, AT&T digital exchange control software.) ((Yes, I used to work for a Lisp vendor.))
Yeah, crapplets still take a long time to start up. I'm not sure why that is, given that the VM startup time has been reduced so much. Maybe it's something to do with the whole plugin mechanism.
Hopefully iWork will include Numbers, the spreadsheet; and iMovie HD will be upgraded to deal with AVCHD (yet another unnecessary non-standard video container format).
So the only way to represent the concept of a class with an ordering but no equality is to have a run-time failure every time someone tries to compare them for equality?
What do you think a programming language should do when I try to compare two things that can't be compared for equality?
Slashdot Mirror
And then one of the losers reported him to the FBI for running an unlicensed gambling ring via the Internet, and he ended up in jail?
I did my own experiments, comparing Kubuntu, Ubuntu and Xubuntu. Same result--KDE is already less bloaty than GNOME. XFCE is less bloaty than both of them, of course.
And I'm currently running GNOME, but planning to switch back to KDE now that Mono is part of GNOME.
Doesn't seem to have killed off the emacs users.
Yeah, I'm sure there's some reason why phone keypads are upside down from every other keypad. Maybe it's to slow down dialing?
Which is another way of saying that the 8088 sucked compared to the competition, the 32/16 bit 68k. Maybe they measured the suck in $, maybe in power, maybe in bus width, who knows? Point is, x86 wasn't picked because it was good.
Like Linux and every major Unix, you mean?
OK, parent is the first post I've seen that explains the real reason why the x86 has become basically the only instruction set in mainstream computing.
There's no technical advantage to x86. In fact, IBM picked it specifically because it sucked--they didn't want the PC to compete with their professional workstations. Grafted on sets of extensions (SSE, MMX etc) have just made x86 more baroque over the years, and backward compatibility requirements have prevented cleaning away crap like segmented memory.
However, once a big enough chunk of the market got behind x86, it became impossible for any other design to keep up in R&D across all segments (mobile, desktop, server etc). Intel collects truckloads of cash, so they can spend more on engineering and make up for x86's deficiencies. IBM can compete with Intel, but even IBM decided it wasn't financially viable to be competitive in all segments, and basically dropped desktop PowerPC to focus on embedded (game consoles) and servers, hence Apple's switch to Intel. Similarly, AMD can compete, but only in desktop and servers. VIA compete, but only in embedded and low-end desktop.
The interesting question is whether the same thing will happen with operating systems. We're now basically down to Windows and Unix, plus a few niche OSs for embedded systems and high end servers. Microsoft finds itself in the awkward position of having to compete against most of the rest of the computing industry, including Sun, IBM, Apple, HP... At the same time they have certainly the biggest--and likely the cruftiest--codebase in the history of computing.
Ten years ago they were able to deliver technology before the competition, albeit not original technology--DDE and OLE shipped in usable form before the Publish-and-subscribe and OpenDoc they were copied from. Now things are different, Microsoft is struggling to keep up with Apple. It seems they can't copy Apple's new technology as fast as Apple can invent more new stuff. And at the same time, they're trying to fight two more wars in the embedded space with Xbox and Windows CE. Hence 5 years between desktop OS releases, while Apple has a release every 18 months.
Well, yes, there are always going to be the envelope-pushing games that need the extra few percent speed of C or C++. However, that doesn't explain why the other 95% of games don't make more use of other languages. Given that you can write something like Quake 2 in Java and have it run plenty fast enough on today's common hardware, that covers the speed needs of a hell of a lot of games.
Perhaps if game developers made more use of better languages, the frequency of games in development hell would be reduced. Perhaps we'd also lower development costs for the non-envelope-pushing games and get more inventive original games.
The problem is that like most things in programming language design, there's a tradeoff. Insisting on static method signature checking at compile time, for example, means you can't dynamically extend objects at run time without a lot of awkwardness.
Look up The Uranus Experiment. First zero gravity cum shot, I believe.
Right, and now that every kid with a DS Lite has WiFi in his handheld game system, the kids could be playing Animal Crossing online.
You're wrong. I refer you to Roger's Profanisaurus, as compiled from the pages of Viz Comic, surely the definitive word on UK vulgarity.
Well, if we're doing anecdotage, I'm still using CFL bulbs I bought in 1997. Maybe your light fittings have dodgy switches that bounce a lot, or your electricity supply is full of spikes?
What's a VCR? Is that like those "gramophones" my grandmother used to talk about?
FFS, RTFA.
The bulbs do make sense economically.
Not if you're driving a Ford.
(The Pinto, Crown Vic and Mustang have all had major safety issues regarding rear collisions and gasoline being spewed into the passenger compartment.)
Yes, I understand what "has an ordering but no equality" means. I wasn't questioning the usefulness of the notion, I was asking what you would expect the language to do when you try to compare two objects for equality and they don't have an equality defined, since apparently throwing an exception is unacceptable.
Presumably you're one of those "static type system" people? So you'd want a compile time error?
Well, in general that assumes the language is totally statically typed. If I wanted that kind of tradeoff for type safety, I'd be writing Java.
There are lots of games other than those two written in Java.
I imagine that most games are still written in C/C++ for a number of reasons:
1. C/C++ is what the developers know.
2. Toolkits and engines (RenderWare, Havok, PS2 dev kit etc) are mostly built for C/C++.
3. Java's suitability for games is a somewhat recent development, and it'll take a while to catch on.
4. Myths that Java can't run fast enough for games.
Lisp has the same problems. Hence although it has been used for games and real-time programs for years, it's still a minority language for the problem area. (Random examples of mainstream games written in Lisp: Jak and Daxter series on PS2, "Abuse" for PC. Random examples of real time systems written in Lisp: NASA Deep Space One control software, AT&T digital exchange control software.) ((Yes, I used to work for a Lisp vendor.))
"Indiana Jones and the Looting of Iraq".
Yeah, crapplets still take a long time to start up. I'm not sure why that is, given that the VM startup time has been reduced so much. Maybe it's something to do with the whole plugin mechanism.
Hopefully iWork will include Numbers, the spreadsheet; and iMovie HD will be upgraded to deal with AVCHD (yet another unnecessary non-standard video container format).
Actually, knowing Apple they'll just use a trivial variant of a standard protocol, but fail to document it--like how AirTunes uses a variant of RTSP.
What do you think a programming language should do when I try to compare two things that can't be compared for equality?
They do.
The You Don't Know Jack series was the first I was aware of, and that was back in the 90s. A recent one is Chrome .