Live data from Hacker News

The SCO lawsuit, 20 years later

lwn.net

131–140 of 259 posts

Re: The SCO lawsuit, 20 years later

#131
post #84

Earlier quoted context omitted.

Yes, but the arguments of that era always seemed to revolve around minutiae like the package manager, or default filesysem, or choice of default desktop.

You're being dismissive of issues that were far bigger than you make them look. >like the package manager It wasn't about, for example, dpkg vs rpm, but apt-get versus.. nothing, because Red Hat had nothing to solve dependencies. Installing software on Red Hat was a truly hellish experience. >default filesysem I have never in my life seen people dismiss a distro because of a default filesystem. I question whether you…

> You're being dismissive of issues that were far bigger than you make them look.

You whooshed on the humor above, so I should spell it out. The point is exactly the opposite. This focus on tribal distro warfare obscures the objectively much more important threat posed by this lawsuit to the entire ecosystem.

I mean, no, you're simply wrong. SCO was a far, far, far larger threat to the Linux world than the fact that Red Hat inexplicably dragged their feet shipping yum on their enterprise distro.

And it's important, as a matter of history, to remember that period and the players and the resulting and continuing effects on our culture. While on the flip side, no one cares (or rather: no one should care) about the lessons of apt vs. yum, all of which have been recapitulated a thousand times since. Let it go.

Re: The SCO lawsuit, 20 years later

#132
post #125

Earlier quoted context omitted.

Likely because they want to keep that powder dry until someone with deep pockets gets involved, Microsoft, or IBM or someone. Because there's a moderate change that it goes against them.

Btrfs has also been improving. Certainly not for all use cases but it's the default for desktop Fedora now and some Synology NASs use it, among others.

On one hand ZFS has held down btrfs because "why bother" when you already have something that does much of what you want, but on the other hand it shows what can be done.

I hope btrfs becomes quite stable and usable.

Re: The SCO lawsuit, 20 years later

#133
Anybody know anything about the part where SCO actually won? I'm referring to the final event years later where IBM made a settlement payment to them. I assume it didn't make up for the years of effort, but I'd love to know what it was based on.

Re: The SCO lawsuit, 20 years later

#134

I would love to get a signed picture of Darl McBride for my bathroom. Because he paid for it. I heard about this lawsuit, called up a couple of IP lawyers, talked to a bunch of programmers, and read everything on groklaw. I called both analysts who covered the stock -- one had a price target of $5, while the other had a price target of $45 (stock was about 20 at the time). Then I shorted it with most of the money I h…

OK, that beats my "I made $25,000 on the VA Linux IPO simply because I was an early sourceforge user and got invited to the friends and family program".

Re: The SCO lawsuit, 20 years later

#135
post #42

Earlier quoted context omitted.

There were several good versions of Red Hat (IIRC 7.3 was pretty good) and then RH9 had NPTL but unfortunately was incompatible with the rest of the world (very custom kernel, userspace, compiler). IIRC the egcs included in that led to all sorts of interesting outcomes.

I'm confused. RH9 is the latest release, how is it custom? What are you referring to exactly?

Red Hat 9- https://en.wikipedia.org/wiki/Red_Hat_Linux was in 2003. I may be misremembering some details since I thought RH9 brought in egcs but it was 7.3 that did that.

Re: The SCO lawsuit, 20 years later

#136

This is a hilarious quote, in the article, attributed to Linus, related to the concept of source code pedigree and the developer certification of origin for any contribution. > For example, in the case of "ctype.h", what made it so clear that it was original work was the horrible bugs it contained originally, and since we obviously don't do bugs any more (right?), we should probably plan on having other ways to docum…

Well, mapmakers often sneak errors here and there to catch plagiarists. https://en.m.wikipedia.org/wiki/Phantom_settlement

Re: The SCO lawsuit, 20 years later

#137
post #28

Earlier quoted context omitted.

From my experience as a Linux sysadmin? RedHat ran half the planet because they had the best sales force and legal team (as exhibited by my example), but they did not have the best technology.

It looks like RHEL zealots never die from the other people’s comments. RHEL had plenty of problems just like all the other OSes and distros.

I think you're romanticizing it. Until RHEL and LTS releases for Debian/Ubuntu, most distros you never knew if running and update was going to break something because there simply wasn't effective quality control testing in the hobbyist distros. Best you could do was run a version behind, but that hurt if you needed security updates.

There were plenty of people and small highly knowledgeable shops and academics that thought 6 hours fixing a bug after custom compiling a patch was fine and normal (and a RHEL subscription at least meant RedHat would have a team doing that part for you if absolutely necessary), but its not the way companies operated. RHEL at least meant whatever release was stable and an actual QA team put patches through their paces on various hardware and configurations (especially those enterprise high end server configs with special SCSI/RAID controllers, high end network cards, and other chipset other distros simply didn't have the means to test on). The QA/support team wasn't bug reports and guys on usenet going "it works for me, you should have gotten the exact same hardware I have, or be willing to go through the code and figure it out and patch it, and submit it to the source, like a good user should". Or tell you go back to Micro$oft if you want support for your storage controller that the kernel module for worked fine in the last version. Those were the zealots, the rest were sys admins with too much other things on their hands to do than deal with Slackware or whatever the hot distro was on distrowatch.

Re: The SCO lawsuit, 20 years later

#138
post #28

Earlier quoted context omitted.

From my experience as a Linux sysadmin? RedHat ran half the planet because they had the best sales force and legal team (as exhibited by my example), but they did not have the best technology.

Wrong. Two reasons actually: 1. RHEL was the first distro directed at enterprise deployment (meaning, strong preference of rock solid stability and predictability over constant churn). Which made it the only distro Dells and HPs of the world recognized and agreed to support. 2. RHEL was created on legacy of RedHat Linux, which was the best distro for non-hobbyist environments (from reproducible deployments to the bre…

I don't think "Wrong" is a very interesting, helpful, or productive response to someone's lived experience.

Re: The SCO lawsuit, 20 years later

#139

Earlier quoted context omitted.

Rh 4.2 ran half the planet, where are you getting this from?

My main experience with RedHat has been needing to bend over backwards to support its wildly outdated library versions. Because RedHat “supports” operating systems for about a decade, there’s always an argument that a library should be written to support whatever toolchain is provided by the oldest supported RHEL version. RHEL’s “support” should be seen as “your software will continue to run unmodified when on this s…

Current development was better done on Fedora, the upstream of RHEL, I think they were pretty clear that's what it was for. RHEL was for when you needed everything to work no matter what. Fedora was for new development and latest and greatest.

Re: The SCO lawsuit, 20 years later

#140

Earlier quoted context omitted.

Rh 4.2 ran half the planet, where are you getting this from?

My main experience with RedHat has been needing to bend over backwards to support its wildly outdated library versions. Because RedHat “supports” operating systems for about a decade, there’s always an argument that a library should be written to support whatever toolchain is provided by the oldest supported RHEL version. RHEL’s “support” should be seen as “your software will continue to run unmodified when on this s…

They're talking about stuff that predates RHEL by half a decade.
Post reply on HN