Go to any security related website and count the number of security holes for Linux and Windows as well as Solaris. WIndows is very bad while Linux is behind as a close second.
Keep in mind that Solaris 8 comes with squat as far as software. Of course it's going to be more secure than Redhat Linux. The default install doesn't come with Apache, POP servers, and all sorts of other stuff. Redhat gives you the kitchen sink, and the typical user will just opt to install everything. A Solaris installation would be just as insecure if you installed the same software and didn't pay attention to it. And Solaris admins do install the same software that comes with Redhat. But they need to go out and download it from somewhere else, either binaries from sunfreeware.com or compile their own stuff. Those won't be counted as Solaris security holes.
If you compare the software that comes with a Solaris 8 installation with the equivalent software that comes in a Linux distribution, I seriously doubt you'd find Linux any less secure.
And simply comparing the number of kernel patches to Solaris patches is not fair. Linux is a rapidly evolving operating system. Solaris is stagnant. It hasn't fundamentally changed since the original Solaris 2. Linux supports more devices, more filesystems, more platforms. It's open source, so people find and fix security holes more quickly. How many security holes are in Solaris 8? How quickly do those holes get fixed? There are always plenty of security patches for Solaris.
Solaris is in some ways more dangerous, because it's such a pain to keep software up to date. Sunfreeware.com has only some of the packages you need and they're always out of date. Inevitably, people have to compile and install things themselves. That's a lot of work, and if you don't have a Solaris admin you may not be inclined to do it.
Actually the FCC says that common areas can be used for Dishes, and it would be illegal for an apartment complex to not allow a dish to go.
I know, but the definition of "common area" is sufficiently vague. Here (SF Bay Area), they're telling me that the common area includes the inside of my patio and the inside of the apartment. There's a five foot wall around the patio and it faces north. I wanted to use this suction cup contraption: www.inwall.com to suspend the dish from the outside of a south facing window, but they wouldn't let me do it.
Could this be an example of the government doing something right? And maybe, just maybe protecting the rights of its citizens?
No such luck. This is an example of the administration trying to protect their cronies in the cable industry.
Individually, Dish Networks and DirectTV are no threat to the local cable companies. People who live in apartment complexes are rarely able to install satellite dishes. If your patio doesn't point the right way or you don't have a clear 45 degree line of site over any trees, you're screwed. A few complexes will let you install a dish on the roof if you're on the top floor. But they don't have to so they usually will not permit it. Many windows are opaque to satellite signals, so simply finding a window pointing in the right direction is not necessarily enough. I have to open a bedroom window to use my dish.
And even if you can get a dish installed, you probably won't get all your local networks. Although there will always be one station broadcast for every network from your satellite, you can't get access to any station that's not in your "broadcast area". Dish and DirecTV would probably like to sell you a package that gives you access to a replacement station in a different region, but they're not allowed to. The law prohibits it. Years ago, the cable companies lobbied the government to put that law in place to protect themselves from satellite competitors. How many people will subscribe to satellite TV when they'd be missing one or two of ABC, NBC, CBS, FOX, UPN, and WB?
No, what Hart is saying is that Lucas did not knowingly incorporate mythological elements. He only knowingly incorporated stories from pulp science fiction. Those stores could very well have been derived from mythology, or were based on something else derived from mythology, etc. And as you say, most stories, especially adventures, have elements which stem from mythology.
The point is, Lucas shouldn't be going around pretending he is some kind of literary genius by claiming to have constructed Star Wars from elements of all mythologies. He claims he intended to do this from the start, and that's a load of a crap. Campbell is correct that Star Wars displays mythological elements, but he shouldn't be praising Lucas for any insight. There's a difference between finding your general good vs. evil parallels with mythology and suggesting that a given scene in Star Wars is modelled after a specific mythological story.
Ah, but the point is that the Morpheus user isn't the customer. The Morpheus user is the product that is sold to these advertisers, the real customers. The Morpheus software is bait.
The point is you're not forced to buy a Mac. People (typically) buy Macs because they like them and like MacOS. People often buy Wintel because they feel they have no choice. They want/need the software availability only offered on Windows, but they despise the operating system that makes their system crash. Windows users are forced to upgrade to newer versions of Windows that are generally slower and very expensive. Another group of Microsoft haters are Linux-x86 users. They use Microsoft's hardware and have to fight to get support from hardware venders who don't like working with anyone but Microsoft. And are pissed off that they have to pay for Windows on the desktops/laptops they get from a major vendors. While you have the same gripe with Apple, but there are not very many of you. Most Linux fans use Wintel PCs they've built from parts.
Re:Mandrake8.1 ships with both 2.4 and 2.2
on
2.4, The Kernel of Pain
·
· Score: 2, Insightful
But 2.4 is *supposed* to be stable. That's why it's called a stable kernel branch. It's perfectly justified to complain that it's not stable.
And as far as the VM mess, it wasn't really an issue of communication. It was an issue of Linus arbitrarily accepting some patches from Rik, and ignoring others. Alan Cox at least made a real attempt to incorporate all of Rik's VM patches in the -ac branch. And the -ac branch had a much improved VM as a result. But Linus didn't make the effort for some reason.
The reason 2.4 has been unstable is because the maintainership has been poor. Usually Linus turns over maintainership to someone else (previously Alan) very early on in the series. I think that happened at 2.2.7 for the 2.2 series. Alan puts out of lots of prepatches and gives people enough time to test prerelease kernel patches. Linus is random about it. He'll release a kernel that has changes that weren't in the prepatches. And a bunch of times those changes broke something badly. It probably doesn't help that he has a day job. Alan gets paid to work on Linux full time. The 2.2 series only started getting stable when Alan took over. 2.4 only just recently got handed off.
Currently existing compilers, and statistics will always be more accurate for run time optimization, but who's to say some of that can't be done ahead of time?
Compilers make optimizations when code is compiled to machine language. A run time optimization is an optimization that is made dynamically when the code is run. So how can a compiler be more accurate at run time? It's not there at run time!
And since when does anyone worry about larger exe files?
Think about a loop that has a hundred iterations. If you unrolled it all the way, you have one hundred times more code. Compilers obviously don't do that. After you unroll a few times, you stop getting any more benefit. Larger executables mean more memory usage and memory accesses take forever. It makes a guess about how many times they should bother unrolling it. They unroll maybe 5 times at most. But a compiler can't make a perfect guess because the time it takes to execute some code are often dependant on runtime conditions. The number of loop iterations might be based on a value a user inputs in. The compiler has no idea what value the user will input. Also, the time to access a piece of data in memory varies depending if it's in cache, memory, or paged to disk. These things will only be known at runtime.
The Itanium has hardware support for executing x86 instructions. That's about as hybrid x86 as a processor should get, I think. You can only take the x86 architecture so far before it becomes impossible to speed up no matter how much brute force Intel applies. We're getting near that point. Integer performance has been relatively decent compared to RISC processors, but the floating point is hopelessly bad. At least the integer unit is CISC. The floating point unit is even more primitive: stack based. The implementation of SIMD on x86 (MMX and SSE) is so hacked as to be almost useless. For example, MMX shares the same registers as the floating point unit. There are too few registers, and mixing SSE registers with stack based FP registers is a pain. Generating useful SIMD code is an artform on x86. The Altivec set on PowerPC is far more useful. Apple has been able to get noticeable increases in GUI speed by using it. That could never happen on x86. MMX and SSE are relegated to video drivers, games, and number crunchers. For anything else, the overhead and programming difficult outweight the benefits. And with processor speeds trailing memory year by year, you really have to start thinking about architectures that will promote efficient use of registers.
Pulling the plug on x86 may not be so hard. Microsoft is ready to provide an OS and compilers for Itanium. And all the code that people use today are written in higher level programming languages and are no longer very hardware dependant. There are already tons of old programs that will not work properly in Windows XP. People who care about running their ancient programs will not be doing so on new computers.
Hell, Apple managed to pull off the switch between x86 to PowerPC. And they did that on an OS that was written in Pascal and assembly. The PowerPC didn't even have any 680x0 emulation.
The problem isn't trying to support the x86 instruction set or MMX, SSE, or SSE2. It's that VIA wants to use the same bus protocol as the Pentium 4, so that their chip is a drop-in replacement. Since the Pentium 2, everyone has been barred from doing that. Intel's bus protocol for their Pentium 2 through 4 line is patented. Chipset vendors like VIA were able to get licenses to implement support for the Pentium 2 and Pentium 3's bus (GTL), but not for making processors for it. That's why AMD couldn't make processors that work on Intel chipsets and motherboards after the Pentium. Intel is also sueing VIA for making a chipset supporting the Pentium 4.
Wrong, first I don't know where Java fits into that picture,
Java has builtin support for native GUIs. It currently only support Motif on Linux, but Sun plans to provide GNOME support. If they went with Qt, then it's possible that any commercial Java code would require a Qt Pro license.
second, you only need to pay if you want to SELL your code.
So are you saying that Solaris customers shouldn't be selling code?! Look, I'm not talking about open source Solaris development or people who buy Suns for web servers. I'm talking about software companies that sell closed source code on Solaris. Those people still matter to Sun.
Things like Borland Delphi or Kylix or Visual Studio are not free, too.
But they aren't $1500 either. It's one thing to pay for a compiler or IDE, it's another thing to have to pay a large sum for the right to program the GUI in any way. Any UNIX vendor that switches to Qt is basically at the whim of Trolltech. They can sell development environments to their customers, but their customers can't program the system unless they also pay Trolltech.
Many UNIX software vendors have developed a close relationship with Sun over the years. They don't want to maintain a separate relationship with Trolltech for basically the same product. Sun doesn't need to outsource their GUI to a commercial company. They have the resources and money to fund their own GUI development. They are effectively doing that with GNOME.
Sun customers would effectively pay for GNOME, because Sun is using their revenues to fund developers for the project. The same goes for Microsoft and their GUI. For CDE and Windows, every user and developer contributes money to pay the GUI developers. No matter what, the person who writes the GUI is getting paid. It's just a question of who gets paid and when. For Qt, the closed source developer is the only one that pays. And right now they pay a lot because there aren't enough Qt customers to reduce the price.
1. Sega's current arcade machine (Naomi) is dreamcast (powervr) based. This makes it easier for Sega to release games on Naomi, and then port to Dreamcast. Without Dreamcast, there's no point in continuing to use PowerVR for their arcade hardware.
2. Sega tried really hard to sell a game console. The Dreamcast is way better priced than the Playstation 2, and proved to be just as capable for real world uses. Unfortunately, hardly anyone realized that. Sony successfully brainwashed the media (and as a result, the public) into thinking the Emotion Engine is the fastest processor on earth or something. The PSX2 may have gobs of functional units, but no one knows how to use them. Instead of having a separate video processor, Sony stuffs all functions into a single VLIW processor. This looks great for marketing, because the Emotion Engine is made to look cool and buff. But it doesn't make it any better than the standard hardware architectures that the Gamecube, Dreamcast, and XBox use. It just makes it more expensive and difficult to program. Notice that the Gamecube will sell for less than the PS2, will cost much less to produce, and will be faster. Sony had deeper pockets to spend on marketing. Sony lost more money on the PS2 than Sega did. But Sony could afford to lose a lot. It would have been pointless for Sega to continue in the home console market. They don't stand a chance against monstrous companies like Sony and Microsoft. It doesn't make sense to keep on fighting a hopeless battle when their most successful business is writing games.
3. Sega is a superb game developer. People would buy Dreamcasts just to play Sega games, even though Sony was very likely to kill off the platform. Sega rules the arcades, and their arcade ports are always among the best games released on any platform. Most console game developers have at most one or two successful games over a period of months. Sega somehow is able to churn them out: Shenmue, Jet Grind Radio, House of the Dead 2, Skies of Arcadia, Crazy Taxi, Phantasy Star Online, Sega Rally 2, Space Channel 5, etc. I don't think Sega will have too much trouble as a game developer.
It can get more open source. GNOME and GTK+ are LGPL'd, meaning you can compile and sell closed source software that links with them. The GPL forbids this. So if you want to write commercial closed source code with Qt, you need to pay about $1500-$2000 for a Qt Professional license.
Sun isn't the one who has to pay for the developer license. It's each and every Solaris developer who has to pay. Imagine you are Sun, and you give away your OS for almost nothing along with your hardware. Your customer paid $1000 for their Blade 100. So now with Solaris 9, you tell them you've switched from CDE to Qt and so now every Solaris customer needs to caugh up $2000 per developer and send it to Trolltech if they write any GUI C/C++ code or Java code. Now imagine those customers telling you (Sun) to go to hell. Solaris developers who do GUI work may be content with Motif and CDE for programming. It's free for them, it's well documented, and it gets the job done. Sun needs to give them a reason to migrate their code.
But 'C' vs 'C++' did also have a lot to do with it. GNU C++ is incompatible with Sun's C++. You can't link Sun C++ libraries with GNU C++ code. There's no built-in C++ standard library on Solaris. And it's too late now because they wouldn't be able to decide whether to ship with Sun's C++ standard library or GNU's.
Sun developed LWPs in Sun OS 4, which was based on 4.3BSD. Sun contributed lots of stuff back to BSD, like vnodes, NFS, RPC, and their SysV shared library and shared memory incorporation. Sun never patented any of it, so they can't sue. The core of Solaris 2 is from AT&T SVR4 anyway.
MS didn't put in USB 2.0 support because they wanted to push Firewire. This is a good thing from Apple's standpoint. Apple invented Firewire, and Intel invented USB. Intel is trying to kill Firewire with USB 2.0 so they can receive more royalty money. But MS is in favor of Firewire because it is a better technology. Apple is just trying to play it safe by supporting USB 2.0 . They would much rather you use Firewire for high speed connectivity. Hopefully the industry will give Intel a well deserved bitch-slap and stick with Firewire for digital camcorders and such. MS is adding support for USB 2.0 in the next XP service pack.
Regardless of development speed, there's no way that Sun could have gone with Qt. There are no licensing fees associated with developing under CDE. For Sun to ask their customers to dish out $2000 per developer to some other company would be suicide. That's doubling the cost of an Ultra 5 development system. Sun customers would simply revolt. Arguing the attractiveness of Qt would do no good. They don't care. Most of them write networking software and the GUI component is not something they invest much time in. Anyone who ever cared about selling desktop oriented software moved over to the Microsoft world.
And it's not just the cost of the license, it's the fact that Sun customers have to deal with a 3rd party when before they just to deal with Sun. There's the extra cost of managing this relationship, calculating the number of licenses to buy, etc.
Sun has the resources to develop a toolkit just as good as Qt from scratch. But the last time they tried that (OpenLook), everyone revolted against them. But they can always improve GNOME. Gtk may have a messy C interface, but you could always use a C++ binding to abstract away the details. Similar things have been done with Motif. C++ is nice and all, but C++ library compatibility is nonexistent right now. Until every vendor can ship with a C++ shared library that gcc and all the commercial compilers can link with, standardizing on C++ will be impossible.
No. Both fascism and socialism believe that the needs of the society outweigh the individual. But socialism believes in equality, while fascism does not. Now try to find a society that never takes away some individual freedom for the interest of the society as a whole. Just because he's not a libertarian doesn't make him a fascist.
What's wrong with this? It's important that people understand what licenses are compatible with the GPL. If you blindly go about merging GPL'd code with GPL-incompatible, you're violating license agreements. By dubbing the whole thing GPL, you're violating the non-GPL license. And by not doing so, you're violating the GPL license. That's just the way the GPL works. License compatibility has to be clearcut, otherwise the license is not enforceable. The list clearly shows that GPL has a lot of compatibility problems. If that's a problem for you, the solution is not to use the GPL'd code.
Console manufacturers sell their systems at a loss. They only make profit from game royalties. So it's to their advantage that games for a console are produced for as long as possible. And since console hardware architectures change so much, it takes a long time for game makers to get the hang of new systems. And since the games don't work on older systems, lots of console owners get pissed off that they don't work on systems they bought just a year ago.
In the PC world, new processors come out all the time. But new software will still work on 3 year old systems (typically). There are plenty of API and driver layers to make hardware transparent. But on consoles, there isn't much of an OS. You work on bare hardware basically. Games then become very dependant on the behavior and timings of the hardware. The advantage is they can squeeze the most capability out the hardware and use very small amounts of memory. The disadvantage, of course, is that forward compatibility is not possible without emulation.
I don't understand why this is never mentioned in the reviews. How did support for MP Athlon just appear? From my understanding, AMD is using the EV6 multiprocessor protocol which is incompatible Intel's patented APIC protocol. So how does Windows 2000 just work?
Sony has also pressured retailers to not stock the Dreamcast at all. Sony reps have gone so low as to sabotage DCs on display. And they've been doing crap like this for years. Long ago the Wherehouse was considering stocking the Saturn. Sony told them they'd pull all Columbia movies and music if they did. Sony has bought and bribed game developers just to stop them from developing for other platforms. Many people have had their PSX's overheat and die within their warranty lifetime. When they called Sony to complain, Sony told them they weren't supposed to use their PSX's on carpet and voided their warranties.
Sony has done all of this so blatantly, but the public doesn't seem to notice or care. And it doesn't look like the slashdot community cares either. Sony develops on Linux and is selling a Linux distribution for the PS2. Sega provided Windows CE. So that automatically makes Sony the good guys.
Same deal with Creative Labs and 3dfx. Creative Labs made Soundblaster and SB Pro a standard and allowed their competition to emulate them. And then once you needed to use Soundblaster emulation for every game, Creative sued the hell out of everyone and made SB16 proprietary. Mediavision went bankrupt but later reformed as Aureal. And then Creative copies their success, releasing their own PCI sound card. Then Creative sued Aureal into bankruptcy and bought their remains. But Creative released a GPL'd Linux driver, so slashdot loves them. 3dfx sued everyone trying to implement a Glide wrapper, but when they release Glide under the GPL they're suddenly the good guys.
Go to any security related website and count the number of security holes for Linux and Windows as well as Solaris. WIndows is very bad while Linux is behind as a close second.
Keep in mind that Solaris 8 comes with squat as far as software. Of course it's going to be more secure than Redhat Linux. The default install doesn't come with Apache, POP servers, and all sorts of other stuff. Redhat gives you the kitchen sink, and the typical user will just opt to install everything. A Solaris installation would be just as insecure if you installed the same software and didn't pay attention to it. And Solaris admins do install the same software that comes with Redhat. But they need to go out and download it from somewhere else, either binaries from sunfreeware.com or compile their own stuff. Those won't be counted as Solaris security holes.
If you compare the software that comes with a Solaris 8 installation with the equivalent software that comes in a Linux distribution, I seriously doubt you'd find Linux any less secure.
And simply comparing the number of kernel patches to Solaris patches is not fair. Linux is a rapidly evolving operating system. Solaris is stagnant. It hasn't fundamentally changed since the original Solaris 2. Linux supports more devices, more filesystems, more platforms. It's open source, so people find and fix security holes more quickly. How many security holes are in Solaris 8? How quickly do those holes get fixed? There are always plenty of security patches for Solaris.
Solaris is in some ways more dangerous, because it's such a pain to keep software up to date. Sunfreeware.com has only some of the packages you need and they're always out of date. Inevitably, people have to compile and install things themselves. That's a lot of work, and if you don't have a Solaris admin you may not be inclined to do it.
Actually the FCC says that common areas can be used for Dishes, and it would be illegal for an apartment complex to not allow a dish to go.
I know, but the definition of "common area" is sufficiently vague. Here (SF Bay Area), they're telling me that the common area includes the inside of my patio and the inside of the apartment. There's a five foot wall around the patio and it faces north. I wanted to use this suction cup contraption: www.inwall.com to suspend the dish from the outside of a south facing window, but they wouldn't let me do it.
Could this be an example of the government doing something right? And maybe, just maybe protecting the rights of its citizens?
No such luck. This is an example of the administration trying to protect their cronies in the cable industry.
Individually, Dish Networks and DirectTV are no threat to the local cable companies. People who live in apartment complexes are rarely able to install satellite dishes. If your patio doesn't point the right way or you don't have a clear 45 degree line of site over any trees, you're screwed. A few complexes will let you install a dish on the roof if you're on the top floor. But they don't have to so they usually will not permit it. Many windows are opaque to satellite signals, so simply finding a window pointing in the right direction is not necessarily enough. I have to open a bedroom window to use my dish.
And even if you can get a dish installed, you probably won't get all your local networks. Although there will always be one station broadcast for every network from your satellite, you can't get access to any station that's not in your "broadcast area". Dish and DirecTV would probably like to sell you a package that gives you access to a replacement station in a different region, but they're not allowed to. The law prohibits it. Years ago, the cable companies lobbied the government to put that law in place to protect themselves from satellite competitors. How many people will subscribe to satellite TV when they'd be missing one or two of ABC, NBC, CBS, FOX, UPN, and WB?
It's the same thing now. The POWER3 is a PowerPC 630. They're not using the old POWER instruction set anymore.
No, what Hart is saying is that Lucas did not knowingly incorporate mythological elements. He only knowingly incorporated stories from pulp science fiction. Those stores could very well have been derived from mythology, or were based on something else derived from mythology, etc. And as you say, most stories, especially adventures, have elements which stem from mythology.
The point is, Lucas shouldn't be going around pretending he is some kind of literary genius by claiming to have constructed Star Wars from elements of all mythologies. He claims he intended to do this from the start, and that's a load of a crap. Campbell is correct that Star Wars displays mythological elements, but he shouldn't be praising Lucas for any insight. There's a difference between finding your general good vs. evil parallels with mythology and suggesting that a given scene in Star Wars is modelled after a specific mythological story.
Ah, but the point is that the Morpheus user isn't the customer. The Morpheus user is the product that is sold to these advertisers, the real customers. The Morpheus software is bait.
The point is you're not forced to buy a Mac. People (typically) buy Macs because they like them and like MacOS. People often buy Wintel because they feel they have no choice. They want/need the software availability only offered on Windows, but they despise the operating system that makes their system crash. Windows users are forced to upgrade to newer versions of Windows that are generally slower and very expensive. Another group of Microsoft haters are Linux-x86 users. They use Microsoft's hardware and have to fight to get support from hardware venders who don't like working with anyone but Microsoft. And are pissed off that they have to pay for Windows on the desktops/laptops they get from a major vendors. While you have the same gripe with Apple, but there are not very many of you. Most Linux fans use Wintel PCs they've built from parts.
But 2.4 is *supposed* to be stable. That's why it's called a stable kernel branch. It's perfectly justified to complain that it's not stable.
And as far as the VM mess, it wasn't really an issue of communication. It was an issue of Linus arbitrarily accepting some patches from Rik, and ignoring others. Alan Cox at least made a real attempt to incorporate all of Rik's VM patches in the -ac branch. And the -ac branch had a much improved VM as a result. But Linus didn't make the effort for some reason.
The reason 2.4 has been unstable is because the maintainership has been poor. Usually Linus turns over maintainership to someone else (previously Alan) very early on in the series. I think that happened at 2.2.7 for the 2.2 series. Alan puts out of lots of prepatches and gives people enough time to test prerelease kernel patches. Linus is random about it. He'll release a kernel that has changes that weren't in the prepatches. And a bunch of times those changes broke something badly. It probably doesn't help that he has a day job. Alan gets paid to work on Linux full time. The 2.2 series only started getting stable when Alan took over. 2.4 only just recently got handed off.
Compilers make optimizations when code is compiled to machine language. A run time optimization is an optimization that is made dynamically when the code is run. So how can a compiler be more accurate at run time? It's not there at run time!
And since when does anyone worry about larger exe files?
Think about a loop that has a hundred iterations. If you unrolled it all the way, you have one hundred times more code. Compilers obviously don't do that. After you unroll a few times, you stop getting any more benefit. Larger executables mean more memory usage and memory accesses take forever. It makes a guess about how many times they should bother unrolling it. They unroll maybe 5 times at most. But a compiler can't make a perfect guess because the time it takes to execute some code are often dependant on runtime conditions. The number of loop iterations might be based on a value a user inputs in. The compiler has no idea what value the user will input. Also, the time to access a piece of data in memory varies depending if it's in cache, memory, or paged to disk. These things will only be known at runtime.
The Itanium has hardware support for executing x86 instructions. That's about as hybrid x86 as a processor should get, I think. You can only take the x86 architecture so far before it becomes impossible to speed up no matter how much brute force Intel applies. We're getting near that point. Integer performance has been relatively decent compared to RISC processors, but the floating point is hopelessly bad. At least the integer unit is CISC. The floating point unit is even more primitive: stack based. The implementation of SIMD on x86 (MMX and SSE) is so hacked as to be almost useless. For example, MMX shares the same registers as the floating point unit. There are too few registers, and mixing SSE registers with stack based FP registers is a pain. Generating useful SIMD code is an artform on x86. The Altivec set on PowerPC is far more useful. Apple has been able to get noticeable increases in GUI speed by using it. That could never happen on x86. MMX and SSE are relegated to video drivers, games, and number crunchers. For anything else, the overhead and programming difficult outweight the benefits. And with processor speeds trailing memory year by year, you really have to start thinking about architectures that will promote efficient use of registers.
Pulling the plug on x86 may not be so hard. Microsoft is ready to provide an OS and compilers for Itanium. And all the code that people use today are written in higher level programming languages and are no longer very hardware dependant. There are already tons of old programs that will not work properly in Windows XP. People who care about running their ancient programs will not be doing so on new computers.
Hell, Apple managed to pull off the switch between x86 to PowerPC. And they did that on an OS that was written in Pascal and assembly. The PowerPC didn't even have any 680x0 emulation.
No SPARC or UltraSPARC processor supports out of order execution.
The problem isn't trying to support the x86 instruction set or MMX, SSE, or SSE2. It's that VIA wants to use the same bus protocol as the Pentium 4, so that their chip is a drop-in replacement. Since the Pentium 2, everyone has been barred from doing that. Intel's bus protocol for their Pentium 2 through 4 line is patented. Chipset vendors like VIA were able to get licenses to implement support for the Pentium 2 and Pentium 3's bus (GTL), but not for making processors for it. That's why AMD couldn't make processors that work on Intel chipsets and motherboards after the Pentium. Intel is also sueing VIA for making a chipset supporting the Pentium 4.
Java has builtin support for native GUIs. It currently only support Motif on Linux, but Sun plans to provide GNOME support. If they went with Qt, then it's possible that any commercial Java code would require a Qt Pro license.
second, you only need to pay if you want to SELL your code.
So are you saying that Solaris customers shouldn't be selling code?! Look, I'm not talking about open source Solaris development or people who buy Suns for web servers. I'm talking about software companies that sell closed source code on Solaris. Those people still matter to Sun.
Things like Borland Delphi or Kylix or Visual Studio are not free, too.
But they aren't $1500 either. It's one thing to pay for a compiler or IDE, it's another thing to have to pay a large sum for the right to program the GUI in any way. Any UNIX vendor that switches to Qt is basically at the whim of Trolltech. They can sell development environments to their customers, but their customers can't program the system unless they also pay Trolltech.
Many UNIX software vendors have developed a close relationship with Sun over the years. They don't want to maintain a separate relationship with Trolltech for basically the same product. Sun doesn't need to outsource their GUI to a commercial company. They have the resources and money to fund their own GUI development. They are effectively doing that with GNOME.
Sun customers would effectively pay for GNOME, because Sun is using their revenues to fund developers for the project. The same goes for Microsoft and their GUI. For CDE and Windows, every user and developer contributes money to pay the GUI developers. No matter what, the person who writes the GUI is getting paid. It's just a question of who gets paid and when. For Qt, the closed source developer is the only one that pays. And right now they pay a lot because there aren't enough Qt customers to reduce the price.
1. Sega's current arcade machine (Naomi) is dreamcast (powervr) based. This makes it easier for Sega to release games on Naomi, and then port to Dreamcast. Without Dreamcast, there's no point in continuing to use PowerVR for their arcade hardware.
2. Sega tried really hard to sell a game console. The Dreamcast is way better priced than the Playstation 2, and proved to be just as capable for real world uses. Unfortunately, hardly anyone realized that. Sony successfully brainwashed the media (and as a result, the public) into thinking the Emotion Engine is the fastest processor on earth or something. The PSX2 may have gobs of functional units, but no one knows how to use them. Instead of having a separate video processor, Sony stuffs all functions into a single VLIW processor. This looks great for marketing, because the Emotion Engine is made to look cool and buff. But it doesn't make it any better than the standard hardware architectures that the Gamecube, Dreamcast, and XBox use. It just makes it more expensive and difficult to program. Notice that the Gamecube will sell for less than the PS2, will cost much less to produce, and will be faster. Sony had deeper pockets to spend on marketing. Sony lost more money on the PS2 than Sega did. But Sony could afford to lose a lot. It would have been pointless for Sega to continue in the home console market. They don't stand a chance against monstrous companies like Sony and Microsoft. It doesn't make sense to keep on fighting a hopeless battle when their most successful business is writing games.
3. Sega is a superb game developer. People would buy Dreamcasts just to play Sega games, even though Sony was very likely to kill off the platform. Sega rules the arcades, and their arcade ports are always among the best games released on any platform. Most console game developers have at most one or two successful games over a period of months. Sega somehow is able to churn them out: Shenmue, Jet Grind Radio, House of the Dead 2, Skies of Arcadia, Crazy Taxi, Phantasy Star Online, Sega Rally 2, Space Channel 5, etc. I don't think Sega will have too much trouble as a game developer.
It can get more open source. GNOME and GTK+ are LGPL'd, meaning you can compile and sell closed source software that links with them. The GPL forbids this. So if you want to write commercial closed source code with Qt, you need to pay about $1500-$2000 for a Qt Professional license.
Sun isn't the one who has to pay for the developer license. It's each and every Solaris developer who has to pay. Imagine you are Sun, and you give away your OS for almost nothing along with your hardware. Your customer paid $1000 for their Blade 100. So now with Solaris 9, you tell them you've switched from CDE to Qt and so now every Solaris customer needs to caugh up $2000 per developer and send it to Trolltech if they write any GUI C/C++ code or Java code. Now imagine those customers telling you (Sun) to go to hell. Solaris developers who do GUI work may be content with Motif and CDE for programming. It's free for them, it's well documented, and it gets the job done. Sun needs to give them a reason to migrate their code.
But 'C' vs 'C++' did also have a lot to do with it. GNU C++ is incompatible with Sun's C++. You can't link Sun C++ libraries with GNU C++ code. There's no built-in C++ standard library on Solaris. And it's too late now because they wouldn't be able to decide whether to ship with Sun's C++ standard library or GNU's.
Sun developed LWPs in Sun OS 4, which was based on 4.3BSD. Sun contributed lots of stuff back to BSD, like vnodes, NFS, RPC, and their SysV shared library and shared memory incorporation. Sun never patented any of it, so they can't sue. The core of Solaris 2 is from AT&T SVR4 anyway.
MS didn't put in USB 2.0 support because they wanted to push Firewire. This is a good thing from Apple's standpoint. Apple invented Firewire, and Intel invented USB. Intel is trying to kill Firewire with USB 2.0 so they can receive more royalty money. But MS is in favor of Firewire because it is a better technology. Apple is just trying to play it safe by supporting USB 2.0 . They would much rather you use Firewire for high speed connectivity. Hopefully the industry will give Intel a well deserved bitch-slap and stick with Firewire for digital camcorders and such. MS is adding support for USB 2.0 in the next XP service pack.
Regardless of development speed, there's no way that Sun could have gone with Qt. There are no licensing fees associated with developing under CDE. For Sun to ask their customers to dish out $2000 per developer to some other company would be suicide. That's doubling the cost of an Ultra 5 development system. Sun customers would simply revolt. Arguing the attractiveness of Qt would do no good. They don't care. Most of them write networking software and the GUI component is not something they invest much time in. Anyone who ever cared about selling desktop oriented software moved over to the Microsoft world.
And it's not just the cost of the license, it's the fact that Sun customers have to deal with a 3rd party when before they just to deal with Sun. There's the extra cost of managing this relationship, calculating the number of licenses to buy, etc.
Sun has the resources to develop a toolkit just as good as Qt from scratch. But the last time they tried that (OpenLook), everyone revolted against them. But they can always improve GNOME. Gtk may have a messy C interface, but you could always use a C++ binding to abstract away the details. Similar things have been done with Motif. C++ is nice and all, but C++ library compatibility is nonexistent right now. Until every vendor can ship with a C++ shared library that gcc and all the commercial compilers can link with, standardizing on C++ will be impossible.
No. Both fascism and socialism believe that the needs of the society outweigh the individual. But socialism believes in equality, while fascism does not. Now try to find a society that never takes away some individual freedom for the interest of the society as a whole. Just because he's not a libertarian doesn't make him a fascist.
or maybe get one of those Panasonic DVD-RAM video recorders.
What's wrong with this? It's important that people understand what licenses are compatible with the GPL. If you blindly go about merging GPL'd code with GPL-incompatible, you're violating license agreements. By dubbing the whole thing GPL, you're violating the non-GPL license. And by not doing so, you're violating the GPL license. That's just the way the GPL works. License compatibility has to be clearcut, otherwise the license is not enforceable. The list clearly shows that GPL has a lot of compatibility problems. If that's a problem for you, the solution is not to use the GPL'd code.
Console manufacturers sell their systems at a loss. They only make profit from game royalties. So it's to their advantage that games for a console are produced for as long as possible. And since console hardware architectures change so much, it takes a long time for game makers to get the hang of new systems. And since the games don't work on older systems, lots of console owners get pissed off that they don't work on systems they bought just a year ago.
In the PC world, new processors come out all the time. But new software will still work on 3 year old systems (typically). There are plenty of API and driver layers to make hardware transparent. But on consoles, there isn't much of an OS. You work on bare hardware basically. Games then become very dependant on the behavior and timings of the hardware. The advantage is they can squeeze the most capability out the hardware and use very small amounts of memory. The disadvantage, of course, is that forward compatibility is not possible without emulation.
I don't understand why this is never mentioned in the reviews. How did support for MP Athlon just appear? From my understanding, AMD is using the EV6 multiprocessor protocol which is incompatible Intel's patented APIC protocol. So how does Windows 2000 just work?
Sony has also pressured retailers to not stock the Dreamcast at all. Sony reps have gone so low as to sabotage DCs on display. And they've been doing crap like this for years. Long ago the Wherehouse was considering stocking the Saturn. Sony told them they'd pull all Columbia movies and music if they did. Sony has bought and bribed game developers just to stop them from developing for other platforms. Many people have had their PSX's overheat and die within their warranty lifetime. When they called Sony to complain, Sony told them they weren't supposed to use their PSX's on carpet and voided their warranties.
Sony has done all of this so blatantly, but the public doesn't seem to notice or care. And it doesn't look like the slashdot community cares either. Sony develops on Linux and is selling a Linux distribution for the PS2. Sega provided Windows CE. So that automatically makes Sony the good guys.
Same deal with Creative Labs and 3dfx. Creative Labs made Soundblaster and SB Pro a standard and allowed their competition to emulate them. And then once you needed to use Soundblaster emulation for every game, Creative sued the hell out of everyone and made SB16 proprietary. Mediavision went bankrupt but later reformed as Aureal. And then Creative copies their success, releasing their own PCI sound card. Then Creative sued Aureal into bankruptcy and bought their remains. But Creative released a GPL'd Linux driver, so slashdot loves them. 3dfx sued everyone trying to implement a Glide wrapper, but when they release Glide under the GPL they're suddenly the good guys.