Re:I'm a Maths Graduate but ...
on
Does P = NP?
·
· Score: 1
I think the definition is simply this: a nondeterministic computer is one that can simultaneously verify all possible solutions. If a solution is verifiable in polynomial time, then the nondeterministic computer can solve the problem in polynomial time. Hence the problem is in NP. I think that's about as clear as the definition gets.
So how does this conflict with what I said? I didn't say the intl kernel patch couldn't be hosted on a US site. I said it's not integrated into the kernel and there are no plans for it to be. And I said that the IKP developers will not accept patches from people in the US. If it were to be integrated into the kernel, it would immediately be subject to U.S. export restrictions because Linus is in America. And if he wasn't living in the US, it still wouldn't help because there are many other kernel developers in the U.S. All their code would have to be removed and no patches could be accepted from any American. Unless of course Linus decides to go through the export control bullshit.
Alpha 21264 has four times the FP and twice the integer. Twice the speed of Intel FP isn't really an achievement when you're competing against a stack based floating point architecture. What's depressing is that the UltraSparc isn't any faster at integer. Out of order execution would have helped. Every other superscalar architecture supports it.
It's still going to be hard for FreeBSD to compete. OpenBSD has the advantage of being based in Canada, where there are no restrictions on the export of encryption. The encryption projects won't accept any patches from the U.S. at all. OpenBSD has high level encryption in the kernel, while FreeBSD has had trouble even including DES. The current encryption stuff for FreeBSD comes as libraries ported from OpenBSD. The FreeBSD people can't develop the code, they can only distribute it. No kernel crypto, just stuff for applications. The standard Linux kernel doesn't have cryptography either. And the International Kernel Patch authors will not accept patches from Americans. It's still possible for FreeBSD to do stuff because export restrictions have been relaxed. But we're still subject to some restrictions. We can't allow countries on the terrorist list from obtaining the code or developing it. And the government has to approve exported code. It's enough a nuisance that it's still preventing things from happening. It's still enough to keep crypto out of the Linux kernel.
It's the stupidest thing. America invents so much encryption technology, but we have to use foreign implementations!
I first started Xaccel with BSD/OS 2.0. It came with a free single-user edition of Xaccel 1.2 . Was something like 1993-1994. I later bought a copy of 2.1 for Linux and have been upgrading since then, up to version 5. So something like $99 + 2*$50 in payment to Xig over a period of 4 years.
I'm not really sure that it was worth it. But I have been very impressed with the performance and display quality of their X server. I started with a Matrox Mystique, followed by an i740, and then an Nvidia TNT2-Ultra. I've tried to buy cards that would be supported by both XFree86 and Xig, in the hopes that XFree would get to the point where I could ditch Xig. So far, I haven't seen matching quality in XFree86. Maybe I'm just picking the wrong video cards. I've tried XFree86 on ATI Rage 128's as well. With XFree86 3.3.6 on an Xpert 2000, there is a screen distortion whenever I move my mouse. Sometimes scrolled text will appear on the root window. I was surprised, because ATI cards are usually well supported in XFree86.
That said, Xaccel has its own problems as well. In newer releases of Xaccel, I got screen corruption from the Mystique. The i740 also had problems. Xig's response was basically that so few of their customers were using the cards at the time, that they never knew of any such problems. Xaccel on the Xpert 2000 also makes text disappear in a crucial area of our product, so we ended up going back to XFree86. Although XFree86 is slower, it always behaves correctly and it doesn't crash. If a driver worked well at some time, it usually stays working well. Xaccel's support for older hardware gets worse and worse with new releases. Even hardware that's just 2 years old won't work properly.
Xig also refuses to support XFree86 extensions like DGA. These have become required for xquake and tv card applications. They refused to support DGA because they claim their MIT-SHM implementation is so good that it wasn't necessary. And now there's DGA 2.0, required by VMware, and several other extensions. Xig doesn't officially plan support for any of them. This is probably the last release that I'll buy from them. If only I could find a hardware combination that works well with XFree86.
They ported CDE before GNOME or KDE came about, and the maintainence cost is small. The OSF wrote all the code, so they just had to do a little porting and then keep up to date with the OSF's source tree. They probably figure they might as well try to sell it until people stop buying it.
One thing people should consider is that Xig has been selling CDE and Motif in some form for many years. Long before GNOME, KDE, or Qt have been around. The article makes it seem that Xig suddenly decided to produce a CDE product, after everyone decided to go down the route of GNOME or KDE. If that was so, I'd agree that Xig was being stupid. But this is an EXISTING product. They used to be in competition with Redhat's Triteal CDE. It was already there, they've just been keeping up with the OSF's patches. It used to cost $250+. But with the coming of OpenMotif, they didn't have to buy Motif from the OSF. Motif 2.1 itself was something like $200.
It's not like Xig is trying to sabotage anyone else's efforts. Back when they ported Motif and CDE, people thought Motif was the future. Linux was still a small force, used mainly by UNIX workstation fans that wanted to reproduce the same setup at home. But now they're "stuck" with it, so obviously they'd like someone to still buy it. Their products have always had tiny userbases. But they're also a tiny company. They're so small that they beg people to let them borrow boards so they can add support. In return you get a free copy of AccelX. I think they know they'll never have anything but a niche market. They'll be lucky if they can maintain any niche.
The same could have been said about Sony before they launched the PSX. Others had tried to enter into competition with Nintendo and Sega, and they failed quickly. NEC's TurboGraphix and 3DO were unsuccessful, and NEC definately had money. Sony came in with no console or arcade experience whatsoever and managed to conquer the market. Sega had been extremely successful with the Genesis, and even tried to do the backward compatibility thing with the 32X. Sony won because they marketed a single decent platform and threw tons of cash at developers, sometimes bribing them to not develop for Sega or Nintendo. It didn't matter that the Genesis had a large market, because backware compatibility wasn't a desirable option. If you wanted to run old games, you used your old console. You didn't look to getting a faster console to run old games faster.
Microsoft doesn't even need to find new developers. Most PSX games have been ported to the PC. Sony won't be able to rely on their past success to sustain PSX2. They'll definately gain from the loyalty and name-brand respect they garnered from the original PSX, but that's not enough by itself.
Microsoft isn't a nobody either. The PC has become a major game platform. It used to be that PC games were imitations of console games. But now look how things have changed. People are playing Quake and Tomb Raider on consoles. And hardware in game consoles is now influenced by the PC market: the DC is using a PowerVR2, and Sony is including stuff like USB and hard drives. And Microsoft has stronger ties with PC hardware makers. Instead of porting existing technology, they have the advantage of being able to get newer technology on their platform before or at the same time it arrives on the PC. Of course Sony invents their own technology, but their stuff isn't successful unless it becomes a shared standard.
I'm not saying that Microsoft will beat Sony. But I think they definately have a chance at being very competitive. But I hope that M$ loses!
I don't think so. The only other manufacturers (I think) are VIA/Cyrix and Transmeta. Cyrix's old processors shared Super 7 with AMD, and the new one is Socket 370. I think Transmeta does their own thing. I don't think you can go out and buy a Transmeta chip or motherboard. You'd only get it prebuilt into some portable computer or device.
AMD uses the Alpha's EV6 bus protocol. Presumably the EV6 was either open or had cheap licensing. Intel uses their own, and won't willingly allow a competitor to use it. Cyrix managed to gain access as a result of a cross licensing agreement which had this unintended consequence. The VIA bought Cyrix and managed to inherit the rights. AMD most definately would have preferred to license use of Intel's protocol instead. You can't run a P2 or P3 on an Athlon board because Intel's processors only support their own bus protocol. But Intel could make such a processor if they wanted to, but they have no reason to.
1. Total domination of motherboard chipset market. At first (before Slot 1) nobody cared because you could run your AMD and Cyrix chips on Intel chipsets.
2. Slot 1. Now Intel makes their bus protocol proprietary. Meaning AMD and Cyrix can't stick their chips on Pentium 2 motherboards. And because of (1), they must now depend on inferior 3rd party chipsets.
3. RAMBUS. Intel pushing slower, proprietary, and expensive memory to get lucrative shares in the company. And then not providing quality SDRAM mobo chipsets after 440BX to force use of RAMBUS.
4. Demanding an injunction against VIA to stop all imports of their chipsets. There would then be no Athlon motherboard chipset.
5. Possible: www.faceintel.com . But perhaps not enough people know about it to make an impact.
Unless you use more than 4 GB of RAM or monstrous databases, don't expect to gain from 64 bit. The vast majority of users would gain much more with a decent RISC architecture over x86. Replacing the stack-based floating point with modern RISC could double or quadruple the floating point performance. (The Alpha 21264 claims four times the fp performance of the P6's).
And you may not want to get too excited about IA64 either. It's widely believed that Merced will be too slow for production use. And even the next gen design, McKinley, will have a lot of trouble performing until there are compilers that can generate optimal code for it. Right now, they're performing worse than they would on RISC architectures. And even worse than the x86 for normal stuff. Which is really bad considering the whole point of EPIC was to go better than RISC. Intel and HP still have to a lot more work before they can convince people that IA64 was a good idea. Things are definately not going as planned.
It's because Intel has been so long overdue with Merced that they've extended the life of their x86 series. And they've realized that Merced will execute x86 instructions far slower than a native IA32 processor. And IA64 will be expensive for many years. It'll probably be in the price range of the UltraSPARCs and Alphas. Unless Intel can push the mainstream market to switch to Merced, they can't generate the volume production to push the chip prices into the PC market. They'll have a tough time doing that, and Sledgehammer will make it much tougher.
Actually, infinity is quite often recognized in quantum physics. Disturbingly often in fact. Infinities and negative infinities get added together to form finite numbers. They call this "renormalization". Here's an example, quantum electrodynamics states that the bare energy of an electron is negative infinity. But an electron is always surrounded by a cloud of an infinite number of virtual photons. Photons are constantly plucked from nothingness and absorbed by the electron. Since the electron constantly absorbs these infinite number of photons, it's energy is negative infinity + positive infinity. This somehow results in an energy of 10^-19 Joules. These infinities can never be separated, they just magically cancel out.
More relevantly, physics also states that any charged particle exerts a calculable force from any finite distance away. The force only drops to 0 when the distance is infinite. This yields an infinite number of energy levels, but all are quantized. The infinities don't result from infinite packing in space, which the uncertainty principle disallows. It's just that quantum states spread out to an infinite distance. But then of course the universe is finite in size.
But not everyone who buys Sun buys big boxes. There are plenty of people stuck with Sparcstation 4's, 5's, 10's, Ultra 5's, and Ultra 10's with a measly 32 or 64MB of RAM. Solaris is a memory hog, and you can't even use inexpensive PC memory. Sun plain out just sells desktop machines that don't have enough memory to run their OS well. Not even from the day they are sold. And when your system is thrashing, all the advantages of Solaris disappear.
If your only choice was Solaris, you'd have to just throw those old computers out because you're not going to spend money Sparc 5 memory. Hell, even the Ultra 5's and 10's require memory that costs twice as much as PC memory today. But why throw them away when you can get a free OS that makes your computer useful again?
I wonder what we'd be able to gain. Kind of a strange thought that it could be Caldera, a long time Linux vender, that releases the source code to SVR4. But I suppose the core SVR4 code is worthless. Linux 2.4 can do everything it does, but better. And for the stuff Linux and BSD can't do, it's easier to implement from scratch than porting SVR4's stuff. The journalled filesystem is VERITAS's, so that won't be released. What's left?
Redhat's been around for a long time, though. That might have a lot to do with it. Caldera and Turbolinux are fairly new. And Mandrake is an offshoot from Redhat 5.2. I believe Slackware was the first. I don't remember there being any noticeable competitors for several years. Slackware didn't have the concept of a package management system, and there wasn't really any polish to it. For an experienced UNIX user, it was good enough. And Linux users back then pretty much had all prior experience with UNIX.
The fact that Slackware even provided precompiled software was itself a pretty sweet thing. SunOS gave us squat. Redhat came in later with basically 2 contributions. Redhat introduced the first popular package management system, RPM. And they created all these GUI configuration tools. Perhaps it was RPM that made Redhat successful. Now you could install 3rd party software for Linux without having to compile it. That must have been very attractive to Linux newbies or to people like me who are generally too lazy to compile stuff.
That and a lot of marketing probably made Redhat what it is today. And since then Redhat has built up hardware alliances with VA Linux and Dell. And companies tend to feel more comfortable with an operating system from a known established provider. Redhat's an American company and so they've put more work into marketing here. Suse has been around for a long time in Europe, and they directed their marketing efforts there. The same with TurboLinux in the Pacific Rim. So 3 of the top Linux distributers have distinct geographic strongholds.
And as you said, Redhat isn't really a clear winner in any category. They're slow to provide security fixes and slow to update kernels and other software. But when they gained that marketshare, it was pretty much the opposite. But now after having grown so much, they've gotten sluggish.
Well, that's what these MPEG4 contestants are trying to do. They're trying to make an open GPL'd codec based on the MPEG4 reference. I was just trying to explain to the guy why this matters. Designing your own codec from scratch is supposedly really really hard. But I don't think we have to, we can use the MPEG4 reference codec. Assuming that there aren't patents we'd be infringing on, of course. The cable modem guys have said they wanted to come up with an open MPEG4 codec to use for streaming video. Not for normal TV broadcasts, MPEG2 is better for that. There was a previous slashdot article on that. So the other advantages of doing MPEG4 then is that there is already a lot of demand for an open codec and there is a lot of industry acceptance of MPEG4.
You mean play all those proprietary codecs for which you can't even obtain documentation for under NDA? Quicktime 4 stuff ain't gonna happen. Sorenson and Apple won't let anyone have at that. Not even M$ can play those, you have to use Apple's player. And M$ asf ain't gonna happen either. That one's the M$ proprietary MPEG4 standard. And Real Networks won't let anyone get at realvideo. Even for the Intel Indeo codec, you have to sign an NDA. With just the one xanim guy coding at it, it's not going to get very far. So what's there left to play? I guess there's MPEG1 and MPEG2, but those files are HUGE.
And we aren't going to get decent playback performance unless there's some hardware acceleration available in X, which there isn't. But why bother with that now, when we can't touch any decent codec.
When you violate a license agreement, you lose the rights to use the software. That's simply what happens. You can't use that software again until the author forgives you for it and allows you to use it. RMS, unlike KDE and Trolltech, believes that the QPL is incompatible with the GPL. Therefore, any use of GPL'd code within Qt would be a violation of the GPL'd code's license. An author of a piece of GPL code would have to make a specific exemption for Qt. RMS probably didn't keep track of what code was used in KDE, and whether all the authors of the code made that exemption. But he does have the power to forgive KDE for what he perceived as a license violation if KDE used any FSF code.
If you assume that the QPL is incompatible with the GPL, then it's pretty clear that KDE needs to make amends for any GPL licenses had violated. (Assuming they used any GPL'd code without an author's permission). Legally, that's what they would need to do. If they don't, the FSF doesn't have the power to do anything about it. But the author of that piece of software could try to sue KDE. Seems to me that RMS is just trying to provide some legal advice.
As for those other groups got away with violations. In the instances I remember, it was the copyright holders that alerted the violaters. And it's only the copyright holders that can punish a violater. The violaters resolved the issue directly with the copyright holders. KDE isn't prevented from "getting away with it" either. It's up to the copyright holders to deal with the situation. RMS is just saying what he thinks KDE has to do. In this case it seems that the point might be moot. KDE says they didn't use any GPL'd code that didn't have the Qt exemption.
There's a difference between the compiler that you wrote in a semester in college and the the compiler which had been developed for over 4 years before 386BSD started. The former might barely work, while the latter would perform well enough for people to bother using your OS. GCC 1.17 was released in January 1988, while 386BSD 0.1 was released in 1992. Linux had been a year old, and Solaris was released that same year. If 386BSD had been released a year earlier, BSD might be where Linux is today. Without gcc then, they wouldn't even have survived.
Neither FreeBSD or XFree86 would exist without gcc.
Without the GNU C compiler, the 4.4BSD project wouldn't have survived. Even though BSD was open source, it had depended on commercial support for there to have been any implementations. But all the former BSD venders (Sun, DEC, etc) abandoned BSD. Sun had betrayed BSD and went with AT&T SVR4. And AT&T was sueing the hell out of BSD. The University of California pulled their support.
They could never have implemented 4.4BSD on anything unless they had a compiler. And a compilers code specifically for a particular operating system and hardware. That means that there needed to be a compiler that could produce code specific to 4.4BSD and for the architecture.
And that of course didn't exist, because they were inventing a new OS in the first place. Before GCC, every operating system vender had to write a specific C compiler for their platform themselves from scratch. And that's as enormous a project as the operating itself. But GCC was open source, and it had the revolutionary ability of supporting any number of architectures and operating systems. Somebody just needed to make it support the 386 instruction set. And then individual operating system projects just needed to add in support for their system calls and binary format.
GCC was the first and only open source compiler, and it took a considerable time to develop. The 386BSD project wouldn't have been attempted without gcc. gcc was already very stable and widely used when UNIX on the PC was still a dream.
All the BSD command line stuff and background daemons would probably be easily maintainable. Supposedly, Mac OS X uses a FreeBSD 3.x based server on top of Mach. X libraries are portable. You can probably compile all the X11 programs (clients) you want to, if you wanted to install X libraries. They won't be any use without an Xserver, of course. You'll need that to run any X11 clients. Tenon will offer an X server that can run within the Mac OS X Aqua GUI (i.e. within Openstep).
You pay nothing to write proprietary code with LGPL'd stuff. So how is LGPL less fair? Both are "fair", it's just a question of how free they want to make it. GNOME charges no one, while Qt charges non-open-source developers. It's a choice. It remains to be seen if this choice has an impact on their success.
I'm not sure what kind of patches you're talking about. I was talking about build configuration changes. In which case you'd either be modifying an RPM spec file or the one BSD ports makefile. The FreeBSD patches directory is only for patching the actual source in the tarball. Those patches always need to be updated for each new software release. RPM can also automatically apply patches as well, but you need to specify the names of each patch in the spec file. The patch files get bundled together with the main tarball in the source rpm.
One thing I don't like about the FreeBSD ports system is that you can install a package that conflicts with another package, sometimes without even knowing about it. For example, I installed kde 1.2 from ports a while back. Now I recently installed kde 2.0beta4 from ports. I had trouble getting kde2 to compile in the first place, so I didn't want to remove kde 1.2 . But now that both are installed, they both claim ownership to certain files. So now if I were to uninstall kde 1.2, it would delete kde2 files as well.
I see this happening a lot with library packages. You might have a previous version of gtk installed, for example. But then when you compile a new GNOME application, it'll trigger the compile and install of a new version of gtk. But the old one doesn't get uninstalled. It just installs on top of it. And then there's no way to clean out the old one after the fact. I end up deinstalling both, and reinstalling the new one. I think that at the very least, packages should all attempt to uninstall earlier versions before installing.
With FreeBSD ports, you can find out what files are part of an installed package. But you can't go the reverse direction. You can't ask what package a file belongs to. RPM can do this. I suppose that's how RPM prevents packages from clobbering each others files. And somehow RPM can do this without making the install process slow.
Redhat Linux's RPMization of everything does make things rigid. But there are some advantages. It's mostly easy to upgrade to newer versions of the distribution. Since the Redhat installation just consists of bunches of installed rpm's, you just need to upgrade every package. Once I had a Redhat 6.1 upgrade installer break on me. But all I had to do was do an "rpm -Uvh" on each of the rpms to upgrade from RH6.0 to RH6.1 .
But in FreeBSD, an upgrade install (or make world) just dumps stuff on top of whatever you already have. So shared libraries and programs from the earlier install get left around.
Slashdot Mirror
I think the definition is simply this: a nondeterministic computer is one that can simultaneously verify all possible solutions. If a solution is verifiable in polynomial time, then the nondeterministic computer can solve the problem in polynomial time. Hence the problem is in NP. I think that's about as clear as the definition gets.
So how does this conflict with what I said? I didn't say the intl kernel patch couldn't be hosted on a US site. I said it's not integrated into the kernel and there are no plans for it to be. And I said that the IKP developers will not accept patches from people in the US. If it were to be integrated into the kernel, it would immediately be subject to U.S. export restrictions because Linus is in America. And if he wasn't living in the US, it still wouldn't help because there are many other kernel developers in the U.S. All their code would have to be removed and no patches could be accepted from any American. Unless of course Linus decides to go through the export control bullshit.
Alpha 21264 has four times the FP and twice the integer. Twice the speed of Intel FP isn't really an achievement when you're competing against a stack based floating point architecture. What's depressing is that the UltraSparc isn't any faster at integer. Out of order execution would have helped. Every other superscalar architecture supports it.
It's still going to be hard for FreeBSD to compete. OpenBSD has the advantage of being based in Canada, where there are no restrictions on the export of encryption. The encryption projects won't accept any patches from the U.S. at all. OpenBSD has high level encryption in the kernel, while FreeBSD has had trouble even including DES. The current encryption stuff for FreeBSD comes as libraries ported from OpenBSD. The FreeBSD people can't develop the code, they can only distribute it. No kernel crypto, just stuff for applications. The standard Linux kernel doesn't have cryptography either. And the International Kernel Patch authors will not accept patches from Americans. It's still possible for FreeBSD to do stuff because export restrictions have been relaxed. But we're still subject to some restrictions. We can't allow countries on the terrorist list from obtaining the code or developing it. And the government has to approve exported code. It's enough a nuisance that it's still preventing things from happening. It's still enough to keep crypto out of the Linux kernel.
It's the stupidest thing. America invents so much encryption technology, but we have to use foreign implementations!
I first started Xaccel with BSD/OS 2.0. It came with a free single-user edition of Xaccel 1.2 . Was something like 1993-1994. I later bought a copy of 2.1 for Linux and have been upgrading since then, up to version 5. So something like $99 + 2*$50 in payment to Xig over a period of 4 years.
I'm not really sure that it was worth it. But I have been very impressed with the performance and display quality of their X server. I started with a Matrox Mystique, followed by an i740, and then an Nvidia TNT2-Ultra. I've tried to buy cards that would be supported by both XFree86 and Xig, in the hopes that XFree would get to the point where I could ditch Xig. So far, I haven't seen matching quality in XFree86. Maybe I'm just picking the wrong video cards. I've tried XFree86 on ATI Rage 128's as well. With XFree86 3.3.6 on an Xpert 2000, there is a screen distortion whenever I move my mouse. Sometimes scrolled text will appear on the root window. I was surprised, because ATI cards are usually well supported in XFree86.
That said, Xaccel has its own problems as well. In newer releases of Xaccel, I got screen corruption from the Mystique. The i740 also had problems. Xig's response was basically that so few of their customers were using the cards at the time, that they never knew of any such problems. Xaccel on the Xpert 2000 also makes text disappear in a crucial area of our product, so we ended up going back to XFree86. Although XFree86 is slower, it always behaves correctly and it doesn't crash. If a driver worked well at some time, it usually stays working well. Xaccel's support for older hardware gets worse and worse with new releases. Even hardware that's just 2 years old won't work properly.
Xig also refuses to support XFree86 extensions like DGA. These have become required for xquake and tv card applications. They refused to support DGA because they claim their MIT-SHM implementation is so good that it wasn't necessary. And now there's DGA 2.0, required by VMware, and several other extensions. Xig doesn't officially plan support for any of them. This is probably the last release that I'll buy from them. If only I could find a hardware combination that works well with XFree86.
They ported CDE before GNOME or KDE came about, and the maintainence cost is small. The OSF wrote all the code, so they just had to do a little porting and then keep up to date with the OSF's source tree. They probably figure they might as well try to sell it until people stop buying it.
One thing people should consider is that Xig has been selling CDE and Motif in some form for many years. Long before GNOME, KDE, or Qt have been around. The article makes it seem that Xig suddenly decided to produce a CDE product, after everyone decided to go down the route of GNOME or KDE. If that was so, I'd agree that Xig was being stupid. But this is an EXISTING product. They used to be in competition with Redhat's Triteal CDE. It was already there, they've just been keeping up with the OSF's patches. It used to cost $250+. But with the coming of OpenMotif, they didn't have to buy Motif from the OSF. Motif 2.1 itself was something like $200.
It's not like Xig is trying to sabotage anyone else's efforts. Back when they ported Motif and CDE, people thought Motif was the future. Linux was still a small force, used mainly by UNIX workstation fans that wanted to reproduce the same setup at home. But now they're "stuck" with it, so obviously they'd like someone to still buy it. Their products have always had tiny userbases. But they're also a tiny company. They're so small that they beg people to let them borrow boards so they can add support. In return you get a free copy of AccelX. I think they know they'll never have anything but a niche market. They'll be lucky if they can maintain any niche.
The same could have been said about Sony before they launched the PSX. Others had tried to enter into competition with Nintendo and Sega, and they failed quickly. NEC's TurboGraphix and 3DO were unsuccessful, and NEC definately had money. Sony came in with no console or arcade experience whatsoever and managed to conquer the market. Sega had been extremely successful with the Genesis, and even tried to do the backward compatibility thing with the 32X. Sony won because they marketed a single decent platform and threw tons of cash at developers, sometimes bribing them to not develop for Sega or Nintendo. It didn't matter that the Genesis had a large market, because backware compatibility wasn't a desirable option. If you wanted to run old games, you used your old console. You didn't look to getting a faster console to run old games faster.
Microsoft doesn't even need to find new developers. Most PSX games have been ported to the PC. Sony won't be able to rely on their past success to sustain PSX2. They'll definately gain from the loyalty and name-brand respect they garnered from the original PSX, but that's not enough by itself.
Microsoft isn't a nobody either. The PC has become a major game platform. It used to be that PC games were imitations of console games. But now look how things have changed. People are playing Quake and Tomb Raider on consoles. And hardware in game consoles is now influenced by the PC market: the DC is using a PowerVR2, and Sony is including stuff like USB and hard drives. And Microsoft has stronger ties with PC hardware makers. Instead of porting existing technology, they have the advantage of being able to get newer technology on their platform before or at the same time it arrives on the PC. Of course Sony invents their own technology, but their stuff isn't successful unless it becomes a shared standard.
I'm not saying that Microsoft will beat Sony. But I think they definately have a chance at being very competitive. But I hope that M$ loses!
I don't think so. The only other manufacturers (I think) are VIA/Cyrix and Transmeta. Cyrix's old processors shared Super 7 with AMD, and the new one is Socket 370. I think Transmeta does their own thing. I don't think you can go out and buy a Transmeta chip or motherboard. You'd only get it prebuilt into some portable computer or device.
AMD uses the Alpha's EV6 bus protocol. Presumably the EV6 was either open or had cheap licensing. Intel uses their own, and won't willingly allow a competitor to use it. Cyrix managed to gain access as a result of a cross licensing agreement which had this unintended consequence. The VIA bought Cyrix and managed to inherit the rights. AMD most definately would have preferred to license use of Intel's protocol instead. You can't run a P2 or P3 on an Athlon board because Intel's processors only support their own bus protocol. But Intel could make such a processor if they wanted to, but they have no reason to.
In historical order:
1. Total domination of motherboard chipset market. At first (before Slot 1) nobody cared because you could run your AMD and Cyrix chips on Intel chipsets.
2. Slot 1. Now Intel makes their bus protocol proprietary. Meaning AMD and Cyrix can't stick their chips on Pentium 2 motherboards. And because of (1), they must now depend on inferior 3rd party chipsets.
3. RAMBUS. Intel pushing slower, proprietary, and expensive memory to get lucrative shares in the company. And then not providing quality SDRAM mobo chipsets after 440BX to force use of RAMBUS.
4. Demanding an injunction against VIA to stop all imports of their chipsets. There would then be no Athlon motherboard chipset.
5. Possible: www.faceintel.com . But perhaps not enough people know about it to make an impact.
6. Probably other stuff too =P
Unless you use more than 4 GB of RAM or monstrous databases, don't expect to gain from 64 bit. The vast majority of users would gain much more with a decent RISC architecture over x86. Replacing the stack-based floating point with modern RISC could double or quadruple the floating point performance. (The Alpha 21264 claims four times the fp performance of the P6's).
And you may not want to get too excited about IA64 either. It's widely believed that Merced will be too slow for production use. And even the next gen design, McKinley, will have a lot of trouble performing until there are compilers that can generate optimal code for it. Right now, they're performing worse than they would on RISC architectures. And even worse than the x86 for normal stuff. Which is really bad considering the whole point of EPIC was to go better than RISC. Intel and HP still have to a lot more work before they can convince people that IA64 was a good idea. Things are definately not going as planned.
It's because Intel has been so long overdue with Merced that they've extended the life of their x86 series. And they've realized that Merced will execute x86 instructions far slower than a native IA32 processor. And IA64 will be expensive for many years. It'll probably be in the price range of the UltraSPARCs and Alphas. Unless Intel can push the mainstream market to switch to Merced, they can't generate the volume production to push the chip prices into the PC market. They'll have a tough time doing that, and Sledgehammer will make it much tougher.
Actually, infinity is quite often recognized in quantum physics. Disturbingly often in fact. Infinities and negative infinities get added together to form finite numbers. They call this "renormalization". Here's an example, quantum electrodynamics states that the bare energy of an electron is negative infinity. But an electron is always surrounded by a cloud of an infinite number of virtual photons. Photons are constantly plucked from nothingness and absorbed by the electron. Since the electron constantly absorbs these infinite number of photons, it's energy is negative infinity + positive infinity. This somehow results in an energy of 10^-19 Joules. These infinities can never be separated, they just magically cancel out.
More relevantly, physics also states that any charged particle exerts a calculable force from any finite distance away. The force only drops to 0 when the distance is infinite. This yields an infinite number of energy levels, but all are quantized. The infinities don't result from infinite packing in space, which the uncertainty principle disallows. It's just that quantum states spread out to an infinite distance. But then of course the universe is finite in size.
But not everyone who buys Sun buys big boxes. There are plenty of people stuck with Sparcstation 4's, 5's, 10's, Ultra 5's, and Ultra 10's with a measly 32 or 64MB of RAM. Solaris is a memory hog, and you can't even use inexpensive PC memory. Sun plain out just sells desktop machines that don't have enough memory to run their OS well. Not even from the day they are sold. And when your system is thrashing, all the advantages of Solaris disappear.
If your only choice was Solaris, you'd have to just throw those old computers out because you're not going to spend money Sparc 5 memory. Hell, even the Ultra 5's and 10's require memory that costs twice as much as PC memory today. But why throw them away when you can get a free OS that makes your computer useful again?
I wonder what we'd be able to gain. Kind of a strange thought that it could be Caldera, a long time Linux vender, that releases the source code to SVR4. But I suppose the core SVR4 code is worthless. Linux 2.4 can do everything it does, but better. And for the stuff Linux and BSD can't do, it's easier to implement from scratch than porting SVR4's stuff. The journalled filesystem is VERITAS's, so that won't be released. What's left?
Redhat's been around for a long time, though. That might have a lot to do with it. Caldera and Turbolinux are fairly new. And Mandrake is an offshoot from Redhat 5.2. I believe Slackware was the first. I don't remember there being any noticeable competitors for several years. Slackware didn't have the concept of a package management system, and there wasn't really any polish to it. For an experienced UNIX user, it was good enough. And Linux users back then pretty much had all prior experience with UNIX.
The fact that Slackware even provided precompiled software was itself a pretty sweet thing. SunOS gave us squat. Redhat came in later with basically 2 contributions. Redhat introduced the first popular package management system, RPM. And they created all these GUI configuration tools. Perhaps it was RPM that made Redhat successful. Now you could install 3rd party software for Linux without having to compile it. That must have been very attractive to Linux newbies or to people like me who are generally too lazy to compile stuff.
That and a lot of marketing probably made Redhat what it is today. And since then Redhat has built up hardware alliances with VA Linux and Dell. And companies tend to feel more comfortable with an operating system from a known established provider. Redhat's an American company and so they've put more work into marketing here. Suse has been around for a long time in Europe, and they directed their marketing efforts there. The same with TurboLinux in the Pacific Rim. So 3 of the top Linux distributers have distinct geographic strongholds.
And as you said, Redhat isn't really a clear winner in any category. They're slow to provide security fixes and slow to update kernels and other software. But when they gained that marketshare, it was pretty much the opposite. But now after having grown so much, they've gotten sluggish.
Well, that's what these MPEG4 contestants are trying to do. They're trying to make an open GPL'd codec based on the MPEG4 reference. I was just trying to explain to the guy why this matters. Designing your own codec from scratch is supposedly really really hard. But I don't think we have to, we can use the MPEG4 reference codec. Assuming that there aren't patents we'd be infringing on, of course. The cable modem guys have said they wanted to come up with an open MPEG4 codec to use for streaming video. Not for normal TV broadcasts, MPEG2 is better for that. There was a previous slashdot article on that. So the other advantages of doing MPEG4 then is that there is already a lot of demand for an open codec and there is a lot of industry acceptance of MPEG4.
You mean play all those proprietary codecs for which you can't even obtain documentation for under NDA? Quicktime 4 stuff ain't gonna happen. Sorenson and Apple won't let anyone have at that. Not even M$ can play those, you have to use Apple's player. And M$ asf ain't gonna happen either. That one's the M$ proprietary MPEG4 standard. And Real Networks won't let anyone get at realvideo. Even for the Intel Indeo codec, you have to sign an NDA. With just the one xanim guy coding at it, it's not going to get very far. So what's there left to play? I guess there's MPEG1 and MPEG2, but those files are HUGE.
And we aren't going to get decent playback performance unless there's some hardware acceleration available in X, which there isn't. But why bother with that now, when we can't touch any decent codec.
When you violate a license agreement, you lose the rights to use the software. That's simply what happens. You can't use that software again until the author forgives you for it and allows you to use it. RMS, unlike KDE and Trolltech, believes that the QPL is incompatible with the GPL. Therefore, any use of GPL'd code within Qt would be a violation of the GPL'd code's license. An author of a piece of GPL code would have to make a specific exemption for Qt. RMS probably didn't keep track of what code was used in KDE, and whether all the authors of the code made that exemption. But he does have the power to forgive KDE for what he perceived as a license violation if KDE used any FSF code.
If you assume that the QPL is incompatible with the GPL, then it's pretty clear that KDE needs to make amends for any GPL licenses had violated. (Assuming they used any GPL'd code without an author's permission). Legally, that's what they would need to do. If they don't, the FSF doesn't have the power to do anything about it. But the author of that piece of software could try to sue KDE. Seems to me that RMS is just trying to provide some legal advice.
As for those other groups got away with violations. In the instances I remember, it was the copyright holders that alerted the violaters. And it's only the copyright holders that can punish a violater. The violaters resolved the issue directly with the copyright holders. KDE isn't prevented from "getting away with it" either. It's up to the copyright holders to deal with the situation. RMS is just saying what he thinks KDE has to do. In this case it seems that the point might be moot. KDE says they didn't use any GPL'd code that didn't have the Qt exemption.
There's a difference between the compiler that you wrote in a semester in college and the the compiler which had been developed for over 4 years before 386BSD started. The former might barely work, while the latter would perform well enough for people to bother using your OS. GCC 1.17 was released in January 1988, while 386BSD 0.1 was released in 1992. Linux had been a year old, and Solaris was released that same year. If 386BSD had been released a year earlier, BSD might be where Linux is today. Without gcc then, they wouldn't even have survived.
Neither FreeBSD or XFree86 would exist without gcc.
Without the GNU C compiler, the 4.4BSD project wouldn't have survived. Even though BSD was open source, it had depended on commercial support for there to have been any implementations. But all the former BSD venders (Sun, DEC, etc) abandoned BSD. Sun had betrayed BSD and went with AT&T SVR4. And AT&T was sueing the hell out of BSD. The University of California pulled their support.
They could never have implemented 4.4BSD on anything unless they had a compiler. And a compilers code specifically for a particular operating system and hardware. That means that there needed to be a compiler that could produce code specific to 4.4BSD and for the architecture.
And that of course didn't exist, because they were inventing a new OS in the first place. Before GCC, every operating system vender had to write a specific C compiler for their platform themselves from scratch. And that's as enormous a project as the operating itself. But GCC was open source, and it had the revolutionary ability of supporting any number of architectures and operating systems. Somebody just needed to make it support the 386 instruction set. And then individual operating system projects just needed to add in support for their system calls and binary format.
GCC was the first and only open source compiler, and it took a considerable time to develop. The 386BSD project wouldn't have been attempted without gcc. gcc was already very stable and widely used when UNIX on the PC was still a dream.
All the BSD command line stuff and background daemons would probably be easily maintainable. Supposedly, Mac OS X uses a FreeBSD 3.x based server on top of Mach. X libraries are portable. You can probably compile all the X11 programs (clients) you want to, if you wanted to install X libraries. They won't be any use without an Xserver, of course. You'll need that to run any X11 clients. Tenon will offer an X server that can run within the Mac OS X Aqua GUI (i.e. within Openstep).
You pay nothing to write proprietary code with LGPL'd stuff. So how is LGPL less fair? Both are "fair", it's just a question of how free they want to make it. GNOME charges no one, while Qt charges non-open-source developers. It's a choice. It remains to be seen if this choice has an impact on their success.
I'm not sure what kind of patches you're talking about. I was talking about build configuration changes. In which case you'd either be modifying an RPM spec file or the one BSD ports makefile. The FreeBSD patches directory is only for patching the actual source in the tarball. Those patches always need to be updated for each new software release. RPM can also automatically apply patches as well, but you need to specify the names of each patch in the spec file. The patch files get bundled together with the main tarball in the source rpm.
One thing I don't like about the FreeBSD ports system is that you can install a package that conflicts with another package, sometimes without even knowing about it. For example, I installed kde 1.2 from ports a while back. Now I recently installed kde 2.0beta4 from ports. I had trouble getting kde2 to compile in the first place, so I didn't want to remove kde 1.2 . But now that both are installed, they both claim ownership to certain files. So now if I were to uninstall kde 1.2, it would delete kde2 files as well.
I see this happening a lot with library packages. You might have a previous version of gtk installed, for example. But then when you compile a new GNOME application, it'll trigger the compile and install of a new version of gtk. But the old one doesn't get uninstalled. It just installs on top of it. And then there's no way to clean out the old one after the fact. I end up deinstalling both, and reinstalling the new one. I think that at the very least, packages should all attempt to uninstall earlier versions before installing.
With FreeBSD ports, you can find out what files are part of an installed package. But you can't go the reverse direction. You can't ask what package a file belongs to. RPM can do this. I suppose that's how RPM prevents packages from clobbering each others files. And somehow RPM can do this without making the install process slow.
Redhat Linux's RPMization of everything does make things rigid. But there are some advantages. It's mostly easy to upgrade to newer versions of the distribution. Since the Redhat installation just consists of bunches of installed rpm's, you just need to upgrade every package. Once I had a Redhat 6.1 upgrade installer break on me. But all I had to do was do an "rpm -Uvh" on each of the rpms to upgrade from RH6.0 to RH6.1 .
But in FreeBSD, an upgrade install (or make world) just dumps stuff on top of whatever you already have. So shared libraries and programs from the earlier install get left around.