Slashdot Mirror

Remember that not everyone has an "OSS at any cost!" mentality. Some people use Linux for pragmatic reasons, not for ideological ones.

You're exactly correct. I won't use closed software unless absolutely unavoidable because it's the least pragmatic solution. When you don't "own" the code running on your system, you're at the mercy of someone else.

I had a FreeBSD desktop with a GeForce 4 AGP card. Just before the buffer overflow vulnerability was found that made it possible to crack a display using the closed NVidia drivers just by displaying an appropriately-formatted image, NVidia dropped support for the GeForce 4 series from their new drivers. They also announced that the vulnerability was fixed in the new drivers but that the old ones were EOLed and unsupported. The old drivers didn't support the currently released version of FreeBSD that I was using, and the new ones didn't support my graphics card. Furthermore, I couldn't find a new AGP card that would work on the motherboard I had at the time, and the rest of my hardware was a couple of years behind the then-modern stuff on Newegg.

In my opinion, having to choose between living with a known vulnerability that actually affects you and paying to replace your entire system, from graphics card to motherboard to CPU to RAM, is pretty freaking impractical. I would've been happy to have the option of switching to a working FOSS driver, even if the performance was a third of the closed driver's.

Happened to me with an old Nvidia GeForce 4. It was in a light-duty desktop and worked perfectly for what I needed: something I could use to check mail and surf a couple of websites on occasion. The machine was an older AGP system that doubled as my home file and print server. I wouldn't have bothered with it, except the drivers were the ones hit with a critical security vulnerability. They were also deprecated and Nvidia had declared that only the newer drivers would be patched. My options were:

1. Live with a remote root vulnerability,
2. Upgrade my motherboard to something with PCIe, a new CPU, new RAM, and a new graphics card, or
3. Hope the Free drivers were at least minimally functional.

The "practical" choice of using closed drivers would have cost me a few hundred dollars. I'm glad the impractical alternative existed.

Yeah, I eventually upgraded the whole thing anyway. I just didn't want to have to do it that week because Nvidia decided not to bother with me anymore.

Our loaded cost for a Windows machine is cheaper than that for Linux. I'm a die hard linux evangelist, but the numbers don't lie.

Then go here and learn how to create your own system. You can also use such services as this and others in order to stay on top of security vulnerabilities. There is also this site which talks about designing network infrastructure.

You'll need to do some homework, and it might seem daunting at first, but the amount of money you could save surely makes this at least worth thinking about. I can't understand why this unique ability that FOSS gives you (to strike out completely on your own, independent of a vendor) isn't capitalised on by more organisations. There is absolutely no need to pay a Linux vendor a single cent if you don't want to...it is entirely a choice.

There's TEPATCHE for binary updates.http://www.gwolf.org/soft/tepatche/
I don't see Theo and all supporting binary updates. And this, I think, because of the security goal. But I may be wrong. For instance, remember when Debian's servers were cracked (about 1 1/2 year ago, AFAIK)? What if you installed a binary with malicious code?

But in fact, why don't they officially support binary updates? What's the "official" answer on this issue?

At least, that seems like a reasonable motivation. OTOH, system administrators probably will automate their own process of applying patches. There's the XML for vulnerabilities for non-base software (http://www.vuxml.org/openbsd/index.html, also.

Stop acting like such a little drama queen. You mentioned FBSD, which with the ports and this is pretty sweet at tracking software and its vulns.

OpenBSD can suffer from the same problem - packages *do* get fixed when security holes are found, of course, but they're not generally taken as seriously as the base system.

But, of course! Do you /really/ expect Theo de Raadt and the other OpenBSD developers to worry because /you/ installed some looser badly written in C Linux software, full of potential for buffer overflows? This is just just not possible.
You must be a grown up, you must patch for yourself, follow security and ports list, look at http://www.vuxml.org/openbsd/.
OTOH, no other systems has the amount of checks built-in to avoid security disasters.

For binary upgrades you might want to look at:
https://bsdupdates.com/index.php
It's a free service, but I don't know if they do ports.

But freebsd security team just cares about the "core" system packages not about the 13000 ports.

Nice FUD. Of course, one cannot claim that a port will have gone through the same security audit that core stuff has been through. Also, there's an aspect of educating people about some unsafe practices (the OpenBSD crew has written about this here and there).
The ports and packages are reported using VuXML here:

http://www.vuxml.org/freebsd/
http://www.vuxml.org/openbsd/

Here's a suggestion for Debian: separate core and non-core packages.

But freebsd security team just cares about the "core" system packages not about the 13000 ports.

Nice FUD. Of course, one cannot claim that a port will have gone through the same security audit that core stuff has been through. Also, there's an aspect of educating people about some unsafe practices (the OpenBSD crew has written about this here and there).
The ports and packages are reported using VuXML here:

http://www.vuxml.org/freebsd/
http://www.vuxml.org/openbsd/

Here's a suggestion for Debian: separate core and non-core packages.

We can all sleep better now.