but a quick look at one would probably scream chordate-- CNS, circulatory system, etc. Once you've got that, a cephalopod starts looking like your only option.
Ummm, I don't claim to be a biologist, and my taxonomy sucks, but cephalopods aren't chordates. Chordata is the phylum which consists mostly of vertebrates.
part of the problem (for an chinese perspective) is that the HTML/XML/ETc tags have to be in English otherwise the browsers won't translate right (as well as being the
W3C standard.
OK, what does <A HREF=...> mean in English? Look it up: "A" - indefinite article. No help at all - you have to know it really stands for "anchor". HREF - not a word at all, you have to know it's short for "hypertext reference".
But he might just do it because he's cool (as is the case with this interview, I assume)
He's far cooler than Slashdot. I hope nobody manages to convince him to waste his time in such a manner. There are so many better things he can do with it.
Ever wonder why the elderly get so many benefits (like Medicare, SS, etc)??? Because organizations like the AARP are loud and vocal in the pursuit of their interests.
And well-funded. Sure, they have a lot of votes (although I very much doubt the AARP can deliver their whole membership as a bloc -- old people don't have the blacks-vote-90%-Democrat thing going) but they also have a lot of money to lobby with.
The EFF may be able to deliver some votes, but it can hardly afford to wine and dine Congress in true lobbyist style.
The Supreme Court justices appoint the President, not the other way around. People didn't learn anything from the last election.
(:
That's +1,Funny, but you don't really believe it, right? I mean, I don't mean to insult you, but some people do seem to believe it. What the Court did a year ago was essentially step in and say "You've been counting and recounting votes for a month now, the result hasn't changed, the sore loser has remained the loser, and this is getting ridiculous. Now please get on with the business of transitioning to a new Administration which can't be done overnight and should have started a month ago. Thank you and good night."
And those much-ballyhooed hand recounts of the whole state of Florida done by the media after the fact? Funny, W seems to have won anyway.
I suspect that, should any of this come to SCOTUS, that Scalia would actually be friendly to what we're trying to do. He's a strict constructionist.
(You mean strict consitutionist, or strict consitutionalist, or something.)
Yes, Scalia is my favorite Justice for this reason. "Legislating from the bench" is IMHO a bigger and worse problem than today's IP issues, although I feel pretty strongly about both.
Would that we had eight more justices like him - well, seven more, Justice Thomas is close enough.
Ok correct me if I'm wrong, but doesn't any x86 comouter witha NIC with a proper EPROM network boot?
You're assuming that the NIC has a boot EPROM. Remember, this is the same computer whose BIOS can't boot from CDROM.
Remember, until a couple years ago the most popular NIC in the world was the ISA-based 3c509 series. [The RTL-8139 and 2114x chipsets are probably winning now.] And there are a lot of old Cabletron E2100s and NE2000s out there as well.
i wonder how hard it would be for them to recycle an entire computer's heat back into energy.. that would certainly make laptops run forever and a half....
An entire computer's heat? Not possible, thanks to thermodynamics - you're talking perpetual motion here. And, since heat has so much more entropy than electricity, you probably can't even come close, even theoretically.
And don't forget the light output from the laptop's LCD, or the other EM output from the various motherboard components. The only way to "recoup" some of that power would be to harness the kinetic energy wasted on moving the keyboard keys track ball.
Easier by far to keep coming up with ways to (a) use less power and/or (b) store more power.
Hrm... in that case, it would be removing the heat from the CPU (by turning it into some other form of energy). So the end result would be a dynamic heatsink (as opposed to a static one without moving parts) that cooled more efficiently as it got hotter, because it would move air through itself.
Unfortunately, it would have to have some sort of capacitor to smooth out the power source, or it would only work in spurts - if it worked too well the CPU would become cool for a short time, cutting off power to the "dynamic heatsink". Unless this device were very quiet, I imagine the clicking noise from turning itself on and off (or merely revving up and down) would get annoying. Not to mention probably wearing out the part.
The other difficulty is, of course, in designing something that converts heat into a usable form of energy with temperature differences less than, say, what you need for a steam turbine. No present solution to this problem seems to be particularly cheap.
Possibly even sattelite connection to another CAVE system to make it multiplayer!
Remember your physics... the speed of light... going to and from a satellite adds quite a few milliseconds to your latency. Latency is bad for FPS (and in this case we're talking really first-person) games.
4 LCD projectors, at a minimum of $1200 or so each for cheesy ones.
Cheesy is right. I imagine for that money you get 800x600 resolution. A 1280x1024 projector is thousands more. But anyway...
3 rear projection surfaces - since we're using cheap projectors, you may as well use white bedsheets attached to a homebuilt wooden frame
You want something that won't flap in the breeze. To get any decent focusing you need F-L-A-T.
Skip the floor projection, I guess - it would require a hard screen - think mid-five-figure range for quality, I dunno how cheap you could go. The sides could perhaps use latex, for which the big boys would still want at least four figures per each... guess it would depend on size. I'm not sure offhand what you could build on the cheap, but I strongly suspect that bed sheets wouldn't cut it.
3 or 4 small-ish mirrors
...and mounts which let you adjust at least one angle - you don't want to hard-code this or your final adjustments will Not Be Fun. Also, I don't know if this is critical for a "budget CAVE", but for our VR center here we have front-silvered mirrors - for obvious-I-hope reasons.
Lots of CPU, and software.
Yeah. And not just CPU but lots of motherboard bandwidth - you'll probably want 66MHz and/or 64-bit PCI for the GigE, and the same (or AGP4x) for graphics.
I wonder if NTFS was the first journalling filesystem supported under Linux. That would be amusing, to say the least.
Well... that depends on
a) how you define "journalling" - some people consider NTFS to be a "logging" filesystem instead...
b) whether you count the fact that the Linux NTFS support doesn't actually journal the write data (which is what makes it so broken, I believe)...
c) if point (b) is ok with you, whether you consider a filesystem to be supported before it actually exists. Because ext3 in non-journalling mode was supported ever since ext2 was merged, which was way before NTFS support. (:
Reading down a bit further in the logs, it seems to be "Block I/O". Now I know.:-)
Yup, a shiny new block device layer, supposed to scale better on big boxes. It required significant changes to all block drivers, meaning all the hardware drivers for IDE, SCSI, RAID, floppy, etc.
This is what makes 2.5.1 a "caution, do not try this at home" development kernel. The early kernels in 2.3 were pretty tame by comparison - the big breakage there (the Great Page Cache Migration) didn't happen until I think 2.3.7.
Yeah I am aware of that, but how about Alan's personal set of patches (the -ac patch)? Is he still doing them?
No. 2.4.15 was where Alan pushed most of his ready-for-primetime stuff to Linus, and that was the end of the -ac series for now. Alan pushes stuff straight to Marcelo now (see the changelogs), and presumably he doesn't have all that much queued up from -ac anymore.
I have to support some of those old monsters. Does anyone know what the story is on the seperate driver issue? Considering the amount of effort it took to learn how to configure those boogers, I'm a little bummed that all that effort is going to waste.
'tulip' as I'm sure you know supports quite an array of chips and cards - from the original DEC 21040 through the 10/100 2114x and several "imitation" chips. Not only that, but the other hardware on a tulip card can vary in minor but annoying ways.
What seems to be happening is that the kernel people (Jeff Garzik probably) are getting tired of supporting all those configurations in a single driver. Thus the older chips and configurations will go in one driver and the newer ones in another. The old driver will need very little maintenance since it won't have to support any new hardware in the future.
This is similar to what happened with the NE2000 driver - long ago it was split up into a legacy (ISA etc) driver and a PCI driver. See also the various NCR SCSI drivers.
Upshot is, you just need to pick the correct driver for your hardware. Then do whatever it is you need to do currently to set up your card correctly (media settings?).
Shoot, I barely understand SCSI on the 2.4 series. What changed?
If you read the changelog (see link in/. blurb) you'll see lots of entries from Jens Axboe related to "bio". That's the new block I/O layer which is being born. That in turn means a rewrite of certain portions of all the block drivers, including IDE, SCSI, RAID, floppy, etc.
Depending on your particular SCSI card, it may or may not work correctly, yet. I haven't been tracking the 2.5.1 prepatches - don't really have a system I can afford to trash - but I understand IDE and a few of the more popular SCSI cards were converted early on and probably work ok by now. But I don't trust that assumption enough to load 2.5.1 on my machine, which doesn't have quite a recent enough backup for my liking..
Then your boxes just aren't set up right. Our Linux boxes do not go down at all, and they are under the heaviest load in the company. I'm not slamming you but you're obviously doing SOMETHING wrong.
Here's my experience: we have a couple Linux servers and a couple NT servers.
For NT, either an app restart (Exchange server, usually) or a reboot (IIS, which often wedges itself to the point where it won't let you restart it normally) usually does the trick. Our most annoying NT problem by far was a bad Adaptec scsi chip - the driver apparently had poor error handling and bluescreened the box every couple of days. A new Tekram scsi card fixed it.
Which brings me to my actual point. Many of the Linux failures I've seen appear to be hardware-related. We recycled an old desktop machine for use as our main Linux server. (It will be moving to a server-class motherboard + case soon.) You get what you pay for and I suspect some of the hardware is marginal - IDE disks off a PIIX4 chipset, that sort of thing. And a really cramped case with probably less-than-adequate cooling.
Linux is often deployed this way, I understand, on an otherwise-obsolete machine and used for little stuff like DNS and POP3. So hardware-related failures are probably more common in Linux than in Windows 2000, which is more often deployed on a brand-new machine.
The two are the exact same chip, excepting AMD's "SMP certification". So, if you want an even cheaper duel cpu solution, (without the warrenty of course) go for an 760MPX board with 2 XPs.
Yeah, and get the 1800+ rated chips instead of 1900+ and just overclock 'em.
Or, if overclocking makes you nervous (as it should), using XP chips instead of MP chips should make you nervous as well, for exactly the same reason.
I believe that very recent releases of the Linux kernel include a check to see if you're using Athlon XP chips for SMP. (Actually I don't know if the check made it in, but Dave Jones was at least playing with it.) This information is included in stack dumps, so you can cut and paste it into your bug report email and the kernel developers will know your machine is out of spec. Apparently there have been some odd bug reports in the past that might point to XP + SMP issues.
Why are files locked in the first place? In general, file locking and unlocking is done around changes that need to be atomic.
True, locking is generally used to ensure consistency across two separate accesses to a file. It is also used to implement mutual exclusion - for example, locking a PID file to make sure only one copy of a daemon is running.
Backing up a file that is in the middle of such a change is not very useful, as it may not be in a consistent state.
True again. But what if you lose power? Should the application be able to recover? A well-written one will leave a file in a recoverable state at all times (either via checkpointing / journalling or via atomic rename).
And in that case, you do want to back up the locked file. Because the lock exists to prevent two applications from overwriting each other's changes. The backup program catches the file in the middle of an update - fine, so that update is rolled back when the file is restored and the server process restarted.
Decent backup software should have an option to attempt to take locks on all files (to make sure nobody else has them locked). But it should be an option, which is not possible with mandatory locks (like many locks in Windows).
Yeah, shut down networking. On an NT box bring to a halt both the workstation and server services with the net command. For Linux simply kill Samba or NFS, depending on what you're doing.
Call it a bug or a feature, but Linux (along with other Unix flavors) will never deny read access to a file due to locking. That is, it doesn't have mandatory r/w locks. (Someone correct me if I'm wrong - perhaps some Unices out there do have these.) Throw in the fact that in Linux/Unix you can rename or delete open / locked files (due to the Inode Paradigm) and I call it a very handy feature rather than a bug.
You might still want to shut down server processes, simply to ensure a consistent state of their data files. A well-written server process will use journaling / checkpointing to ensure disk file consistency at all times (think: what happens if you get a sudden power failure or system crash?) but perhaps not all server apps are well-written.
the _value is completely unneeded, min & max is unambiguous
Ummmm, have you tried to compile the above? You will be in for a rude surprise when you discover that the kernel headers (specifically <linux/kernel.h>) define macros 'max' and 'min'.
This is a rather recent development (debuting in 2.4.10, a controversial variant appeared in 2.4.9) - Linus has long been staunchly opposed to the traditional 'max' and 'min' macros because they mask unsafe type promotions - i.e. they can easily hide bugs. Someone (Dave Miller, was it?) came up with the current versions in kernel.h in which the compiler whinges noisily if you try to use them on incompatible types.
Pure genius, if you ask me, but then I think that about a lot of Linux kernel code, which probably goes to show the dearth of my lifetime exposure to clever code. (:
Slashdot Mirror
Ummm, I don't claim to be a biologist, and my taxonomy sucks, but cephalopods aren't chordates. Chordata is the phylum which consists mostly of vertebrates.
OK, what does <A HREF=...> mean in English? Look it up: "A" - indefinite article. No help at all - you have to know it really stands for "anchor". HREF - not a word at all, you have to know it's short for "hypertext reference".
Now COBOL, on the other hand.......
He's far cooler than Slashdot. I hope nobody manages to convince him to waste his time in such a manner. There are so many better things he can do with it.
And well-funded. Sure, they have a lot of votes (although I very much doubt the AARP can deliver their whole membership as a bloc -- old people don't have the blacks-vote-90%-Democrat thing going) but they also have a lot of money to lobby with.
The EFF may be able to deliver some votes, but it can hardly afford to wine and dine Congress in true lobbyist style.
(Score: -1,Offtopic)
(:
That's +1,Funny, but you don't really believe it, right? I mean, I don't mean to insult you, but some people do seem to believe it. What the Court did a year ago was essentially step in and say "You've been counting and recounting votes for a month now, the result hasn't changed, the sore loser has remained the loser, and this is getting ridiculous. Now please get on with the business of transitioning to a new Administration which can't be done overnight and should have started a month ago. Thank you and good night."
And those much-ballyhooed hand recounts of the whole state of Florida done by the media after the fact? Funny, W seems to have won anyway.
(You mean strict consitutionist, or strict consitutionalist, or something.)
Yes, Scalia is my favorite Justice for this reason. "Legislating from the bench" is IMHO a bigger and worse problem than today's IP issues, although I feel pretty strongly about both.
Would that we had eight more justices like him - well, seven more, Justice Thomas is close enough.
You're assuming that the NIC has a boot EPROM. Remember, this is the same computer whose BIOS can't boot from CDROM.
Remember, until a couple years ago the most popular NIC in the world was the ISA-based 3c509 series. [The RTL-8139 and 2114x chipsets are probably winning now.] And there are a lot of old Cabletron E2100s and NE2000s out there as well.
...because it is Unix. MacOS X == FreeBSD + custom GUI toolkit + various compatibility layers to make it look, feel and work like MacOS 9. Remember?
An entire computer's heat? Not possible, thanks to thermodynamics - you're talking perpetual motion here. And, since heat has so much more entropy than electricity, you probably can't even come close, even theoretically.
And don't forget the light output from the laptop's LCD, or the other EM output from the various motherboard components. The only way to "recoup" some of that power would be to harness the kinetic energy wasted on moving the keyboard keys track ball.
Easier by far to keep coming up with ways to (a) use less power and/or (b) store more power.
Unfortunately, it would have to have some sort of capacitor to smooth out the power source, or it would only work in spurts - if it worked too well the CPU would become cool for a short time, cutting off power to the "dynamic heatsink". Unless this device were very quiet, I imagine the clicking noise from turning itself on and off (or merely revving up and down) would get annoying. Not to mention probably wearing out the part.
The other difficulty is, of course, in designing something that converts heat into a usable form of energy with temperature differences less than, say, what you need for a steam turbine. No present solution to this problem seems to be particularly cheap.
Remember your physics ... the speed of light ... going to and from a satellite adds quite a few milliseconds to your latency. Latency is bad for FPS (and in this case we're talking really first-person) games.
Cheesy is right. I imagine for that money you get 800x600 resolution. A 1280x1024 projector is thousands more. But anyway...
You want something that won't flap in the breeze. To get any decent focusing you need F-L-A-T.
Skip the floor projection, I guess - it would require a hard screen - think mid-five-figure range for quality, I dunno how cheap you could go. The sides could perhaps use latex, for which the big boys would still want at least four figures per each ... guess it would depend on size. I'm not sure offhand what you could build on the cheap, but I strongly suspect that bed sheets wouldn't cut it.
...and mounts which let you adjust at least one angle - you don't want to hard-code this or your final adjustments will Not Be Fun. Also, I don't know if this is critical for a "budget CAVE", but for our VR center here we have front-silvered mirrors - for obvious-I-hope reasons.
Yeah. And not just CPU but lots of motherboard bandwidth - you'll probably want 66MHz and/or 64-bit PCI for the GigE, and the same (or AGP4x) for graphics.
Sheesh, if you're gonna correct someone, get your facts straight. It was "Netscape engineers", not "Netscape programmers".
Well ... that depends on
a) how you define "journalling" - some people consider NTFS to be a "logging" filesystem instead ...
b) whether you count the fact that the Linux NTFS support doesn't actually journal the write data (which is what makes it so broken, I believe) ...
c) if point (b) is ok with you, whether you consider a filesystem to be supported before it actually exists. Because ext3 in non-journalling mode was supported ever since ext2 was merged, which was way before NTFS support. (:
Yup, a shiny new block device layer, supposed to scale better on big boxes. It required significant changes to all block drivers, meaning all the hardware drivers for IDE, SCSI, RAID, floppy, etc.
This is what makes 2.5.1 a "caution, do not try this at home" development kernel. The early kernels in 2.3 were pretty tame by comparison - the big breakage there (the Great Page Cache Migration) didn't happen until I think 2.3.7.
No. 2.4.15 was where Alan pushed most of his ready-for-primetime stuff to Linus, and that was the end of the -ac series for now. Alan pushes stuff straight to Marcelo now (see the changelogs), and presumably he doesn't have all that much queued up from -ac anymore.
'tulip' as I'm sure you know supports quite an array of chips and cards - from the original DEC 21040 through the 10/100 2114x and several "imitation" chips. Not only that, but the other hardware on a tulip card can vary in minor but annoying ways.
What seems to be happening is that the kernel people (Jeff Garzik probably) are getting tired of supporting all those configurations in a single driver. Thus the older chips and configurations will go in one driver and the newer ones in another. The old driver will need very little maintenance since it won't have to support any new hardware in the future.
This is similar to what happened with the NE2000 driver - long ago it was split up into a legacy (ISA etc) driver and a PCI driver. See also the various NCR SCSI drivers.
Upshot is, you just need to pick the correct driver for your hardware. Then do whatever it is you need to do currently to set up your card correctly (media settings?).
If you read the changelog (see link in /. blurb) you'll see lots of entries from Jens Axboe related to "bio". That's the new block I/O layer which is being born. That in turn means a rewrite of certain portions of all the block drivers, including IDE, SCSI, RAID, floppy, etc.
Depending on your particular SCSI card, it may or may not work correctly, yet. I haven't been tracking the 2.5.1 prepatches - don't really have a system I can afford to trash - but I understand IDE and a few of the more popular SCSI cards were converted early on and probably work ok by now. But I don't trust that assumption enough to load 2.5.1 on my machine, which doesn't have quite a recent enough backup for my liking..
Really? What makes you think so? (:
Here's my experience: we have a couple Linux servers and a couple NT servers.
For NT, either an app restart (Exchange server, usually) or a reboot (IIS, which often wedges itself to the point where it won't let you restart it normally) usually does the trick. Our most annoying NT problem by far was a bad Adaptec scsi chip - the driver apparently had poor error handling and bluescreened the box every couple of days. A new Tekram scsi card fixed it.
Which brings me to my actual point. Many of the Linux failures I've seen appear to be hardware-related. We recycled an old desktop machine for use as our main Linux server. (It will be moving to a server-class motherboard + case soon.) You get what you pay for and I suspect some of the hardware is marginal - IDE disks off a PIIX4 chipset, that sort of thing. And a really cramped case with probably less-than-adequate cooling.
Linux is often deployed this way, I understand, on an otherwise-obsolete machine and used for little stuff like DNS and POP3. So hardware-related failures are probably more common in Linux than in Windows 2000, which is more often deployed on a brand-new machine.
Yeah, and get the 1800+ rated chips instead of 1900+ and just overclock 'em.
Or, if overclocking makes you nervous (as it should), using XP chips instead of MP chips should make you nervous as well, for exactly the same reason.
I believe that very recent releases of the Linux kernel include a check to see if you're using Athlon XP chips for SMP. (Actually I don't know if the check made it in, but Dave Jones was at least playing with it.) This information is included in stack dumps, so you can cut and paste it into your bug report email and the kernel developers will know your machine is out of spec. Apparently there have been some odd bug reports in the past that might point to XP + SMP issues.
True, locking is generally used to ensure consistency across two separate accesses to a file. It is also used to implement mutual exclusion - for example, locking a PID file to make sure only one copy of a daemon is running.
True again. But what if you lose power? Should the application be able to recover? A well-written one will leave a file in a recoverable state at all times (either via checkpointing / journalling or via atomic rename).
And in that case, you do want to back up the locked file. Because the lock exists to prevent two applications from overwriting each other's changes. The backup program catches the file in the middle of an update - fine, so that update is rolled back when the file is restored and the server process restarted.
Decent backup software should have an option to attempt to take locks on all files (to make sure nobody else has them locked). But it should be an option, which is not possible with mandatory locks (like many locks in Windows).
Not to mention /proc/kcore, which is rather large and rather useless. (:
Call it a bug or a feature, but Linux (along with other Unix flavors) will never deny read access to a file due to locking. That is, it doesn't have mandatory r/w locks. (Someone correct me if I'm wrong - perhaps some Unices out there do have these.) Throw in the fact that in Linux/Unix you can rename or delete open / locked files (due to the Inode Paradigm) and I call it a very handy feature rather than a bug.
You might still want to shut down server processes, simply to ensure a consistent state of their data files. A well-written server process will use journaling / checkpointing to ensure disk file consistency at all times (think: what happens if you get a sudden power failure or system crash?) but perhaps not all server apps are well-written.
Ummmm, have you tried to compile the above? You will be in for a rude surprise when you discover that the kernel headers (specifically <linux/kernel.h>) define macros 'max' and 'min'.
This is a rather recent development (debuting in 2.4.10, a controversial variant appeared in 2.4.9) - Linus has long been staunchly opposed to the traditional 'max' and 'min' macros because they mask unsafe type promotions - i.e. they can easily hide bugs. Someone (Dave Miller, was it?) came up with the current versions in kernel.h in which the compiler whinges noisily if you try to use them on incompatible types.
Pure genius, if you ask me, but then I think that about a lot of Linux kernel code, which probably goes to show the dearth of my lifetime exposure to clever code. (: