... that the only science of intelligent design... IS the science of evolution.
The reason IMO, even as a staunch defender of intelligent design theories, that this is the correct move, is because the only real science (currently) for intelligent design, is the exact same science as that of darwin's evolution.
I.e. the only way to prove evolution is to design a repeatable experiment, whereby the experimenter designs the environment of the experiment (e.g. with fruitflys), and then evolution occurs before the naked eye, as organisms adapt, or are selected by fitness, and ultimately evolve in the controlled confines of this scientifically reproducable experiment.
Of course, the irony is that this simultaneously proves both evolution, and intelligent design. Because without an intelligent designer of the experiment intervening and subverting nature, there would be no results and no new life forms to witness.
Precisely sir, "the system's design makes the administration requirements". We are discussing system design here, and whether or not the addition of selinux is a benefit or a detriment. And for the sake of argument, we are not really discussing specific security measures, but rather selinux as a whole.
As a whole, the introduction of selinux into your system design, will *ADD REDUNDANT* administration requirements. To me that is a negative. The security added by selinux is a positive. Each system you design will have varying needs for security, and those needs should dictate your system design, including whether or not to use selinux.
I'm saying, that if selinux were smart enough to respect and obey the user intentions reflected by the httpd.conf file, rather than duplicately hard coding the defaults of those values into it's own config files, that the system would be (IMO much) better.
But please, by all means, go on arguing why you have no complaints about a system design that requires redundant administration steps. And then reread my statements, and realize that when I say "the system" I mean the entire blackbox appliance, to which you have written an administration manual for, so that your employer needn't be tied to having to hire an expensive human administrator who is well versed in esoteric selinux management. And the real point to all of this, is to simplify that administration manual as much as possible, because when you have redundant steps, you are adding complexity to the system. And unnecessary administrative complexity makes a system LESS SECURE AND MORE PRONE TO FAILURE. Let alone the fact that your engineers could be dedicating those esoteric selinux brain cells to features in the actual product or service you are developing or supporting.
So are you telling me that cp --preserve=all will be sufficient, and that I won't run into problems because "/var/www" is 'hard coded' in config files under/etc/selinux? (I.e. are the/var/www entries in/etc/selinux/ just for initialization and won't interfere if I've done the cp --preserve=all)?
For the record, I was never talking about installing things from source. And what you said only applies to my case if "redhat does not officially support moving docroot away from/var/www". And that is only if they haven't tweaked things in the years since I recalled having that issue. I assumed (perhaps incorrectly) that there was an selinux policy config for apache that limited it's access to files there. Perhaps that is not the issue. Honestly given the perceived complexity of SELinux, I have never wanted to research the issue to conclusion (though I admit I've most likely wasted more time arguing about it).
I'm quite certain that at some point this will be 'fixed' if it is not already. Perhaps a system event (watched file modification) notification system will cause edits to httpd.conf to trigger into some selinux intelligent subroutine that "does the right thing(tm)". Or perhaps the redhat vision is that all software that was designed to be configured via manual editing of files, will be eradicated from their distribution and replaced with some 'master configuration process' which selinux is intimitely tied to.
whatever... I just hope to avoid it until somehow it's implemented so well that I can get its benefits without having to understand and administer it. Because that takes time, and attention that I'd rather spend elsewhere.
It's called software design you idiot. The apache webserver was designed so that if I want to move docroot, I edit a setting in httpd.conf. THAT ADMINISTRATOR ACTION IS WHAT TELLS THE SYSTEM THAT APACHE IS NOW ALLOWED TO ACCESS THE FILES IN THE NEW LOCATION.
Any further administrative actions required which DO NOTHING MORE THAN EMPHASIZE THE INTENTION OF THE ORIGINAL ACTION, are evidence of a poorly designed security system. IMO.
I think at some point, SELinux was touted as being a *transparent* security enhancement. Which sounded really cool to me. Then I discovered that it was a _vastly complex beast that required constant attention in order to prevent breakage of applications in situations where those applications were being used precisely as the application developers had intended_.
SELinux is hard to use. The amount of energy required by my brain to contemplate MAC policies for all the types of situations I run into, is not worth the security it is bringing me.
Just because all the coders who wrote the linux kernel, apache webserver, and distribution I was using didn't know how to implement SELinux's features in the first place, does NOT mean that they were stupid, or that their code was broken.
The question is whether or not selinux is worth the trouble. I'm arguing (not alone dare I say) that in a lot of situations (majority? vast majority?) it is not. But don't give me this bullshit about 'because I don't know how to use it doesn't mean it's broken'.
Great, after decades with --archive --verbose being sufficient cp flag knowlege, now I have to pay attention to some new crap. (i.e. the main point I was making). Somehow having to learn to deal with and use --sparse for tar seemed less offensive to me. Mainly I suppose because the --sparse gives me immediate satisfaction of seeing the benefits of a new feature (i.e. free disk space, smaller files, etc...). Wheras the --preserve=context and selinux only give me "security". Personally I'll stick with the philosophy that security should be part of the foundation, invisible to the user interface. (not that I won't use selinux where appropriate, just that I'll continue to be vocally annoyed).
First, my name doesn't have to be Bruce Schneier to dismiss anybody claiming "100% protection".
Second, I have nothing against SELinux, though I will consider it broken until a default install handles this situation correctly-
1) I install the OS, leaving the default selinux enabled 2) after running a webserver for awhile, I decide I want to move my apache's docroot from/var/www/html to/mnt/data/www/html, after having mkfs.ext3'd some partition and mounted it at/mnt/data. 3) naturally after "cp -av/var/www/mnt/data" as root, I edit/etc/httpd/conf/httpd.conf, changing any instance of/var/www to/mnt/data/www" 4) I run 'service httpd restart' (reload should work as well of course)
The last time I tried this with a version of redhat/fedora that had selinux enabled, it failed. And for most of the sites I'm serving (many that are never seen outside my home non-internet-connected lan), I see no motivation to invest my time in selinux.
Now mind you, I completely expect things like this to be worked out by the selinux folks, if they haven't been already. The last redhat person I spoke with who defended the above, claimed that they didn't want people mucking around with commandlines and editing configfiles. I then asked that person how I should have gone about changing my DocRoot in such a way that SELinux "just worked". I got no reply. Given no reply, I can speculate as to one- They expect/var/www/html to always be the docroot, and/var to be on LVM and online expandable. Ok. Whatever.
In the absence of a well known specifically laid out variant of ID, philosophy is all this was ever about, and you have been philosophizing all along without realizing it.
I.e. scientifically we weren't debating 'evolution'. That's just a word, perhaps with as many subtle variants of meaning as the word 'universe'. Scientifically we were discussing _darwins_ theory of evolution, versus the philosophy of Intelligent Design.
If you'd really like to vet out a scientific theory of intelligent design, then point me to the author of the theory's whitepaper, and there is about a 95% chance that I'll join in with you in bashing it's author's lack of scientific rigor. Of course, I am genuinely interested in the 5% chance that I might run across an ID theory that is as _scientifically_ attackable as **darwin's** theory of evolution.
Please forgive me... I admit that my philosophizing with a confused scientist, was perhaps a bit of a troll. But given how much irrational BS comes out of scientists when they attack the _philosophy_ of ID _as_ science, I feel I need to do my part to make them look just as foolish as they think they are making the ID philosophers look.
In closing- It all boils down to a scientific whitepaper/treatise/whatever. If you start attacking ID without prefixing it with something as specific as "darwin's theory of", then you are philosophizing whether you are aware of it or not.
Wierd, that i.e. e.g. thing must have been part of your sig. Anyway, it's what earned this reply (i.e. thanks for the education, though I think for the most part I was using i.e. correctly).
I see a few issues with your response, which all really boil down to the fact that I.D. is not a theory, in the same league with a specific theory laid out by a specific scientist.
I personally defend ID because I think time may yet reveal a good theory based around the idea that "most if not all of what we see around us is the result of intelligent design".
So, to counter your points-
"whereas ID seeks to act as a theory for where all life came from"
This is wrong for the reasons mentioned above. It may be a perfectly valid attack against many other people's personal ID variants, but not mine. And I hope that given your reply to me, that you respect my reasoning enough to grant that my above personal ID variant is worth debating.
next-
"If that source can produce a being capable of high intelligence and creating the universe"
I point out again the semantic issue of what one means by the word 'universe'. It's one of those tricky words like 'natural' or 'should'. Maybe you can whip out the historical derivation of the world that I'm too lazy to google, but I see the emphasis on "uni" as in "the one thing", the implication being that _any_ _thing_ must be a part of or a subset of _the_ 'universe'. Thus with my semantics, any and all creators are 'things' which must by _definition_ be part of _the_ universe. Thus your above statement really makes no sense with my semantics. Once you open the semantic door to *other* universeS, then I can just call any particular zoo a "universe" which was obviously intelligently designed. Thus ID has been proven, QED.
And finally-
"After all, since we haven't seen any intelligent designers spontaneously form in nature"
This is so obviously wrong... Genetically engineered crops, any example of human architecture, embryo's selected due to sex or lack of genetic disease traits,... The world is RIFE with intelligent designers that have spontaneously formed in nature. (oops, 'nature' is another of those tricky words...)
" The problem is that any such Alien Designer would have had to evolve himself, which is impossible according to "Intelligent Design". "
See, when you use (incidentally wrong and baseless) absolutes like this, people like me get to shoot down your argument wholesale by attacking a single sentence.
I'll grant, that any variant of ID that states that Everything* was created by a creator, is scientifically ludicrous. But take for example what a hypothetically intelligent chimp living in a zoo would come to believe over time. With sufficient intelligence, it could really only conclude that its entire environment was intelligently designed by one or more members of another species. Perhaps even a species that is so closely related to itself, that it could be thought of as a distant relative (perhaps not a father per-se...). Now, would this chimp in one lifetime without access to a vast social information network be able to come to understand the complete process by which scientific evolution surrounded him with nearly perfect cylindrical refined metal bars that restrict his movement?
All I'm saying is that the idea that the vast majority of what we see around us, is the result of some intelligent design, does not seem so ludicrous to me, even outside my religous faith. I mean, do you find it inconceivable that in the next 200 years, mankind might not genetically engineer the vast majority of our crops, and somewhere along the line annihilate ourselves and our civilization. And then in a few hundred/thousand/million years some of the survivors evolve to our current technological level. In that scenario, would it be wrong to say that their entire environment was intelligently designed? Right down to the nature of the food crops they eat?
I know about occams razor, and honestly the idea that we are currently the VERY FIRST EVOLUTION OF INTELLIGENCE IN OUR SOLAR SYSTEM to our level of technology, over the last BILLIONS OF YEARS, just seems far less likely to me, than the idea that some ancestors or ancient species (or individual/collective-hivelike-consciousness) didn't signifigantly and radically shape (if not outright create) our environment. (and possibly leave some symbolic history, which no doubt would have suffered horrible degradation over the millenia, much like the traditional children's 'phone game')
* thats the big E, what I would equate with my definition of the Universe. I.e. by my definition of Universe, there ain't no 'other Universes'. But thats a semantic issue.
Here is the not tremendously mature code for doing wifi on the NDS.
On the other hand, there are a couple articles in the slashdot submission queue pointing out the release of homebrew quake (with wifi) for the NDS. So its fair to say it's a solved problem. But again, there is a fair amount of work to be done as far as releasing a truly polished, complete, easy to use development environment for the NDS. What is there is certainly not bad, but it is a bit rough around the edges.
I'll admit, that the development environment for the NDS is lacking, and that would be a big selling point for the Qwerk at this moment. But what is important to keep in mind is that the NDS dev env isn't lacking due to any fundamental DRM or otherwise locked down or obfuscation problem. It really just needs some more elbow grease from the community to polish what we already have. I'm personally doing my small part to that end.
Now then, to answer your question about the RoboDS which isn't _quite_ shipping yet (This person/people have a good track record however, the DSerial(2) had a similar pre-order/ship-date, and they absolutely hit it. Also, the schematic and parts list for the DSerial are available, so there is no reason that were it popular, any manufacturer or university, couldn't produce however many they needed to fill demand.
As for specs, it's probably best to look at the specs of the NDS and DSerial2. The RoboDS is just a few rudimentary physical parts. Abbreviating the NDS- An ARM7 AND and ARM9, 802.11, 2 LCD screens, one with touchpad, microphone, stereo speakers, headphone jack, buttons.
The Supercard-Lite-MicroSD gives you up to 2GB(+?) flash memory support, 32MB of ram (in addition to the 4MB that the NDS has natively)
And cutting and pasting from the natrium website regarding the DSerial2
# 8051 microcontroller running at 24MHz # Reprogrammable from DS, firmwares available at NaWiki # Free development tools available # 18 GPIO lines, 2 status LEDs # UART with RS-232 level converter (can be disabled) # Full-speed USB 2.0 device # PWM and ADC available # 2D tilt sensor
Combine with the open source full linux wifi environment, and I don't know why you'd want to spend $350 on that controller (I'm lazy and haven't even read the specs on the thing, but seriously, I can't imagine there is anything the roboDS can't do that it could)
Re:No. - Re:Wouldn't a live CD do this?
on
A Closed Off System?
·
· Score: 2, Insightful
"Out of my way" is as vague a phrase as "should". Yes I had to follow some instructions, but technically I'm also following instructions when I dial my phone.
Yes the bootloader only needs to be on the blessed list, but in the absence of a blessed bootloader which allows arbitrary code to execute...
To your last point, signing and verifying every executable is not a heavy CPU tax. The real issue is the granularity, and if you can prevent any excutable which intentionally or unintentionally allows arbitrary external code to be executed from getting blessed.
No. - Re:Wouldn't a live CD do this?
on
A Closed Off System?
·
· Score: 5, Insightful
No. LiveCDs do offer read-only system images. But they do nothing whatsoever to prevent other programs from being run. I.e. programs downloaded from the net, autorun(or manually) from cd.
LiveCDs get you the benefit that each reboot resets you to an known state. That is quite different from an OS which only allows programs from a blessed whitelist to execute.
One scenario might be the discovery of way to remotely log into the system. In the livecd case, the attacker can now run whatever program they want, and likely regain entry in an identical fashion should the system be rebooted. What the author of this post is interested in, is a system what would not let the attacker with remote login be able to execute any code not on the blessed whitelist.
Now mind you, the idea that such a system would be 'invulnerable' is ludicrous. The XBox seems the quintessential example of a system which tried to achieve this design goal. My XBox currently runs ssh, freevo, and any executable I want, proving it is difficult to achieve a successful implementation of such a design.
-jdog
Is there truly no way to detect that the current running OS is running on virtualized hardware?
I mean, sure the toplevel malware kernel can intercept attempts to read the current running kernel and other memory/system locations. And that all becomes a cat and mouse excercise. But thats how rootkit security has always been. Again, what I'm asking to someone knowledgable is- does the new wave of hardware supported virtualization make it truly impossible for a process in the virtualized host to detect that it's been virtualized?
I mean, couldn't you look at the reported processor, and run a suite of simple benchmark code, and detect that a parasite meta-host is sucking away cycles that you expect to be there (this assumes the benchmark/detection code is run as root/kernel, and can therefore stop/ignore all other processes for some inconsequential amount of time).
> but it seems to need root permissions to start (installed with sudo on the 'binary' installer)
I for one had no problem installing and running as a user under fedora core 5. Perhaps the fact that you installed it with sudo (rather than as a user) is the problem. I would try, for a global installation, using sudo to create a world writable/usr/local/GoogleEarth directory, then install as a user to there.
I know you're not kidding, but someone needs to set you straight-
RPMs, at least the ones in fedora (and I'm pretty sure the rest), hold very well (never seen an exception), to the specification that no user interaction is required for a default install.
Debian packages are _supposed_ to have this behaviour, if you specify the environment priority=critical, but there are dozens of stable packages which do NOT obey. The result is that if you want a truly unattented install, you are borked, until you spend gobs of time tracking down registry settings to preseed. Even then there are a couple more that aren't even that easy to fix.
Now, this is a totally fixable set of bugs, and in fact there is a nice web page that enumerates which packages are broken. But there are a lot of them. And I can't see why debian didn't see the wisdom of redhat's implementational choice of "make every package install with sane defaults, and let the user configure more after installation if they want to".
I'll admit, that I think the ideal solution would be a blending of the two, where you can specify a flag to rpm/yum/apt saying "interrupt me with detailed configuration dialogs _right now_". But the fact remains, doing unattended installs with debian is a royal pain in the ass, compared to rpm based distros.
Slashdot Mirror
I don't have any mod points today :(
Yes, this has nothing to do with microsoft, but the borg tag seems so much more relevent...
... that the only science of intelligent design ... IS the science of evolution.
The reason IMO, even as a staunch defender of intelligent design theories, that this is the correct move, is because the only real science (currently) for intelligent design, is the exact same science as that of darwin's evolution.
I.e. the only way to prove evolution is to design a repeatable experiment, whereby the experimenter designs the environment of the experiment (e.g. with fruitflys), and then evolution occurs before the naked eye, as organisms adapt, or are selected by fitness, and ultimately evolve in the controlled confines of this scientifically reproducable experiment.
Of course, the irony is that this simultaneously proves both evolution, and intelligent design. Because without an intelligent designer of the experiment intervening and subverting nature, there would be no results and no new life forms to witness.
God Speed Mr Wiz... -dmc
Precisely sir, "the system's design makes the administration requirements". We are discussing system design here, and whether or not the addition of selinux is a benefit or a detriment. And for the sake of argument, we are not really discussing specific security measures, but rather selinux as a whole.
As a whole, the introduction of selinux into your system design, will *ADD REDUNDANT* administration requirements. To me that is a negative. The security added by selinux is a positive. Each system you design will have varying needs for security, and those needs should dictate your system design, including whether or not to use selinux.
I'm saying, that if selinux were smart enough to respect and obey the user intentions reflected by the httpd.conf file, rather than duplicately hard coding the defaults of those values into it's own config files, that the system would be (IMO much) better.
But please, by all means, go on arguing why you have no complaints about a system design that requires redundant administration steps. And then reread my statements, and realize that when I say "the system" I mean the entire blackbox appliance, to which you have written an administration manual for, so that your employer needn't be tied to having to hire an expensive human administrator who is well versed in esoteric selinux management. And the real point to all of this, is to simplify that administration manual as much as possible, because when you have redundant steps, you are adding complexity to the system. And unnecessary administrative complexity makes a system LESS SECURE AND MORE PRONE TO FAILURE. Let alone the fact that your engineers could be dedicating those esoteric selinux brain cells to features in the actual product or service you are developing or supporting.
So are you telling me that cp --preserve=all will be sufficient, and that I won't run into problems because "/var/www" is 'hard coded' in config files under /etc/selinux? (I.e. are the /var/www entries in /etc/selinux/ just for initialization and won't interfere if I've done the cp --preserve=all)?
For the record, I was never talking about installing things from source. And what you said only applies to my case if "redhat does not officially support moving docroot away from /var/www". And that is only if they haven't tweaked things in the years since I recalled having that issue. I assumed (perhaps incorrectly) that there was an selinux policy config for apache that limited it's access to files there. Perhaps that is not the issue. Honestly given the perceived complexity of SELinux, I have never wanted to research the issue to conclusion (though I admit I've most likely wasted more time arguing about it).
I'm quite certain that at some point this will be 'fixed' if it is not already. Perhaps a system event (watched file modification) notification system will cause edits to httpd.conf to trigger into some selinux intelligent subroutine that "does the right thing(tm)". Or perhaps the redhat vision is that all software that was designed to be configured via manual editing of files, will be eradicated from their distribution and replaced with some 'master configuration process' which selinux is intimitely tied to.
whatever... I just hope to avoid it until somehow it's implemented so well that I can get its benefits without having to understand and administer it. Because that takes time, and attention that I'd rather spend elsewhere.
It's called software design you idiot. The apache webserver was designed so that if I want to move docroot, I edit a setting in httpd.conf. THAT ADMINISTRATOR ACTION IS WHAT TELLS THE SYSTEM THAT APACHE IS NOW ALLOWED TO ACCESS THE FILES IN THE NEW LOCATION.
Any further administrative actions required which DO NOTHING MORE THAN EMPHASIZE THE INTENTION OF THE ORIGINAL ACTION, are evidence of a poorly designed security system. IMO.
I think at some point, SELinux was touted as being a *transparent* security enhancement. Which sounded really cool to me. Then I discovered that it was a _vastly complex beast that required constant attention in order to prevent breakage of applications in situations where those applications were being used precisely as the application developers had intended_.
SELinux is hard to use. The amount of energy required by my brain to contemplate MAC policies for all the types of situations I run into, is not worth the security it is bringing me.
Just because all the coders who wrote the linux kernel, apache webserver, and distribution I was using didn't know how to implement SELinux's features in the first place, does NOT mean that they were stupid, or that their code was broken.
The question is whether or not selinux is worth the trouble. I'm arguing (not alone dare I say) that in a lot of situations (majority? vast majority?) it is not. But don't give me this bullshit about 'because I don't know how to use it doesn't mean it's broken'.
Great, after decades with --archive --verbose being sufficient cp flag knowlege, now I have to pay attention to some new crap. (i.e. the main point I was making). Somehow having to learn to deal with and use --sparse for tar seemed less offensive to me. Mainly I suppose because the --sparse gives me immediate satisfaction of seeing the benefits of a new feature (i.e. free disk space, smaller files, etc...). Wheras the --preserve=context and selinux only give me "security". Personally I'll stick with the philosophy that security should be part of the foundation, invisible to the user interface. (not that I won't use selinux where appropriate, just that I'll continue to be vocally annoyed).
First, my name doesn't have to be Bruce Schneier to dismiss anybody claiming "100% protection".
/var/www/html to /mnt/data/www/html, after having mkfs.ext3'd some partition and mounted it at /mnt/data. /var/www /mnt/data" as root, I edit /etc/httpd/conf/httpd.conf, changing any instance of /var/www to /mnt/data/www"
/var/www/html to always be the docroot, and /var to be on LVM and online expandable. Ok. Whatever.
Second, I have nothing against SELinux, though I will consider it broken until a default install handles this situation correctly-
1) I install the OS, leaving the default selinux enabled
2) after running a webserver for awhile, I decide I want to move my apache's docroot from
3) naturally after "cp -av
4) I run 'service httpd restart' (reload should work as well of course)
The last time I tried this with a version of redhat/fedora that had selinux enabled, it failed. And for most of the sites I'm serving (many that are never seen outside my home non-internet-connected lan), I see no motivation to invest my time in selinux.
Now mind you, I completely expect things like this to be worked out by the selinux folks, if they haven't been already. The last redhat person I spoke with who defended the above, claimed that they didn't want people mucking around with commandlines and editing configfiles. I then asked that person how I should have gone about changing my DocRoot in such a way that SELinux "just worked". I got no reply. Given no reply, I can speculate as to one- They expect
In the absence of a well known specifically laid out variant of ID, philosophy is all this was ever about, and you have been philosophizing all along without realizing it.
I.e. scientifically we weren't debating 'evolution'. That's just a word, perhaps with as many subtle variants of meaning as the word 'universe'. Scientifically we were discussing _darwins_ theory of evolution, versus the philosophy of Intelligent Design.
If you'd really like to vet out a scientific theory of intelligent design, then point me to the author of the theory's whitepaper, and there is about a 95% chance that I'll join in with you in bashing it's author's lack of scientific rigor. Of course, I am genuinely interested in the 5% chance that I might run across an ID theory that is as _scientifically_ attackable as **darwin's** theory of evolution.
Please forgive me... I admit that my philosophizing with a confused scientist, was perhaps a bit of a troll. But given how much irrational BS comes out of scientists when they attack the _philosophy_ of ID _as_ science, I feel I need to do my part to make them look just as foolish as they think they are making the ID philosophers look.
In closing- It all boils down to a scientific whitepaper/treatise/whatever. If you start attacking ID without prefixing it with something as specific as "darwin's theory of", then you are philosophizing whether you are aware of it or not.
Be seeing you...
Wierd, that i.e. e.g. thing must have been part of your sig. Anyway, it's what earned this reply (i.e. thanks for the education, though I think for the most part I was using i.e. correctly).
... The world is RIFE with intelligent designers that have spontaneously formed in nature. (oops, 'nature' is another of those tricky words...)
I see a few issues with your response, which all really boil down to the fact that I.D. is not a theory, in the same league with a specific theory laid out by a specific scientist.
I personally defend ID because I think time may yet reveal a good theory based around the idea that "most if not all of what we see around us is the result of intelligent design".
So, to counter your points-
"whereas ID seeks to act as a theory for where all life came from"
This is wrong for the reasons mentioned above. It may be a perfectly valid attack against many other people's personal ID variants, but not mine. And I hope that given your reply to me, that you respect my reasoning enough to grant that my above personal ID variant is worth debating.
next-
"If that source can produce a being capable of high intelligence and creating the universe"
I point out again the semantic issue of what one means by the word 'universe'. It's one of those tricky words like 'natural' or 'should'. Maybe you can whip out the historical derivation of the world that I'm too lazy to google, but I see the emphasis on "uni" as in "the one thing", the implication being that _any_ _thing_ must be a part of or a subset of _the_ 'universe'. Thus with my semantics, any and all creators are 'things' which must by _definition_ be part of _the_ universe. Thus your above statement really makes no sense with my semantics. Once you open the semantic door to *other* universeS, then I can just call any particular zoo a "universe" which was obviously intelligently designed. Thus ID has been proven, QED.
And finally-
"After all, since we haven't seen any intelligent designers spontaneously form in nature"
This is so obviously wrong... Genetically engineered crops, any example of human architecture, embryo's selected due to sex or lack of genetic disease traits,
Anyway, it's been fun philosophizing with you...
peace...
-dmc/jdog
"
The problem is that any such Alien Designer would have had to evolve himself, which is impossible according to "Intelligent Design".
"
See, when you use (incidentally wrong and baseless) absolutes like this, people like me get to shoot down your argument wholesale by attacking a single sentence.
I'll grant, that any variant of ID that states that Everything* was created by a creator, is scientifically ludicrous. But take for example what a hypothetically intelligent chimp living in a zoo would come to believe over time. With sufficient intelligence, it could really only conclude that its entire environment was intelligently designed by one or more members of another species. Perhaps even a species that is so closely related to itself, that it could be thought of as a distant relative (perhaps not a father per-se...). Now, would this chimp in one lifetime without access to a vast social information network be able to come to understand the complete process by which scientific evolution surrounded him with nearly perfect cylindrical refined metal bars that restrict his movement?
All I'm saying is that the idea that the vast majority of what we see around us, is the result of some intelligent design, does not seem so ludicrous to me, even outside my religous faith. I mean, do you find it inconceivable that in the next 200 years, mankind might not genetically engineer the vast majority of our crops, and somewhere along the line annihilate ourselves and our civilization. And then in a few hundred/thousand/million years some of the survivors evolve to our current technological level. In that scenario, would it be wrong to say that their entire environment was intelligently designed? Right down to the nature of the food crops they eat?
I know about occams razor, and honestly the idea that we are currently the VERY FIRST EVOLUTION OF INTELLIGENCE IN OUR SOLAR SYSTEM to our level of technology, over the last BILLIONS OF YEARS, just seems far less likely to me, than the idea that some ancestors or ancient species (or individual/collective-hivelike-consciousness) didn't signifigantly and radically shape (if not outright create) our environment. (and possibly leave some symbolic history, which no doubt would have suffered horrible degradation over the millenia, much like the traditional children's 'phone game')
* thats the big E, what I would equate with my definition of the Universe. I.e. by my definition of Universe, there ain't no 'other Universes'. But thats a semantic issue.
Here is the not tremendously mature code for doing wifi on the NDS.
On the other hand, there are a couple articles in the slashdot submission queue pointing out the release of homebrew quake (with wifi) for the NDS. So its fair to say it's a solved problem. But again, there is a fair amount of work to be done as far as releasing a truly polished, complete, easy to use development environment for the NDS. What is there is certainly not bad, but it is a bit rough around the edges.
http://akkit.org/dswifi/
I'll admit, that the development environment for the NDS is lacking, and that would be a big selling point for the Qwerk at this moment. But what is important to keep in mind is that the NDS dev env isn't lacking due to any fundamental DRM or otherwise locked down or obfuscation problem. It really just needs some more elbow grease from the community to polish what we already have. I'm personally doing my small part to that end.
Now then, to answer your question about the RoboDS which isn't _quite_ shipping yet (This person/people have a good track record however, the DSerial(2) had a similar pre-order/ship-date, and they absolutely hit it. Also, the schematic and parts list for the DSerial are available, so there is no reason that were it popular, any manufacturer or university, couldn't produce however many they needed to fill demand.
As for specs, it's probably best to look at the specs of the NDS and DSerial2. The RoboDS is just a few rudimentary physical parts. Abbreviating the NDS- An ARM7 AND and ARM9, 802.11, 2 LCD screens, one with touchpad, microphone, stereo speakers, headphone jack, buttons.
The Supercard-Lite-MicroSD gives you up to 2GB(+?) flash memory support, 32MB of ram (in addition to the 4MB that the NDS has natively)
And cutting and pasting from the natrium website regarding the DSerial2
# 8051 microcontroller running at 24MHz
# Reprogrammable from DS, firmwares available at NaWiki
# Free development tools available
# 18 GPIO lines, 2 status LEDs
# UART with RS-232 level converter (can be disabled)
# Full-speed USB 2.0 device
# PWM and ADC available
# 2D tilt sensor
-dmc/jdog
$129 - Nintendo DS
$54 - Supercard-Lite-MicroSD
$15 - 1GB microSD
$49 - DSerial2
$99 - RoboDS
---
$350
Combine with the open source full linux wifi environment, and I don't know why you'd want to spend $350 on that controller (I'm lazy and haven't even read the specs on the thing, but seriously, I can't imagine there is anything the roboDS can't do that it could)
http://www.natrium42.com/shop/robods.php
-dmc/jdog
Ahh, and I thought I wouldn't get to talk about usenet again until the retirement home...
if I had moderator status, I'd do it myself
"Out of my way" is as vague a phrase as "should". Yes I had to follow some instructions, but technically I'm also following instructions when I dial my phone.
Yes the bootloader only needs to be on the blessed list, but in the absence of a blessed bootloader which allows arbitrary code to execute...
To your last point, signing and verifying every executable is not a heavy CPU tax. The real issue is the granularity, and if you can prevent any excutable which intentionally or unintentionally allows arbitrary external code to be executed from getting blessed.
No. LiveCDs do offer read-only system images. But they do nothing whatsoever to prevent other programs from being run. I.e. programs downloaded from the net, autorun(or manually) from cd. LiveCDs get you the benefit that each reboot resets you to an known state. That is quite different from an OS which only allows programs from a blessed whitelist to execute. One scenario might be the discovery of way to remotely log into the system. In the livecd case, the attacker can now run whatever program they want, and likely regain entry in an identical fashion should the system be rebooted. What the author of this post is interested in, is a system what would not let the attacker with remote login be able to execute any code not on the blessed whitelist. Now mind you, the idea that such a system would be 'invulnerable' is ludicrous. The XBox seems the quintessential example of a system which tried to achieve this design goal. My XBox currently runs ssh, freevo, and any executable I want, proving it is difficult to achieve a successful implementation of such a design. -jdog
Is there truly no way to detect that the current running OS is running on virtualized hardware?
I mean, sure the toplevel malware kernel can intercept attempts to read the current running kernel and other memory/system locations. And that all becomes a cat and mouse excercise. But thats how rootkit security has always been. Again, what I'm asking to someone knowledgable is- does the new wave of hardware supported virtualization make it truly impossible for a process in the virtualized host to detect that it's been virtualized?
I mean, couldn't you look at the reported processor, and run a suite of simple benchmark code, and detect that a parasite meta-host is sucking away cycles that you expect to be there (this assumes the benchmark/detection code is run as root/kernel, and can therefore stop/ignore all other processes for some inconsequential amount of time).
-jdog
> but it seems to need root permissions to start (installed with sudo on the 'binary' installer)
/usr/local/GoogleEarth directory, then install as a user to there.
I for one had no problem installing and running as a user under fedora core 5. Perhaps the fact that you installed it with sudo (rather than as a user) is the problem. I would try, for a global installation, using sudo to create a world writable
Can someone please explain to me how vancorps article here got moderated a 5informative?
:(
Does mentioning nlite automod you all the way up?
I'll give it a 3informative+deficientverbalizationskills, but a 5? Puhleez... (and 3 seems a bit generous, though I've yet to achieve one...
I know you're not kidding, but someone needs to set you straight-
RPMs, at least the ones in fedora (and I'm pretty sure the rest), hold very well (never seen an exception), to the specification that no user interaction is required for a default install.
Debian packages are _supposed_ to have this behaviour, if you specify the environment priority=critical, but there are dozens of stable packages which do NOT obey. The result is that if you want a truly unattented install, you are borked, until you spend gobs of time tracking down registry settings to preseed. Even then there are a couple more that aren't even that easy to fix.
Now, this is a totally fixable set of bugs, and in fact there is a nice web page that enumerates which packages are broken. But there are a lot of them. And I can't see why debian didn't see the wisdom of redhat's implementational choice of "make every package install with sane defaults, and let the user configure more after installation if they want to".
I'll admit, that I think the ideal solution would be a blending of the two, where you can specify a flag to rpm/yum/apt saying "interrupt me with detailed configuration dialogs _right now_". But the fact remains, doing unattended installs with debian is a royal pain in the ass, compared to rpm based distros.
-jdog