Byte was *never* variable. You're thinking of "word" which represents a natural unit for a system. Thus a PC has a 32 bit word, a Unisys Mainframe has 48 bit words, and an embedded processor has a 16 bit word.
At least that explains her stories about all the people who "stayed after the evacuation". There's been a careful, ongoing international study done on the aftermath of the Chernobyl disaster. Her claims just didn't fit the facts of that study.
Of course, the inconsistencies didn't tip me off either. I just thought that she was stretching things a bit. *shrug*
You appear to misunderstand what a virtual machine is. The BSD kernel in OS X is 100% native code, running 100% in concert with the rest of the system. "Virtual Machine" implies that you are attempting to fool software into believing that it is running on hardware (real or imagined) that it isn't.
Instead, the BSD layer of Mac OS X simply provides a POSIX interface to programs. "Kernel calls" are captured in the BSD kernel server, but are routed to the proper Mach server instead of being routed to the driver or I/O area of a full BSD kernel. Depending on how this is implemented, it could have a very minimal impact on performance. Even if it does slow things down in the processor, programs spend 90% of their time blocking on hardware anyway.
The BSD kernel used on top is not really a kernel in the truest sense. Instead, it's another microkernel server that provides an interface from the programs to the other servers. This design turned out to be quite sensible. It allowed the OS to "skin" its interface with programs on the fly, without inheriting a lot of the faults of the previously monolithic kernels. Thus Apple was able to run OS 9 programs in an OS 9 kernel "server", and then run ultramodern Unix/Cocoa apps in the BSD kernel "server". All without locking up the machine via OS 9's memory problems and poor system drivers.
annenbaum is also the guy who thought that micro-kernels were a good idea.
I'm sorry, who was it that had that much coveted OS that "just works", and is so cool that everyone wants it but doesn't have the first clue as to how to copy it?
Oh, right. Microkernels seem to work pretty well for Apple.
Linus wrote Linux, and that's all there is to it. Anything to the contrary is Microsoft FUD.
Can't argue with that. I can't read the article, but I don't think that Tannenbaum argues with that either. He probably said something like Linus copied the basic Minix design (true) and the reporter blew it out of proportion.
I've got old skool sound effects right here. The whole game fit in 4K, even won the 4K Java Game programming contest.
It requires that you have Java installed in order to play. It doesn't work on Linux, tho. Sorry. Complain at Sun to get full screen mode working on Linux.
Not to mention that half the time I'm looking for a file that was just dumped to disk by an install, packaging program, or untar. Searching source trees for the file you need is a particularly good example of this.
There are a couple things that you have to consider. For one, if part of the disk corrupts, how will you identify a header? Or for that matter, how would you identify the header space vs. file space in a non-corrupted file system?
You're probably thinking "just store the size of the file", This is perfectly valid, but it does have certain implications. You see, in Comp-Sci, we refer to a list like this as a "linked list". The concept basically being that each item in the list has information (i.e. a "link") that helps identify the next item in the list. Such a data structure has a worst case access time of O(n). Or in other words, if your item is at the end of the list,and you have you have 2000 files, you'll have to check through all two thousand headers before finding your file.
Popular file systems circumvent this by using what's called a Tree structure. A tree is similar to a linked list, but allows for multiple links that point to children of the node. A node that has no children is referred to as a "leaf node". In a file system the directories and files are nodes of a tree, with files being leaf nodes. This configuration gives us two performance characteristics that we must calculate for:
1. The maximum number of children in a node. 2. The maximum depth of the tree.
Let's call them "c" for children and "d" for depth. Our performance formula is now O(c*d) and is irrespective of the number of items in the data structure. Let's make up and example to run this calculation against:
Plugging the above numbers (72 for c, 4 for d) we get a worst case of 72*4 = 288 operations. Thus our worst case is much better than the linked list. And if we calculate the real case to access/usr/local/bin/mybinary, we get 34+10+9+72 = 134 operations.
It's okay. It just came after a long string of people putting words in my mouth. Just yesterday, I had one guy complain about my use of "most" when I said "many", and another tell me that Diesel was more energy dense than gasoline when I had said "petroleum". I must be doing something wrong here...
The absolute BEST airframe is a complete vacuum. However, an absolute vacuum would require much stronger materials (1-1.5 atmospheres of pressure on the materials vs. a pressure of.01 atmospheres in a standard blimp). These stronger materials would of course be heavier and thus defeat any gains you would get by creating a vacuum.
Second this a science fair, what did you expect? Booth babes and explosions? This guys blog was meant to just show what some of the project were, not be an informative guide to them. Give him a break already.
No, he was quite right. The pictures *are* boring. I would have expected to see things like hovercraft and pocket nuclear reactors. Instead we're treated to images of this guy's plane ride, his Starbucks purchase, a laser light intro that's only interesting while it's moving, and a Material Safety Data Sheet (MSDS). Since most of us either already know what's on the MSDS or simply don't care, his photojournal ends up being useless.
It's a common mistake. People tend to have the idea in their heads that helium is a magic anti-gravity substance. Once you point out their error to them, they tend to realize that they'd never really considered how it worked in the first place.
Did you consider compressing the helium? Compressed gasses take up less space, so you would have needed a much smaller envelope.
I'm not completely up to speed on airship technology, but my understanding is that this presents two problems:
1. To compress the helium, you need a stronger gasbag structure. Making the gasbag stronger makes it heavier, thus defeating the purpose of compressing it.
2. Compressing the gas simply adds more gas for the same amount of displacement. Thus you've actually made the blimp or rigid airship heavier instead of lighter.
Keep in mind that airships work by displacing air like boats displace water. The only reason that helium helps generate lift is that it adds structural integrity to the airframe/gasbag while being lighter than if it had been filled with air. The absolute BEST airframe is a complete vacuum. However, an absolute vacuum would require much stronger materials (1-1.5 atmospheres of pressure on the materials vs. a pressure of.01 atmospheres in a standard blimp). These stronger materials would of course be heavier and thus defeat any gains you would get by creating a vacuum.
Actually, I recently considered what it would take to build a go kart for the sky. My idea was to take a basic frame (like that of a go-kart), add blimp-like "pontoons" to the sides, and attach a lightweight propeller to the back. I figured that if I could get it to lift a few hundred pounds, I'd have myself a new way of getting to work. The problem came in when I did the actual calculations.
To lift one kilogram of weight, I need about.4 kilograms of helium. This didn't sound so bad until I found out that the.4 kilograms of helium takes up about 1 cubic meter of space. I then assumed two gasbags, each one cylindrical, about one meter in diameter, and 4.9 meters in length. This worked out to about 8 cubic meters. (.5^2 * 3.14 * 4.9 * 2 = 7.693 m^3) 8 cubic meters would only give me 8 kilograms of lift! I then did the figures to lift 250kg of weight, and found that I'd need a gasbag the size of my living room to lift it.
So much time spent on JOSRTS and I STILL couldn't get you to learn patience. I understand that it's easy to get frustrated. But when people don't know something, they stumble around looking for answers. Given that many users are from a generation that is used to asking live people, they contact support instead of looking for a FAQ or manual.
All of this is irrelevant anyway. In this case he called support. Support told him that it should work but it doesn't. The community then told him that it was his own damn fault (why?) and that they knew all the answers. He provided them with the specs, and the community then continued to claim he was stupid, but changed their tune to say that Linux should be used for Enterprise stuff and who cares about sound?
I've found that most of the time RTFM + flames is a *good* answer - it trains the user to look things up for themselves rather than to get me to look it up for them.
There are ways of doing that without berating people. I used to have to deal with a bunch of Unix neophytes who hated to look up command line commands for themselves. I simply got in the habit of first asking, "did you try the 'man' command?" Usually they'd sheepishly go back and try the 'man' command. If 'man' didn't help, then I'd answer their question. Over time, they simply stopped asking me and looked it up for themselves. I never once had to be rude to anyone. You shouldn't have to be either.
At the same time I was reaching for the more subtle point that OS support is just that, OS support. It is only because of our current monolithic OS culture that many people have to come to view the OS as including driver files to support hardware.
And again, it's a conscious decision on the part of the Linux kernel maintainers. If they allowed binary compatibility from version to version of the kernel, hardware vendors could provide their own drivers. Instead, they'd rather write a driver for every piece of hardware in existence. Talk about a needless waste of time.
But wait! It's free as in Libre! (As if the source to a modem driver will matter in 5-10 years.)
Actually, diesel has slightly higher energy density than gasoline.
I did say petroleum. Diesel is petroleum as well.
Personally, I don't see any kind of hydrogen storage becoming anyway near competetive with good old hydrocarbons. In the future we'll probably drive cars that still use hydrocarbon fuels, but use fuel cells instead of internal combustion engines. And the hydrocarbon fuel will be some kind of renewable or synthetic fuel instead of dead dinosaurs.
It takes a tremendous amount of energy and materials to synthesize hydrocarbons. Thus I have some very serious doubts about this method. Hydrogen fuel appears to be the cheapest and easiest fuel storage method currently available. Sure, your MPG will be significantly less, but you'll have a larger tank to accommodate it.
HW vendors don't support Linux for a variety of reasons. One is that they don't see it as a big enough markert. Another is that they fear/dislike/don't understand the GPL. Finally, why write a driver when someone else will write it for you for free!
The real reason is that you can't write a binary driver for Linux. Linus made the choice that kernel modules would be kernel specific. Thus anyone who wants to release a binary module must release one for every "standard" kernel in existence. NVidia attempted this for awhile before finally building an installer that would compile some "glue" code that creates a kernel specific wrapper around their binary module.
Just about every other hardware vendor doesn't care enough to jump through these hoops. Give them a big enough market and they would care. Or make it easy for them to scoop up the small Linux market with a single driver. Since the former isn't working, perhaps some attention should be payed to the later?
Slashdot Mirror
* the term was more liquid in the past
Byte was *never* variable. You're thinking of "word" which represents a natural unit for a system. Thus a PC has a 32 bit word, a Unisys Mainframe has 48 bit words, and an embedded processor has a 16 bit word.
Sorry, but you should have RTFA. It explains that she and her husband (sorry guys) took the standard "tourist" tour through in a car.
At least that explains her stories about all the people who "stayed after the evacuation". There's been a careful, ongoing international study done on the aftermath of the Chernobyl disaster. Her claims just didn't fit the facts of that study.
Of course, the inconsistencies didn't tip me off either. I just thought that she was stretching things a bit. *shrug*
Dude, it was a joke. Laugh. Yes, it's out of date. My review was of Fedora Core 2 Test 1.
If it makes you feel any better, the review in my journal is still up. Maybe if we try hard enough, we can Slashdot, Slashdot. ;-)
You forgot AtheOS.
You appear to misunderstand what a virtual machine is. The BSD kernel in OS X is 100% native code, running 100% in concert with the rest of the system. "Virtual Machine" implies that you are attempting to fool software into believing that it is running on hardware (real or imagined) that it isn't.
Instead, the BSD layer of Mac OS X simply provides a POSIX interface to programs. "Kernel calls" are captured in the BSD kernel server, but are routed to the proper Mach server instead of being routed to the driver or I/O area of a full BSD kernel. Depending on how this is implemented, it could have a very minimal impact on performance. Even if it does slow things down in the processor, programs spend 90% of their time blocking on hardware anyway.
The BSD kernel used on top is not really a kernel in the truest sense. Instead, it's another microkernel server that provides an interface from the programs to the other servers. This design turned out to be quite sensible. It allowed the OS to "skin" its interface with programs on the fly, without inheriting a lot of the faults of the previously monolithic kernels. Thus Apple was able to run OS 9 programs in an OS 9 kernel "server", and then run ultramodern Unix/Cocoa apps in the BSD kernel "server". All without locking up the machine via OS 9's memory problems and poor system drivers.
"It was the dawn of the third age of mankind. Ten years after the Earth-Minbari war,
"the Babylon project was a dream given form
"Its goal: to prevent another war by creating a place where humans and aliens could work out their differences peacefully.
"It's a port-of-call, home away from home for diplomats, hustlers, entrepreneurs, and wanderers.
"Humans and aliens wrapped in two million five hundred thousand tons of spinning metal, all alone in the night.
"It can be a dangerous place, but it's our last, best hope for peace.
"This is the story of the last of the Babylon stations. The year is 2258.
"The name of the place is Babylon5."
"Oh, and GNU Hurd was just released."
annenbaum is also the guy who thought that micro-kernels were a good idea.
I'm sorry, who was it that had that much coveted OS that "just works", and is so cool that everyone wants it but doesn't have the first clue as to how to copy it?
Oh, right. Microkernels seem to work pretty well for Apple.
Linus wrote Linux, and that's all there is to it. Anything to the contrary is Microsoft FUD.
Can't argue with that. I can't read the article, but I don't think that Tannenbaum argues with that either. He probably said something like Linus copied the basic Minix design (true) and the reporter blew it out of proportion.
I've got old skool sound effects right here. The whole game fit in 4K, even won the 4K Java Game programming contest.
It requires that you have Java installed in order to play. It doesn't work on Linux, tho. Sorry. Complain at Sun to get full screen mode working on Linux.
Not to mention that half the time I'm looking for a file that was just dumped to disk by an install, packaging program, or untar. Searching source trees for the file you need is a particularly good example of this.
Grep and find don't pre-index the files.
:-/
"locate" does, but the index is never up to date.
There are a couple things that you have to consider. For one, if part of the disk corrupts, how will you identify a header? Or for that matter, how would you identify the header space vs. file space in a non-corrupted file system?
/usr/local/bin/mybinary
/usr (10) /usr/local (9) /usr/local/bin (72)
/usr/X11R6/include/X11
/usr/local/bin/mybinary, we get 34+10+9+72 = 134 operations.
:-)
You're probably thinking "just store the size of the file", This is perfectly valid, but it does have certain implications. You see, in Comp-Sci, we refer to a list like this as a "linked list". The concept basically being that each item in the list has information (i.e. a "link") that helps identify the next item in the list. Such a data structure has a worst case access time of O(n). Or in other words, if your item is at the end of the list,and you have you have 2000 files, you'll have to check through all two thousand headers before finding your file.
Popular file systems circumvent this by using what's called a Tree structure. A tree is similar to a linked list, but allows for multiple links that point to children of the node. A node that has no children is referred to as a "leaf node". In a file system the directories and files are nodes of a tree, with files being leaf nodes. This configuration gives us two performance characteristics that we must calculate for:
1. The maximum number of children in a node.
2. The maximum depth of the tree.
Let's call them "c" for children and "d" for depth. Our performance formula is now O(c*d) and is irrespective of the number of items in the data structure. Let's make up and example to run this calculation against:
Path:
Nodes:
/ (34)
Longest path:
Plugging the above numbers (72 for c, 4 for d) we get a worst case of 72*4 = 288 operations. Thus our worst case is much better than the linked list. And if we calculate the real case to access
Hope this helps.
It's okay. It just came after a long string of people putting words in my mouth. Just yesterday, I had one guy complain about my use of "most" when I said "many", and another tell me that Diesel was more energy dense than gasoline when I had said "petroleum". I must be doing something wrong here...
What's wrong with just using this?
Last I checked, Sun doesn't allow deployment of the reference implementation.
Did you READ my post? I did say:
.01 atmospheres in a standard blimp). These stronger materials would of course be heavier and thus defeat any gains you would get by creating a vacuum.
The absolute BEST airframe is a complete vacuum. However, an absolute vacuum would require much stronger materials (1-1.5 atmospheres of pressure on the materials vs. a pressure of
Second this a science fair, what did you expect? Booth babes and explosions? This guys blog was meant to just show what some of the project were, not be an informative guide to them. Give him a break already.
No, he was quite right. The pictures *are* boring. I would have expected to see things like hovercraft and pocket nuclear reactors. Instead we're treated to images of this guy's plane ride, his Starbucks purchase, a laser light intro that's only interesting while it's moving, and a Material Safety Data Sheet (MSDS). Since most of us either already know what's on the MSDS or simply don't care, his photojournal ends up being useless.
It's a common mistake. People tend to have the idea in their heads that helium is a magic anti-gravity substance. Once you point out their error to them, they tend to realize that they'd never really considered how it worked in the first place.
In short, cut the guy some slack will ya?
Did you consider compressing the helium? Compressed gasses take up less space, so you would have needed a much smaller envelope.
.01 atmospheres in a standard blimp). These stronger materials would of course be heavier and thus defeat any gains you would get by creating a vacuum.
I'm not completely up to speed on airship technology, but my understanding is that this presents two problems:
1. To compress the helium, you need a stronger gasbag structure. Making the gasbag stronger makes it heavier, thus defeating the purpose of compressing it.
2. Compressing the gas simply adds more gas for the same amount of displacement. Thus you've actually made the blimp or rigid airship heavier instead of lighter.
Keep in mind that airships work by displacing air like boats displace water. The only reason that helium helps generate lift is that it adds structural integrity to the airframe/gasbag while being lighter than if it had been filled with air. The absolute BEST airframe is a complete vacuum. However, an absolute vacuum would require much stronger materials (1-1.5 atmospheres of pressure on the materials vs. a pressure of
Actually, I recently considered what it would take to build a go kart for the sky. My idea was to take a basic frame (like that of a go-kart), add blimp-like "pontoons" to the sides, and attach a lightweight propeller to the back. I figured that if I could get it to lift a few hundred pounds, I'd have myself a new way of getting to work. The problem came in when I did the actual calculations.
.4 kilograms of helium. This didn't sound so bad until I found out that the .4 kilograms of helium takes up about 1 cubic meter of space. I then assumed two gasbags, each one cylindrical, about one meter in diameter, and 4.9 meters in length. This worked out to about 8 cubic meters. (.5^2 * 3.14 * 4.9 * 2 = 7.693 m^3) 8 cubic meters would only give me 8 kilograms of lift! I then did the figures to lift 250kg of weight, and found that I'd need a gasbag the size of my living room to lift it.
To lift one kilogram of weight, I need about
Ah well, another idea bites the dust.
Hello Shish.
*sigh*
So much time spent on JOSRTS and I STILL couldn't get you to learn patience. I understand that it's easy to get frustrated. But when people don't know something, they stumble around looking for answers. Given that many users are from a generation that is used to asking live people, they contact support instead of looking for a FAQ or manual.
All of this is irrelevant anyway. In this case he called support. Support told him that it should work but it doesn't. The community then told him that it was his own damn fault (why?) and that they knew all the answers. He provided them with the specs, and the community then continued to claim he was stupid, but changed their tune to say that Linux should be used for Enterprise stuff and who cares about sound?
I've found that most of the time RTFM + flames is a *good* answer - it trains the user to look things up for themselves rather than to get me to look it up for them.
There are ways of doing that without berating people. I used to have to deal with a bunch of Unix neophytes who hated to look up command line commands for themselves. I simply got in the habit of first asking, "did you try the 'man' command?" Usually they'd sheepishly go back and try the 'man' command. If 'man' didn't help, then I'd answer their question. Over time, they simply stopped asking me and looked it up for themselves. I never once had to be rude to anyone. You shouldn't have to be either.
At the same time I was reaching for the more subtle point that OS support is just that, OS support. It is only because of our current monolithic OS culture that many people have to come to view the OS as including driver files to support hardware.
And again, it's a conscious decision on the part of the Linux kernel maintainers. If they allowed binary compatibility from version to version of the kernel, hardware vendors could provide their own drivers. Instead, they'd rather write a driver for every piece of hardware in existence. Talk about a needless waste of time.
But wait! It's free as in Libre! (As if the source to a modem driver will matter in 5-10 years.)
Actually, diesel has slightly higher energy density than gasoline.
I did say petroleum. Diesel is petroleum as well.
Personally, I don't see any kind of hydrogen storage becoming anyway near competetive with good old hydrocarbons. In the future we'll probably drive cars that still use hydrocarbon fuels, but use fuel cells instead of internal combustion engines. And the hydrocarbon fuel will be some kind of renewable or synthetic fuel instead of dead dinosaurs.
It takes a tremendous amount of energy and materials to synthesize hydrocarbons. Thus I have some very serious doubts about this method. Hydrogen fuel appears to be the cheapest and easiest fuel storage method currently available. Sure, your MPG will be significantly less, but you'll have a larger tank to accommodate it.
HW vendors don't support Linux for a variety of reasons. One is that they don't see it as a big enough markert. Another is that they fear/dislike/don't understand the GPL. Finally, why write a driver when someone else will write it for you for free!
The real reason is that you can't write a binary driver for Linux. Linus made the choice that kernel modules would be kernel specific. Thus anyone who wants to release a binary module must release one for every "standard" kernel in existence. NVidia attempted this for awhile before finally building an installer that would compile some "glue" code that creates a kernel specific wrapper around their binary module.
Just about every other hardware vendor doesn't care enough to jump through these hoops. Give them a big enough market and they would care. Or make it easy for them to scoop up the small Linux market with a single driver. Since the former isn't working, perhaps some attention should be payed to the later?