Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The SCO lawsuit, 20 years later

lwn.net

Post reply on HN
Print view View original

241–250 of 259 posts

Re: The SCO lawsuit, 20 years later

#241

Post by up2isomorphism »

wsc981 wrote: post #234
cjensen wrote: post #215

Earlier quoted context omitted.

SCO the "cool UNIX vendor" was not the company that sued. In 2001, the cool UNIX vendor was struggling and sold its UNIX business to Caldera. Caldera renamed itself "the SCO Group" and filed the lawsuit. [1] [1] https://en.wikipedia.org/wiki/Santa_Cruz_Operation

Let's not forget the following [0]: > SCO's Linux lawsuit made no sense and no one at the time gave it much of a chance of succeeding. Over time it was revealed that Microsoft had been using SCO as a sock puppet against Linux. Unfortunately for Microsoft and SCO, it soon became abundantly clear that SCO didn't have a real case against Linux and its allies. In a way this was a proxy war of Microsoft vs Linux. --- [0]:…

Microsoft is very very American.

Re: The SCO lawsuit, 20 years later

#242

Post by robennals »

Taniwha wrote: post #221
robotelvis wrote: post #213

I was actually the "author" of one of the pieces of code that SCO claimed had been stolen from them - SCO's implementation of the Berkeley Packet Filter. SCO had a collaboration with IBM called Project Monterey, in which SCO and IBM were merging their operating systems in order to be better positioned for IA64 (which at that point people still thought would be good). One minor detail of the Monterey deal was that SCO…

The original SCO wasn't particularly cool either, I worked for a competing company that got called in to help them when they couldn't get get the 286 MMU to work, the deal was that we would get a copy of the resulting code, we got it working but in the end got zilch

I can’t speak to what it was like to work with them from the outside, but (at least when I was there) they definitely had a fun internal culture.

Small enough to not have a “big company” feel, yet profitable enough (at that time) to not have “startup panic”. Plus lots of cool hackers, including some of the original authors of UNIX, who had joined through the AT&T deal.

Re: The SCO lawsuit, 20 years later

#243

Post by robennals »

noisy_boy wrote: post #218
cjensen wrote: post #215

Earlier quoted context omitted.

SCO the "cool UNIX vendor" was not the company that sued. In 2001, the cool UNIX vendor was struggling and sold its UNIX business to Caldera. Caldera renamed itself "the SCO Group" and filed the lawsuit. [1] [1] https://en.wikipedia.org/wiki/Santa_Cruz_Operation

I remember seeing original SCO unix in our server room in 1998 - they were a legitimate player then but I also remember seeing all new orders going for SunOS (and later for Sun Solaris).

Internally, SCO used to joke that they were “the most popular operating system you haven’t heard of”.

It was (at that time) the best Unix on cheap x86 hardware, so it was deployed everywhere. In gas station pumps, in cash registers, in ATMs, in back office databases. I think SCO made up the majority of Oracle database instances.

Most people interacted with SCO code on a daily basis but didn’t know.

Of course they rapidly lost the x86 UNIX crown to Linux. At the time I was there SCO could still do a lot of stuff well that Linux couldn’t, but the advantages were rapidly going down and the writing was on the wall.

Re: The SCO lawsuit, 20 years later

#244

Post by surge »

MereInterest wrote: post #163
surge wrote: post #139

Earlier quoted context omitted.

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.

The problem with needing “everything to work no matter what” is that it just doesn’t exist. The type of stability that RHEL provides is conditional on never using third-party libraries. RHEL backpoets security fixes to packages that it provides, but you’re on your own for anything else. For example, RHEL 7 was released in 2014, has production support for another year, and extended support until 2026. As libraries are…

That level of backwards compatiblity with legacy versions exists on other platforms (Windows, z/OS, AIX), especially those implemented in enterprise environments. If I have a Windows app written in Win32 API, it'll run on Windows 11 on 64-bit architecture. That's what companies want. That's how Linux became viable for those customers. Even Edge has an IE mode because that's what enterprise environments need, support for older libraries and APIs. I won't deny RHEL was higher technical debt for sure, but that was the trade off, because that's what enterprises prioritized, support, stability, and knowledge that an update during their monthly patch cycle and change window for rebooting the server won't break the business applications they rely on for fundamental operations, at least not on the same major release version.

RHEL was never supposed to be the latest, I think even a every new major release they'd be on a kernel and library version that was 2 years behind but had been through its paces. IOW, it was a feature not a bug, and its what companies were paying for (their customers were boring legacy Fortune 500s not startups). As a business model, it was solid, and the most successful in the commercial market by far because it catered to their customers needs, even if they're not our own, even Ubuntu Server took pages from their book.

Re: The SCO lawsuit, 20 years later

#245

Post by surge »

ethbr0 wrote: post #200
surge wrote: post #137

