DaemonForums  

Go Back   DaemonForums > NetBSD > NetBSD General

NetBSD General Other questions regarding NetBSD which do not fit in any of the categories below.

Reply
 
Thread Tools Display Modes
  #1   (View Single Post)  
Old 23rd May 2009
Meta_Ridley Meta_Ridley is offline
OFM Addict
 
Join Date: May 2008
Posts: 21
Default Thoughts on NetBSD 5.0

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?

Those are my thoughts. What are yours?
Reply With Quote
  #2   (View Single Post)  
Old 23rd May 2009
Oko's Avatar
Oko Oko is offline
Rc.conf Instructor
 
Join Date: May 2008
Location: Kosovo, Serbia
Posts: 1,102
Default

Quote:
Originally Posted by Meta_Ridley View Post
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?
That is actually a very good decision. You can Google why.

Last edited by Oko; 23rd May 2009 at 03:14 PM.
Reply With Quote
  #3   (View Single Post)  
Old 23rd May 2009
vermaden's Avatar
vermaden vermaden is offline
Administrator
 
Join Date: Apr 2008
Location: pl_PL.lodz
Posts: 1,056
Default

Quote:
Originally Posted by Meta_Ridley View Post
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 View Post
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 View Post
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 Torvalds

Linux 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: links resources deviantart spreadbsd
Reply With Quote
  #4   (View Single Post)  
Old 23rd May 2009
ephemera's Avatar
ephemera ephemera is offline
Knuth's homeboy
 
Join Date: Apr 2008
Posts: 537
Default

I have used an 386 and its unbearably slow (assuming you have enough memory to run a recent bsd on it, the one i used had just 1MB ).
Reply With Quote
  #5   (View Single Post)  
Old 23rd May 2009
TerryP's Avatar
TerryP TerryP is offline
Arp Constable
 
Join Date: May 2008
Location: USofA
Posts: 1,547
Default

Heck there are consumer routers with more get up & go, then PCs built for the Intel 80386 ever had!

It should be a mile stone, not a wake ;-)
__________________
My Journal

Thou shalt check the array bounds of all strings (indeed, all arrays), for surely where thou typest ``foo'' someone someday shall type ``supercalifragilisticexpialidocious''.
Reply With Quote
  #6   (View Single Post)  
Old 23rd May 2009
BSDfan666 BSDfan666 is offline
Real Name: N/A, this is the interweb.
Banned
 
Join Date: Apr 2008
Location: Ontario, Canada
Posts: 2,223
Default

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.

All 3 of the major projects no longer support the 386, I say it's a good thing..
Reply With Quote
  #7   (View Single Post)  
Old 23rd May 2009
Oko's Avatar
Oko Oko is offline
Rc.conf Instructor
 
Join Date: May 2008
Location: Kosovo, Serbia
Posts: 1,102
Default

Quote:
Originally Posted by BSDfan666 View Post
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.
Reply With Quote
  #8   (View Single Post)  
Old 23rd May 2009
Meta_Ridley Meta_Ridley is offline
OFM Addict
 
Join Date: May 2008
Posts: 21
Default

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.
Reply With Quote
  #9   (View Single Post)  
Old 24th May 2009
TerryP's Avatar
TerryP TerryP is offline
Arp Constable
 
Join Date: May 2008
Location: USofA
Posts: 1,547
Default

Using a unix based OS on a machine with a 33Mhz i386 / 4MB of RAM... I can see that. Actually want to do something useful on it... best have a lot of swap!

Hack the /usr file system on my OpenBSD machine is over 700M in its own right.)
__________________
My Journal

Thou shalt check the array bounds of all strings (indeed, all arrays), for surely where thou typest ``foo'' someone someday shall type ``supercalifragilisticexpialidocious''.
Reply With Quote
Old 24th May 2009
Mr-Biscuit Mr-Biscuit is offline
Banned
 
Join Date: May 2008
Posts: 272
Default

My experience has only been with jibbed.
It's nice.
Reply With Quote
Old 24th May 2009
Oko's Avatar
Oko Oko is offline
Rc.conf Instructor
 
Join Date: May 2008
Location: Kosovo, Serbia
Posts: 1,102
Default

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.
Reply With Quote
Old 24th May 2009
vermaden's Avatar
vermaden vermaden is offline
Administrator
 
Join Date: Apr 2008
Location: pl_PL.lodz
Posts: 1,056
Default

Quote:
Originally Posted by Oko View Post
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 View Post
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 View Post
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 Torvalds

Linux 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: links resources deviantart spreadbsd
Reply With Quote
Old 24th May 2009
Oko's Avatar
Oko Oko is offline
Rc.conf Instructor
 
Join Date: May 2008
Location: Kosovo, Serbia
Posts: 1,102
Default

Quote:
Originally Posted by vermaden View Post

Maybe I will contact OSS4 developers why then do not continus any work for NetBSD.
Actually I did You can read the answer.

http://www.4front-tech.com/forum/viewtopic.php?t=3133

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.

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.
Reply With Quote
Old 25th May 2009
vermaden's Avatar
vermaden vermaden is offline
Administrator
 
Join Date: Apr 2008
Location: pl_PL.lodz
Posts: 1,056
Default

Quote:
Originally Posted by Oko View Post
Actually I did You can read the answer.

http://www.4front-tech.com/forum/viewtopic.php?t=3133

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 View Post
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 Torvalds

Linux 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: links resources deviantart spreadbsd
Reply With Quote
Old 25th May 2009
BSDfan666 BSDfan666 is offline
Real Name: N/A, this is the interweb.
Banned
 
Join Date: Apr 2008
Location: Ontario, Canada
Posts: 2,223
Default

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.

http://marc.info/?l=openbsd-misc&m=124321644617877&w=2

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 View Post
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.
Reply With Quote
Old 25th May 2009
Oko's Avatar
Oko Oko is offline
Rc.conf Instructor
 
Join Date: May 2008
Location: Kosovo, Serbia
Posts: 1,102
Default

Quote:
Originally Posted by BSDfan666 View Post
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.

http://marc.info/?l=openbsd-misc&m=124321644617877&w=2

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

http://marc.info/?l=openbsd-misc&m=124323616306697&w=2

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.

Last edited by Oko; 25th May 2009 at 07:11 PM.
Reply With Quote
Old 25th May 2009
vermaden's Avatar
vermaden vermaden is offline
Administrator
 
Join Date: Apr 2008
Location: pl_PL.lodz
Posts: 1,056
Default

Quote:
Originally Posted by BSDfan666 View Post
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.

http://marc.info/?l=openbsd-misc&m=124321644617877&w=2

Quote:
Originally Posted by BSDfan666 View Post
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 View Post
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 Torvalds

Linux 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: links resources deviantart spreadbsd
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
ZFS thoughts and questions mtx FreeBSD General 3 28th November 2008 07:27 AM
NFS your thoughts rex FreeBSD General 4 24th September 2008 03:32 AM
FreeBSD as a desktop - Thoughts.. harisman FreeBSD General 62 6th September 2008 01:27 AM
Your Thoughts on WINE (Codeweaver products incl.) ninjatux General software and network 5 21st July 2008 11:56 PM
MTA thoughts cajunman4life General software and network 37 8th June 2008 07:37 PM


All times are GMT. The time now is 09:18 AM.


Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Content copyright © 2007-2010, the authors
Daemon image copyright ©1988, Marshall Kirk McKusick