Live data from Hacker News

OpenBSD was right to disable hyperthreading [video]

youtube.com

11–20 of 284 posts

Re: OpenBSD was right to disable hyperthreading [video]

#11
post #5

Earlier quoted context omitted.

The BSD troubles rather than wars: it wasn't a spat between BSD distros, it was BSDi and UC (Berkeley) getting sued by USL. It cast a long shadow over the viability of Berkeley at the height of the UNIX wars, and just as Linux was appearing as a completely independent and unencumbered UNIX supported by the maturation & advocacy of GNU and the FSF.

In retrospect, it's probably a good thing. BSD splinters have largely become incompatible with each other, whereas Linux distro splinters have (largely) remained compatible due to licensing and cultural differences. We probably would have had BSD wars for real not long after, if it had become popular. To some extent, this is by design, as there's no culture or ethos that pushes people back together.

On the other hand, if BSDs had been more popular, one of these splinters might have dominated the market as much as Linux does, due to the many positive feedback effects of being the most successful free OS.

Re: OpenBSD was right to disable hyperthreading [video]

#12
post #8
post #2

Why aren’t the *BSD operating systems more popular in the server and workstation spaces?

Because the people who pay folks to work on systems dont like to pay enough money to get that level of talent.

> Because the people who pay folks to work on systems dont like to pay enough money to get that level of talent.

People like Google can't pay enough? Do all the BSD developers work as front-end quants or something? How are they all earning so much that nobody can afford them?

Re: OpenBSD was right to disable hyperthreading [video]

#13
post #6
post #2

Why aren’t the *BSD operating systems more popular in the server and workstation spaces?

IIRC Netflix is using FreeBSD. Outside the server scope, OSX is mainly BSD with a different kernel. FreeNAS is based on FreeBSD too.

It also has a bit of an outdated userland, imported from FreeBSD/NetBSD years ago.

Re: OpenBSD was right to disable hyperthreading [video]

#15
Two of the three (current) top-level replies compare BSDs to Linux in general, but that really has nothing to do with whether you disable HT. Using Linux should not have stopped anyone from listening to Theo and disabling HT months ago. Your security authorities don't have to be your kernel developers.

Re: OpenBSD was right to disable hyperthreading [video]

#16

Perhaps someone might know better than me: why is hyperthreading necessarily bad? Can't you just keep it on and give your tenants cores with affinity? For example, some tenant wants two cores, you give them two vcores on the same core; some tenant wants four cores, you give them two vcores over two, etc.

It's not necessarily bad, but it is not secure by default. That's why it ships turned off.

Re: OpenBSD was right to disable hyperthreading [video]

#17
post #8

Earlier quoted context omitted.

Because the people who pay folks to work on systems dont like to pay enough money to get that level of talent.

> Because the people who pay folks to work on systems dont like to pay enough money to get that level of talent. People like Google can't pay enough? Do all the BSD developers work as front-end quants or something? How are they all earning so much that nobody can afford them?

Google doesn't use BSD. (to my knowledge)

Yahoo! did but they also had BSD developers on the payroll.

Any Silicon Valley company will pay enough but that is why when you leave Silicon Valley or a big tech hub everything is windows. The pay attracts the talent.

Re: OpenBSD was right to disable hyperthreading [video]

#18
post #5

Earlier quoted context omitted.

The BSD troubles rather than wars: it wasn't a spat between BSD distros, it was BSDi and UC (Berkeley) getting sued by USL. It cast a long shadow over the viability of Berkeley at the height of the UNIX wars, and just as Linux was appearing as a completely independent and unencumbered UNIX supported by the maturation & advocacy of GNU and the FSF.

In retrospect, it's probably a good thing. BSD splinters have largely become incompatible with each other, whereas Linux distro splinters have (largely) remained compatible due to licensing and cultural differences. We probably would have had BSD wars for real not long after, if it had become popular. To some extent, this is by design, as there's no culture or ethos that pushes people back together.

> whereas Linux distro splinters have (largely) remained compatible due to licensing and cultural differences.

Seems to me this had nothing to do with licensing or culture, but rather that if you wanted your distribution you'd use the upstream kernel and build your own userland with blackjack and hookers and whatever direction you were interested in, so there's some measure of strong relatedness in the kernel everyone shares. You might add a few modules or patches, but few people bother (or need) to fork the kernel itself.

Since BSDs are systems, if you want to go your own way you fork the entire system (that's literally the genesis of both OpenBSD and Dragonfly).

Re: OpenBSD was right to disable hyperthreading [video]

#19
post #6
post #2

Why aren’t the *BSD operating systems more popular in the server and workstation spaces?

IIRC Netflix is using FreeBSD. Outside the server scope, OSX is mainly BSD with a different kernel. FreeNAS is based on FreeBSD too.

They are using FreeBSD for their CDN appliances that they have dotted around the world, everything else runs on Ubuntu out of AWS.

Re: OpenBSD was right to disable hyperthreading [video]

#20

Perhaps someone might know better than me: why is hyperthreading necessarily bad? Can't you just keep it on and give your tenants cores with affinity? For example, some tenant wants two cores, you give them two vcores on the same core; some tenant wants four cores, you give them two vcores over two, etc.

That's mostly fine, but it complicates the scheduler and doesn't necessarily help performance. IIRC hyperthreading performs best when the workload on each thread is different (not taking caches into account), so running threads from the same process on the same core can (although isn't always; I'd hesitate to claim anything concrete here without benchmarks) be detrimental.

OpenBSD devs are likely open to it, but there are other inefficiencies in the kernel like locking that have priority.

Post reply on HN