I'm not sure about OpenBSD, but there's not much shared code in those areas between NetBSD and FreeBSD. On NetBSD, Bill Sommerfeld did most of the i386 SMP code, and Nathan Williams is the guy who's working on scheduler activations. SA is a M:N implementation, not much different from FreeBSD's KSE, which was developed mainly by Julian Elisher. SMPng is the work of many people, specially John Baldwin. Note that KSE is only really finished on i386, Alpha and Sparc64 are still missing some bits.
SA is not as advanced as KSE, though, but it looks very promising. AFAIK, kernel assisted threading and SMP have never been priorities for the OpenBSD people, ergo, little work has been done in those areas.
There are times when GPLd software does make sense for the base system (from the FreeBSD perspective). That's when the software is clearly the best of breed and won't encumber anything else. A good example is GNU tar.
Funny that you mention GNU tar. The NetBSD folks have had problems with tar files generated by GNU tar which couldn't later be unpacked by NetBSD's pax, and, no, it wasn't PAX's fault, but this annoying 'embrace and extend' trend in GNU software.
"It seems pretty certain that there will be only Linux and OS-X left as viable O/S in the UNIX world in ten years time. Every other UNIX will be a legacy platform on minimal life support. Eventually they will become Linux subsystems the way VMS is becomming a Windows NT subsystem."
Gimme a break, Solaris, UNICOS and the BSDs aren't going away anytime soon, much less being replaced by Linux or OS X. Nice troll, though.
Some games that relied in pure cpu power, games that used the freescape engine like Dark Side, ran very slowly on the C64, since it was just 1MHz. With this new computer you'll be able to fully enjoy them.;-)
Honestly, besides the 'because we can' and geek value, I can't imagine why would one want one, but the C64 hackers have been enchancing their hardware for years, adding modems, ide drivers, almost anything you can imagine. It's a very active community.
If you are running FreeBSD 4-STABLE you can get prebuilt packages from Fruitsalad.org. It's not in ports yet tho, but it will. FreeBSD has a very active KDE team. No idea about the others, but NetBSD will surely get it soon.
"Sun doesn't actually fab anything. They only do the chip design, and have them fab out-of-house."
Absolutely. Given the small volume of UltraSparc cpus produced every year (very small compared to the x86 world), it would be extremely expensive for them to have an own fab. During my work at Sun I saw USIIi cpu boards made by companies like IBM (those had the well known ecache bug) and Sony.
Bill Paul, the guy who coded the Realtek 8139 driver put a very
funny comment:
/*
* The RealTek 8139 PCI NIC redefines the meaning of 'low end.' This is
* probably the worst PCI ethernet controller ever made, with the possible
* exception of the FEAST chip made by SMC. The 8139 supports bus-master
* DMA, but it has a terrible interface that nullifies any performance
* gains that bus-master DMA usually offers.
*
You're talking out of your ass, aren't you? This cluster uses POWER4 processors made by IBM. Also, where do you see Myrinet? All I see is a kind of quad-ethernet board, not really like Myrinet hardware.
Have you read the SPECint and SPECfp results posted above? The Pentium4 runs at 6 (six) times this cpu's speed, yet only scores twice. Talk about good cpu design.
You should also keep in mind that SGI has some ass kicking technology when it comes to cpu and memory interconnect. NUMAFlex makes it possible to have a penalty as little as 1.5 vs 1 for memory accesses outside the local ram banks. Now try doing that with commodity x86 hardware. For problems that aren't easily broken down in small parts and, that have huge datasets, nothing touches SGI.
When a company violates the GPL, the slashdot crowd jumps over them instantly. Now how come you defend the opposite? Be honest, how many people have you seen purchase a PS2 modchip for other purpose than pirating games? And don't bring the backup/fair use bullshit, I have audio Cds I bought in 1990 that still work like the first day. Or do book publishers give you another copy for free just because you spilled coffee on you book? Do you also make a photocopy of every book you buy 'just in case'?
I'll give you that the xbox modchip can be used for interesting stuff, e.g. running Linux, but PS2? Gimme a break.
but with smell there are really only a few words people used to describe a smell, "good" and "bad" most of the time.
Although our olfatory sensors are not as developed as dogs', it's also a matter of trainning too. Perfume companies hire specialized people (called 'noses'), that evaluate how a given perfume smells. This needs a bit more <insert flower fragance here>. These people are able to tell which "components" are included in a given perfume, which ultimately make a difference in smell. Same goes for people who specialize on wines. Also, smell and taste are very strongly connected in humans, not sure that's the case for other animals, except, perhaps, snakes, who capture smell particles with their tongue.
To finish, just a quick anecdote. Perfumes don't smell the same on different people. I remember going to work one day, and the girl near me was wearing 'Anais Anais', but the way it smelled on her triggered memories of an ex on me immediatly, it smelled the same way on those two women, so yes, I think we keep memories on smells too, not as strong as images, tho.
Check this post to the netbsd-users mailing list (emphasis mine) :
From: David Maxwell
To: Stefan Schumacher
Cc: netbsd-users@netbsd.org
Subject: Re: Trojans in libpcap and tcpdump
Date: Wed, 13 Nov 2002 14:39:05 -0500
Sender: netbsd-users-owner@netbsd.org
User-Agent: Mutt/1.4i
On Wed, Nov 13, 2002 at 06:52:38PM +0100, Stefan Schumacher wrote:
> Hi there,
>
> report was given that trojans were detected in libpcap and tcpdump.
>
> http://hlug.fscker.com/
>
> I fetched tcpdump and libpcap and took a look in the sources, seems so as
> if we IMHO are not affected.
That is correct.
I've been at the console of the tcpdump.org server today, working with
Michael Richardson to investigate the problem. He will release a
statement on the details at some point. The system was not running an
up to date version of NetBSD, so there is no indication that users with
up to date systems are vulnerable to some new bug.
The trojan was installed within the last two days. The signatures in
pkgsrc are eight _months_ old. Users installing from pkgsrc (source, or
binary packages) could not be affected by this trojan without
specifically overriding the incorrect signature on the distribution
file.
Michael's contact information is listed in the whois entry for the
tcpdump.org domain, but as far as I know, he did not receive a call
about this issue, it was slashdotted.
Re:Have the init scripts been fixed yet?
on
NetBSD 1.6 Released
·
· Score: 3, Informative
Please, take your time to study how the NetBSD rc system works. It has all the advantages of sysV style init scritps, but none of the disadvantages. Let's say I install apache via the pkgsrc system. Now all I have to do is add apache=YES in my/etc/rc.conf file and the system will automagically start apache at boot time. Of course I can start or stop it manually should I have the need to do so with a simple/etc/rc.d/apache [start|stop]
FWIW, FreeBSD 5.0 will feature this same system, Gordon Tetlow and others are working on a port of NetBSD's script system to FreeBSD.
Re:Been there...
on
FreeBSD 4.6
·
· Score: 2, Interesting
The fact that the mini iso as already there doesn't mean it had been officially released. A new version of FreeBSD is not officially out until the announcement is made. This is necessary because isos and files need to be mirrored before the load spike comes. For the rest of us, we just cvsup and don't really worry when it comes:-)
flynn@kajsa# uname -a
FreeBSD kajsa.energyhq.tk 4.6-STABLE FreeBSD 4.6-STABLE #0: Sun Jun 16 14:08:54 CEST 2002 root@kajsa.energyhq.tk:/usr/obj/usr/src/sys/KAJSA i386
"to power4 has had to do with reliability at the hardware level. IIRC they have multiple identical cpus that execute the same instruction stream and check the results, or is that only in the BIG mainframes?"
Yes, that only applies to the really big iron, i.e. S/390 mainframes. The other boxen use redundant caches a la Sun's SPARC processors. Keep in mind that running N redundant processors is extremely expensive, not only putting the extra CPUs, but the 'magic' hardware required to compare every instruction executed by them.
" plus a hardware monopoly (even Mac's PCI 'thinks different' from PC PCI, so you can't use PC cards on a Mac and instead must pay three times as much for a card that's five times slower), plus a serious lack of braincells."
What you mean here is the PC is the only architecture that doesn't support Forth-code-enabled PCI cards, like the rest of the industry does, right?
Apparently Matt found one bug in the softupdates code and reported it to McKusick, who has written a patch. Matt is still testing the new code in -current and if everythings works ok it will be MFC'ed to -stable within one week, so that this code makes it for 4.5-RELEASE that is coming soon.
Slashdot Mirror
I'm not sure about OpenBSD, but there's not much shared code in those areas between NetBSD and FreeBSD. On NetBSD, Bill Sommerfeld did most of the i386 SMP code, and Nathan Williams is the guy who's working on scheduler activations. SA is a M:N implementation, not much different from FreeBSD's KSE, which was developed mainly by Julian Elisher. SMPng is the work of many people, specially John Baldwin. Note that KSE is only really finished on i386, Alpha and Sparc64 are still missing some bits.
SA is not as advanced as KSE, though, but it looks very promising. AFAIK, kernel assisted threading and SMP have never been priorities for the OpenBSD people, ergo, little work has been done in those areas.
There are times when GPLd software does make sense for the base system (from the FreeBSD perspective). That's when the software is clearly the best of breed and won't encumber anything else. A good example is GNU tar.
Funny that you mention GNU tar. The NetBSD folks have had problems with tar files generated by GNU tar which couldn't later be unpacked by NetBSD's pax, and, no, it wasn't PAX's fault, but this annoying 'embrace and extend' trend in GNU software.
"It seems pretty certain that there will be only Linux and OS-X left as viable O/S in the UNIX world in ten years time. Every other UNIX will be a legacy platform on minimal life support. Eventually they will become Linux subsystems the way VMS is becomming a Windows NT subsystem."
Gimme a break, Solaris, UNICOS and the BSDs aren't going away anytime soon, much less being replaced by Linux or OS X. Nice troll, though.
Some people are already working on that in the -CURRENT tree. It's called syspkg. See the original post here
Some games that relied in pure cpu power, games that used the freescape engine like Dark Side, ran very slowly on the C64, since it was just 1MHz. With this new computer you'll be able to fully enjoy them. ;-)
Honestly, besides the 'because we can' and geek value, I can't imagine why would one want one, but the C64 hackers have been enchancing their hardware for years, adding modems, ide drivers, almost anything you can imagine. It's a very active community.
If you are running FreeBSD 4-STABLE you can get prebuilt packages from Fruitsalad.org. It's not in ports yet tho, but it will. FreeBSD has a very active KDE team. No idea about the others, but NetBSD will surely get it soon.
"Sun doesn't actually fab anything. They only do the chip design, and have them fab out-of-house."
Absolutely. Given the small volume of UltraSparc cpus produced every year (very small compared to the x86 world), it would be extremely expensive for them to have an own fab. During my work at Sun I saw USIIi cpu boards made by companies like IBM (those had the well known ecache bug) and Sony.
Bill Paul, the guy who coded the Realtek 8139 driver put a very funny comment:
* The RealTek 8139 PCI NIC redefines the meaning of 'low end.' This is
* probably the worst PCI ethernet controller ever made, with the possible
* exception of the FEAST chip made by SMC. The 8139 supports bus-master
* DMA, but it has a terrible interface that nullifies any performance
* gains that bus-master DMA usually offers.
*
You're talking out of your ass, aren't you? This cluster uses POWER4 processors made by IBM. Also, where do you see Myrinet? All I see is a kind of quad-ethernet board, not really like Myrinet hardware.
Have you read the SPECint and SPECfp results posted above? The Pentium4 runs at 6 (six) times this cpu's speed, yet only scores twice. Talk about good cpu design.
You should also keep in mind that SGI has some ass kicking technology when it comes to cpu and memory interconnect. NUMAFlex makes it possible to have a penalty as little as 1.5 vs 1 for memory accesses outside the local ram banks. Now try doing that with commodity x86 hardware. For problems that aren't easily broken down in small parts and, that have huge datasets, nothing touches SGI.
Kudos to the SGI engineers for their great job.
A long time SGI fan :)
When a company violates the GPL, the slashdot crowd jumps over them instantly. Now how come you defend the opposite? Be honest, how many people have you seen purchase a PS2 modchip for other purpose than pirating games? And don't bring the backup/fair use bullshit, I have audio Cds I bought in 1990 that still work like the first day. Or do book publishers give you another copy for free just because you spilled coffee on you book? Do you also make a photocopy of every book you buy 'just in case'?
I'll give you that the xbox modchip can be used for interesting stuff, e.g. running Linux, but PS2? Gimme a break.
Now mod this down: -1, Against groupthink
but with smell there are really only a few words people used to describe a smell, "good" and "bad" most of the time.
Although our olfatory sensors are not as developed as dogs', it's also a matter of trainning too. Perfume companies hire specialized people (called 'noses'), that evaluate how a given perfume smells. This needs a bit more <insert flower fragance here>. These people are able to tell which "components" are included in a given perfume, which ultimately make a difference in smell. Same goes for people who specialize on wines. Also, smell and taste are very strongly connected in humans, not sure that's the case for other animals, except, perhaps, snakes, who capture smell particles with their tongue.
To finish, just a quick anecdote. Perfumes don't smell the same on different people. I remember going to work one day, and the girl near me was wearing 'Anais Anais', but the way it smelled on her triggered memories of an ex on me immediatly, it smelled the same way on those two women, so yes, I think we keep memories on smells too, not as strong as images, tho.
Check this post to the netbsd-users mailing list (emphasis mine) :
From: David Maxwell
To: Stefan Schumacher
Cc: netbsd-users@netbsd.org
Subject: Re: Trojans in libpcap and tcpdump
Date: Wed, 13 Nov 2002 14:39:05 -0500
Sender: netbsd-users-owner@netbsd.org
User-Agent: Mutt/1.4i
On Wed, Nov 13, 2002 at 06:52:38PM +0100, Stefan Schumacher wrote:
> Hi there,
>
> report was given that trojans were detected in libpcap and tcpdump.
>
> http://hlug.fscker.com/
>
> I fetched tcpdump and libpcap and took a look in the sources, seems so as
> if we IMHO are not affected.
That is correct.
I've been at the console of the tcpdump.org server today, working with
Michael Richardson to investigate the problem. He will release a
statement on the details at some point. The system was not running an
up to date version of NetBSD, so there is no indication that users with
up to date systems are vulnerable to some new bug.
The trojan was installed within the last two days. The signatures in
pkgsrc are eight _months_ old. Users installing from pkgsrc (source, or
binary packages) could not be affected by this trojan without
specifically overriding the incorrect signature on the distribution
file.
Michael's contact information is listed in the whois entry for the
tcpdump.org domain, but as far as I know, he did not receive a call
about this issue, it was slashdotted.
--
I agree with most of what you say, except I'll nitpick on one thing:
And Mplayer doesn't seek in an incomplete DivX file...
That's what I thought too, until I discovered the -idx option. Yes, man pages are useful sometimes :-)
christine: {2} sysctl hw
hw.machine = i386
hw.model = Intel Pentium III (Katmai) (686-class)
hw.ncpu = 2
christine: {3} uname -srn
NetBSD christine 1.6
Please, take your time to study how the NetBSD rc system works. It has all the advantages of sysV style init scritps, but none of the disadvantages. Let's say I install apache via the pkgsrc system. Now all I have to do is add apache=YES in my /etc/rc.conf file and the system will automagically start apache at boot time. Of course I can start or stop it manually should I have the need to do so with a simple /etc/rc.d/apache [start|stop]
FWIW, FreeBSD 5.0 will feature this same system, Gordon Tetlow and others are working on a port of NetBSD's script system to FreeBSD.
The fact that the mini iso as already there doesn't mean it had been officially released. A new version of FreeBSD is not officially out until the announcement is made. This is necessary because isos and files need to be mirrored before the load spike comes. For the rest of us, we just cvsup and don't really worry when it comes :-)
flynn@kajsa# uname -a
FreeBSD kajsa.energyhq.tk 4.6-STABLE FreeBSD 4.6-STABLE #0: Sun Jun 16 14:08:54 CEST 2002 root@kajsa.energyhq.tk:/usr/obj/usr/src/sys/KAJSA i386
"But for non-C kernels, try BeOS (C++)"
Sorry, but there's not a single line of C++ in the BeOS kernel. Their motto was always: "No C++ in kernel code".
"to power4 has had to do with reliability at the hardware level. IIRC they have multiple identical cpus that execute the same instruction stream and check the results, or is that only in the BIG mainframes?"
Yes, that only applies to the really big iron, i.e. S/390 mainframes. The other boxen use redundant caches a la Sun's SPARC processors. Keep in mind that running N redundant processors is extremely expensive, not only putting the extra CPUs, but the 'magic' hardware required to compare every instruction executed by them."You'll note that he's using it on a dual celeron 533"
Dude, last time I checked, Eugenia Loli-Queru was a girl :-)
I'm not sure if you are serious about this. Darwin has been running on x86 since day one!
Read about it here
" plus a hardware monopoly (even Mac's PCI 'thinks different' from PC PCI, so you can't use PC cards on a Mac and instead must pay three times as much for a card that's five times slower), plus a serious lack of braincells."
What you mean here is the PC is the only architecture that doesn't support Forth-code-enabled PCI cards, like the rest of the industry does, right?I've been running Linux' jdk on OpenBSD for a while, nothing new really.
Merge From Current, when a patch or new feature is tested long enough in -CURRENT the core team back ports it to -STABLE.
Apparently Matt found one bug in the softupdates code and reported it to McKusick, who has written a patch. Matt is still testing the new code in -current and if everythings works ok it will be MFC'ed to -stable within one week, so that this code makes it for 4.5-RELEASE that is coming soon.