So let's rephrase it: If steal $5 from you at knifepoint, I should end up in jail but if I defraud you through the stock market I should be free?
Sure, I should get smacked down for pulling knives on people, but shouldn't I get smacked down harder for stealing millions?
Even when the Milkens of the world get (relatively) enormous fines and some jail time, when they come out they're STILL RICH, because their ill-gotten gains are still waiting for them in the bank.
"The Law, in its majestic equality, forbids the rich, as well as the poor, to sleep under the bridges, to beg in the streets, and to steal bread." -- Anatole France
In a way, I'm glad it's IBM fighting the first big GPL court battle, rather than any of the advocacy organizations, which while strongly motivated and highly expert, are also woefully underfunded and would almost certainly lose in a drawn-out war of attrition.
Sorry, I used (US) electrician terminology--they generally talk about the stuff that comes out of the wall as current, e.g., "two-twenty three-phase current", even if it's technically a misnomer.
I know the difference between volts and amperes, ohms and henries, reactive and resistive loads, ground planes versus ground loops, SWR versus SNR, etc.
And no, voltage is NOT the only thing that varies at the wall outlet due to environmental conditions.
Either I haven't read the comments up to this point carefully enough, or nobody has said anything about line current, and its effect on PSU performance. The article didn't have any tests for it either.
I know we all power our machines through UPSs with nice clean conditioned power, but most of the unwashed masses plug theirs right into the wall, with all the attendant brownouts, spikes, and neat things that happen during thunderstorms.
Too bad they couldn't test the performance and robustness of those units under degraded line current. Would be much more useful information for me than what color the connectors are.
You're saying that "./configure; make" is more complicated than building a 100' tower with a tribander on top?:)
Back in the day, it took me a couple months of evenings and weekends to set up my "client", a Heathkit HW-101. And you're right, for as much fun as the Internet is, it's somehow missing something that those faint late-night bleeps had, coming through the original "ether" net.
Actually, it's not who you know, it's who knows you.
I've gotten to know quite a few of the more famous and powerful names in this business over the years. Theoretically, they should be ideal sources for job leads and recommendations. OTOH, the half-life of a business relationship is about six months, no matter how closely you worked together in the past.
Some of the people I have not maintained contact with, so at this point, it's doubtful they could pick me out of a police lineup. Reestablishing contact, should I need to do so, would be through one of those difficult, embarrassing "Remember me?" calls or emails.
Moral: Always keep networking, even when you're happily situated.
True story: Back in the day, I worked on UnixWare for Novell, having been assimilated from USL. At one point I had a meeting with a bunch of old-guard Novell engineering managers to discuss companywide process issues. One of those managers asked me, "UnixWare? Does that run under Unix?"
And anyone wonders how it is that all these Utah companies, cross-pollinated with the same people over decades, so handily ran UnixWare into the ground, despite it being (IMO) a solid and feature-rich OS. A lot of the time we felt like we were working for Xerox.
Here's their current price list. I don't know if their "insurance policy" binary licenses will be priced the same. I suspect they'll be lower, because they're trying to get as many sux0rs to buy into their protection racket as possible.
As a manager, I'd be more likely to bet $200 (for, say, a single-page hold-harmless letter masquerading as a 0-user 0-CPU 0GB UW "license") than I would be to bet $2400 (the current cost of a 25-user dual-CPU 4GB UW7.1.3 license plus media).
This sort of thing has been around for decades. I remember as far back as the early 1970s, hobbyist magazines' "Buyer's Guide" issues would have deliberately bogus entries to ensure that their competitors didn't steal the data wholesale for their own buyer's guides.
So are AOL's long-term lease on IE, and its buy-high-sell-low Netscape strategy precursors of further mergers (think MSN/AOL)?
Not only could it provide many more chances for opportunistic middle managers to use layoffs to make it look like they're Doing Something, but the thought of putting Time Warner's clout behind its longstanding efforts at being a multimedia content provider must make MS salivate. (MSNBC? Zzzz.)
You have to answer this question every time you improve or add to the metadata. One recent instance of this was the addition of ACLs. An ancient instance of this was the addition of long (>14 character) filenames.
The file-as-directory scheme goes a long way toward generalizing this, so that once the common tools like tar can handle it, new metadata introduction will likely not be such a transportability nightmare.
BTW, ClearCase has had files-as-directories for years, just with a slightly different notation that maintains transportability at the expense of namespace pollution. Call something file and you get the version you're supposed to get. Call it file@@/ and you have transparent access to the file's entire version tree, as well as all the tags applied to it.
One of the initial claims by SCO is that there is no way that certain features could have legitimately been added to Linux--the OSS community simply didn't have the capability to develop them or the resources to test them. After they were reminded of OSDL and various corporate support, they changed their tack and started in with the claims about all the code in Linux that matches code in UnixWare, and the implicit claim that IBM had something to do with the UW code getting into Linux.
A timeline could either support or refute that claim. SCO says they found instances of code in Linux that is SCO's IP or otherwise license-encumbered, and alleges that IBM is the vector. There are two scenarios here:
In the first case, the vector is likely not in dispute. The code written by Sequent got incorporated into AIX then found its way into Linux. What's in dispute here is whether the Sequent code is enough of a derivative work of System V that it cannot be freely distributed without violating SCO's (claimed) IP rights to "Unix", or whether its path through IBM placed it under the umbrella of the SCO/IBM licensing agreements. So here, you're right; we wouldn't get much help from a source repository analysis.
The second case is the existence of ancestral System V code in Linux, which SCO can claim got there by IBM's hand whether or not it was ever also part of AIX. SCO still has to show that a) the code existed in UnixWare prior to its appearance in Linux (this is where the source repositories come in handy), and b) it could not have gotten into Linux by some other path (from SCO itself or another of its licensees). The case for (a) becomes stronger if you can show that the code was in UW, then was code-dropped to IBM, then was checked into AIX, then was sent to Linus from IBM, then was checked into Linux. In any case, access to all three source repositories is necessary (but not completely sufficient) for establishing the path of the code.
Linux is publically auditable, but there is no such guarantee from SCO, as everything is closed-source.
The AIX and UW code bases don't have to be publicly auditable in order to be conclusively audited.
IANAL, but if I were (for either side), I'd demand that the source repositories for both AIX and UnixWare be made available for examination during discovery. Were I representing IBM, I'd subpoena (or whatever you do during discovery) the UW repositories and demand that each block of allegedly copied code be traced back to its earliest check-in in any of the AIX, UW or Linux source repositories.
Were I representing SCO, I'd subpoena the AIX source repository and proactively do the same thing, and if the vast majority of tracing didn't conclusively show the direct line of code transfer starting with UW, through AIX, thence to Linux, never getting out from under SCO's contract with IBM, I'd advise my client to drop the case and STFU.
Re:I like Ms. Ullman's writing, but...
on
The Bug
·
· Score: 3, Interesting
a tension where none really exists naturally
In 1983 I was working on the firmware for a combination port selector and stat MUX. Two weeks before we were to ship, a bug appeared that intermittently crashed (what we would now call) the NIC.
This was a startup, in a time and place where there was no payroll insurance. In addition to the usual crushing startup pressure, if we didn't ship, the company didn't get paid, so we didn't get paid.
It took four of us the full two weeks to find and work around the bug. We were finally convinced it was a bug in the CPU, because swapping two adjacent independent load-one-register-from-another instructions made the problem go away. We ended our final push, having been up for over 72 hours, by leaving at 6:30am for the three-hour trip to the customer site with two sets of new EPROMs for the units they already had on site.
If you've never experienced tension like that, I want to work where you work!
Re:You'll just have to wait...
on
The Bug
·
· Score: 4, Funny
No, no, no.
In the Stephen King (Richard Bachman, if you want to get technical) version, everybody on the development team has to work until the bug is found, no matter how long it takes. The instant you stop typing, you're shot.
I think the residual part refers to the compensation that happens on its own over decades of adulthood. You don't apparently exhibit some particular AS trait (like the inability to make small talk) any more, but the trait was there before you learned your way through it.
By way of analogy, my right eye pretty much doesn't work, so I have essentially no natural depth perception. But I can still drive a car, catch a ball, hit a badminton bird, etc., because my brain taught itself depth perception by mechanisms other than stereoscopic vision, not because my right eye started working again.
My son has an AS diagnosis. Among other things, he gets social skills training, because basic social skills (like saying "hello") have to be taught to him by rote the same way we had to be taught by rote that the fork goes on the left. Undiagnosed adults with AS had to learn that stuff the hard way.
Finally, I recommend going to a neurologist as well as a psychologist for ASD diagnoses. For my son, sensory integration problems and motor delays were part and parcel of his diagnosis (the "pervasive" part of PDD).
True, plus there's a lot of third-party code (e.g., VxFS from Veritas) in UnixWare whose source neither SCO now nor IBM later would be permitted to open.
OK, you've piqued my curiosity. Just how much storage?
Let's start with a two-hour film shot at 60fps with 2048 lines of vertical resolution, 48bpp color, and a 2.35:1 aspect ratio.
If we round off the screen resolution to 4800x2048, that's 9.375Mpixels, 56.25MB/frame, 3.3GB/second, or about 23TB for a two-hour film, uncompressed. I don't know much about video compression, but it sounds intuitive to me that you could get 5:1 compression and still get an OK picture, which works out to about 4.6TB. Let's round that up to 5TB for a good back-of-the-envelope guess.
By the time movies start coming out in a format like this (someone still has to build the cameras and the post-production infrastructure), a single hard drive should be able to hold that much, but that still sticks you with mailing physical media to the theaters. I'll leave it to someone else to do the math as to whether multicast distribution over a private network would be feasible.
I think in the meantime, we should follow Roger Ebert's recommendation for improving the viewer experience. Switch to 35mm film at 48fps. The projector mods are much less expensive than digital projectors,and they're backwards-compatible with conventional film. In its current incarnation, digital is a boon to the studios at the expense of the theaters.
(Side note: Showscan, 70mm film at 60fps IIRC, was the coolest thing I've ever seen projected anywhere.)
Not many, actually. Those customers don't build those tools, they use the versions of Apache and Perl that SCO provides with the OS. Their home-grown applications are almost always built with the compiler SCO sells, not GCC. One throat to choke, and all that.
Claimer: I worked on UnixWare for USL and Novell from 1993 to 1996, so I know something of the engineering and marketing decisions behind it.
The point of all this is that there is a small set of large businesses who buy UnixWare in quantity. They buy it for specialized applications, like retail point-of-sale. With a few notable exceptions like Apache, they COULDN'T CARE LESS about the entire corpus of OSS. They only care if their application works, wherever and whenever it's installed.
Sure, there are organizations who install large quantities of Linux systems (think TiVo), but those sets of people don't intersect very much with the UnixWare customer base. The people basing their products on Linux and the GNU toolchain obviously have a vested interest in what the OSS community is doing, and it's in their best interests to keep a good relationship with them.
By ceasing to distribute Linux, SCO no longer has that burden, so I stand by my original point. What the OSS community thinks about whether their products should be supported on UW isn't going to keep Darl awake at night.
Right. All OSS projects should stop supporting SCO. Because we all know that corporations pay big bucks for UnixWare so that they can run OpenOffice and GNUCash on it.
It's the ISVs that can really hurt SCO, because UW is usually on their bottom tier of supported OSes. One glance in the wrong direction and the ISVs start singing Hello, Solaris. I know for a fact that in at least one case, Novell PAID an ISV for the port of their product to UW and in another, no amount of money would get the vendor to port any of their products to UW.
Unfortunately, ISVs whose bread and butter is proprietary intellectual property are not likely to be all that sympathetic to a boycott of someone who has a chance to set a legal precedent that could help them all in the long run.
Slashdot Mirror
So let's rephrase it: If steal $5 from you at knifepoint, I should end up in jail but if I defraud you through the stock market I should be free?
Sure, I should get smacked down for pulling knives on people, but shouldn't I get smacked down harder for stealing millions?
Even when the Milkens of the world get (relatively) enormous fines and some jail time, when they come out they're STILL RICH, because their ill-gotten gains are still waiting for them in the bank.
"The Law, in its majestic equality, forbids the rich, as well as the poor, to sleep under the bridges, to beg in the streets, and to steal bread." -- Anatole France
In a way, I'm glad it's IBM fighting the first big GPL court battle, rather than any of the advocacy organizations, which while strongly motivated and highly expert, are also woefully underfunded and would almost certainly lose in a drawn-out war of attrition.
For once, a corporate behemoth on our side...
Your right to free speech does not obligate me, as a private citizen, to provide you a forum in which to exercise that right.
Thus, a spammer's free speech rights have no bearing on my inbox.
Sorry, I used (US) electrician terminology--they generally talk about the stuff that comes out of the wall as current, e.g., "two-twenty three-phase current", even if it's technically a misnomer.
I know the difference between volts and amperes, ohms and henries, reactive and resistive loads, ground planes versus ground loops, SWR versus SNR, etc.
And no, voltage is NOT the only thing that varies at the wall outlet due to environmental conditions.
Either I haven't read the comments up to this point carefully enough, or nobody has said anything about line current, and its effect on PSU performance. The article didn't have any tests for it either.
I know we all power our machines through UPSs with nice clean conditioned power, but most of the unwashed masses plug theirs right into the wall, with all the attendant brownouts, spikes, and neat things that happen during thunderstorms.
Too bad they couldn't test the performance and robustness of those units under degraded line current. Would be much more useful information for me than what color the connectors are.
You're saying that "./configure; make" is more complicated than building a 100' tower with a tribander on top? :)
Back in the day, it took me a couple months of evenings and weekends to set up my "client", a Heathkit HW-101. And you're right, for as much fun as the Internet is, it's somehow missing something that those faint late-night bleeps had, coming through the original "ether" net.
Actually, it's not who you know, it's who knows you.
I've gotten to know quite a few of the more famous and powerful names in this business over the years. Theoretically, they should be ideal sources for job leads and recommendations. OTOH, the half-life of a business relationship is about six months, no matter how closely you worked together in the past.
Some of the people I have not maintained contact with, so at this point, it's doubtful they could pick me out of a police lineup. Reestablishing contact, should I need to do so, would be through one of those difficult, embarrassing "Remember me?" calls or emails.
Moral: Always keep networking, even when you're happily situated.
Would that be the American commuter lifestyle, which is a nightly hour of bad streets and then enormous amounts of trash on TV?
(Disclaimer: I am an American commuter.)
True story: Back in the day, I worked on UnixWare for Novell, having been assimilated from USL. At one point I had a meeting with a bunch of old-guard Novell engineering managers to discuss companywide process issues. One of those managers asked me, "UnixWare? Does that run under Unix?"
And anyone wonders how it is that all these Utah companies, cross-pollinated with the same people over decades, so handily ran UnixWare into the ground, despite it being (IMO) a solid and feature-rich OS. A lot of the time we felt like we were working for Xerox.
Here's their current price list. I don't know if their "insurance policy" binary licenses will be priced the same. I suspect they'll be lower, because they're trying to get as many sux0rs to buy into their protection racket as possible.
As a manager, I'd be more likely to bet $200 (for, say, a single-page hold-harmless letter masquerading as a 0-user 0-CPU 0GB UW "license") than I would be to bet $2400 (the current cost of a 25-user dual-CPU 4GB UW7.1.3 license plus media).
This sort of thing has been around for decades. I remember as far back as the early 1970s, hobbyist magazines' "Buyer's Guide" issues would have deliberately bogus entries to ensure that their competitors didn't steal the data wholesale for their own buyer's guides.
The parent comment is proof that Slashdot needs a "+1 Troll" moderation.
So are AOL's long-term lease on IE, and its buy-high-sell-low Netscape strategy precursors of further mergers (think MSN/AOL)?
Not only could it provide many more chances for opportunistic middle managers to use layoffs to make it look like they're Doing Something, but the thought of putting Time Warner's clout behind its longstanding efforts at being a multimedia content provider must make MS salivate. (MSNBC? Zzzz.)
The file-as-directory scheme goes a long way toward generalizing this, so that once the common tools like tar can handle it, new metadata introduction will likely not be such a transportability nightmare.
BTW, ClearCase has had files-as-directories for years, just with a slightly different notation that maintains transportability at the expense of namespace pollution. Call something file and you get the version you're supposed to get. Call it file@@/ and you have transparent access to the file's entire version tree, as well as all the tags applied to it.
One of the initial claims by SCO is that there is no way that certain features could have legitimately been added to Linux--the OSS community simply didn't have the capability to develop them or the resources to test them. After they were reminded of OSDL and various corporate support, they changed their tack and started in with the claims about all the code in Linux that matches code in UnixWare, and the implicit claim that IBM had something to do with the UW code getting into Linux.
A timeline could either support or refute that claim. SCO says they found instances of code in Linux that is SCO's IP or otherwise license-encumbered, and alleges that IBM is the vector. There are two scenarios here:
In the first case, the vector is likely not in dispute. The code written by Sequent got incorporated into AIX then found its way into Linux. What's in dispute here is whether the Sequent code is enough of a derivative work of System V that it cannot be freely distributed without violating SCO's (claimed) IP rights to "Unix", or whether its path through IBM placed it under the umbrella of the SCO/IBM licensing agreements. So here, you're right; we wouldn't get much help from a source repository analysis.
The second case is the existence of ancestral System V code in Linux, which SCO can claim got there by IBM's hand whether or not it was ever also part of AIX. SCO still has to show that a) the code existed in UnixWare prior to its appearance in Linux (this is where the source repositories come in handy), and b) it could not have gotten into Linux by some other path (from SCO itself or another of its licensees). The case for (a) becomes stronger if you can show that the code was in UW, then was code-dropped to IBM, then was checked into AIX, then was sent to Linus from IBM, then was checked into Linux. In any case, access to all three source repositories is necessary (but not completely sufficient) for establishing the path of the code.
The AIX and UW code bases don't have to be publicly auditable in order to be conclusively audited.
IANAL, but if I were (for either side), I'd demand that the source repositories for both AIX and UnixWare be made available for examination during discovery. Were I representing IBM, I'd subpoena (or whatever you do during discovery) the UW repositories and demand that each block of allegedly copied code be traced back to its earliest check-in in any of the AIX, UW or Linux source repositories.
Were I representing SCO, I'd subpoena the AIX source repository and proactively do the same thing, and if the vast majority of tracing didn't conclusively show the direct line of code transfer starting with UW, through AIX, thence to Linux, never getting out from under SCO's contract with IBM, I'd advise my client to drop the case and STFU.
In 1983 I was working on the firmware for a combination port selector and stat MUX. Two weeks before we were to ship, a bug appeared that intermittently crashed (what we would now call) the NIC.
This was a startup, in a time and place where there was no payroll insurance. In addition to the usual crushing startup pressure, if we didn't ship, the company didn't get paid, so we didn't get paid.
It took four of us the full two weeks to find and work around the bug. We were finally convinced it was a bug in the CPU, because swapping two adjacent independent load-one-register-from-another instructions made the problem go away. We ended our final push, having been up for over 72 hours, by leaving at 6:30am for the three-hour trip to the customer site with two sets of new EPROMs for the units they already had on site.
If you've never experienced tension like that, I want to work where you work!
No, no, no.
In the Stephen King (Richard Bachman, if you want to get technical) version, everybody on the development team has to work until the bug is found, no matter how long it takes. The instant you stop typing, you're shot.
Oh wait. That's MY company. Oh, SHI-----
NO CARRIER
TFA says that the amount of radiation exposure is comparable to sunshine.
I want to get a T-shirt that says, "Asperger's is hereditary -- you get it from your kids."
I know many adults who got AS diagnoses when they had themselves evaluated after their kids were diagnosed.
I think the residual part refers to the compensation that happens on its own over decades of adulthood. You don't apparently exhibit some particular AS trait (like the inability to make small talk) any more, but the trait was there before you learned your way through it.
By way of analogy, my right eye pretty much doesn't work, so I have essentially no natural depth perception. But I can still drive a car, catch a ball, hit a badminton bird, etc., because my brain taught itself depth perception by mechanisms other than stereoscopic vision, not because my right eye started working again.
My son has an AS diagnosis. Among other things, he gets social skills training, because basic social skills (like saying "hello") have to be taught to him by rote the same way we had to be taught by rote that the fork goes on the left. Undiagnosed adults with AS had to learn that stuff the hard way.
Finally, I recommend going to a neurologist as well as a psychologist for ASD diagnoses. For my son, sensory integration problems and motor delays were part and parcel of his diagnosis (the "pervasive" part of PDD).
True, plus there's a lot of third-party code (e.g., VxFS from Veritas) in UnixWare whose source neither SCO now nor IBM later would be permitted to open.
OK, you've piqued my curiosity. Just how much storage?
Let's start with a two-hour film shot at 60fps with 2048 lines of vertical resolution, 48bpp color, and a 2.35:1 aspect ratio.
If we round off the screen resolution to 4800x2048, that's 9.375Mpixels, 56.25MB/frame, 3.3GB/second, or about 23TB for a two-hour film, uncompressed. I don't know much about video compression, but it sounds intuitive to me that you could get 5:1 compression and still get an OK picture, which works out to about 4.6TB. Let's round that up to 5TB for a good back-of-the-envelope guess.
By the time movies start coming out in a format like this (someone still has to build the cameras and the post-production infrastructure), a single hard drive should be able to hold that much, but that still sticks you with mailing physical media to the theaters. I'll leave it to someone else to do the math as to whether multicast distribution over a private network would be feasible.
I think in the meantime, we should follow Roger Ebert's recommendation for improving the viewer experience. Switch to 35mm film at 48fps. The projector mods are much less expensive than digital projectors,and they're backwards-compatible with conventional film. In its current incarnation, digital is a boon to the studios at the expense of the theaters.
(Side note: Showscan, 70mm film at 60fps IIRC, was the coolest thing I've ever seen projected anywhere.)
Not many, actually. Those customers don't build those tools, they use the versions of Apache and Perl that SCO provides with the OS. Their home-grown applications are almost always built with the compiler SCO sells, not GCC. One throat to choke, and all that.
Claimer: I worked on UnixWare for USL and Novell from 1993 to 1996, so I know something of the engineering and marketing decisions behind it.
The point of all this is that there is a small set of large businesses who buy UnixWare in quantity. They buy it for specialized applications, like retail point-of-sale. With a few notable exceptions like Apache, they COULDN'T CARE LESS about the entire corpus of OSS. They only care if their application works, wherever and whenever it's installed.
Sure, there are organizations who install large quantities of Linux systems (think TiVo), but those sets of people don't intersect very much with the UnixWare customer base. The people basing their products on Linux and the GNU toolchain obviously have a vested interest in what the OSS community is doing, and it's in their best interests to keep a good relationship with them.
By ceasing to distribute Linux, SCO no longer has that burden, so I stand by my original point. What the OSS community thinks about whether their products should be supported on UW isn't going to keep Darl awake at night.
Right. All OSS projects should stop supporting SCO. Because we all know that corporations pay big bucks for UnixWare so that they can run OpenOffice and GNUCash on it.
It's the ISVs that can really hurt SCO, because UW is usually on their bottom tier of supported OSes. One glance in the wrong direction and the ISVs start singing Hello, Solaris. I know for a fact that in at least one case, Novell PAID an ISV for the port of their product to UW and in another, no amount of money would get the vendor to port any of their products to UW.
Unfortunately, ISVs whose bread and butter is proprietary intellectual property are not likely to be all that sympathetic to a boycott of someone who has a chance to set a legal precedent that could help them all in the long run.