Earlier quoted context omitted.

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…

My Redhat experience always seemed to devolve into "this package that I want has a dependency that isn't listed yet..." (cue 2 hours of recursively and manually tracking down dependencies on the early web). But I was a lot younger and didn't know a lot of what I do now, so was probably doing everything RPM wrong.

I had the dependency spiral issue on every distro (I played with quite a few), compiling with something like Gentoo made it worse. RPM Forge existed, I think the Linux experience in general was bad back then, and RedHat actually was one of the least problematic. Until Ubuntu, it was the easiest and most approachable to use for novices.

Re: The SCO lawsuit, 20 years later

#246

Post by surge »

worik wrote: post #208
surge wrote: post #137

Earlier quoted context omitted.

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…

I think you are exaggerating. Computers of all stripes are more reliable now. In the late nineties I ran apache + mod-perl built from source. We had a lot of problems, but I cannot recall ever having a problem with those two. We tested every update, of course, but it was not a huge burden.

If you were running Apache fine, I think Linux in the late 90s was the work horse of web servers. That might have been the one thing that just worked. I was using it as a workstation and for everything else. Try getting your window manager to work with your Xserver and graphics card. Upgrade a package that needs a newer packlage, that needs another package that no one has built yet, so now you need to custom compile the library, but if it replaces the existing library it breaks something else that relies on the older library.

That's inbetween figuring out how to get things to compile and the dependencies of dependencies, etc.

I got Linux to work, but it was also a love hate relationship, when I got it working, it worked and worked for months, but I had almost a PTSD reaction when it was time to upgrade anything, I knew what was coming and I was afraid.

Re: The SCO lawsuit, 20 years later

#247

Post by ok123456 »

ethbr0 wrote: post #200
surge wrote: post #137

Earlier quoted context omitted.

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…

My Redhat experience always seemed to devolve into "this package that I want has a dependency that isn't listed yet..." (cue 2 hours of recursively and manually tracking down dependencies on the early web). But I was a lot younger and didn't know a lot of what I do now, so was probably doing everything RPM wrong.

Using redhat before yum, meant visiting rpmfind.net and manually collecting what you needed.

In some ways, RHEL is still like that, because popular packages are usually a major version or two behind if they're even there at all. You have to hunt down an EPEL that has whatever you need.

Re: The SCO lawsuit, 20 years later

#248

Post by elkos »

talkingtab wrote: post #180

Personally, the most interesting thing about that event was groklaw. ( http://www.groklaw.net/index.php ) It is hard now to reconstruct the experience of having a website dedicated to something I cared passionately about. Groklaw is an example, in my opinion, of what the internet could be, should be and isn't. A website that provided a community for people with a common cause. I don't mean to diminish the importance…

I really miss Groklaw. Sometimes I wish they could come back, the insight of the author and the community around the site was really valuable and allowed me to have a more informed opinion.

Re: The SCO lawsuit, 20 years later

#249

Post by kkielhofner »

sgc wrote: post #154
kkielhofner wrote: post #145

Earlier quoted context omitted.

As CTO I generally tracked software and applicable use license(s) across the entire codebase. My internal sheet more or less lined up with their results - with the notable exception being my project I referenced. FWIR it was something like 400 entries and I’d put it at roughly 95% accurate on this anecdotal rough estimate.

That is surprisingly bad. I would expect it to be some sigma level of accuracy for the money they charge. Perhaps I misunderstand the problem.

This was over 10 years ago. Not only is my memory fuzzy I would imagine (hope) it's gotten significantly better since then.

Per usual for these kinds of things what you're really paying for is the name and "trust" associated with it.

In the grand scheme of things when you're raising tens of millions - billions of dollars the cost of these tools in terms of total services across due diligence is nothing. Additionally, tools like this are selected by the investor and you don't really have much say in the matter.

Basically, you use "expensive" $SOLUTION the investor prefers, check the box, and move on to the hundreds/thousands of other due diligence items in the transaction.

Where it gets really interesting (to me) are cases with super aggressive investors like Tiger Global and anything in bubble (crypto) where close times are days and almost no due diligence is performed.

As one example I doubt anyone used these kinds of tools at FTX...

Re: The SCO lawsuit, 20 years later

#250

Post by jasoneckert »

jzb wrote: post #223
sgt wrote: post #219

Earlier quoted context omitted.

In my mind, I associate Caldera with that Linux distribution that was pretty OK, but nothing to write home about.

Caldera’s big trick IIRC was its installer. You could play Tetris in the installer while it copied packages onto the hard drive. It was also a better installer for new users than a lot of others. I think the desktop experience was pretty polished for the time, too.

They also had Minesweeper too (I can't remember if it was a choice, or they had two distro flavors - one with Tetris and one with Minesweeper).
Post reply on HN