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

NetBSD 8.0 released

netbsd.org

Post reply on HN
Print view View original

51–60 of 120 posts

Re: NetBSD 8.0 released

#51

Post by floatboth »

Keyframe wrote: post #40
bch wrote: post #31

Earlier quoted context omitted.

Perceived balance of Unix tradition, progressiveness and sane engineeering/community. The base build system (build.sh)[0] which is essentially Makefiles is absolutely beautiful to work with, ditto for pkgsrc[1]. They’re “progressive” enough to include dtrace[2], work on neat security[3], and kernel models[4][5], but have eschewed modern Linux-isms like ip(1), systemd. Of BSD v Linux, my heart is definitely with the m…

Can you go a bit more in detail why Net vs Free? I would LOVE to replace Linux (Fedora) with one of the BSD's. It's philosophy and everything basically suits me far more than anything else, but I need CUDA, I need Nvidia drivers, I like to play with ML, I need few more things like that which makes it a no go as far as I'm aware.

nvidia makes official drivers for FreeBSD, but last time I checked they did not include CUDA.

Re: NetBSD 8.0 released

#52

Post by peatmoss »

Keyframe wrote: post #40
bch wrote: post #31

Earlier quoted context omitted.

Perceived balance of Unix tradition, progressiveness and sane engineeering/community. The base build system (build.sh)[0] which is essentially Makefiles is absolutely beautiful to work with, ditto for pkgsrc[1]. They’re “progressive” enough to include dtrace[2], work on neat security[3], and kernel models[4][5], but have eschewed modern Linux-isms like ip(1), systemd. Of BSD v Linux, my heart is definitely with the m…

Can you go a bit more in detail why Net vs Free? I would LOVE to replace Linux (Fedora) with one of the BSD's. It's philosophy and everything basically suits me far more than anything else, but I need CUDA, I need Nvidia drivers, I like to play with ML, I need few more things like that which makes it a no go as far as I'm aware.

You probably have a herculean challenge ahead with the Nvidia / CUDA stuff. A couple years ago I got an R stack up and going on OpenBSD, and that took some deep dives to get all my packages working. It was rewarding and worked well, but it wasn’t something I’d do under deadline.

NVidia on the other hand seems like a far harder problem than needing to patch some C code here and there. NVidia make the drivers that they make. AMD has been more open source friendly these days, which is good if you want 3D graphics, but doesn’t solve the CUDA issue.

Re: NetBSD 8.0 released

#53

Post by cpeterso »

PeCaN wrote: post #3
avar wrote: post #2

> USB stack rework, USB3 support added. I didn't realize NetBSD was that far behind on some basic features like USB support. "The Linux kernel mainline contains support for USB 3.0 since version 2.6.31, which was released in September 2009"[1]. "FreeBSD supports USB 3.0 since version 8.2, which was released in February 2011.". So they're getting USB 3.0 almost 10 years after it was released for Linux. 1. https://en.w…

Most of the machines NetBSD runs on don't have USB 3 ports.

But is that a cause or effect of NetBSD not supporting USB3?

Re: NetBSD 8.0 released

#54

Post by cpeterso »

avar wrote: post #2

> USB stack rework, USB3 support added. I didn't realize NetBSD was that far behind on some basic features like USB support. "The Linux kernel mainline contains support for USB 3.0 since version 2.6.31, which was released in September 2009"[1]. "FreeBSD supports USB 3.0 since version 8.2, which was released in February 2011.". So they're getting USB 3.0 almost 10 years after it was released for Linux. 1. https://en.w…

Playing armchair software architect here, I wish NetBSD and FreeBSD would join forces. The NetBSD developers could bring their portable architecture to FreeBSD's more featureful kernel and userland. What other value does NetBSD have over FreeBSD besides portability?

IIUC, macOS uses NetBSD's userland though it has FreeBSD bits in its XNU kernel, so there must be benefits to NetBSD beyond its portability that I am just not aware of. :)

Re: NetBSD 8.0 released

#55

Post by bitofhope »

bch wrote: post #35
bch wrote: post #31

Earlier quoted context omitted.

Perceived balance of Unix tradition, progressiveness and sane engineeering/community. The base build system (build.sh)[0] which is essentially Makefiles is absolutely beautiful to work with, ditto for pkgsrc[1]. They’re “progressive” enough to include dtrace[2], work on neat security[3], and kernel models[4][5], but have eschewed modern Linux-isms like ip(1), systemd. Of BSD v Linux, my heart is definitely with the m…

Additionally, it’s not windows, not MacOS, and not Linux. It’s difficult to escape those in day-to-day computing, so my daily driver (thinkpad laptop) is slightly different on purpose, the idea being that, to a degree, everything I do is necessarily very “conscious”. What I mean is that nothing works automatically because I’m part of a vast majority. Where I run into friction, I try to take note and keep this in mind…

I also run NetBSD (mostly on servers, but occasionally PCs as well). I can relate to this. Difference is good; it helps challenge assumptions. Running different operating systems is good for the same reason as testing websites on different browsers is, or having things tested by disabled people for accessibility, or visiting foreign countries and learning about different cultures.

One of my NetBSD machines is an UltraSPARC box. I've heard both NetBSD and OpenBSD devs say it's one of their favourite platforms, because being a big-endian 64 bit machine, it helps discover many false assumptions made in low level code.

Re: NetBSD 8.0 released

#56

Post by rjsw »

dfox wrote: post #50

PaX support on pmax? There is only one reaction I have for that: why? (With "because we can" probably being the reason) [Edit: landisk platform are various NAS boxes, so nothing of comparable obsolescence as pmax]

The pmax is supported by several emulators, if you want to develop PaX for MIPS then it is as good a starting point as anything else.

The EdgeRouter devices are MIPS and people are still using Loongson laptops.

Re: NetBSD 8.0 released

#57

Post by bch »

bitofhope wrote: post #55
bch wrote: post #35

Earlier quoted context omitted.

Additionally, it’s not windows, not MacOS, and not Linux. It’s difficult to escape those in day-to-day computing, so my daily driver (thinkpad laptop) is slightly different on purpose, the idea being that, to a degree, everything I do is necessarily very “conscious”. What I mean is that nothing works automatically because I’m part of a vast majority. Where I run into friction, I try to take note and keep this in mind…

I also run NetBSD (mostly on servers, but occasionally PCs as well). I can relate to this. Difference is good; it helps challenge assumptions. Running different operating systems is good for the same reason as testing websites on different browsers is, or having things tested by disabled people for accessibility, or visiting foreign countries and learning about different cultures. One of my NetBSD machines is an Ultr…

This is another good point that I think can’t be overstated (running on big-endian or otherwise non-x86 arch). Support the unconventional and it supports you back. It’s a fun, positive feedback loop.

Re: NetBSD 8.0 released

#58

Post by Fnoord »

cpeterso wrote: post #53
PeCaN wrote: post #3

Earlier quoted context omitted.

Most of the machines NetBSD runs on don't have USB 3 ports.

But is that a cause or effect of NetBSD not supporting USB3?

That was true before USB3 even existed, but USB3 could be part of a greater set of features which suffer from a similar problem.

A domino effect perhaps, or the result of finding a niche?

Re: NetBSD 8.0 released

#59

Post by tarlinian »

zippie wrote: post #4

This release of NetBSD disables eagerfpu on vulnerable FPU’s. Often overlooked while discussing performance impact of context switching; context switching also applies to the FPU. There are two modes in which the OS performs FPU context switching: lazy and eager. “lazy” FPU context switching leaves the previous context on the FPU until a different context gives it a set of instructions. This saves an unload on the FP…

Lazy FPU state restoration almost never makes sense on modern CPUs (regardless of security issues) because the cost of an interrupt for state restoration is so high and because "FPU" registers are used for a lot more than just FP calculations these days.
Post reply on HN