Live data from Hacker News

Announcing NetBSD 7.0

blog.netbsd.org

11–20 of 26 posts

Re: Announcing NetBSD 7.0

#11
post #9

Earlier quoted context omitted.

I am, and love it. It's not without flaws, but it's compelling enough that I live with its shortcomings. What do I like ? 1) One codebase that supports 57 targets. This code is well exercised. 2) Nice balance of conservatism and progressiveness. Seems well-rooted in tradition, but still progressive/interesting with things like the RUMP kernels[0], Lua kernel interface[1], etc. 3) Plays well with others. It's probably…

OK, what is laptop support like? I may try a test install over the weekend.

I've historically run on Thinkpads.

I've had accelerated Intel integrated gfx, working wireless (Intel Centrino 4965/5000/1000, 1000/2000/6000, 7260/7265/3160), tuneable CPU frequency...

If you've got the luxury of some medium that you can do a test install on, just do it. The install is text-based and really simple, so you shouldn't get hung up there. I assume you'll want X11, so you'll run "X -configure" to generate an xorg.conf. Grab the pkgsrc[0] framework to build 3rd party apps from source, or, use pkg_add(1)[1] (I don't know what's currently available for NetBSD7 in terms of pre-built packages; quick check shows at least some packages are, and they're _probably_ the most popular ones)

#netbsd on freenode.net IRC is your friend, too.

Good luck!

[0] https://www.pkgsrc.org/

[1] http://ftp.netbsd.org/pub/pkgsrc/current/pkgsrc/README-all.h...

Re: Announcing NetBSD 7.0

#12
post #11

Earlier quoted context omitted.

OK, what is laptop support like? I may try a test install over the weekend.

I've historically run on Thinkpads. I've had accelerated Intel integrated gfx, working wireless (Intel Centrino 4965/5000/1000, 1000/2000/6000, 7260/7265/3160), tuneable CPU frequency... If you've got the luxury of some medium that you can do a test install on, just do it. The install is text-based and really simple, so you shouldn't get hung up there. I assume you'll want X11, so you'll run "X -configure" to generat…

Thanks for reply. I shall indeed try an install and see what I can get from pkg_add. OpenBSD works fine with suspend functionality on the X61s.

Re: Announcing NetBSD 7.0

#13
post #11

Earlier quoted context omitted.

I've historically run on Thinkpads. I've had accelerated Intel integrated gfx, working wireless (Intel Centrino 4965/5000/1000, 1000/2000/6000, 7260/7265/3160), tuneable CPU frequency... If you've got the luxury of some medium that you can do a test install on, just do it. The install is text-based and really simple, so you shouldn't get hung up there. I assume you'll want X11, so you'll run "X -configure" to generat…

Thanks for reply. I shall indeed try an install and see what I can get from pkg_add. OpenBSD works fine with suspend functionality on the X61s.

Ya, OpenBSD has done some pretty remarkable work on the laptop front, and I find it interesting, because it's not where I would have guessed they'd be interested. They're leaders in the accelerated gfx and wireless. I'm used to thinking of the project being more focused on hardening applications. Certainly NetBSD has benefited from the work done in Open, by way of the famous *BSD cross-pollination.

I hope you enjoy Net even a fraction as much as I do.

Re: Announcing NetBSD 7.0

#14
post #5

Congratulations to the NetBSD team! The new blacklistd sounds interesting, are the plans to make it available on other operating system as well? Is anyone using NetBSD on a "Orange Pi" board (AllWinner A20, it's mentioned in the release notes so I guess it will work)? What about the "Orange Pi Plus" (AllWinner H3)? These boards offer a lot of performance for the buck.

The Orange Pi Plus isn't supported.

Re: Announcing NetBSD 7.0

#16
I'm not sure if I understand well the "rump kernel"/"anykernel" idea as implemented in NetBSD. Could anybody please help me with that - specifically, how this differs from a microkernel?

My current idea is that I can take the current NetBSD kernel and:

a) for some (any? or only some?) hardware subsystems, ask the kernel (by some switch/config? where?) to run drivers in userspace, in "microkernel-like" way (and thus they reboot transparently in case of failure/bug/crash?), at some performance cost;

b) compile out/disable (? by some preprocessor directive?) some subsystems of the kernel, so that I get a "smaller" kernel e.g. for embedded machines which don't have video-card/GPU hardware;

