Since there hasn't been much going on here lately I thought I'd share my thoughts on NetBSD 5.0 and ask others who have used it to do the same.

I like what they've done with puffs and rump. The idea of being able to mount any filesystem in userspace reminds me of Plan 9, and in this case I think it's a good thing. It means that the kernel itself no longer has to support the filesystem, just the userspace programs. Of course, the kernel must have puffs support in it, which the GENERIC kernel does. Being able to mount filesystems in userspace also means that if the filesystem or the code for it doesn't work, the kernel and thus the whole system doesn't go down, just the program that's used to mount the filesystem. This will make using and supporting new filesystems much less risky.

Unfortunately I'm going to get negative from here on out. Probably the biggest annoyance is that not only did they make SMP support the default, but mandatory, at least on the i386 port. I could have lived with the developers making it the default, but making it mandatory means my systems, none of which have more than one processor, have to load the SMP code, which wastes RAM and is a source of potential problems that I shouldn't have to deal with since I'm not running multiprocessor machines. And from what I understand you can't even disable it when building a custom kernel since it's mandatory, as I stated earlier.

The second-biggest annoyance to me is how they made the priority scheduling more Linux-like and made the linux option the default for mounting /proc. For the former, I've had bad experiences trying to nice a program only to have it up its priority, and all the priorities are now in the double digits, and some even reach the triple digits. Why was this necessary? I can forgive making the linux option the default on /proc since it's mainly used for emulating Linux programs, but it does seem to me to be one more little thing to make NetBSD more Linux-like, a direction I don't want it to go in. If I wanted it to, I'd use a Linux distribution as my primary OS.

Also, the removal of 386 support in the i386 port seems to be antithetical to the NetBSD motto "Of course it runs NetBSD." I realize that not many people are running 386s these days, but was it really necessary to remove support for it? Did it really save that much on code that the developers had to remove support for the processor that NetBSD was originally made for?

Also, the removal of 386 support in the i386 port seems to be antithetical to the NetBSD motto "Of course it runs NetBSD." I realize that not many people are running 386s these days, but was it really necessary to remove support for it? Did it really save that much on code that the developers had to remove support for the processor that NetBSD was originally made for?

Unfortunately I'm going to get negative from here on out. Probably the biggest annoyance is that not only did they make SMP support the default, but mandatory, at least on the i386 port. I could have lived with the developers making it the default, but making it mandatory means my systems, none of which have more than one processor, have to load the SMP code, which wastes RAM and is a source of potential problems that I shouldn't have to deal with since I'm not running multiprocessor machines. And from what I understand you can't even disable it when building a custom kernel since it's mandatory, as I stated earlier.

What problems you got from running this SMP setup on your boxes, propably the overhead/memory usage for SMP is so small, that NetBSD team made that decision to simplify code management, only SMP, KISS.

Quote:

Originally Posted by Meta_Ridley

The second-biggest annoyance to me is how they made the priority scheduling more Linux-like and made the linux option the default for mounting /proc. For the former, I've had bad experiences trying to nice a program only to have it up its priority, and all the priorities are now in the double digits, and some even reach the triple digits. Why was this necessary? I can forgive making the linux option the default on /proc since it's mainly used for emulating Linux programs, but it does seem to me to be one more little thing to make NetBSD more Linux-like, a direction I don't want it to go in. If I wanted it to, I'd use a Linux distribution as my primary OS.

About /proc and/or Linux compatibility, IMHO user should be asked at install process (like in FreeBSD) if he wants to use Linux or not.

Quote:

Originally Posted by Meta_Ridley

Also, the removal of 386 support in the i386 port seems to be antithetical to the NetBSD motto "Of course it runs NetBSD." I realize that not many people are running 386s these days, but was it really necessary to remove support for it? Did it really save that much on code that the developers had to remove support for the processor that NetBSD was originally made for?

Please ... who is using 386 these days? FreeBSD dropped that long time ago and NetBSD team did great thing doing that.

About my rants, I currently do not like the audio subsystem, it should be like in FreeBSD and/or OSS4.

__________________religions, worst damnation of mankind"If 386BSD had been available when I started on Linux, Linux would probably never had happened." Linus TorvaldsLinux is not UNIX! Face it! It is not an insult. It is fact: GNU is a recursive acronym for “GNU's Not UNIX”.vermaden's:linksresourcesdeviantartspreadbsd

The i386 is notably different then the later generations of x86, go through the commit logs and see how many i386 kludges were removed.

I still own a couple 486 systems, they're unlikely to remove support for that family any time soon.. some embedded systems still have 486 class processors.

It makes far more sense to support Atari TT or Amiga than i386 (that is about the same time line 1991-1993). If anybody like vintage computing he is far more likely to hate Wintel hardware than to run it.
My favorite machine of that time was Micro VAX 3000 probably because I was studying at the places that were
poor to have Alpha stations and HP Risk stations.

Okay, you've all proved your point on the code for supporting the actual i386. I put it in there more as an illustration of the principle than anything else. Of course I think that anyone who tries to run a modern OS (except for maybe FreeDOS) on a 386 is going to run into problems, and in the end removing the code will probably be for the best.

I just found it to be quite notable and a bit ironic. There's a reason why I mentioned it last. At least it got you guys talking again.

NetBSD used to be really simple (good) OS. How is that XOrg coming along? Is it as good and simple as
XFree86 was? I thought that moving to Xorg was no brainer. I am not so sure anymore. Can you select XOrg during default installation as you could with XFree86 or it is not anymore bundled with the Kernel.

Can anybody give more details about NetBSD audio. I heard lots of people complaining about audio.

Is it possible to compile OSS on NetBSD. OSS used to have a package for NetBSD 31. and also OpenBSD 3.8 but since then they support only FreeBSD.

NetBSD used to be really simple (good) OS. How is that XOrg coming along? Is it as good and simple as
XFree86 was? I thought that moving to Xorg was no brainer. I am not so sure anymore. Can you select XOrg during default installation as you could with XFree86 or it is not anymore bundled with the Kernel.

In 5.0 install you can select between various x11 sets that contain xorg package, it is propably possible to use xfree from pkgsrc, but I have too little knowledge in NetBSD to confirm that.

Quote:

Originally Posted by Oko

Can anybody give more details about NetBSD audio. I heard lots of people complaining about audio.

Its not like OSS @ FreeBSD or like OSS4 with live kernel mixing (at least was when I last checked it), I wasnt able to get sound on my Dell d630 laptop, but I must take little more deep into that problem.

On older hardware the sound worked, but if you have 1 physical channel, then only 1 sound that uses OSS will be playing (no live in kernel audio mixing), but I have also read on some efforts to make it that way.

Quote:

Originally Posted by Oko

Is it possible to compile OSS on NetBSD. OSS used to have a package for NetBSD 31. and also OpenBSD 3.8 but since then they support only FreeBSD.

OSS3.9 package maybe works on NetBSD 3 but it does not work for sure on NetBSD 5.0, I already tried

Maybe I will contact OSS4 developers why then do not continus any work for NetBSD.

__________________religions, worst damnation of mankind"If 386BSD had been available when I started on Linux, Linux would probably never had happened." Linus TorvaldsLinux is not UNIX! Face it! It is not an insult. It is fact: GNU is a recursive acronym for “GNU's Not UNIX”.vermaden's:linksresourcesdeviantartspreadbsd

If I was NetBSD developer that would be probably the fastest way for NetBSD to get serious audio support. The only thing now remaining is to
get a NetBSD developer interested in actual work.

Propably as usual with NetBSD, lack of man power, but they do great job with such small team anyway.

Maybe they already work on their own (prolably ultra light/simple) implementation of live in kernel mixed OSS based on both FreeBSD and/or OSS4, that would be best idea/sollution, but OSS4 worked on OpenSolaris really well for me, default OSS @ FreeBSD even better

Quote:

Originally Posted by Oko

OpenBSD is little bit specific case due to the security consideration but porting OSSv4 has been discussed on misc about a half year ago. Actually, I will check again.

This should not be such serious case IMHO, similar thing happened with kqemu accelration module, while OpenBSD does not support loadable modules, they can link modules before boot, so OSS4 should also work with this IMHO.

__________________religions, worst damnation of mankind"If 386BSD had been available when I started on Linux, Linux would probably never had happened." Linus TorvaldsLinux is not UNIX! Face it! It is not an insult. It is fact: GNU is a recursive acronym for “GNU's Not UNIX”.vermaden's:linksresourcesdeviantartspreadbsd

