...That the people who can't sleep at night worrying about wether free software will ruin customer choice didn't even blink at Microsoft's "Unix is Dead" campaign. And that these self same people consider the "fragmentation" of Unix to be it's critical failure, and instead perfer the enforced sameness of Windows.
Unlike Microsoft, I cannot think of a _single_ software company that has been destroyed by free software. The role call of software and software companies killed by Microsoft is long indeed.
The punchline here is, of course, that all evidence indicates that free software _increases_ choice. Consider: Gnome vr.s KDE, Caldera vr.s Redhat vr.s SuSE vr.s etc., Linux vr.s *BSD, Sendmail vr.s qmail vr.s smail, perl vr.s python, vi vr.s emacs.
Oh, and cheap computers are hardly new- anyone remember the C-64? TI-99?
... it's downright deadly. Using LoC as a measure of programming productivity:
- Encourages cut&paste programming ("Look- I just wrote 2000 lines of working code without touching the keyboard!"). The danger of cut&paste programming was ablely demonstrated with the Y2K problem- simply fixing the problem in one place doesn't fix the problem, you have to find all the places that code was copied to and fix it there as well. What should have been a 30-minute fix turned into a multi-year code spelunking expedition.
- discourages black-box reuse- both of older code and of existing libraries.
- discriminates against maintainance programming- did Linus write 5K lines of code this year? Not much more, in either case. Is he lazy? Of course not.
- discriminates against testing and debugging. I'm a middlin-decent typist (for a programmer), and I can type in one to two thousand lines of code in a single day. Testing and debugging said code can take days or even weeks- during which my code output is exceeding low to non-existant. Last year there was an entire month of busting my butt where my sum total code output was 2 lines (finding the two lines of code in the device driver to fix was a bitch).
- Discriminates against time spent on design. Especially design which increases code reuse, and decreases code complexity and size.
- Discriminates against writting documentation (that's not code).
In fact, LoC Discrimates against all parts of programming _except_ the typing parts.
Programming is not an assembly line production, no matter how much some managers wish it were. There are no easy measurements of programmer productivity. And I do not beleive the American programmer is "lazy".
The uniformity is across operating systems, not across peices of hardware. So a single driver _source_ (note: UDI is source-level compatible, not binary!) can support Linux, *BSD, SCO, Solaris, Digital Unix, and others (I forget who all is signed up).
I think the UDI will actually make open-source drivers _more_ common. It's a source-level spec, so you'd have to recompile the driver for different operating systems. Most of the companies writting device drivers are hardware companies- device drivers are loss leaders to sell hardware. The biggest problem with support "alternative" (i.e. non-Windows) operating systems is the engineering effort required. With UDI, they can write (and release open-source, or at least source-available) one driver and get sales to numerous different operating systems.
As is normal, this "Microsoft" innovation is old-hat everywhere outside of Redmond. The DWIM instruction set was rumored to have been in several 1960's era mainframes, and the technology was even built into Soviet Fighters which the US, um, "appropriated" back in the mid-80's.
This technology is, in fact, so easy a child of nine could do. It's good to see that Microsoft has finally hired a child of nine. What they hey- he's got to be more computer savvy than that herd of PhD's they've hired.
It's not just _a_ compiler that has to be worked over, it's all of them.
In addition, it's widely accepted that there will be faster RISC CPUs available then Merced when Merced ships, and even faster x86 chips (at running x86 binaries). Before using this to claim that Merced is dead, remember that this was true of the initial RISC chips when they came out. What this means is that it'll simply take a while for EPIC to mature and for the advantages to come to the fore.
The problem is that Intel doesn't have much of a choice. Well, I suppose they could have gone for a standard RISC chip. But something post-x86 is necessary. If nothing else, the 32-bit limitations of the architecture are hurting Intel's sales in the lucrative server market (where 10's of gigabytes of RAM are common, and 100's not unknown). The desktop user probably won't care for another 4-5 years, but the server market started caring 3 years ago.
One interesting note in all of this is how this is affecting the Intel/Microsoft relationship. By it's actions, Intel has no confindence in Microsoft being able to ship an Enterprise-ready 64-bit clean OS any time soon. Not that I blame them.
Intel is learning one nice feature about open-source operating systems- they don't have to depend upon someone else to support their chips. For a small engineering investment, they can do it themselves- and if you want something done right, doing it yourself is a real good idea. Making a small investment in a small company (like, say, Redhat) makes a lot of sense in this context.
That being said, I think EPIC is an interesting design with a lot of long-term potiential. Standard RISC processors have a hard time averaging more than about 2 parallel instructions. Research done by HP indicates a lot more than that is possible- it's just computationally infeasible for the _processor_ to find it.
In addition to the suits invading our world, we are invading theirs. Or what do you think "Linux in the enterprise" means? The culture clash works both ways, and it's debatable who is invading whom. Even Linus Torvalds needs to work a 9-5 job for a suit to put food on the table- is it that the suits are adopting Linux, or is it that the hackers are bringing Linux with them to their day jobs?
For decades, embedded programming has been the submerged part of the computer sales iceberg. From cars to stereos to kitchen appliances to cash registers to furbies, embedded computers abound and are mostly unremarked on.
Every once in a while, a pundit whose spent his whole career talking about the desktop and only being dimly aware of the server market, stumbles upon this fact, and immediately jumps to the conclusion that because this market is so much larger than the PC market (and it is), that PCs must inevitably be doomed. Bleh.
One additional comment- segmenting is a classic tactic of monopolies. It allows you to agressively price in segments where you are facing competition, and make up the profits by overcharging in segments where you're not facing competition. IBM did it- occasionally charging 40% under cost to undercut the competition. Microsoft is trying to do it (98 vr.s NTWS vr.s NTServer vr.s NTEnteprrise), and now Intel is doing it. No big surprise.
Linux is not any harder to install than Windows 98
on
Free the Open Source
·
· Score: 1
I'd even argue easier. I'm currently (re)installing 98 as I type this. I spent this morning simply putting together a DOS boot floppy that could see both the IDE CD-ROM and the FAT-32 partition. I ended up needing to steal the CD-ROM drivers from an old DOS 5.5 disk I just happened to have lying around to make it work.
Fortunately for me, I happen to be well acquainted with such command line gobbledy gook as "fdisk", "format c:", "edit config.sys", etc.
Major nit: none of the Windows-98 CD's I have are bootable. 'Cmon guys! This ain't rocket science!
For comparison, the last time I installed Redhat, I went from unformatted HD to complete Linux/X in about 4 hours. Including the surface scan for bad blocks.
Follow the link to the "Effective C++" web page (I followed the one about exceptions). Notice how few of the problems he's attempting to work around occur in Java...
With the imbending obsolence of DOS-based Windows, it comes as little surpise that sales of NT-installed PCs are on the upswing. With the introduction of W2K, I expect that this upswing will continue, as NT and 2K supplant 95 and 98, and get reclassified from PC's to Workstation's, and promptly inflate NT's presence in the workstation world.
The Unix market is consolodating- and several of the smaller vendors are loosing out to NT (for instance, SCO). The interesting question is "what are the leaders- Sun, HP, and IBM- doing?"
Point by point: 1)Please be more specific. You might try enumerating what (you think) the problems will be if and when Linux hits the problem, and what you think we should be doing to prepare. Vague warnings (except for "if they can buy it, they will", to which I refer you to the GPL) don't help.
2) The reason we haven't moved beyond WIMP is that no one has thought of anything better. Linux already has a best-of-breed CLI, mate that with a good GUI and you're set in the interface department. I do make the prediction: when the next UI appears, it'll appear on Linux first.
3) Choice is good. Not only can there be more than one Linux distribution, there should be- for the same reason there should be more than auto maker, or more than one soft drink. The myth that there can be only one OS controlled by only one company or person is perpetuated by the Microsoft apologists as an excuse for the monopoly.
Caldera et. al. are the ultimate defense against Redhat being bought out- or even comming down with a case of the dumbs (like Apple seems to have fits of). Choice allows you to choose _differently_.
4)You're confusing the development releases with the distribution releases. Simply because Linus released a new kernel doesn't force Redhat to do a new distribution. This is a common mistake made by people just discovering Open Source. The 1351 builds that occurred before NT 4.0 was released where never seen by the public- but they still existed. The only differences are that Linux makes the interim kernels publically available, and generally has fewer of them.
This is part of the value the distributors add- they "gear down" the release cycle to something the channel companies can handle. Just translate "Redhat 5.2" in your mind to "Redhat 5 SP 2", if it makes you feel better (how fast did NT 4.0 SP 1/2 go by? 98 now has how many service packs?).
5) Copyright and patent are laws that can cut _either_ way, as AT&T found out when it sued UCBerkley. Avoid patents and lawsuits (where possible), yes- but this is a means of our defense as well as, via the GPL. Microsoft cannot buy Linux even with all of it's billions- copyright law prevents it.
You mention LZW (which is patented). When the patent came out, FSF learned to it's horror that the unix utility compress was covered. So what happened? After some research, an unpatented and _better_ compression algorithm was found, and thus gzip was born. Similiarly, gif's are giving way to png's. Patents are a threat, I agree, but a managable one.
And the situation is not as bad as it was a decade ago. If a patent lawsuit cropped up, you'd better beleive that Caldera, Redhat, et. al. would help fund the defense. And rumors to the contrary, justice in America is _not_ for sale to the highest bidder (as Microsoft's current legal woes richly testify- as do the previous successfull litigations against Standard Oil and AT&T). This is one place where having money grubbing capitialists as allies helps.
6) So long as you can continue to use Linux to produce "cool and froody", why do you care if someone else uses it to make money? Heck, you may want to use it to make money someday.
7) Now that slavery is abolished, how do you "own a community"?
And finally: 8) Linux isn't Saruman, it's Tom Bombadil.
Anymore than Fibrechannel replaced SCSI. SCSI is a protocol as much as an electrical specification. What you will see is Firewire being the communications protocol SCSI is run over (except for the high end, where FibreChannel and Storage Area Networks will still rule).
Firewire is not going to replace USB. USB is cheaper than Firewire by quite a bit. For low-bandwidth devices (like keyboards and mice) it's not worth it- save the $20.
Firewire may replace PCI. I don't think so, but it may. The next revision of Firewire will be spec'd to 1.6Gbit/sec ~= 160MByte/sec for 33MHz 32bit PCI. PCI, however, has already been Spec'ed up to 64 bit and 66Mhz, giving 400MB/sec performance. What I'm betting will happen is that 64bit 66MHz PCI will become the standard for "high speed, no hotswap" peripherals like video, and for tying together multiple Firewire buses. Firewire (running SCSI among other things) will become the standard for "medium speed, hotswappable" peripherals like hard disks. USB will become the standard for "low speed, ultra low cost" peripherals like keyboards and mice.
He's the archtypeal PHB in his reactions to Linux, and as such serves as a good yardstick to the "corporate mindset" (who, incidently, get their opinions retail from Jesse among others- Management By Reading Magazines).
Let's see. He's hit: 1) Ignorance ("What's Linux?") 2) Denial ("It's not worth writing about") 3) Dismissive ("Could you get fired for using Linux?") 4) Grudging Acceptance with Reservations ("I always said Linux could be a contender. Not on the desktop, though")
Slashdot Mirror
...That the people who can't sleep at night worrying about wether free software will ruin customer choice didn't even blink at Microsoft's "Unix is Dead" campaign. And that these self same people consider the "fragmentation" of Unix to be it's critical failure, and instead perfer the enforced sameness of Windows.
Unlike Microsoft, I cannot think of a _single_ software company that has been destroyed by free software. The role call of software and software companies killed by Microsoft is long indeed.
The punchline here is, of course, that all evidence indicates that free software _increases_ choice. Consider: Gnome vr.s KDE, Caldera vr.s Redhat vr.s SuSE vr.s etc., Linux vr.s *BSD, Sendmail vr.s qmail vr.s smail, perl vr.s python, vi vr.s emacs.
Oh, and cheap computers are hardly new- anyone remember the C-64? TI-99?
... it's downright deadly. Using LoC as a measure of programming productivity:
- Encourages cut&paste programming ("Look- I just wrote 2000 lines of working code without touching the keyboard!"). The danger of cut&paste programming was ablely demonstrated with the Y2K problem- simply fixing the problem in one place doesn't fix the problem, you have to find all the places that code was copied to and fix it there as well. What should have been a 30-minute fix turned into a multi-year code spelunking expedition.
- discourages black-box reuse- both of older code and of existing libraries.
- discriminates against maintainance programming-
did Linus write 5K lines of code this year? Not much more, in either case. Is he lazy? Of course not.
- discriminates against testing and debugging. I'm a middlin-decent typist (for a programmer), and I can type in one to two thousand lines of code in a single day. Testing and debugging said code can take days or even weeks- during which my code output is exceeding low to non-existant. Last year there was an entire month of busting my butt where my sum total code output was 2 lines (finding the two lines of code in the device driver to fix was a bitch).
- Discriminates against time spent on design. Especially design which increases code reuse, and decreases code complexity and size.
- Discriminates against writting documentation (that's not code).
In fact, LoC Discrimates against all parts of programming _except_ the typing parts.
Programming is not an assembly line production, no matter how much some managers wish it were. There are no easy measurements of programmer productivity. And I do not beleive the American programmer is "lazy".
The uniformity is across operating systems, not across peices of hardware. So a single driver _source_ (note: UDI is source-level compatible, not binary!) can support Linux, *BSD, SCO, Solaris, Digital Unix, and others (I forget who all is signed up).
I think the UDI will actually make open-source drivers _more_ common. It's a source-level spec, so you'd have to recompile the driver for different operating systems. Most of the companies writting device drivers are hardware companies- device drivers are loss leaders to sell hardware. The biggest problem with support "alternative" (i.e. non-Windows) operating systems is the engineering effort required. With UDI, they can write (and release open-source, or at least source-available) one driver and get sales to numerous different operating systems.
As is normal, this "Microsoft" innovation is old-hat everywhere outside of Redmond. The DWIM instruction set was rumored to have been in several 1960's era mainframes, and the technology was even built into Soviet Fighters which the US, um, "appropriated" back in the mid-80's.
This technology is, in fact, so easy a child of nine could do. It's good to see that Microsoft has finally hired a child of nine. What they hey- he's got to be more computer savvy than that herd of PhD's they've hired.
It's not just _a_ compiler that has to be worked over, it's all of them.
In addition, it's widely accepted that there will be faster RISC CPUs available then Merced when Merced ships, and even faster x86 chips (at running x86 binaries). Before using this to claim that Merced is dead, remember that this was true of the initial RISC chips when they came out. What this means is that it'll simply take a while for EPIC to mature and for the advantages to come to the fore.
The problem is that Intel doesn't have much of a choice. Well, I suppose they could have gone for a standard RISC chip. But something post-x86 is necessary. If nothing else, the 32-bit limitations of the architecture are hurting Intel's sales in the lucrative server market (where 10's of gigabytes of RAM are common, and 100's not unknown). The desktop user probably won't care for another 4-5 years, but the server market started caring 3 years ago.
One interesting note in all of this is how this is affecting the Intel/Microsoft relationship. By it's actions, Intel has no confindence in Microsoft being able to ship an Enterprise-ready 64-bit clean OS any time soon. Not that I blame them.
Intel is learning one nice feature about open-source operating systems- they don't have to depend upon someone else to support their chips. For a small engineering investment, they can do it themselves- and if you want something done right, doing it yourself is a real good idea. Making a small investment in a small company (like, say, Redhat) makes a lot of sense in this context.
That being said, I think EPIC is an interesting design with a lot of long-term potiential. Standard RISC processors have a hard time averaging more than about 2 parallel instructions. Research done by HP indicates a lot more than that is possible- it's just computationally infeasible for the _processor_ to find it.
If it's anything like "The Road Ahead" it'll be on the remainders rack about tuesday.
In addition to the suits invading our world, we are invading theirs. Or what do you think "Linux in the enterprise" means? The culture clash works both ways, and it's debatable who is invading whom. Even Linus Torvalds needs to work a 9-5 job for a suit to put food on the table- is it that the suits are adopting Linux, or is it that the hackers are bringing Linux with them to their day jobs?
Film at 11.
For decades, embedded programming has been the submerged part of the computer sales iceberg. From cars to stereos to kitchen appliances to cash registers to furbies, embedded computers abound and are mostly unremarked on.
Every once in a while, a pundit whose spent his whole career talking about the desktop and only being dimly aware of the server market, stumbles upon this fact, and immediately jumps to the conclusion that because this market is so much larger than the PC market (and it is), that PCs must inevitably be doomed. Bleh.
One additional comment- segmenting is a classic tactic of monopolies. It allows you to agressively price in segments where you are facing competition, and make up the profits by overcharging in segments where you're not facing competition. IBM did it- occasionally charging 40% under cost to undercut the competition. Microsoft is trying to do it (98 vr.s NTWS vr.s NTServer vr.s NTEnteprrise), and now Intel is doing it. No big surprise.
I'd even argue easier. I'm currently (re)installing 98 as I type this. I spent this morning simply putting together a DOS boot floppy that could see both the IDE CD-ROM and the FAT-32 partition. I ended up needing to steal the CD-ROM drivers from an old DOS 5.5 disk I just happened to have lying around to make it work.
Fortunately for me, I happen to be well acquainted with such command line gobbledy gook as "fdisk", "format c:", "edit config.sys", etc.
Major nit: none of the Windows-98 CD's I have are bootable. 'Cmon guys! This ain't rocket science!
For comparison, the last time I installed Redhat, I went from unformatted HD to complete Linux/X in about 4 hours. Including the surface scan for bad blocks.
Follow the link to the "Effective C++" web page (I followed the one about exceptions). Notice how few of the problems he's attempting to work around occur in Java...
With the imbending obsolence of DOS-based Windows, it comes as little surpise that sales of NT-installed PCs are on the upswing. With the introduction of W2K, I expect that this upswing will continue, as NT and 2K supplant 95 and 98, and get reclassified from PC's to Workstation's, and promptly inflate NT's presence in the workstation world.
The Unix market is consolodating- and several of the smaller vendors are loosing out to NT (for instance, SCO). The interesting question is "what are the leaders- Sun, HP, and IBM- doing?"
Point by point:
1)Please be more specific. You might try enumerating what (you think) the problems will be if and when Linux hits the problem, and what you think we should be doing to prepare. Vague warnings (except for "if they can buy it, they will", to which I refer you to the GPL) don't help.
2) The reason we haven't moved beyond WIMP is that no one has thought of anything better. Linux already has a best-of-breed CLI, mate that with a good GUI and you're set in the interface department. I do make the prediction: when the next UI appears, it'll appear on Linux first.
3) Choice is good. Not only can there be more than one Linux distribution, there should be- for the same reason there should be more than auto maker, or more than one soft drink. The myth that there can be only one OS controlled by only one company or person is perpetuated by the Microsoft apologists as an excuse for the monopoly.
Caldera et. al. are the ultimate defense against Redhat being bought out- or even comming down with a case of the dumbs (like Apple seems to have fits of). Choice allows you to choose _differently_.
4)You're confusing the development releases with the distribution releases. Simply because Linus released a new kernel doesn't force Redhat to do a new distribution. This is a common mistake made by people just discovering Open Source. The 1351 builds that occurred before NT 4.0 was released where never seen by the public- but they still existed. The only differences are that Linux makes the interim kernels publically available, and generally has fewer of them.
This is part of the value the distributors add- they "gear down" the release cycle to something the channel companies can handle. Just translate "Redhat 5.2" in your mind to "Redhat 5 SP 2", if it makes you feel better (how fast did NT 4.0 SP 1/2 go by? 98 now has how many service packs?).
5) Copyright and patent are laws that can cut _either_ way, as AT&T found out when it sued UCBerkley. Avoid patents and lawsuits (where possible), yes- but this is a means of our defense as well as, via the GPL. Microsoft cannot buy Linux even with all of it's billions- copyright law prevents it.
You mention LZW (which is patented). When the patent came out, FSF learned to it's horror that the unix utility compress was covered. So what happened? After some research, an unpatented and _better_ compression algorithm was found, and thus gzip was born. Similiarly, gif's are giving way to png's. Patents are a threat, I agree, but a managable one.
And the situation is not as bad as it was a decade ago. If a patent lawsuit cropped up, you'd better beleive that Caldera, Redhat, et. al. would help fund the defense. And rumors to the contrary, justice in America is _not_ for sale to the highest bidder (as Microsoft's current legal woes richly testify- as do the previous successfull litigations against Standard Oil and AT&T). This is one place where having money grubbing capitialists as allies helps.
6) So long as you can continue to use Linux to produce "cool and froody", why do you care if someone else uses it to make money? Heck, you may want to use it to make money someday.
7) Now that slavery is abolished, how do you "own a community"?
And finally:
8) Linux isn't Saruman, it's Tom Bombadil.
Anymore than Fibrechannel replaced SCSI. SCSI is a protocol as much as an electrical specification. What you will see is Firewire being the communications protocol SCSI is run over (except for the high end, where FibreChannel and Storage Area Networks will still rule).
Firewire is not going to replace USB. USB is cheaper than Firewire by quite a bit. For low-bandwidth devices (like keyboards and mice) it's not worth it- save the $20.
Firewire may replace PCI. I don't think so, but it may. The next revision of Firewire will be spec'd to 1.6Gbit/sec ~= 160MByte/sec for 33MHz 32bit PCI. PCI, however, has already been Spec'ed up to 64 bit and 66Mhz, giving 400MB/sec performance. What I'm betting will happen is that 64bit 66MHz PCI will become the standard for "high speed, no hotswap" peripherals like video, and for tying together multiple Firewire buses. Firewire (running SCSI among other things) will become the standard for "medium speed, hotswappable" peripherals like hard disks. USB will become the standard for "low speed, ultra low cost" peripherals like keyboards and mice.
He's the archtypeal PHB in his reactions to Linux, and as such serves as a good yardstick to the "corporate mindset" (who, incidently, get their opinions retail from Jesse among others- Management By Reading Magazines).
Let's see. He's hit:
1) Ignorance ("What's Linux?")
2) Denial ("It's not worth writing about")
3) Dismissive ("Could you get fired for using Linux?")
4) Grudging Acceptance with Reservations ("I always said Linux could be a contender. Not on the desktop, though")