and probably also combine the both above approaches together - i.e. build a reduced kernel like in (b), and then optionally run any missing subsystems/drivers like in (a).

Is that correct? Or am I wrong?

Re: Announcing NetBSD 7.0

#17
post #9

Anyone here use NetBSD? If so, what are your thoughts? Lack of USB 3.0 support is a turn-off for me... Will probably go with OpenBSD instead.

I am, and love it. It's not without flaws, but it's compelling enough that I live with its shortcomings. What do I like ? 1) One codebase that supports 57 targets. This code is well exercised. 2) Nice balance of conservatism and progressiveness. Seems well-rooted in tradition, but still progressive/interesting with things like the RUMP kernels[0], Lua kernel interface[1], etc. 3) Plays well with others. It's probably…

Thanks for the informative reply. One thing I don't quite know: what is the package ecosystem like? Are packages generally up to date? Do people usually install from source, or use binaries?

Re: Announcing NetBSD 7.0

#18
post #13

Earlier quoted context omitted.

Thanks for reply. I shall indeed try an install and see what I can get from pkg_add. OpenBSD works fine with suspend functionality on the X61s.

Ya, OpenBSD has done some pretty remarkable work on the laptop front, and I find it interesting, because it's not where I would have guessed they'd be interested. They're leaders in the accelerated gfx and wireless. I'm used to thinking of the project being more focused on hardening applications. Certainly NetBSD has benefited from the work done in Open, by way of the famous *BSD cross-pollination. I hope you enjoy N…

  > Ya, OpenBSD has done some pretty remarkable work on the
  > laptop front, and I find it interesting, because it's not
  > where I would have guessed they'd be interested.
My guess is this stems from the very strong dogfooding culture the OpenBSD devs seem to have. If most/all of them are running OpenBSD on their main systems, and some subset of those folks use laptops as their main systems, then I am sure they are motivated to make it not a shit experience.

Re: Announcing NetBSD 7.0

#19
post #16

I'm not sure if I understand well the "rump kernel"/"anykernel" idea as implemented in NetBSD. Could anybody please help me with that - specifically, how this differs from a microkernel? My current idea is that I can take the current NetBSD kernel and: a) for some (any? or only some?) hardware subsystems, ask the kernel (by some switch/config? where?) to run drivers in userspace, in "microkernel-like" way (and thus t…

"a" is sort of orthogonal to rump kernels, but yes, you can run at least file system drivers transparently as userspace servers (just give -o rump to mount(8)). I've also run a USB modem driver as a userspace server, in the "the kernel I'm running doesn't contain support, but a future kernel revision has" fashion.

For "b", rump kernels don't support "compiling out". Rather, the idea is to "link in" only what you need, as in "don't need file systems in that particular application? well don't link in VFS then".

I'm not sure if you're right or wrong, but maybe the rump kernel FAQ at http://wiki.rumpkernel.org/Info:-FAQ will straighten your thoughts. In the regrettable case that it doesn't, you can always suggestion additional questions.

Re: Announcing NetBSD 7.0

#20
post #16

I'm not sure if I understand well the "rump kernel"/"anykernel" idea as implemented in NetBSD. Could anybody please help me with that - specifically, how this differs from a microkernel? My current idea is that I can take the current NetBSD kernel and: a) for some (any? or only some?) hardware subsystems, ask the kernel (by some switch/config? where?) to run drivers in userspace, in "microkernel-like" way (and thus t…

There is a difference between what is possible to do with rump kernels and what NetBSD is currently doing with them. The basic point is to be able to use the same code in different contexts, so in theory you could use rump kernels in implementing a microkernel. However, AFAIK NetBSD currently uses it for (optionally) running filesystems in userland (so you can mount potentially corrupted file systems without crashing the kernel) and for testing. Your (b) is a separate thing that has always been possible in NetBSD (there is also loadable kernel module support). More things could be made to work as userland drivers easily but could still require glue to make it actually work. I don't understand the details but there are multiple ways to make the glue and it can be easier if you are trying to get NetBSD drivers to run in NetBSD userland.

You can also use rump kernels to make an application that runs directly on Xen, KVM, or hardware or that e.g. uses NetBSD file system code on Linux (or Cygwin) userland. Much of this still need some work to do what you want, but less than writing the drivers from scratch, much less maintining them. rumpkernel.org is starting to have packages for some applications. This doesn't require otherwise using NetBSD.

Post reply on HN