Schwartz's mindset (much like SCO's, you will
note) precludes the possibility that a bunch
or loosely connected hackers could put something
together that rivals and exceeds his
company's sweat and tears.
Unlike SCO, which claims that they're precious
source code was stolen, Schwartz instead presumes
that Red Hat's software development works
exactly like Sun's or Microsoft's OS division.
It's just a matter of tiny minds.
This is made obvious not only by this
comment but by others he has made in the past
(see Groklaw etc.)
Both Tru64 (or whatever it's called this month,
I've been using it for over a decade now, so
I still tend to call it OSF/1, and occasionally
slip into Digital Unix) and HP-UX have a lot
of layers added on over their core of "standard"
Unix. (Others will go into great detail about how these are neither "standard" Unix cores but some variant of some variant of some variant of some microkernel but nobody cares anymore, that is really so early 90's.) They both have extensive system management
GUI's, of course not compatible with each other,
as well as fundamentally different "clustering" support. (Note my quotes, whenever you talk about any other product's clustering you always denigrate it by quoting that word.) To mix the two together is a holy living nightmare.
Most sites that are migrating are going away from both as fast as they can. There are a small fraction that truly depend on clustering or other proprietary feature, unfortunately everybody is holding on tenaciously to said features despite the fact that they really do 99% of the applications no good. And most commercial applications have been somehow hoodwinked into the proprietary hooks.
Viruses/Worms themselves work usually be finding a buffer overflow in an OS or application. They are themselves the result of reverse engineering.
It would seem a better defense to use whatever reverse engineering tools are available to fix the application. Things like Purify etc. are of some use for many common problems.
Adding additional/patched code onto a virus/worm sounds like dangerous business to me. Suppose you didn't do everything exactly right, you are now responsible for releasing a new virus into the wild.
Before we had disks (I'm talking about the 1960's), the ultimate in storage was the drum. It was a few feet long, spinning at hundreds to low thousands of RPM, and usually with fixed heads (a few dozen to a few hundred, typically).
This "new drive" seems to have all the disadvantages of a drum, plus another: it doesn't spin. Instead it just shimmies back and forth.
Well, maybe the new magical material will handle this OK. With the old drums, spinning them up often took several minutes because of the huge inertia (weight was often in the hundreds of pounds for the bigger ones... disaster when the
bearings seize and the drum smashes through brick walls!)
SCSI drive capacities have stayed where they
were while IDE drive capacities got bigger because
for real-world RAID arrays (where SCSI drives are used) capacity isn't the goal. It's speed. If
you need 1 Terabyte of really fast RAID storage it makes far more sense to put in 15 73gbyte3 SCSI drives (10K RPM, 15K RPM) than it does to use 4 300 GB IDE drives (7.2K RPM).
In the meantime IDE drives have begun to be used in RAID arrays, but usually where capacity matters and not performance. Admittedly the lines have blurred, especially for network-connected storage arrays where ethernet pipes are the limit and you cannot really tell the difference between a good IDE array and a regular SCSI array.
Thirty years ago, if you built a computer it meant you went out and bought transistors, resistors, chips, etched a PC board, soldered them together, and toggled in your operating system. Then you hooked up a surplus teletype and built your own floppy disk subsystem.
Today, computer building is dominated by "tech" articles about... folded cables.
The Kirk passport is hilarious, but I doubt the FBI would look kindly on a USAian forging documents and sending them (selling them?) overseas, no matter how ludicrous the names and pictures.
It is interesting that a guy passing counterfeit $200 bills with Geroge W Bush's pictures cannot be charged for counterfeiting because there is no such thing as a $200 bill...
It's not automatically true that if you've got a good running product that you can beat the sales team with no actual product.
Even if you're product is technically best by some measure there are other products that may be technically better by some other measure. Hindsight often tells you which benchmark was right and which was wrong but in the heat of battle it's hard to see the forest for the trees.
And all that said, oftentimes the selected product is simply vaporware (as was MS-DOS until Gates bought QDOS) when there are real running products out there. Part of it is salesmanship on one side and lack of salesmanship on the other side, but usually there's some favors being traded under the table.
And while Kildall wasn't the biggest fish in that pond, he had hooks into a number of software packages (CP/M was being sold on millions of PC's, the DR languages and tools too).
Testing of the assembly would have shown up this problem immediately.
Just like you should never write that code that cannot be tested (in the perfect world, every line would be executed during testing), you should never design a subassembly that cannot be tested.
It's a organizational attitude adjustment that's needed to put this into effect.
Scanning your own systems for vulnerabilities, especially when you have third-party stuff on it, is a tough job.
You don't even need third-party stuff or an application to make it hard under Linux. Typical cycle is: kernel version x comes out in March. It's in a Red Hat release in July. Vulnerability found in September, with an immediate release of version x+1 on kernel.org (which also has a lot of changed/evolved drivers etc.) Red Hat back-patches the fix to version x and makes a new funny version number to signify this. They might include a couple other things from x+1 in the back-patch to version x. Except that the funny redhat version number doesn't signify much to anyone on the surface.
Similar things happen for Red Hat (and other branded linux binary distributions) of Apache, SSL, etc., things that are all quite critical and you'd hope would be crystal-clear as to which patches your version has or doesn't have.
Now finding whether version X of a library or
application has a vulnerability patched usually isn't too hard. And Red Hat does a pretty good job of keeping on top, way better than say Microsoft.
Disclaimer: I'm no fan of Microsoft, but I'm not a big fan of Red Hat (or, as I prefer, Head Rat) either (or any binary linux/gnu toolchain/popular application distro for that matter).
I send out flat text files to co-workers, and
they complain that they cannot open them
because they don't have the appropriate reader
on their (Microsoft) E-mail system. Yes,
I know that notepad and Word and probably
other applications can "open" a text file, but
none of the defaults are set to do this
automagically.
If it's an ISO standard it won't do a damn bit
of good until the Microsoft OS's and Microsoft
mail system and Microsoft Applications all know
to do the right thing. Whad'ya think the
chances of Microsoft cooperating are?
Remember Microsoft's response to the rise
of the Internet? They came out with Microsoft
Bob, which completely missed the needs of users
while providing some sickeningly sweet eye-candy.
At least as far as this interview goes, it's
all about corporate strategies AGAINST
Linux suppliers and integrators. Little
to nothing about OSS's/Unix's/Linux's strengths.
Again, they are fundamentally missing the point
in the interview.
That doesn't mean they aren't using their
legal and financial blunderbuss to defeat the
Linux vendors/integrators the same way they
wiped out Netscape, though. If so, they almost
certainly won't talk about it in an interview.
Both are true... A is $14.00, B is $10.00. The difference is the same arithmetically, but doing it fractionally only serves to confuse things (usually, confuse the customer...)
Things get really out of hand when there's a
factor of two:
We are 50% faster than the competition!
From this it's not too far to say
We are twice the speed of the competition!
Which then gets twisted further to
We are 100% faster than the competition!
It's that last step that's most dubious to me, arithmetically (or geometrically) there's no justification.
Weren't the VA boxes just made out of commodity parts? For example, Brand X power supply, Brand Y motherboard, Brand Z disk drives? I'm sure all the docs in the individual parts are findable.
It's vaguely possible that they have some really funky firmware RAID controller, I've seen Dell server machines require a special microcode load into the RAID controller to work with Linux. That's a pain in the butt, and when the only thing is available is the binary and only from the vendor I just think the offending device is evil and punt it. (Lotsa RAID stuff is still this way, and sometimes it's even on the motherboard, which means you toss the motherboard).
Remember, SCO has to put up the front that they really believe that they own all the IP in linux. Otherwise their legal case falls apart. If they anywhere anyhow admit that they don't own all of everything in linux, then their broad claims in their legal actions instantly lose all credibility.
The MPAA represents companies that want to sell movies on DVD. Obviously more DVD players will mean more DVD's sold. So they sue companies that sell DVD players?
I'm sure they've got some harebrained legal theory, but the MPAA is hurting its member companies just to hold up legal fictions.
Even if the written documentation at MS for the MS Office formats are not complete, it would not cost much to have a few programmers document it fully and release that to the public.
Oh, to be young and naive again:-). In my youth I often thought "they're a big company, all they have to do is put a few guys on it and it'll be usefully documented". Some companies are scared to even document their stuff internally out of fear that the document will leak out.
I still feel the empirical evidence is the strongest: The lack of compatibility between different platforms and different versions of Word is the proof that there is no usable documentation.
Seeing how your personal home page tells me that I need Internet Explorer just to view it, I hardly think you know much about standards, much less open standards:-).
Again, my evidence is purely empirical, that the lack of compatibility between different platforms and even versions of Word makes it clear that Microsoft has no useful complete internal documentation on the file formats.
Of course this will never happen because the whole purpose of this "open source" work is so that Microsoft can say
My belief is that this will never happen, because even deep in the bowels of Microsoft they have no complete documentation of the file format. This is the only explanation I have for the lack of compatibility between different platforms, or even different versions, of Word.
You seem to be ascribing the lack of documentation to a Micorosoft corporate policy. But
my best guess, based on the incompatibility between Word versions and platforms, is that even inside Microsoft they have incomplete documentation on the file format.
Slashdot Mirror
Unlike SCO, which claims that they're precious source code was stolen, Schwartz instead presumes that Red Hat's software development works exactly like Sun's or Microsoft's OS division. It's just a matter of tiny minds.
This is made obvious not only by this comment but by others he has made in the past (see Groklaw etc.)
Most sites that are migrating are going away from both as fast as they can. There are a small fraction that truly depend on clustering or other proprietary feature, unfortunately everybody is holding on tenaciously to said features despite the fact that they really do 99% of the applications no good. And most commercial applications have been somehow hoodwinked into the proprietary hooks.
It would seem a better defense to use whatever reverse engineering tools are available to fix the application. Things like Purify etc. are of some use for many common problems.
Adding additional/patched code onto a virus/worm sounds like dangerous business to me. Suppose you didn't do everything exactly right, you are now responsible for releasing a new virus into the wild.
"Flip the switch again"? That's like hitting the "up" button more times to make the elevator come faster.
This "new drive" seems to have all the disadvantages of a drum, plus another: it doesn't spin. Instead it just shimmies back and forth.
Well, maybe the new magical material will handle this OK. With the old drums, spinning them up often took several minutes because of the huge inertia (weight was often in the hundreds of pounds for the bigger ones... disaster when the bearings seize and the drum smashes through brick walls!)
- Relatively open standards for postscript, PDF
- True freeware tools (ghostscript, xpdf, OpenOffice) to read and generate according to the open standard
- Many commercial softwares that read and generate too
- Adobe-supplied free reader for most common Unices and Linux
Really, what else is needed? There are a bazillion companies out there with "Linux strategies" but no products or open standards.Well, there is gigabit Ethernet now, so maybe it is as good as fibre channel (although TCP/IP latency issues are starting to bite.)
SCSI drive capacities have stayed where they were while IDE drive capacities got bigger because for real-world RAID arrays (where SCSI drives are used) capacity isn't the goal. It's speed. If you need 1 Terabyte of really fast RAID storage it makes far more sense to put in 15 73gbyte3 SCSI drives (10K RPM, 15K RPM) than it does to use 4 300 GB IDE drives (7.2K RPM).
In the meantime IDE drives have begun to be used in RAID arrays, but usually where capacity matters and not performance. Admittedly the lines have blurred, especially for network-connected storage arrays where ethernet pipes are the limit and you cannot really tell the difference between a good IDE array and a regular SCSI array.
Today, computer building is dominated by "tech" articles about... folded cables.
THIS ISN'T PROGRESS, PEOPLE!
You've got a point. He says he sent the passport to the guy, but he did it via E-mail, so there wasn't necessarily ever a physical document, I guess.
It is interesting that a guy passing counterfeit $200 bills with Geroge W Bush's pictures cannot be charged for counterfeiting because there is no such thing as a $200 bill...
Somehow manages to take the beauty of a quadractic curve and turns it into a grunge problem.
Even if you're product is technically best by some measure there are other products that may be technically better by some other measure. Hindsight often tells you which benchmark was right and which was wrong but in the heat of battle it's hard to see the forest for the trees.
And all that said, oftentimes the selected product is simply vaporware (as was MS-DOS until Gates bought QDOS) when there are real running products out there. Part of it is salesmanship on one side and lack of salesmanship on the other side, but usually there's some favors being traded under the table.
And while Kildall wasn't the biggest fish in that pond, he had hooks into a number of software packages (CP/M was being sold on millions of PC's, the DR languages and tools too).
Just like you should never write that code that cannot be tested (in the perfect world, every line would be executed during testing), you should never design a subassembly that cannot be tested.
It's a organizational attitude adjustment that's needed to put this into effect.
You don't even need third-party stuff or an application to make it hard under Linux. Typical cycle is: kernel version x comes out in March. It's in a Red Hat release in July. Vulnerability found in September, with an immediate release of version x+1 on kernel.org (which also has a lot of changed/evolved drivers etc.) Red Hat back-patches the fix to version x and makes a new funny version number to signify this. They might include a couple other things from x+1 in the back-patch to version x. Except that the funny redhat version number doesn't signify much to anyone on the surface.
Similar things happen for Red Hat (and other branded linux binary distributions) of Apache, SSL, etc., things that are all quite critical and you'd hope would be crystal-clear as to which patches your version has or doesn't have.
Now finding whether version X of a library or application has a vulnerability patched usually isn't too hard. And Red Hat does a pretty good job of keeping on top, way better than say Microsoft.
Disclaimer: I'm no fan of Microsoft, but I'm not a big fan of Red Hat (or, as I prefer, Head Rat) either (or any binary linux/gnu toolchain/popular application distro for that matter).
If it's an ISO standard it won't do a damn bit of good until the Microsoft OS's and Microsoft mail system and Microsoft Applications all know to do the right thing. Whad'ya think the chances of Microsoft cooperating are?
At least as far as this interview goes, it's all about corporate strategies AGAINST Linux suppliers and integrators. Little to nothing about OSS's/Unix's/Linux's strengths. Again, they are fundamentally missing the point in the interview.
That doesn't mean they aren't using their legal and financial blunderbuss to defeat the Linux vendors/integrators the same way they wiped out Netscape, though. If so, they almost certainly won't talk about it in an interview.
Things get really out of hand when there's a factor of two:
From this it's not too far to sayWhich then gets twisted further toIt's that last step that's most dubious to me, arithmetically (or geometrically) there's no justification.It's vaguely possible that they have some really funky firmware RAID controller, I've seen Dell server machines require a special microcode load into the RAID controller to work with Linux. That's a pain in the butt, and when the only thing is available is the binary and only from the vendor I just think the offending device is evil and punt it. (Lotsa RAID stuff is still this way, and sometimes it's even on the motherboard, which means you toss the motherboard).
Remember, SCO has to put up the front that they really believe that they own all the IP in linux. Otherwise their legal case falls apart. If they anywhere anyhow admit that they don't own all of everything in linux, then their broad claims in their legal actions instantly lose all credibility.
I'm sure they've got some harebrained legal theory, but the MPAA is hurting its member companies just to hold up legal fictions.
I still feel the empirical evidence is the strongest: The lack of compatibility between different platforms and different versions of Word is the proof that there is no usable documentation.
Again, my evidence is purely empirical, that the lack of compatibility between different platforms and even versions of Word makes it clear that Microsoft has no useful complete internal documentation on the file formats.
My belief is that this will never happen, because even deep in the bowels of Microsoft they have no complete documentation of the file format. This is the only explanation I have for the lack of compatibility between different platforms, or even different versions, of Word.
You seem to be ascribing the lack of documentation to a Micorosoft corporate policy. But my best guess, based on the incompatibility between Word versions and platforms, is that even inside Microsoft they have incomplete documentation on the file format.