One interesting O2 oddity is that the native pixel format is RGBA rather than ARGB (the alpha channel is at the other end of each 32 bit word).
Fixing that flushed out a whole bunch of assumptions in X driver and application code, which helps keep non SGI specific X and application code portable. Interesting to think that a user who only runs x86_64/Linux may be running an app with slightly cleaner code thanks to Michael's work on an ol' SGI O2...
(He has also fixed up and extended the accelerated driver for SGI Indy machines with newport graphics, and written drivers for a bunch of other graphics hardware on sparc, macppc and arm)
Most of the focus in NetBSD is on x86_64/i386 and embedded arm/mips/ppc boxes nowdays, but if you squint a little a small enough embedded box looks *really* similar to an older desktop/server box:) so if people want to maintain support, why not?
Anyway, if you want a *really* slow older box you should be looking at an Atari TT or Vax (and lets just say we're not seeing any burst of new graphics drivers for them:)
The interesting part is not converting across to 64-bit time_t, its providing compatibility so all the previously 32-bit time_t compiled binaries and library keep working (at least until 2038:)
dev_t was converted to 64-bits at the same time (two flag days for the price of one)
It involved versioning every function/system call that uses time_t, struct timeval, struct timespec, struct itimerval, struct itimerspec, struct rusage, struct stat, dev_t, struct ppasswd, struct utmp, struct utmpx, and ensuring the system can read both old and new versions of utmpx etc...
Certain bits of code which were using time_t to hold time offsets rather than absolute values were converted to using a normal 32 bit value (a good example might be anything in space constrained boot blocks)
I expect we'll be seeing a *lot* of patches in pkgsrc as the 64bit time_t application issues are fixed...
It would make a lot of sense to group the priority of support for different architectures. The obvious benefits include:
Users know what level of support to expect from a given port
It helps developers judge when adding a feature which ports should be updated first, and if some of the ports have not been updated whether it should necessarily hold up committing the feature
It indicates which ports are looking for a new champion to take up the cause
I've run firefox on 3.0 (and now 4_BETA) pretty much every day, and the last crash I had would have been a couple of months back (I had a dozen or so MB of XML files open and multiple media playing windows).
One thing to definitely test would be your machine's memory. If you can write a CD or floppy image I would strongly suggest downloading memtest from http://www.memtest.org/ and leaving it running overnight.
There are two architectures which have compiler issues not present on other NetBSD platforms, vax and pc532. In both cases support is fading away in more recent gcc versions, and they continue to be built using gcc 2.9.5 rather than the gcc 4.1.2 used by the rest of the NetBSD platforms (there are a couple of platforms still finishing testing for the transition from 3.3.3 to 4.1.2).
This means all constructs in MI areas of the kernel (and the entire userland) need to keep compatible with gcc 2.9.5 and cannot take full advantage of newer C syntax and features.
So those working on the vax port tend to have to spend a reasonable amount of their time just making sure everything still builds, which reduces their time available for adding features and fixing PRs.
Its unfortunate, but the alternative would be to have the vast majority of NetBSD platforms stuck on an older compiler, which would hardly be very progressive:)
Having said that the VAX port is run and developed actively by some people, so its most likely the install tools and some models which have issues.
So, yes, VAX (and pc532) are at a disadvantage to the other ports, but they are still far from dead, and I would suggest tuning into the next bugathon to push your pet PRs...
Just to make a change from the usual 32/64 bit clique, a NetBSD port to the 36bit PDP10 is underway... http://mail-index.netbsd.org/port-pdp 10/2002/09/19/0000.html
Re:Have the init scripts been fixed yet?
on
NetBSD 1.6 Released
·
· Score: 1
> Different files all doing different things, with
> no connection amongst them. Nothing more fun than
> having 95-99 all in order and needing to insert an
> important function before 97 but after 96.
Agreed, using numbers to order startsup scripts is clumsy and awkward at best, which is why NetBSD's startup scripts use a cleaner method:
rc manpage
Just to remind anyone in that situation (old BIOS which hangs while probing large disks), to check for a BIOS update from the motherboard manufacturer. They are not always available, but frequently they can fix the problem.
Otherwise - I've run NetBSD/i386 on a couple of systems with BIOSes too old to work with larger (60GB) disks. In both cases I was adding additional space to an existing system which had a small enough boot drive, so I was able to disable the other drive in the BIOS and boot from the small drive, then NetBSD would see the large drive and use it without problems. Its quite possible I could have told the BIOS the large drive was smaller, but I needed the systems up quickly (and the one I still have has had the aforementioned BIOS upgrade since, so I can't test:)
I can echo this experience on an hp omnibook 6100, and a friend with his sony - both 1400x1050. Xfree86 4's autodetection is dream compared to earlier versions, and the NetBSD version is setup just right. My SO is quite please to have KDE3 and ogle Just Work on her machine at home so she can watch he DVDs:)
On the server front I've just converted two of the www.formula1.com servers and our firewall across from 1.5.3 to 1.6_BETA and setup complete mirrored filesystems with raidframe. The webservers done remotely without needing access to the console (though velocet were kind enough to daisy chain serial consoles between the machines in case they were needed:)
We still have a few linux servers, but since I started using pkgsrc on them it became a lot easier to administer all the software...
Top of my wishlist would probably be a native 1.3 or 1.4 jvm. I'm running the sun-jdk13 under linux compatability and have to say I've not have a problem with it, but I'd just prefer to have the code native...
I'm watching the open packages work with a lot of interest. I'm responsible for a reasonable sized website (350 million hits a month) on a bunch of Linux boxes (recently added a few BSD:).
About two months ago I switched the linux boxes across to using pkgsrc (The NetBSD packge system). It has enabled me to massively reduce the amount of configuation/build magic required and to easily build on one box of each type and install binary packages across onto the others.
They're mainly apache, with some tomcat/jsp with a postgresql backend, nothing overly complicated, but there are various tweaks here and there and pkgsrc allows me to bring those updates forward without spending too much time on it.
Its also good to know if we get the Solaris boxes someone threatened then the packaging system is all ready to go:)
Right now pkgsrc gives me pretty much everything I want, but its good to see projects like openpackages bringing together even more people to work on a unified package system.
I believe there is an issue with VMWare not implementing the ATA flush cache command, and NetBSD not handling the failure gracefully:
You might want to join the thread on port-i386@netbsd.org (which is related to running NetBSD inside VMware on NetBSD, but I'd imagine the issues are pretty similar)
The person sitting next to me has been running NetBSD 1.5 under VMware on Win2K for a few months without any problems. I'll ask him to boot a 1.5.1 kernel to see if it has any issues...
I'm just getting ready to update our servers here to get that nice NFS and IP checksumming speedup:)
Interesting... you be sure to tell Yahoo and Walnut Creek that their business depends on the weakest link.
I'm sure you're intelligent enough to know that a single test does not give anything more than a rating for those conditions running that software.
Tests like that are a good thing - I'm pretty sure any of the issues raised have made their way to the relevant developers and I'd expect them to be addressed in the next release:)
There was a bug in one of the mac68k scsi drivers, which was fixed soon after the release in current and pulled up into the 1.5 release branch. I'm pretty sure it didn't affect any other m68k ports.
I definitely think the NetBSD/vax port is in danger of redefining the term 'computing power' - I think your neighbours are more likely to be concerned about the block wide power drop when you spinup that vax.
Hmmm - would the VAX must be the largest (in a physical sense:) SMP box that NetBSD supports, or would that honour go to one of the big SMP alpha machines? I'm assuming there is nothing in the i386 world with quite the same floor covering capabilities:)
Looking ahead to upcoming SMP ports, what would be left? I think people are looking at sparc, bebox, and macppc, and sgimips covers the MIPS cpu... but are there any interesting m68k SMP capable machines?
I'd like to see NetBSD running SMP on a six CPU hydra board in an arm based RiscPC. The memory bus is going to choke it, but it would be pretty cool:)
Damn, just couldn't resist replying. Apologies to all:)
If *BSD is dying, why one one side are there so many busy lists with users, and on the other only one person pasting the same text again and again.
Maybe you're unhappy that where you work for switched from Linux to BSD, so now you feel you want to get your 'own back'?
Stick to the playground where you're not so out of place.
Incidently - no insult intended to Linux users in general, we also have the occasional clueless adolescent who is only good for causing embarrassment, you just seemed to have (through no fault of your own:) picked up a lulu. My condolences!
OpenBSD is porting UVM to -current (which should not be a massive task given the common heritage to NetBSD), but I do not believe they have made an official release supporting UVM yet. (Its just a matter of time though).
John Dyson rewrote the Mach VM for FreeBSD. This was a massive effort and a quite incredible achievement - the current performance and stability speaks for itself, but I do not believe he designed and wrote a 'new' VM system.
UVM was _not_ taken from the FreeBSD VM. If anything it owes its roots to the 3.X BSD VM system, and was designed and written to specifically and efficiently support unix VM needs, and to offer advanced features such as page loanout which can be used for zero copy network stacks (which is under development).
If a BeBox runs LinuxPPC then I would say linux has been ported to it. It may not fully support all the hardware, but it supports enough to make a usable system.
Redundant in what sense? In the sense of only needing one unix on them? In which case that would have been NetBSD, since I believe NetBSD booted on the imac before linux or Apple's MacOS X:) (It certainly supported USB first).
Note: I do not subscribe to that philosophy - I think people should be able to run/port any OS they like.
'Linux' runs on more different platforms than NetBSD, but what is 'linux'?
The linux that runs on the palm pilot is a totally different product/source tree that just happens to be called 'linux'. Even the sparc and ultrasparc linux sports have split the source tree (though they are working on merging them back).
The different linux source trees can release at different times. This makes it much easier for each platform to develop at its own pace, but makes extra work synchronising between source trees.
NetBSD has one central source tree, and has to synchronise all platforms to release at the same time (sixteen architectures as of 1.4). The fact it can do this is a credit to the almost fanatical desire for clean code, particuarly given the massive developer base available to linux.
I dont believe _any_ OS supports anything like the number of platforms as NetBSD out of the same source tree.
The NetBSD 1.4 release uses egcs on all platforms. NetBSD -current has been using egcs for some significant time:)
The Mach VM system is a general purpose system, not designed specificcally for unix. FreeBSD took turned it into a high quality, performant system, and by all accounts it took one hell of a lot of work.
Chuck Craynor specifically designed UVM for unix VM needs; it has some optimisations and extra features which are not feasible in a Mach derived system.
FreeBSD has a UBC (Unified Buffer Cache), which is still under development for UVM, which gives FreeBSD a significant advantage in filesystem caching.
By all accounts they are both very good systems, and both work very well, but I believe the underlying design of UVM is cleaner and better suited to unix. (The NetBSD way:)
Slashdot Mirror
One interesting O2 oddity is that the native pixel format is RGBA rather than ARGB (the alpha channel is at the other end of each 32 bit word).
Fixing that flushed out a whole bunch of assumptions in X driver and application code, which helps keep non SGI specific X and application code portable. Interesting to think that a user who only runs x86_64/Linux may be running an app with slightly cleaner code thanks to Michael's work on an ol' SGI O2...
(He has also fixed up and extended the accelerated driver for SGI Indy machines with newport graphics, and written drivers for a bunch of other graphics hardware on sparc, macppc and arm)
Most of the focus in NetBSD is on x86_64/i386 and embedded arm/mips/ppc boxes nowdays, but if you squint a little a small enough embedded box looks *really* similar to an older desktop/server box :)
so if people want to maintain support, why not?
Anyway, if you want a *really* slow older box you should be looking at an Atari TT or Vax (and lets just say we're not seeing any burst of new graphics drivers for them :)
NetBSD recently cut across to 64-bit time_t and its shaken out quite a few 32 bit assumptions.
http://mail-index.netbsd.org/current-users/2009/01/05/msg007024.html
The interesting part is not converting across to 64-bit time_t, its providing compatibility so all the previously 32-bit time_t compiled binaries and library keep working (at least until 2038 :)
dev_t was converted to 64-bits at the same time (two flag days for the price of one)
It involved versioning every function/system call that uses time_t, struct timeval, struct timespec, struct itimerval, struct itimerspec, struct rusage, struct stat, dev_t, struct ppasswd, struct utmp, struct utmpx, and ensuring the system can read both old and new versions of utmpx etc...
Certain bits of code which were using time_t to hold time offsets rather than absolute values were converted to using a normal 32 bit value (a good example might be anything in space constrained boot blocks)
I expect we'll be seeing a *lot* of patches in pkgsrc as the 64bit time_t application issues are fixed...
I've run firefox on 3.0 (and now 4_BETA) pretty much every day, and the last crash I had would have been a couple of months back (I had a dozen or so MB of XML files open and multiple media playing windows).
One thing to definitely test would be your machine's memory. If you can write a CD or floppy image I would strongly suggest downloading memtest from http://www.memtest.org/ and leaving it running overnight.
There are two architectures which have compiler issues not present on other NetBSD platforms, vax and pc532. In both cases support is fading away in more recent gcc versions, and they continue to be built using gcc 2.9.5 rather than the gcc 4.1.2 used by the rest of the NetBSD platforms (there are a couple of platforms still finishing testing for the transition from 3.3.3 to 4.1.2).
:)
This means all constructs in MI areas of the kernel (and the entire userland) need to keep compatible with gcc 2.9.5 and cannot take full advantage of newer C syntax and features.
So those working on the vax port tend to have to spend a reasonable amount of their time just making sure everything still builds, which reduces their time available for adding features and fixing PRs.
Its unfortunate, but the alternative would be to have the vast majority of NetBSD platforms stuck on an older compiler, which would hardly be very progressive
Having said that the VAX port is run and developed actively by some people, so its most likely the install tools and some models which have issues.
So, yes, VAX (and pc532) are at a disadvantage to the other ports, but they are still far from dead, and I would suggest tuning into the next bugathon to push your pet PRs...
The minor number was used to indicate a new release:
1.0 -> 1.6, and the tiny number for a minor release
1.6 -> 1.6.1 -> 1.6.2
http://ftp.lug.udel.edu/pub/NetBSD/misc/agc/pkgvie ws.pdf
Personally I have a pkgchk.conf shared between all my boxes so I knw what should be (re)installed at any point :)
If you can read nroff: cvsweb entry for pkg_chk.8
Just to make a change from the usual 32/64 bit clique, a NetBSD port to the 36bit PDP10 is underway...p 10/2002/09/19 /0000.html
http://mail-index.netbsd.org/port-pd
> no connection amongst them. Nothing more fun than
> having 95-99 all in order and needing to insert an
> important function before 97 but after 96.
Agreed, using numbers to order startsup scripts is clumsy and awkward at best, which is why NetBSD's startup scripts use a cleaner method: rc manpage
Just to remind anyone in that situation (old BIOS which hangs while probing large disks), to check for a BIOS update from the motherboard manufacturer. They are not always available, but frequently they can fix the problem.
:)
Otherwise - I've run NetBSD/i386 on a couple of systems with BIOSes too old to work with larger (60GB) disks. In both cases I was adding additional space to an existing system which had a small enough boot drive, so I was able to disable the other drive in the BIOS and boot from the small drive, then NetBSD would see the large drive and use it without problems. Its quite possible I could have told the BIOS the large drive was smaller, but I needed the systems up quickly (and the one I still have has had the aforementioned BIOS upgrade since, so I can't test
I can echo this experience on an hp omnibook 6100, and a friend with his sony - both 1400x1050. Xfree86 4's autodetection is dream compared to earlier versions, and the NetBSD version is setup just right. My SO is quite please to have KDE3 and ogle Just Work on her machine at home so she can watch he DVDs :)
:)
On the server front I've just converted two of the www.formula1.com servers and our firewall across from 1.5.3 to 1.6_BETA and setup complete mirrored filesystems with raidframe. The webservers done remotely without needing access to the console (though velocet were kind enough to daisy chain serial consoles between the machines in case they were needed
We still have a few linux servers, but since I started using pkgsrc on them it became a lot easier to administer all the software...
Top of my wishlist would probably be a native 1.3 or 1.4 jvm. I'm running the sun-jdk13 under linux compatability and have to say I've not have a problem with it, but I'd just prefer to have the code native...
I'm watching the open packages work with a lot of interest. I'm responsible for a reasonable sized website (350 million hits a month) on a bunch of Linux boxes (recently added a few BSD :).
:)
About two months ago I switched the linux boxes across to using pkgsrc (The NetBSD packge system). It has enabled me to massively reduce the amount of configuation/build magic required and to easily build on one box of each type and install binary packages across onto the others.
They're mainly apache, with some tomcat/jsp with a postgresql backend, nothing overly complicated, but there are various tweaks here and there and pkgsrc allows me to bring those updates forward without spending too much time on it.
Its also good to know if we get the Solaris boxes someone threatened then the packaging system is all ready to go
Right now pkgsrc gives me pretty much everything I want, but its good to see projects like openpackages bringing together even more people to work on a unified package system.
I believe there is an issue with VMWare not implementing the ATA flush cache command, and NetBSD not handling the failure gracefully:
/ 0002.html
:)
You might want to join the thread on port-i386@netbsd.org (which is related to running NetBSD inside VMware on NetBSD, but I'd imagine the issues are pretty similar)
http://mail-index.netbsd.org/port-i386/2001/07/11
The person sitting next to me has been running NetBSD 1.5 under VMware on Win2K for a few months without any problems. I'll ask him to boot a 1.5.1 kernel to see if it has any issues...
I'm just getting ready to update our servers here to get that nice NFS and IP checksumming speedup
My guess would be LP64, the same as the existing alpha and sparc64 ports.
Longs and pointers 64 bits, int 32, short 16, long long probably 128.
Interesting ... you be sure to tell Yahoo and Walnut Creek that their business depends on the weakest link.
:)
I'm sure you're intelligent enough to know that a single test does not give anything more than a rating for those conditions running that software.
Tests like that are a good thing - I'm pretty sure any of the issues raised have made their way to the relevant developers and I'd expect them to be addressed in the next release
There was a bug in one of the mac68k scsi drivers, which was fixed soon after the release in current and pulled up into the 1.5 release branch. I'm pretty sure it didn't affect any other m68k ports.
I definitely think the NetBSD/vax port is in danger of redefining the term 'computing power' - I think your neighbours are more likely to be concerned about the block wide power drop when you spinup that vax.
:) SMP box that NetBSD supports, or would that honour go to one of the big SMP alpha machines? I'm assuming there is nothing in the i386 world with quite the same floor covering capabilities :)
:)
Hmmm - would the VAX must be the largest (in a physical sense
Looking ahead to upcoming SMP ports, what would be left? I think people are looking at sparc, bebox, and macppc, and sgimips covers the MIPS cpu... but are there any interesting m68k SMP capable machines?
I'd like to see NetBSD running SMP on a six CPU hydra board in an arm based RiscPC. The memory bus is going to choke it, but it would be pretty cool
Damn, just couldn't resist replying. Apologies to all :)
:) picked up a lulu. My condolences!
If *BSD is dying, why one one side are there so many busy lists with users, and on the other only one person pasting the same text again and again.
Maybe you're unhappy that where you work for switched from Linux to BSD, so now you feel you want to get your 'own back'?
Stick to the playground where you're not so out of place.
Incidently - no insult intended to Linux users in general, we also have the occasional clueless adolescent who is only good for causing embarrassment, you just seemed to have (through no fault of your own
OpenBSD is porting UVM to -current (which should not be a massive task given the common heritage to NetBSD), but I do not believe they have made an official release supporting UVM yet. (Its just a matter of time though).
John Dyson rewrote the Mach VM for FreeBSD. This was a massive effort and a quite incredible achievement - the current performance and stability speaks for itself, but I do not believe he designed and wrote a 'new' VM system.
UVM was _not_ taken from the FreeBSD VM. If anything it owes its roots to the 3.X BSD VM system, and was designed and written to specifically and efficiently support unix VM needs, and to offer advanced features such as page loanout which can be used for zero copy network stacks (which is under development).
If a BeBox runs LinuxPPC then I would say linux has been ported to it. It may not fully support all the hardware, but it supports enough to make a usable system.
Redundant in what sense? In the sense of only needing one unix on them? In which case that would have been NetBSD, since I believe NetBSD booted on the imac before linux or Apple's MacOS X :) (It certainly supported USB first).
:)
Note: I do not subscribe to that philosophy - I think people should be able to run/port any OS they like.
I'm afraid I don't understand the comment
'Linux' runs on more different platforms than NetBSD, but what is 'linux'?
The linux that runs on the palm pilot is a totally different product/source tree that just happens to be called 'linux'. Even the sparc and ultrasparc linux sports have split the source tree (though they are working on merging them back).
The different linux source trees can release at different times. This makes it much easier for each platform to develop at its own pace, but makes extra work synchronising between source trees.
NetBSD has one central source tree, and has to synchronise all platforms to release at the same time (sixteen architectures as of 1.4). The fact it can do this is a credit to the almost fanatical desire for clean code, particuarly given the massive developer base available to linux.
I dont believe _any_ OS supports anything like the number of platforms as NetBSD out of the same source tree.
The NetBSD 1.4 release uses egcs on all platforms. NetBSD -current has been using egcs for some significant time :)
:)
The Mach VM system is a general purpose system, not designed specificcally for unix.
FreeBSD took turned it into a high quality, performant system, and by all accounts it took one hell of a lot of work.
Chuck Craynor specifically designed UVM for unix VM needs; it has some optimisations and extra features which are not feasible in a Mach derived system.
FreeBSD has a UBC (Unified Buffer Cache), which is still under development for UVM, which gives FreeBSD a significant advantage in filesystem caching.
By all accounts they are both very good systems,
and both work very well, but I believe the underlying design of UVM is cleaner and better suited to unix. (The NetBSD way