Yes, this has been hashed over and over again on the kernel list. For the record, there has never been a BSD derived stack in the official linux kernel tree. Someone ported it in the timeframe of early 90s, but because of the license (advertising clause) it couldn't be included in the kernel. I tried to search for a reference to this effort, but couldn't find one right now (Alan Cox mentioned this on linux-kernel once).
Just about the only BSD code that has been included and still lives in the kernel tree, is the PPP compression code. It could only be compiled as a module, but now as the license has been changed, this has changed.
In IPv6 you don't need to. RFC 2462 defines the mechanism for Stateless Address Autoconfiguration which uses the Neighbor Discovery mechanisms defined in RFC 2461 for automatically configuring the host.
Basically all IPv6 routers periodically send Router Advertisement multicast packets to the all-nodes multicast group. The content of these messages is information on how the host should configure itself ('M' flag for managed - i.e. DHCPv6). If SAA is used, the host can create an IP address for itself by prepending its Interface Identifier (E.g. EUI-64) with the prefix contained in the Prefix Information option.
Hosts can at anytime send Router Solicitation messages to request RAs. The IP source address in these messages is the IID prepended by the well-known link-local address prefix. That means, each IPv6 has a scope, link-local, site-local or global.
Despite the fact that the existence of BeFS filesystem for Linux is well documented in Filesystems-HOWTO etc. you seemed to have missed it:
http://milosch.net/beos/
mobile phones and location based services
on
Advertising Via GPS
·
· Score: 1
There are already (or will be in near future) mobile phones which have integrated GPS capabilities. See for example Benefon Esc! from "the other" finnish mobile phone manufacturer. This phone doesn't yet enable "push-style" location based services but I'm sure future WAP enabled versions will. See the rele vant specification from the WAP forum.
I don't know what the previous poster was about but I'm running 2.3.99-pre9 on BP6 with the root partition on a disk hooked to the HPT366/UDMA66 controller.
Anyways, on a serious note, hopefully graphics support under Linux will be up to par when this game is released.
Btw. this just came up on the DRI devel list:
Date: Sun, 16 Apr 2000 00:00:49 -0400 From: Kevin E Martin <kevin@precisioninsight.com> To: DRI Development <dri-devel@lists.sourceforge.net> Subject: [Dri-devel] Rage 128 3D beta release
Beta release of the Rage 128 2D/3D DRI driver ---------------------------------------------
1. Beta Release
This is a public BETA release of the Rage 128 2D/3D DRI driver. It is fully functional and is intended for testing and gathering feedback.
2. Supported hardware
The following hardware is supported in this release:
Other Rage 128 cards will be supported in future releases.
Aurora borealis at Helsinki, Finland
on
G3 Solar Storm
·
· Score: 2
Just to let you know, they were absolutely magnificent. I didn't catch the beginning but even in the light pollution of the city I could see them span through the whole sky. As I walked out they were greenish and had quite fast moving features. Then they began quickly turning to red. After half an hour they begun to dim. The show was mostly over at midnight (+2 UTC).
The 'center' or 'radiant' (if you can call it that) was not directly overhead but maybe five or ten degrees southwards which would account to 50-55 degrees northern latitude.
This question was about mindcraft tests and a little known fact was that FreeBSD and Solaris were tested with the same setup than Linux and NT. Included is a mail from freebsd-hackers mailing list from last summer. I should say that the numbers are this way because what was a bad setup for Linux (4xSMP/4x100MBit), was even worse for FreeBSD.
--- Date: Wed, 23 Jun 1999 20:48:54 -0700 (PDT) From: Julian Elischer To: Karl Denninger Cc: hackers@FreeBSD.ORG ... Ok well here are some real numbers for you.. Win NT 4processors 1GB ram + raid array + IIS webbench... 4000 transactions per second...
FreeBSD.. Identical hardware.. 1450 transactions per seccond Linux: 2000 per second Solaris86 6000 per second
With Netbench: NT blows us away. (we're talking an order of magnitude faster) I'm not going ot give real numbers as I don't have them readily at hand but they are something like 12MB/Sec for FreeBSD vs 90 MB/sec for NT and 120MB/sec for linux. Matt has some patches that raise the 12 to 35 and kirk has some changes that may raise the numbers to 70 or more, and John has some patches that may add more again, but it's all theory, and some of the patches have had less results than we expected.
With Uniprocessor things are a lot more equal. but we still suck on netbench.
This is due to the exact form of netbench which is exactly nonoptimal for FreeBSD.
Also becaosue of the GKL (Giant Kernel Lock) (see Solaris's results)
Basically there are some applications and benchmarks for which FreeBSD will really suck. We're working on them but some things are just a result of how we do things.
So don't assume that NT figures must be bad.. we have too many weaknesses in our own code to throw stones.
Ext2 has no 2GB file size limit. It was a limitation of the VFS layer and the user-land API that bigger files could not be used on 32-bit systems. However this is no longer the case with 2.3.x or future 2.4.
If you want to edit the kernel configuration file by hand on Linux just edit the "linux/.config" file in any editor you wish and afterwards enter the "make oldconfig; make dep; make zlilo; blaablaa" hoopla.
I tried to post this to the PC Week benchmark thread but Slashdot kept corrupting the URLs so I don't know if anybody read it. Of course it would be far more interesting to test FreeBSD with a similar configuration to the C't benchmarks. However although PC Week articles did not mention it FreeBSD (and Solaris 7) were tested in the same Mincraft rematch (and configuration) than Linux and NT. I read the report and results on the FreeBSD-hackers mailing list which you can browse at the list archives.
Here are the relevant bits:
Date: Wed, 23 Jun 1999 20:48:54 -0700 (PDT) From: Julian Elischer To: Karl Denninger Cc: hackers@FreeBSD.ORG
Ok well here are some real numbers for you.. Win NT 4processors 1GB ram + raid array + IIS webbench... 4000 transactions per second...
FreeBSD.. Identical hardware.. 1450 transactions per seccond Linux: 2000 per second Solaris86 6000 per second
With Netbench: NT blows us away. (we're talking an order of magnitude faster) I'm not going ot give real numbers as I don't have them readily at hand but they are something like 12MB/Sec for FreeBSD vs 90 MB/sec for NT and 120MB/sec for linux. Matt has some patches that raise the 12 to 35 and kirk has some changes that may raise the numbers to 70 or more, and John has some patches that may add more again, but it's all theory, and some of the patches have had less results than we expected.
With Uniprocessor things are a lot more equal. but we still suck on netbench.
This is due to the exact form of netbench which is exactly nonoptimal for FreeBSD.
Also becaosue of the GKL (Giant Kernel Lock) (see Solaris's results)
Basically there are some applications and benchmarks for which FreeBSD will really suck. We're working on them but some things are just a result of how we do things.
So don't assume that NT figures must be bad.. we have too many weaknesses in our own code to throw stones.
There was also an earlier account by Mike Smith of the ZD labs tests. Basically it seems that the test setup hit FReeBSD's bad points even more than it hit Linux's.
Not really as the whole working set was only 75 MB and thus fitted completely in the cache. For an idea what happens when the working set is larger see the C't benchmarks (it could be though that RAID5 is extremely bad for NT but that's a pretty usual setup).
Interesting test though the 2.2 kernel used was 2.2.2. I recall there was an issue with the TCP/IP stack of the earlier 2.2.x kernels which could have resulted into the spikyness and lowered performance as shown by the figure. Maybe he should redo the tests with a more recent kernel.
-m interval The syslogd logs a mark timestamp regularly. The default interval between two -- MARK -- lines is 20 minutes. This can be changed with this option. Setting the interval to zero turns it off entirely.
Yes, this has been a prime topic on the linux-usb list for a couple of weeks. You might want to search the archives for the "Alternate USB driver" thread.
Linus posted the original announcement for the usb-0.01 code with a note that he couldn't understand the UUSBD code and needed something simpler. Well, I couldn't understand it either (which of course doesn't mean much:). Anyway the way I see it, things could go to two opposite directions from here; The two drivers keep on going on their separate paths or that they somehow merge in the future. I couldn't really see any future for UUSBD with the former scenario since Linus controls what goes into the kernel.
The most likely scenario I'll see is that the internal structure is kept from Linus-USB (enhanced of course as time goes by) and that the good ideas and some of the higher level device class specific (etc.) code from UUSBD will be ported and merged to Linus-USB.
I haven't gotten hold of the patch yet (and tried four mirrors already) but did Linus include the USB OHCI driver too? No use trying it because it is very incomplete. The version in 2.2.7-pre4 hanged the machine completely.
I'd bet Alan has something else in his mind. Atleast there's a merge of the bogl library (Ben Pfaff's simple graphics library created for the graphical Debian installer) and mini-x (sic) floating around at ftp.uk.linux.org. Mini-x is the windowing system used on Minix. Some of his comments in the diary talk about this too.
Yes, this has been hashed over and over again on the kernel list. For the record, there has never been a BSD derived stack in the official linux kernel tree. Someone ported it in the timeframe of early 90s, but because of the license (advertising clause) it couldn't be included in the kernel. I tried to search for a reference to this effort, but couldn't find one right now (Alan Cox mentioned this on linux-kernel once).
Just about the only BSD code that has been included and still lives in the kernel tree, is the PPP compression code. It could only be compiled as a module, but now as the license has been changed, this has changed.
In IPv6 you don't need to. RFC 2462 defines the mechanism for Stateless Address Autoconfiguration which uses the Neighbor Discovery mechanisms defined in RFC 2461 for automatically configuring the host. Basically all IPv6 routers periodically send Router Advertisement multicast packets to the all-nodes multicast group. The content of these messages is information on how the host should configure itself ('M' flag for managed - i.e. DHCPv6). If SAA is used, the host can create an IP address for itself by prepending its Interface Identifier (E.g. EUI-64) with the prefix contained in the Prefix Information option. Hosts can at anytime send Router Solicitation messages to request RAs. The IP source address in these messages is the IID prepended by the well-known link-local address prefix. That means, each IPv6 has a scope, link-local, site-local or global.
Despite the fact that the existence of BeFS filesystem for Linux is well documented in Filesystems-HOWTO etc. you seemed to have missed it:
http://milosch.net/beos/
There are already (or will be in near future) mobile phones which have integrated GPS capabilities. See for example Benefon Esc! from "the other" finnish mobile phone manufacturer. This phone doesn't yet enable "push-style" location based services but I'm sure future WAP enabled versions will. See the rele vant specification from the WAP forum.
I don't know what the previous poster was about but I'm running 2.3.99-pre9 on BP6 with the root partition on a disk hooked to the HPT366/UDMA66 controller.
According to that Voyager is about 75 AU from Sun.
Anyways, on a serious note, hopefully graphics support under Linux will be up to par when this game is released.
Btw. this just came up on the DRI devel list:
Date: Sun, 16 Apr 2000 00:00:49 -0400
From: Kevin E Martin <kevin@precisioninsight.com>
To: DRI Development <dri-devel@lists.sourceforge.net>
Subject: [Dri-devel] Rage 128 3D beta release
Beta release of the Rage 128 2D/3D DRI driver
---------------------------------------------
1. Beta Release
This is a public BETA release of the Rage 128 2D/3D DRI driver. It is
fully functional and is intended for testing and gathering feedback.
2. Supported hardware
The following hardware is supported in this release:
* Rage Fury 32MB AGP
* XPERT 128 16MB AGP
* XPERT 99 8MB AGP
Other Rage 128 cards will be supported in future releases.
Just to let you know, they were absolutely magnificent. I didn't catch the beginning but even in the light pollution of the city I could see them span through the whole sky. As I walked out they were greenish and had quite fast moving features. Then they began quickly turning to red. After half an hour they begun to dim. The show was mostly over at midnight (+2 UTC).
The 'center' or 'radiant' (if you can call it that) was not directly overhead but maybe five or ten degrees southwards which would account to 50-55 degrees northern latitude.
I'm sorry but it seems you looked too far:
/usr/src/linux/REPORTING-BUGS
See, it was on you hard drive all along.
This question was about mindcraft tests and a little known fact was that FreeBSD and Solaris were tested with the same setup than Linux and NT. Included is a mail from freebsd-hackers mailing list from last summer. I should say that the numbers are this way because what was a bad setup for Linux (4xSMP/4x100MBit), was even worse for FreeBSD.
...
---
Date: Wed, 23 Jun 1999 20:48:54 -0700 (PDT)
From: Julian Elischer
To: Karl Denninger
Cc: hackers@FreeBSD.ORG
Ok well here are some real numbers for you..
Win NT 4processors 1GB ram + raid array + IIS
webbench... 4000 transactions per second...
FreeBSD.. Identical hardware..
1450 transactions per seccond
Linux: 2000 per second
Solaris86 6000 per second
With Netbench:
NT blows us away.
(we're talking an order of magnitude faster)
I'm not going ot give real numbers as I don't have them readily at hand but they are something like 12MB/Sec for
FreeBSD vs 90 MB/sec for NT and 120MB/sec for linux. Matt has some patches that raise the 12 to 35 and kirk
has some changes that may raise the numbers to 70 or more,
and John has some patches that may add more again, but it's all theory, and some of the patches have had less
results than we expected.
With Uniprocessor things are a lot more equal.
but we still suck on netbench.
This is due to the exact form of netbench which is exactly nonoptimal for FreeBSD.
Also becaosue of the GKL (Giant Kernel Lock) (see Solaris's results)
Basically there are some applications and benchmarks for which FreeBSD will really suck. We're working on
them but some things are just a result of how we do things.
So don't assume that NT figures must be bad..
we have too many weaknesses in our own code to throw stones.
I doubt Corel ported it themselves. Much more likely is that they just used the usb backport by Vojtech Pavlik:
usb backport to 2.2Another useful URL:
Linux USB projectExt2 has no 2GB file size limit. It was a limitation of the VFS layer and the user-land API that bigger files could not be used on 32-bit systems. However this is no longer the case with 2.3.x or future 2.4.
The support in the 2.2.x kernels is very basic. You'll be better of with a backport of the 2.3.x kernel code:
Usb backport
More information:
Linux USB site
If you want to edit the kernel configuration file by hand on Linux just edit the "linux/.config" file in any editor you wish and afterwards enter the "make oldconfig; make dep; make zlilo; blaablaa" hoopla.
I tried to post this to the PC Week benchmark thread but Slashdot kept corrupting the URLs so I don't know if anybody read it. Of course it would be far more interesting to test FreeBSD with a similar configuration to the C't benchmarks. However although PC Week articles did not mention it FreeBSD (and Solaris 7) were tested in the same Mincraft rematch (and configuration) than Linux and NT. I read the report and results on the FreeBSD-hackers mailing list which you can browse at the list archives.
Here are the relevant bits:
Date: Wed, 23 Jun 1999 20:48:54 -0700 (PDT)
From: Julian Elischer
To: Karl Denninger
Cc: hackers@FreeBSD.ORG
Ok well here are some real numbers for you..
Win NT 4processors 1GB ram + raid array + IIS
webbench... 4000 transactions per second...
FreeBSD.. Identical hardware..
1450 transactions per seccond
Linux: 2000 per second
Solaris86 6000 per second
With Netbench:
NT blows us away.
(we're talking an order of magnitude faster)
I'm not going ot give real numbers as I don't have them readily at hand
but they are something like 12MB/Sec for FreeBSD vs 90 MB/sec for NT and
120MB/sec for linux. Matt has some patches that raise the 12 to 35 and
kirk has some changes that may raise the numbers to 70 or more,
and John has some patches that may add more again, but it's all theory,
and some of the patches have had less results than we expected.
With Uniprocessor things are a lot more equal.
but we still suck on netbench.
This is due to the exact form of netbench which is exactly nonoptimal for
FreeBSD.
Also becaosue of the GKL (Giant Kernel Lock) (see Solaris's results)
Basically there are some applications and benchmarks for which FreeBSD
will really suck. We're working on them but some things are just a result
of how we do things.
So don't assume that NT figures must be bad..
we have too many weaknesses in our own code to throw stones.
There was also an earlier account by Mike Smith of the ZD labs tests. Basically it seems that the test setup hit FReeBSD's bad points even more than it hit Linux's.
Not really as the whole working set was only 75 MB and thus fitted completely in the cache. For an idea what happens when the working set is larger see the C't benchmarks (it could be though that RAID5 is extremely bad for NT but that's a pretty usual setup).
I know I entered the correct URL but Slashdot keeps adding an extra space in there. Just remove the extra character and it should work.
Maybe this is a lesser know fact because it didn't
appear in the PC Week stories but the FreeBSD people
were there too.
Mike Smith's ZD labs test update
Webbench results including FreeBSD and Solaris 7
The bottom line is of course that given this configuration and test setup neither of the free operating systems have much to boast about.
This site is quite a good recap of the whole Mindcraft affair:
http://www.kegel.com/mindcraft_redux.html
I guess you folks missed this one:
HARLEQUIN LISPWORKS FLIES ON NASA'S DEEP SPACE 1
Cambridge, Mass., May 21, 1999
link to pressrelease
Harlequin LispWorks is supporting the operation of the Remote Agent
Experiment (RAX), activated this week on NASA's Deep Space 1 spacecraft.
Interesting test though the 2.2 kernel used was 2.2.2. I recall there was an issue with the TCP/IP stack of the earlier 2.2.x kernels which could have resulted into the spikyness and lowered performance as shown by the figure. Maybe he should redo the tests with a more recent kernel.
man syslogd
-m interval
The syslogd logs a mark timestamp regularly. The
default interval between two -- MARK -- lines is 20
minutes. This can be changed with this option.
Setting the interval to zero turns it off entirely.
Yes, this has been a prime topic on the linux-usb list for a couple of weeks. You might want to search the archives for the "Alternate USB driver" thread.
:). Anyway the way I see it, things could go to two opposite directions from here; The two drivers keep on going on their separate paths or that they somehow merge in the future. I couldn't really see any future for UUSBD with the former scenario since Linus controls what goes into the kernel.
Linus posted the original announcement for the usb-0.01 code with a note that he couldn't understand the UUSBD code and needed something simpler. Well, I couldn't understand it either (which of course doesn't mean much
The most likely scenario I'll see is that the internal structure is kept from Linus-USB (enhanced of course as time goes by) and that the good ideas and some of the higher level device class specific (etc.) code from UUSBD will be ported and merged to Linus-USB.
I haven't gotten hold of the patch yet (and tried four mirrors already) but did Linus include the USB OHCI driver too? No use trying it because it is very incomplete. The version in 2.2.7-pre4 hanged the machine completely.
I'd bet Alan has something else in his mind. Atleast there's a merge of the bogl library (Ben Pfaff's simple graphics library created for the graphical Debian installer) and mini-x (sic) floating around at ftp.uk.linux.org. Mini-x is the windowing system used on Minix. Some of his comments in the diary talk about this too.