Jacom Meuser responded to Oko's post on the mailing list, he said that OSSv4 is different from OSSv3.. which is implemented via ossaudio(3).

Having OSSv4 as a port would be problematic, it would have to be distributed as a kernel module.. unfortunately it would conflict with the other audio drivers, so users would have to disable them all prior to using it.. making their kernel unsupported by the OpenBSD developers.

Personally, I don't think a OSSv4 port is needed.. the current audio framework and drivers work well, a bonus is that they've been audited along with the rest of the code base.. I'm really excited about the new sndio API, most of the major ports have already been modified to utilize it now, so this fulfils the mixing feature that many people mistakenly believe should be done in the kernel.

Quote:

Originally Posted by vermaden

This should not be such serious case IMHO, similar thing happened with kqemu accelration module, while OpenBSD does not support loadable modules, they can link modules before boot, so OSS4 should also work with this IMHO.

OpenBSD supports the LKM framework, kernel modules can be loaded.. securelevel must be <= 0 for it to work though, not sure what you mean about "linking modules before boot", it surely does no such thing.. but as said above, OSSv4 would conflict with the current audio drivers.

Jacom Meuser responded to Oko's post on the mailing list, he said that OSSv4 is different from OSSv3.. which is implemented via ossaudio(3).

Having OSSv4 as a port would be problematic, it would have to be distributed as a kernel module.. unfortunately it would conflict with the other audio drivers, so users would have to disable them all prior to using it.. making their kernel unsupported by the OpenBSD developers.

Personally, I don't think a OSSv4 port is needed.. the current audio framework and drivers work well, a bonus is that they've been audited along with the rest of the code base.. I'm really excited about the new sndio API, most of the major ports have already been modified to utilize it now, so this fulfils the mixing feature that many people mistakenly believe should be done in the kernel.

OpenBSD supports the LKM framework, kernel modules can be loaded.. securelevel must be <= 0 for it to work though, not sure what you mean about "linking modules before boot", it surely does no such thing.. but as said above, OSSv4 would conflict with the current audio drivers.

Even more interesting answer given by another developer
Alexander Ratchov

Personally, I also never thought porting OSSv4 was needed for OpenBSD. I thought we could benefit from few
extra driver but I do not think so any more based on Alexder's answer.

Same parts of the Jake's answer to me are interesting for NetBSD users. He talks little bit about your audio. Based upon his answer I believe that approach taken by NetBSD team to rewrite kernel support for audio for 6.0 is correct. Unfortunately he also noticed that NetBSD didn't bother even to look at his patches for NetBSD. So you guys have to look at mirror and not to blame anybody else for audio support for NetBSD.

Jacom Meuser responded to Oko's post on the mailing list, he said that OSSv4 is different from OSSv3.. which is implemented via ossaudio(3).

Having OSSv4 as a port would be problematic, it would have to be distributed as a kernel module.. unfortunately it would conflict with the other audio drivers, so users would have to disable them all prior to using it.. making their kernel unsupported by the OpenBSD developers.

Same on FreeBSD/Solaris, first disable built in audio framework, then enable OSS4.

Personally, I don't think a OSSv4 port is needed.. the current audio framework and drivers work well, a bonus is that they've been audited along with the rest of the code base.. I'm really excited about the new sndio API, most of the major ports have already been modified to utilize it now, so this fulfils the mixing feature that many people mistakenly believe should be done in the kernel.

I havent been following OpenBSD changes for longer time so if you say that it is ok, then its ok

Quote:

Originally Posted by BSDfan666

OpenBSD supports the LKM framework, kernel modules can be loaded.. securelevel must be <= 0 for it to work though, not sure what you mean about "linking modules before boot", it surely does no such thing.. but as said above, OSSv4 would conflict with the current audio drivers.

Good to know that it supports LKM, I have always heard that it does not, about linking in loader, as it supports LKM, modules were propably just loaded at boot, then securelevel++ and propably that is what some person seen, some modules loading before boot and described it as that, I must admin that I follow OpenBSD development very little, so thanks for clarifying that.

__________________religions, worst damnation of mankind"If 386BSD had been available when I started on Linux, Linux would probably never had happened." Linus TorvaldsLinux is not UNIX! Face it! It is not an insult. It is fact: GNU is a recursive acronym for “GNU's Not UNIX”.vermaden's:linksresourcesdeviantartspreadbsd