Have you improved it to the point that when the system is borderline out of main memory or has a moderately high load average it actually *works* as a desktop system?
E.g. when Firefox is consuming 65-70% of main memory and slower than #%#$ and you know it is waiting on swapped out pages and your swap rate is measured in the dozens to hundreds rather than hundreds to thousands (on vmstat)? (I mean really, how can one take an operating system seriously when only memory is at 100% and not CPU + memory + Disk I/O?)
The real issue, for those who have read comments that Con has made in interviews, seems to be the lack of concern on the part of most of the "in-crowd" Linux developers for performance on the desktop. In part this seems driven by the fact that the people who actually get paid to maintain Linux, benchmark it and "improve" it only care about its performance in server farms and *not* on the individual desktop. I will weigh in on the side of desktop user out there (that wants the Linux sitting beneath their desk to devote its every waking minute to making *them* happy) by saying that if my mplayer "hangs" in the middle of a song (only to continue with a loud burst of noise 10 seconds later) when the CPU is busy with "nice -19" processes, my Firefox browser takes half a minute to scroll a page or open a screen) when memory is tight, and it takes minutes to bring up a tab or minimized program I haven't touched in 3 days and return them to a functional state then the operating system *Has a PROBLEM*.
Con was very clear in his interviews that the problem is the lack of caring about *desktop* performance. Given my comments in the previous paragraph -- some of these areas may be very difficult to benchmark and as a result one is left with nothing but handwaving and loud voices when it comes to discussions about whether the problem exists and how it should be fixed.
I will say this, in the mid-'90s I used X-windows under Unixware on *Pentium 1s* as a desktop machine. I now use X-windows under Linux on a Pentium 4 (with 5-10x more main memory) as a desktop machine. I would argue that my desktop user experience is as problematic now as it was then *despite* the hardware improvements. That IMO is what Con felt was the problem he was trying to address. That is what it would appear the core Linux developers may be failing to address. Con's points raised my awareness level to the extent that I actually went investigating to see whether there were open source distributions of the BeOS and/or Darwin (which is based on Mach) available since they are based on different OS architecture models and might be more end-user friendly [1]. I was hoping to find something I could run in a VM under Linux on my current hardware without major file system surgery. But I have little confidence that such an approach would fix core problems with the Linux scheduling and paging systems. I would *love* to see a real side-by-side comparison of Linux vs. FreeBSD for desktop users with an emphasis on how BSD scheduling, paging and swapping may be different (better?).
(And as a side note, I could care *zero* about the performance of Linux in file server applications!)
1. I did use both Nextstep (on Pentiums) and IRIX (on a R4000) for a while and found both to provide better end-user experience than Unixware (X) or Windows (95-98). I am disappointed that Linux barely manages to match those experiences given the hardware available nearly a decade later.
I just got through walking 7+ miles (mainly for exercise) and the last time I looked I didn't have to plug myself in. What does this car provide me with that my feet do not? (Other than increased opportunities to damage my body at high velocities and hundreds of dollars a month in payments for an automobile loan and car insurance).
I agree, the conventions are unclear as well as the documentation which is why I tried to give a bit of history. It would be better if there were two commands, e.g. "nice" and "nasty" which did the corresponding priority shifts with no positive and negative conventions involved.
We are becoming confused with the use of a minus character (-) as indicative of a switch/flag and its use to denote a negative number.
"nice -19" (one minus) is really a +19 (a low priority) -- this is how I run my builds so they *should* get minimal CPU time when other processes want CPU time.
"nice --19" (two minuses) is a -19 nice (i.e. high priority) -- running CPU bound processes with this priority will cause all "normal" user processes to perform poorly.
The point of my original message was that "nice -19" does *NO* good when one is dealing with short-running processes (like the thousands of C compiler processes required to build Firefox). I believe this is because the processes never accumulate sufficient CPU time to be considered CPU "hogs" and trigger scheduler options which attempt to balance CPU use. There is much more code in sched.c attempting to deal with multi-CPU machines (SMPs) You should bear in mind that the scheduler code was written from ~1996-2003 and CPUs are significantly faster now than they were during that period -- so "seconds" then (used to determine a CPU hog) should be tenths or hundredths of seconds today in determining CPU hogs.
Sigh... I can't believe I'm giving tutorials on/.:-( The man page is worthless (and if the universe had any sense of justice many of the Linux man pages would be rewritten).
If one has a shell command file, "loop" containing...
EXPR=1; while true; do EXPR=$[ $EXPR + 1 ]; done
and one says:
nice -19./loop then CPU usage goes to 100% and a glance at the nice column on the System Monitor reveals that a shell is running "loop" with a nice value of "19", i.e. the system is quite responsive.
If one (as root) says "nice --19./loop" you will also see CPU usage go to 100% and the System Monitor reveals that the loop shell is running at a nice value of "-19". *And* your system will be performing like a dog. You will not even be able to get the mouse to move "reliably" (this is on a Pentium IV @ 2.8 GHz).
Negative "nices" are are a lower numeric value but a "higher" effective priority (i.e. they get greater CPU time slice allocations).
For those of you who want the history on this, this is because in UNIX version 6, the priority of a process as well as the nice value were kept as signed bytes. Priorities less than zero were negative were system priorities which could not be interrupted. Low value positive priorities were system priorities which could be interrupted. User priorities started at 100. They could be niced to -20 (100 + -20 = 80) or +19 (100+19 = 119) as "starting" points for the scheduler (lowest priority got the CPU). If I recall, the running process had its priority bumped with each clock tick -- so it would go 101, 102, 103, etc. If niced its effective value would go 119, 120, 121, etc. The scheduler did a complete scan of the process table every few clock ticks and reset the priorities so that the totals wouldn't get above 127. You have to remember in the "old" days (1974-5), memory (for storing priorities and nice values) and CPU time for scanning scheduler tables (which are cheaper than linked lists) was expensive and programs were written to get the job done using as few resources as possible.
The problem we now have is that too many system developers (be they Linux kernel developers or Firefox developers) think resources like CPU time and memory are in infinite supply. This of course leads to [1] & [2].
I run both my Gentoo Linux package "emerges" (which can take many hours depending on # of packages) and my Firefox builds (which generally take about an hour) at "nice -19" but it doesn't do any good because the scheduler isn't designed to handle high CPU loads resulting from a process collective (build) vs. low average CPU loads (but potentially high burst loads) associated with long running processes (e.g. X11, mplayer, etc.). It would be very nice if I could actually *use* my system for editing, browsing, etc. while I'm running background system maintenance or development tasks.
1. The "Oh, throw another core at the problem" mentality. 2. The "Oh, throw another GB at the problem" mentality.
I will point out two areas where a "better" scheduler is unlikely to improve performance.
In a case where you have maxed out memory [1].
In a case where you want to run system builds *and* get good user performance [2].
Instead of fixing the software for "emerging" hardware, why not fix the system for the hundreds of millions of installed systems! Until problems such as these are fixed Linux is a toy from a power desktop user standpoint.
It is relatively easy to max out main memory by running Firefox (SeaMonkey, etc.) for long periods (days). Opening lots of tabs/windows can easily push the browser memory usage alone to 1+GB and it will stay there due to heap fragmentation. Allocating or deallocating browser memory requires paging through much of the heap and Linux paging performance stinks! I have found it impossible to max out CPU & Disk I/O in cases where the system is at or over full memory utilization. On a single user desktop PC it seems impossible to cause the system to "page thrash". This seems to be an aspect of how VM paging is scheduled and hasn't changed significantly since at least Linux 2.6.12.
Even when one is running system builds at nice -19, the old scheduling algorithm failed to give top CPU priority to the non-niced processes (niced processes seem to only be penalized after having consumed *seconds* of CPU time). Once complex system builds have placed most of the files in the buffer cache, a single compile proceeds very quickly -- potentially locking the CPU(s) into the build process rather than active (mouse, scrolling, X, etc.) user processes. I haven't seen the *new* scheduler yet but I'd like to see comments suggesting that it fixes the "nicing" problem -- i.e. *no* niced processes run until all "normal" priority processes are satisfied (or child processes inherit the parent's accumulated child CPU time as would be the case for a large make or "emerge"). Allowing "fair" scheduling across CPUs isn't going to be "fair" if small CPU consumption niced processes are being treated as equals of long running (perhaps large amount of accumulated CPU) user processes.
The Mars effort was a stupid agenda from the start (presumably due to the fact that our 'leaders' do not understand science and have no vision).
One should only consider sending humans to planets, after: 1) One has exhausted all possible exploration capabilities of robotic explorers. 2) One has "rad-hardened" (genetically enhanced) astronauts that don't require tons of shielding from radiation. 3) One has robust nanotechnology to make such ventures significantly less expensive.
Now, shortly after one has all of these capabilities using nanorobots to disassemble planets and contribute their mass to a Matrioshka Brain seems like the likely situation. Thus humans don't get to go to the planets because they will no longer exist! The Mars Society is thinking in "primitive human terms" and fails to realize that humans are about to be transcended by significantly modified and/or more capable robots, AIs, and mind uploads. Would you send a "steam locomotive" (aka human)" to Mars if you could send an advanced Mars rover/AI/cyborg instead?
The Singularity ramp up makes any multi-decade long plans based on "common (historical) human perspectives" dead on arrival. One might hope that a few wiser representatives might see that and take actions such as those which seem to be taking place.
No doubt you will probably be able to give your 85 year old uncle a Zune. Whether it gets used is another question (loss of hearing is a major problem with the elderly). But when he dies and leaves it to your teenage nephew it will get thrown in the trash because they will already have both an iPod and an iPhone...
The young markets are going for "cool" and anything your uncle would actually use is bound to be "uncool".
I now run Linux (and on a cold day will use wine, and on a few antarctic temperature days might run a VM with Windows in a sandbox that can't corrupt my files, monitor my keystrokes, yada, yada, yada) and it will be a cold day in hell before I ever willingly use a product which contains software from Microsoft. The fact that Microsoft is largely directly responsible for the viruses, SPAM, security break-ins, etc. around the world -- because you failed to provide secure operating systems for far too long -- is the reason that I will go out of my way to discourage the use of Microsoft products...
Netscape 4.72 worked completely reliably if one selected sites which were not trying to "push" information or advertising to you. If you had to deal with sites which were attempting to push stuff down your throat, well then then, as was observed, "stupid is as stupid does".
There are two kinds of sites in the world -- those who give you explicitly what you request -- and those who attempt to feed you much more than that.
I can cite dozens of sites which only give you explicitly what one requests -- many college library sites for example.
If your browser cannot work with other sites then the question may arise -- is the problem with your browser or with the site? Any attempt to force feed my computer is a violation of my rights. I did not request that. I did not give permission for that. You need to say "may I". I may grant Google permission for the intrusion -- since they seem to be beneficial based on past experience, but I am not likely to grant it to others since "abuse of access" tends to be rampant.
It contributes to the production and distribution of really bad code. Firefox with tens of millions of copies is a case in point. (Oh yes, they *claim* with version 3 they are going to consider performance). I'm still waiting for Firefox to run in the same memory footprint and as fast as Netscape 4.72 did. (Firefox will not start with less than ~55MB of memory under Linux.)
When excessive amounts of memory and processor speeds allow you to release software which by any stretch of the imagination is "bloatware" (could you do the same job with significantly less memory and processor utilization? I strongly suspect so...) then the hardware capabilities is facilitating really "dumb" development processes.
Its like putting an AK-47's (with 300+ rounds) in the hands of people who are hardly qualified to operate pocket knives.
As Forrest was prone to observe, "Stupid is as stupid does." Abusing the CPU or memory capacity at ones disposal is not something I would want tacked onto my resume.
This is a good example of poor moderation (the blind leading the blind).
As Sorak pointed out, he isn't a scientist. I am not either but I have taken senior college level virology courses and worked in the HIV lab at the U. of Washington for a summer (~15 years ago).
The problem starts with the simplification of sugar chains attached to protein molecules (aka "glycoproteins" http://en.wikipedia.org/wiki/Glycoproteins) to "sugar". As the Cell abstract pointed out the peptide interferes with the HIV protein gp41. It isn't clear whether it interferes in the entry or exit portion of the HIV lifecycle http://en.wikipedia.org/wiki/HIV but it is well understood that there are limits to the extent to which genes and the proteins they produce can evolve without "breaking". So even though the HIV reverse transcriptase (which copies the viral "code") is very error prone and thus likely to produce mutations there only some small fraction of those mutations can evade the drug. That is why multidrug cocktails have been successful at defeating HIV. If one in 10,000 viral copies contain a mutation that evades a specific drug and you use the drugs serially one has an evasion probability of 1 / (3 * 10^4) (for 3 drugs). If one uses them simultaneously one has an evasion probability of 1 / (10^4)^3 which is a much smaller probability. I'm fairly sure there are at least two drugs working their way through the pipelines that target two other critical aspects of the HIV lifecycle. The peptide under discussion might be a sixth tool (reducing the probability of escape to 1 / (10^4)^6 if 6 drugs were used).
Now, due to the variability of HIV it is hard to produce vaccines against it (one has to produce multi-strain vaccines -- which is complex but has been done in the recent case of Papilloma virus http://en.wikipedia.org/wiki/Papilloma_virus). Another approach is to develop RNA interference http://en.wikipedia.org/wiki/RNAi based "gene therapy" methods which would make cells immune to HIV infection (rather than programming the immmune system to eliminate cells already infected -- the more classical vaccine approach). Now of course the drug companies would much prefer to develop drugs that you have to take for months or years rather than vaccines or gene therapies that work forever (or at least a very long time). So it will be up to the foundations and governments to do the R&D necessary to nail HIV to the wall. It is worth keeping in mind there have also been 200,000+ papers published involving HIV so it is getting a lot of attention. But bear in mind that the virus jumped to humans relatively recently in the history of our species and that we have only had our hands on the genome for 14 years [1]. It is just a hard problem to solve.
Last weekend Verizon took my Boston suburb DSL line out of service several times (Friday night through Sunday). Its too much of coincidence that it started around 11:30 PM Friday night, came back early Saturday morning, then a similar situation Saturday night. Verizon support claimed cluelessness as to the cause (their support technicians admitted to running Windows XP and being able to ping a Verizon router a couple of hops upstream from my local town office -- though they didn't know how to run a TRACERT to the IP address that the Verizon DNS allocators handed out each time I rebooted the in-home Linksys & DSL modem). [I had to check and TRACERT is a standard XP command, presumably they don't educate support technicians how to do anything more than PING.]
At any rate after this outage, I notice that my Google search requrests seem to be taking significantly longer than they used to. Hmmmm.... Now Verizon is in the process of implementing FIOS in many surrounding communities so my suspicions are (a) priority routing may be going to the FIOS customers or (b) requests to google are being down prioritized (in the hopes of being able to extort $$$ for priority routing). I also notice that for several months digital channels on my Comcast Cable TV service it seems to be taking much longer for the TV signal to start after changing channels than it once did.
So my impression is that the local ISPs (Verizon & Comcast) are most likely moving in the direction of prioritization of routing so as to maximize revenue. (In contrast to models like TV where costs are advertiser supported or monopoly telephone companies where a minimal level of service was required.)
I think the only solution to this will be to revisit these issues at the political level (Congress) and/or develop public solutions that eliminate the monopolies. If people are familiar with high speed internet service in countries like Germany, Japan, Korea, etc. it appears that the U.S. is getting a lot less and paying a lot more due to the duopoly positions of companies like Verizon & Comcast.
Towards "taking back the internet", I would argue that we need 2 things.
First, an open source project to use P2P routing statistics to provide an online *free* analysis of where network congestion (or more importantly specific provider) problems may be occurring. I would love to have been able to say to the Verizon support tech, "Well I just used 10 minutes of my "free" AOL service to confirm using www.opennetstats.org that Verizon DSL services in the following communities north of Boston are all down! If the "public" at large can diagnose your network problems then why can't your own support staff do so [1]? I, and I suspect many Linux users, would be happy to run a server which contributed "peer" statistics to a cloud. This could also be used to determine whether services are being degraded to specific providers. If I consistently get high speed access to Stanford's FTP servers but low speed access to Google's servers (Boston to the Bay area) then something is going to be very suspicious in terms of the QoS the middle-cos are providing [2].
Second, communities need to seriously looking at WiMax based public "town" networks based on cheap Linux routers (the poles may belong to the companies but the airwaves belong to *us*). For people who aren't interested in TV on demand (e.g. people whose internet use is still largely base on *reading* and *writing*) there should be a standard high level quality of service which is dictated by the upstream provider (e.g. how many server farms Google wants to build) and not the money sucking, promise you the world and deliver nearly zippo at a decent cost, telcos and cablecos.
So why can't we at/. start at least the opennetstats.org part of this? Perhaps people familiar with small community open WiMax type projects can post URLs for those as well.
1. The primary problem here appears to be that the data side of the telephone companies rarely if
Firefox is clearly bloated. IMO this is a function of the DOM and the ability to allow users to twiddle hundreds of variables at runtime. But I can easily over the course of a few days push it to 1.2+GB of VM and 700+MB of resident memory and I think that is because they are keeping all of the document & window representations in VM [1]. (Now, of course you can argue that a person shouldn't use 80 windows and 500 tabs but perhaps you don't do research in medicine where one can easily need to juggle dozens of abstracts and papers, or perhaps you don't open up a dozens of URLs going through Firefox bug reports and Wiki discussions about why various Firefox modules will not compile under Gentoo Linux [2]).
The problem of Flash crashing Firefox is a serious one. Even with the session restore capability trying to restore a 500+ tab session can easily take 20 minutes of nearly 100% CPU utilization on a Pentium 4 (and a good chunk of 100% utilization on a DSL line). To avoid that pain I've disabled Flash entirely for Firefox. This is a *big* problem with plugins. You've got an open source browser but closed source plug-in shared libraries you are mapping into your address space. Thats a security hole as big as Texas.
And although performance and memory utilization improvements are listed as being priority items for Firefox 3.0 I see little evidence for improvement in these areas in 3.0 vs. 2.0 under Linux.
And of course, improvements to the bookmark/history search functions seem to be missing (again). One longs for the days of Netscape 4.72.
1. Which I think is one of the reasons performance will degrade significantly with the opening of more documents and increased fragmentation of the heap which results from using the browser for extended periods. 2. Which of course they don't. The released Linux Firefox 3.0a3 as well as the current CVS sources have at least 4 files which have to be patched to get it to compile.
Also of note, is the attempts by living breathing human beings to produce children in the face of difficult odds. I have direct relatives and close friends who could fall into this category. For anyone to claim "clinically dead" is really "dead" does not realize the human desires and goals that are in play. The human genome, if it has not already done so, will rise from the "dead". Framework engineers may attempt to prevent this. They will fail. Reproduction (and resurrection) knows no bounds. One may construct boundaries and they will be defeated. One may erect temporary barriers but a wise man realizes that eventually such barriers are null and void.
One might hope that the human genome will collectively realize that evolution is the path rather than static preservation. (This I currently view as up in the air).
The key factors distill to this... What contains the information content? Is the information content preserved or recoverable? To what extent (and this is perhaps the most important), does the information have value?
If you cannot answer those questions, you cannot sit at this table.
Well that all depends upon whether you desire to mod up or mod down. Invariably, one has to bear in mind Murphy's Law, e.g. that 100m asteroid that NASA lacks the funds to detect will split in two and precisely strike both the Alcor and Cryonics Institute preservation facilities thus vaporizing the bulk of the most pseudo-dead individuals on the planet today. Which will in turn give rise to a host of conspiracy theories as to why the "aliens" do not want humans to resurrect themselves.
The transition from uneducated children who will believe whatever they are told to superintelligences who can manipulate the universe is a drunkards walk through a swamp of pitfalls into which one may fall. The Barrow-Downs of Middle Earth are but a child's swamp by comparison.
The critical questions are "How shall the universe be?" and "Have we reached such points in some parts already?".
I meant exactly what I said. "Dead" as in the current conventionally accepted definition of death. Of course "man can never fly" was the conventional wisdom until we did that. "Man can never go to the moon" was the conventional widom until we did that. You have to make a key distinction between "we can't do this yet" and "we will never be able to do this because it violates known laws of physics".
One should not "get over it". If only for the reason that those children who die from childhood leukemia, fires, gunshot wounds, etc. whose minds are still largely intact when they are pronounced "dead" never got a chance to "grow old" and do not in any way "deserve" a premature "death" as the net summary of their lives. If society were to stop "accepting" a pronouncement of "death", such individuals might stand a decent chance of living out their ~75 year current expected lifespan and perhaps one that could be significantly longer given anticipated future technologies.
A factual statement would be more along the lines of "Most people who have died up until now are really dead, particularly those who have been cremated". There may be a hundred or so "dead" people currently in cryonic suspension. Anyone who follows information science and technology progress knows that the information in those individuals may be recoverable. The information on your hard drive isn't *really* gone until one drops it into a blast furnace (or uses equivalent means of explicitly erasing it). Just as there are now firms which specialize in data recovery from "dead" drives, there will be specialists in the future who will practice the reanimation of frozen brains or bodies or at least in the recovery of the information they contain and its restoration onto an alternate substrate. One might even envision possible paths for data recovery from embalmed or dessicated human brains. Unless one takes explicit measures (e.g. cremation or burial without embalming) to destroy the information content of a current human mind it is questionable whether someone who meets the clinical definition for "dead" is really in fact dead.
It used to be that once ones heart stopped beating one was considered "clinically dead". But that definition has changed over the years as our understanding of human physiology and biochemistry improved to the point where we could restart hearts.
If one accepts things like mind uploading and the technological singularity enabling things like the evolution of current human beings into "distributed replicated intelligences", then many people alive today might live trillions of years. Given that possibility an assertion that "We're *all* going to die sometime" is highly questionable.
Sending antiques is stupid...
on
Interstellar Ark
·
· Score: 2, Interesting
The argument only makes sense when coupled with a strong argument that near future technologies will not develop much better solutions. First and foremost why would you want to send "humans" when you could send nearly human capable robots (one might notice those Mars rovers keep going and going and going...) and greater than human level intelligence with next to zero energy requirements during the trip and much greater than human intelligence capabilities once the destination is reached? For example, a 1 cm^3 nanocomputer with the computational capacity of 100,000 human brains could use next to zero power during the trip and 100,000 W upon reaching the destination once solar arrays were unfurled and/or manufactured from materials harvested at the destination [1].
Instead of building this huge arc and going there using fusion power (fusion reactors are not small or lightweight), you would build a large space based mass driver (nanotechnology cares significantly less about high-g accelerations than human bodies) and launch a carrier at 0.1c or 0.5c (increasing v if you are willing to expend the energy, decreasing v depending upon the mass required for shields to defend against damage caused by encountering interstellar dust at high velocities). The carrier contains either its own mass driver or moderately large chemical rockets that launch the probe in the opposite direction at -0.9999... * v of the carrier entering the system so as to result in the probe having a net velocity that will result in its capture by the gravity of the destination system. The first probe can then go about constructing an reverse mass driver so future probes can be decelerated using power from the destination system (allowing most of the subsequent mass transfered to be "information content" rather than power systems or velocity control systems [2]).
If most of humanity hasn't undergone mind uploading several hundred years from now I'd be very surprised. So those early pioneers who decided on the "ark" approach are going to very surprised as they approach the destination system and discover that it has been converted into a Matrioshka Brain [3] and there is nothing left to explore or colonize [4,5].
No matter *how* pessimistic you are about molecular nanotechology developing in the next two decades -- you have to make a *very* strong argument that it will not be developed over the next fifty years [6]. So any future planning scenarios involving 100+ year time frames should be left as virtual reality exercises.
This is the "classical" rod-logic nanocomputer described by Drexler in Nanosystems.
There are strong arguments that the most efficient way to transfer large quantities of information (e.g. Library of Congress equivalents, human mind equivalents, Google database equivalants, etc.) between stars is by mass transfer and *not* by electromagnetic radiation (particularly if reverse mass drivers captures and recycles most of the energy used to send the information from the originating system).
"Welcome to our system ancient humans. We are happy to utilize 10^-26 of our intellectual capacity to interact with you..."
Of course as the humans watch their destination star(s) during the trip they will notice them going dark. So there may be hasty meetings organized to alter course to a virgin star system. Of course altering course at high velocity doesn't come cheap. As Matrioshka Brain conversions are likely to occur on a "most useful system first" perspective, ancient humans had better select systems that the Matrioshka Brains are going to deem "dregs of the galaxy".
Those who want to make that argument should read Ray Kurzweil's The Singularity is Nearfirst.
Sure. And if you look at the ORNL decay paths for the various isotopes of plutonium [1] you will notice that the primary radiation is alpha particle, not gamma rays. So it is relatively easy to shield the nanorobots from the alpha particle effects. This is why Robert Freitas choose Gd-148 (also an alpha particle emitter) as a power source for nuclear powered nanorobots [2].
You have to keep in mind that it doesn't matter whether ionizing radiation is destroying the atomic bonds within nanorobots (and therefore gradually disrupting the normal function of the nanorobots) so long as there is either (a) sufficient redundancy in the nanorobot to tolerate gradual loss of functional components (as is the case in many biological systems); or (b) the nanorobot can remanufacture damaged parts faster than the radiation can destroy them. That is something which should be possible for relatively sophisticated nanorobots (though not the most simple variants). Even simple "bionanorobots" such as E. coli, if supplied with sufficient materials and energy, could replicate to the mass of the Earth in less than 2 days. So having nanorobots (or microscale nanofactories) recycling radiation damaged nanorobots and replacing them with functional nanorobots doesn't seem to present a significant problem.
The "problem" isn't a "real" problem. In 20-30 years when we have robust molecular nanotechnology you simply sort all of the "waste", atom by atom, into nice little isotopically pure piles. Then you feed them into breeder reactors (or accelerators) that are designed to breed each isotope into Gadolinium-148 which in turn makes for a really nice power source for nanorobots. The problem isn't that the waste is radioactive, or that there is a lot of it. The problem is that we don't have inexpensive molecular sorting capabilities that would allow efficient nuclear transmutation disposal methods. Long before one is worried about the decay of the nuclear waste storage vessels one should be worried about the nanofactories sucking all of the carbon out of the atmosphere (to build huge nanoyachts) and as a result killing all of the plant life on the planet. Now *there* is a *real* problem.
While others have commented on the fact that the oceans are not rising (and will not ultimately rise very much) it is useful to note that the land on which the island rested could be sinking. You have both (a) the problem of sea floors being driven under the continent plates (subduction) as well as (b) the fact that islands which are built out of sedimentary material are going to be compressed (and sink) over time. So before everyone runs off to cite this as an example of global warming at work it would be useful to know whether other processes may be contributing.
Generally speaking you have to be very careful about the precise material as well as its size. Iron and copper ions for example can be very toxic due to their ability to contribute to the production of free radicals (which will damage proteins and DNA). Zinc ions on the other hand are essential and play important roles in the structure of all zinc finger regulatory proteins. Organisms have protein systems that control the transport and storage of iron and copper ions to a much greater extent than zinc ions.
Now it seems likely that metal oxides, being noncharged, are less likely to be involved in chemical reactions (its usually very hard to get oxides to interact at all). So I would expect zinc oxide (in contrast to iron particles) to be relatively benign. The question becomes whether the body has effective mechanisms for binding to and either degrading or removing nanoparticles. If it does not then exposure is potentially cumulative and may be harmful. The normal reaction of the body to something it cannot degrade or remove is to form a granuloma (a collection of cells designed to isolate the problem) surrounding it. So depending on the precise size of the particles they might either penetrate cell membranes and accumulate within cells (which is probably not good) or potentially accumulate until the point where granulomas may form. On the skin surface that isn't bad since you are sheding the skin anyway. Within the lungs however it can be a much larger problem (as silicosis and black lung disease show).
Nanoparticles are not new -- coal miners, blacksmiths and cooks have been dealing with them for centuries. What may be new is greater exposure to a larger variety of nanoparticles by a greater fraction of the population. That is worth being careful about but does not translate into throwing out the baby with the bathwater.
Anytime I startup a Java program I want to run and hide due to fear that the pages being swapped out to make room for it will crush me where I stand.
Maybe as open source software people will be able to look at it and ask *why* does it have to take up so much memory to do such simple jobs? Compare for example Azureus (in Java) to bittorrent (in Python).
It is not that it might not be happening -- the growth of CO2 levels in the atmosphere over the last 300 years (industrial civilization) are clear. The probable consequences are also clear (planet gets warmer, ice caps may melt, etc.) What is not clear is that the time frame makes the debate irrelevant. You can take apart the planet (Earth) in far less time than global warming would occur. (Since I'm sure many will find the statement objectionable let me repeat it -- you can take the planet (Earth) apart in far less time than global warming would occur.) The problem is whether we will apply the tools we have (based on biotechnology) or the tools we might have (based on nanotechnology) to mitigating the negative consequences of the path we are currently on? *Everyone* involved in this debate is engaged in it from the standpoint that it is "destiny" -- rather than accepting that humanity has reached the point where it can write the script.
We can apply solutions much faster than the problem is developing if we choose to do so.
And I would like to point out that there seems to be a rather universal perception that global warming is "bad". But having a fair understanding of the amount of land in Canada and Russia which is currently "uninhabitable" but might become "inhabitable" should the global temperature increase I tend to view it as nothing more than a population relocation problem.
Should we not instead be asking questions like "What should the global average temperature be?" and "What is the best way to set that?"
Slashdot Mirror
Have you improved it to the point that when the system is borderline out of main memory or has a moderately high load average it actually *works* as a desktop system?
E.g. when Firefox is consuming 65-70% of main memory and slower than #%#$ and you know it is waiting on swapped out pages and your swap rate is measured in the dozens to hundreds rather than hundreds to thousands (on vmstat)? (I mean really, how can one take an operating system seriously when only memory is at 100% and not CPU + memory + Disk I/O?)
The real issue, for those who have read comments that Con has made in interviews, seems to be the lack of concern on the part of most of the "in-crowd" Linux developers for performance on the desktop. In part this seems driven by the fact that the people who actually get paid to maintain Linux, benchmark it and "improve" it only care about its performance in server farms and *not* on the individual desktop. I will weigh in on the side of desktop user out there (that wants the Linux sitting beneath their desk to devote its every waking minute to making *them* happy) by saying that if my mplayer "hangs" in the middle of a song (only to continue with a loud burst of noise 10 seconds later) when the CPU is busy with "nice -19" processes, my Firefox browser takes half a minute to scroll a page or open a screen) when memory is tight, and it takes minutes to bring up a tab or minimized program I haven't touched in 3 days and return them to a functional state then the operating system *Has a PROBLEM*.
Con was very clear in his interviews that the problem is the lack of caring about *desktop* performance. Given my comments in the previous paragraph -- some of these areas may be very difficult to benchmark and as a result one is left with nothing but handwaving and loud voices when it comes to discussions about whether the problem exists and how it should be fixed.
I will say this, in the mid-'90s I used X-windows under Unixware on *Pentium 1s* as a desktop machine. I now use X-windows under Linux on a Pentium 4 (with 5-10x more main memory) as a desktop machine. I would argue that my desktop user experience is as problematic now as it was then *despite* the hardware improvements. That IMO is what Con felt was the problem he was trying to address. That is what it would appear the core Linux developers may be failing to address. Con's points raised my awareness level to the extent that I actually went investigating to see whether there were open source distributions of the BeOS and/or Darwin (which is based on Mach) available since they are based on different OS architecture models and might be more end-user friendly [1]. I was hoping to find something I could run in a VM under Linux on my current hardware without major file system surgery. But I have little confidence that such an approach would fix core problems with the Linux scheduling and paging systems. I would *love* to see a real side-by-side comparison of Linux vs. FreeBSD for desktop users with an emphasis on how BSD scheduling, paging and swapping may be different (better?).
(And as a side note, I could care *zero* about the performance of Linux in file server applications!)
1. I did use both Nextstep (on Pentiums) and IRIX (on a R4000) for a while and found both to provide better end-user experience than Unixware (X) or Windows (95-98). I am disappointed that Linux barely manages to match those experiences given the hardware available nearly a decade later.
I just got through walking 7+ miles (mainly for exercise) and the last time I looked I didn't have to plug myself in. What does this car provide me with that my feet do not? (Other than increased opportunities to damage my body at high velocities and hundreds of dollars a month in payments for an automobile loan and car insurance).
If you want to go someplace faster buy a bike.
I agree, the conventions are unclear as well as the documentation which is why I tried to give a bit of history. It would be better if there were two commands, e.g. "nice" and "nasty" which did the corresponding priority shifts with no positive and negative conventions involved.
We are becoming confused with the use of a minus character (-) as indicative of a switch/flag and its use to denote a negative number.
"nice -19" (one minus) is really a +19 (a low priority) -- this is how I run my builds so they *should* get minimal CPU time when other processes want CPU time.
"nice --19" (two minuses) is a -19 nice (i.e. high priority) -- running CPU bound processes with this priority will cause all "normal" user processes to perform poorly.
The point of my original message was that "nice -19" does *NO* good when one is dealing with short-running processes (like the thousands of C compiler processes required to build Firefox). I believe this is because the processes never accumulate sufficient CPU time to be considered CPU "hogs" and trigger scheduler options which attempt to balance CPU use. There is much more code in sched.c attempting to deal with multi-CPU machines (SMPs) You should bear in mind that the scheduler code was written from ~1996-2003 and CPUs are significantly faster now than they were during that period -- so "seconds" then (used to determine a CPU hog) should be tenths or hundredths of seconds today in determining CPU hogs.
Sigh... I can't believe I'm giving tutorials on /. :-(
./loop
./loop" you will also see CPU usage go to 100% and the System Monitor reveals that the loop shell is running at a nice value of "-19". *And* your system will be performing like a dog. You will not even be able to get the mouse to move "reliably" (this is on a Pentium IV @ 2.8 GHz).
The man page is worthless (and if the universe had any sense of justice many of the Linux man pages would be rewritten).
If one has a shell command file, "loop" containing...
EXPR=1; while true; do EXPR=$[ $EXPR + 1 ]; done
and one says:
nice -19
then CPU usage goes to 100% and a glance at the nice column on the System Monitor reveals that a shell is running "loop" with a nice value of "19", i.e. the system is quite responsive.
If one (as root) says "nice --19
Negative "nices" are are a lower numeric value but a "higher" effective priority (i.e. they get greater CPU time slice allocations).
For those of you who want the history on this, this is because in UNIX version 6, the priority of a process as well as the nice value were kept as signed bytes. Priorities less than zero were negative were system priorities which could not be interrupted. Low value positive priorities were system priorities which could be interrupted. User priorities started at 100. They could be niced to -20 (100 + -20 = 80) or +19 (100+19 = 119) as "starting" points for the scheduler (lowest priority got the CPU). If I recall, the running process had its priority bumped with each clock tick -- so it would go 101, 102, 103, etc. If niced its effective value would go 119, 120, 121, etc. The scheduler did a complete scan of the process table every few clock ticks and reset the priorities so that the totals wouldn't get above 127. You have to remember in the "old" days (1974-5), memory (for storing priorities and nice values) and CPU time for scanning scheduler tables (which are cheaper than linked lists) was expensive and programs were written to get the job done using as few resources as possible.
The problem we now have is that too many system developers (be they Linux kernel developers or Firefox developers) think resources like CPU time and memory are in infinite supply. This of course leads to [1] & [2].
I run both my Gentoo Linux package "emerges" (which can take many hours depending on # of packages) and my Firefox builds (which generally take about an hour) at "nice -19" but it doesn't do any good because the scheduler isn't designed to handle high CPU loads resulting from a process collective (build) vs. low average CPU loads (but potentially high burst loads) associated with long running processes (e.g. X11, mplayer, etc.). It would be very nice if I could actually *use* my system for editing, browsing, etc. while I'm running background system maintenance or development tasks.
1. The "Oh, throw another core at the problem" mentality.
2. The "Oh, throw another GB at the problem" mentality.
Instead of fixing the software for "emerging" hardware, why not fix the system for the hundreds of millions of installed systems! Until problems such as these are fixed Linux is a toy from a power desktop user standpoint.
The Mars effort was a stupid agenda from the start (presumably due to the fact that our 'leaders' do not understand science and have no vision).
One should only consider sending humans to planets, after:
1) One has exhausted all possible exploration capabilities of robotic explorers.
2) One has "rad-hardened" (genetically enhanced) astronauts that don't require tons of shielding from radiation.
3) One has robust nanotechnology to make such ventures significantly less expensive.
Now, shortly after one has all of these capabilities using nanorobots to disassemble planets and contribute their mass to a Matrioshka Brain seems like the likely situation. Thus humans don't get to go to the planets because they will no longer exist! The Mars Society is thinking in "primitive human terms" and fails to realize that humans are about to be transcended by significantly modified and/or more capable robots, AIs, and mind uploads. Would you send a "steam locomotive" (aka human)" to Mars if you could send an advanced Mars rover/AI/cyborg instead?
The Singularity ramp up makes any multi-decade long plans based on "common (historical) human perspectives" dead on arrival. One might hope that a few wiser representatives might see that and take actions such as those which seem to be taking place.
No doubt you will probably be able to give your 85 year old uncle a Zune. Whether it gets used is another question (loss of hearing is a major problem with the elderly). But when he dies and leaves it to your teenage nephew it will get thrown in the trash because they will already have both an iPod and an iPhone...
The young markets are going for "cool" and anything your uncle would actually use is bound to be "uncool".
I now run Linux (and on a cold day will use wine, and on a few antarctic temperature days might run a VM with Windows in a sandbox that can't corrupt my files, monitor my keystrokes, yada, yada, yada) and it will be a cold day in hell before I ever willingly use a product which contains software from Microsoft. The fact that Microsoft is largely directly responsible for the viruses, SPAM, security break-ins, etc. around the world -- because you failed to provide secure operating systems for far too long -- is the reason that I will go out of my way to discourage the use of Microsoft products...
I hope others will as well.
Netscape 4.72 worked completely reliably if one selected sites which were not trying to "push" information or advertising to you. If you had to deal with sites which were attempting to push stuff down your throat, well then then, as was observed, "stupid is as stupid does".
There are two kinds of sites in the world -- those who give you explicitly what you request -- and those who attempt to feed you much more than that.
I can cite dozens of sites which only give you explicitly what one requests -- many college library sites for example.
If your browser cannot work with other sites then the question may arise -- is the problem with your browser or with the site? Any attempt to force feed my computer is a violation of my rights. I did not request that. I did not give permission for that. You need to say "may I". I may grant Google permission for the intrusion -- since they seem to be beneficial based on past experience, but I am not likely to grant it to others since "abuse of access" tends to be rampant.
It contributes to the production and distribution of really bad code. Firefox with tens of millions of copies is a case in point. (Oh yes, they *claim* with version 3 they are going to consider performance). I'm still waiting for Firefox to run in the same memory footprint and as fast as Netscape 4.72 did. (Firefox will not start with less than ~55MB of memory under Linux.)
When excessive amounts of memory and processor speeds allow you to release software which by any stretch of the imagination is "bloatware" (could you do the same job with significantly less memory and processor utilization? I strongly suspect so...) then the hardware capabilities is facilitating really "dumb" development processes.
Its like putting an AK-47's (with 300+ rounds) in the hands of people who are hardly qualified to operate pocket knives.
As Forrest was prone to observe, "Stupid is as stupid does." Abusing the CPU or memory capacity at ones disposal is not something I would want tacked onto my resume.
As Sorak pointed out, he isn't a scientist. I am not either but I have taken senior college level virology courses and worked in the HIV lab at the U. of Washington for a summer (~15 years ago).
The problem starts with the simplification of sugar chains attached to protein molecules (aka "glycoproteins" http://en.wikipedia.org/wiki/Glycoproteins) to "sugar". As the Cell abstract pointed out the peptide interferes with the HIV protein gp41. It isn't clear whether it interferes in the entry or exit portion of the HIV lifecycle http://en.wikipedia.org/wiki/HIV but it is well understood that there are limits to the extent to which genes and the proteins they produce can evolve without "breaking". So even though the HIV reverse transcriptase (which copies the viral "code") is very error prone and thus likely to produce mutations there only some small fraction of those mutations can evade the drug. That is why multidrug cocktails have been successful at defeating HIV. If one in 10,000 viral copies contain a mutation that evades a specific drug and you use the drugs serially one has an evasion probability of 1 / (3 * 10^4) (for 3 drugs). If one uses them simultaneously one has an evasion probability of 1 / (10^4)^3 which is a much smaller probability. I'm fairly sure there are at least two drugs working their way through the pipelines that target two other critical aspects of the HIV lifecycle. The peptide under discussion might be a sixth tool (reducing the probability of escape to 1 / (10^4)^6 if 6 drugs were used).
Now, due to the variability of HIV it is hard to produce vaccines against it (one has to produce multi-strain vaccines -- which is complex but has been done in the recent case of Papilloma virus http://en.wikipedia.org/wiki/Papilloma_virus). Another approach is to develop RNA interference http://en.wikipedia.org/wiki/RNAi based "gene therapy" methods which would make cells immune to HIV infection (rather than programming the immmune system to eliminate cells already infected -- the more classical vaccine approach). Now of course the drug companies would much prefer to develop drugs that you have to take for months or years rather than vaccines or gene therapies that work forever (or at least a very long time). So it will be up to the foundations and governments to do the R&D necessary to nail HIV to the wall. It is worth keeping in mind there have also been 200,000+ papers published involving HIV so it is getting a lot of attention. But bear in mind that the virus jumped to humans relatively recently in the history of our species and that we have only had our hands on the genome for 14 years [1]. It is just a hard problem to solve.
1. http://www.ncbi.nlm.nih.gov/entrez/query.fcgi?db=g enome&cmd=Retrieve&dopt=Overview&list_uids=10902
Last weekend Verizon took my Boston suburb DSL line out of service several times (Friday night through Sunday). Its too much of coincidence that it started around 11:30 PM Friday night, came back early Saturday morning, then a similar situation Saturday night. Verizon support claimed cluelessness as to the cause (their support technicians admitted to running Windows XP and being able to ping a Verizon router a couple of hops upstream from my local town office -- though they didn't know how to run a TRACERT to the IP address that the Verizon DNS allocators handed out each time I rebooted the in-home Linksys & DSL modem). [I had to check and TRACERT is a standard XP command, presumably they don't educate support technicians how to do anything more than PING.]
/. start at least the opennetstats.org part of this?
At any rate after this outage, I notice that my Google search requrests seem to be taking significantly longer than they used to. Hmmmm.... Now Verizon is in the process of implementing FIOS in many surrounding communities so my suspicions are (a) priority routing may be going to the FIOS customers or (b) requests to google are being down prioritized (in the hopes of being able to extort $$$ for priority routing). I also notice that for several months digital channels on my Comcast Cable TV service it seems to be taking much longer for the TV signal to start after changing channels than it once did.
So my impression is that the local ISPs (Verizon & Comcast) are most likely moving in the direction of prioritization of routing so as to maximize revenue. (In contrast to models like TV where costs are advertiser supported or monopoly telephone companies where a minimal level of service was required.)
I think the only solution to this will be to revisit these issues at the political level (Congress) and/or develop public solutions that eliminate the monopolies. If people are familiar with high speed internet service in countries like Germany, Japan, Korea, etc. it appears that the U.S. is getting a lot less and paying a lot more due to the duopoly positions of companies like Verizon & Comcast.
Towards "taking back the internet", I would argue that we need 2 things.
First, an open source project to use P2P routing statistics to provide an online *free* analysis of where network congestion (or more importantly specific provider) problems may be occurring. I would love to have been able to say to the Verizon support tech, "Well I just used 10 minutes of my "free" AOL service to confirm using www.opennetstats.org that Verizon DSL services in the following communities north of Boston are all down! If the "public" at large can diagnose your network problems then why can't your own support staff do so [1]? I, and I suspect many Linux users, would be happy to run a server which contributed "peer" statistics to a cloud. This could also be used to determine whether services are being degraded to specific providers. If I consistently get high speed access to Stanford's FTP servers but low speed access to Google's servers (Boston to the Bay area) then something is going to be very suspicious in terms of the QoS the middle-cos are providing [2].
Second, communities need to seriously looking at WiMax based public "town" networks based on cheap Linux routers (the poles may belong to the companies but the airwaves belong to *us*). For people who aren't interested in TV on demand (e.g. people whose internet use is still largely base on *reading* and *writing*) there should be a standard high level quality of service which is dictated by the upstream provider (e.g. how many server farms Google wants to build) and not the money sucking, promise you the world and deliver nearly zippo at a decent cost, telcos and cablecos.
So why can't we at
Perhaps people familiar with small community open WiMax type projects can post URLs for those as well.
1. The primary problem here appears to be that the data side of the telephone companies rarely if
Firefox is clearly bloated. IMO this is a function of the DOM and the ability to allow users to twiddle hundreds of variables at runtime. But I can easily over the course of a few days push it to 1.2+GB of VM and 700+MB of resident memory and I think that is because they are keeping all of the document & window representations in VM [1]. (Now, of course you can argue that a person shouldn't use 80 windows and 500 tabs but perhaps you don't do research in medicine where one can easily need to juggle dozens of abstracts and papers, or perhaps you don't open up a dozens of URLs going through Firefox bug reports and Wiki discussions about why various Firefox modules will not compile under Gentoo Linux [2]).
The problem of Flash crashing Firefox is a serious one. Even with the session restore capability trying to restore a 500+ tab session can easily take 20 minutes of nearly 100% CPU utilization on a Pentium 4 (and a good chunk of 100% utilization on a DSL line). To avoid that pain I've disabled Flash entirely for Firefox. This is a *big* problem with plugins. You've got an open source browser but closed source plug-in shared libraries you are mapping into your address space. Thats a security hole as big as Texas.
And although performance and memory utilization improvements are listed as being priority items for Firefox 3.0 I see little evidence for improvement in these areas in 3.0 vs. 2.0 under Linux.
And of course, improvements to the bookmark/history search functions seem to be missing (again). One longs for the days of Netscape 4.72.
1. Which I think is one of the reasons performance will degrade significantly with the opening of more documents and increased fragmentation of the heap which results from using the browser for extended periods.
2. Which of course they don't. The released Linux Firefox 3.0a3 as well as the current CVS sources have at least 4 files which have to be patched to get it to compile.
Also of note, is the attempts by living breathing human beings to produce children in the face of difficult odds. I have direct relatives and close friends who could fall into this category. For anyone to claim "clinically dead" is really "dead" does not realize the human desires and goals that are in play. The human genome, if it has not already done so, will rise from the "dead". Framework engineers may attempt to prevent this. They will fail. Reproduction (and resurrection) knows no bounds. One may construct boundaries and they will be defeated. One may erect temporary barriers but a wise man realizes that eventually such barriers are null and void.
One might hope that the human genome will collectively realize that evolution is the path rather than static preservation. (This I currently view as up in the air).
The key factors distill to this...
What contains the information content?
Is the information content preserved or recoverable?
To what extent (and this is perhaps the most important), does the information have value?
If you cannot answer those questions, you cannot sit at this table.
Robert
Well that all depends upon whether you desire to mod up or mod down. Invariably, one has to bear in mind Murphy's Law, e.g. that 100m asteroid that NASA lacks the funds to detect will split in two and precisely strike both the Alcor and Cryonics Institute preservation facilities thus vaporizing the bulk of the most pseudo-dead individuals on the planet today. Which will in turn give rise to a host of conspiracy theories as to why the "aliens" do not want humans to resurrect themselves.
The transition from uneducated children who will believe whatever they are told to superintelligences who can manipulate the universe is a drunkards walk through a swamp of pitfalls into which one may fall. The Barrow-Downs of Middle Earth are but a child's swamp by comparison.
The critical questions are "How shall the universe be?" and "Have we reached such points in some parts already?".
Robert
I meant exactly what I said. "Dead" as in the current conventionally accepted definition of death. Of course "man can never fly" was the conventional wisdom until we did that. "Man can never go to the moon" was the conventional widom until we did that. You have to make a key distinction between "we can't do this yet" and "we will never be able to do this because it violates known laws of physics".
One should not "get over it". If only for the reason that those children who die from childhood leukemia, fires, gunshot wounds, etc. whose minds are still largely intact when they are pronounced "dead" never got a chance to "grow old" and do not in any way "deserve" a premature "death" as the net summary of their lives. If society were to stop "accepting" a pronouncement of "death", such individuals might stand a decent chance of living out their ~75 year current expected lifespan and perhaps one that could be significantly longer given anticipated future technologies.
A factual statement would be more along the lines of "Most people who have died up until now are really dead, particularly those who have been cremated". There may be a hundred or so "dead" people currently in cryonic suspension. Anyone who follows information science and technology progress knows that the information in those individuals may be recoverable. The information on your hard drive isn't *really* gone until one drops it into a blast furnace (or uses equivalent means of explicitly erasing it). Just as there are now firms which specialize in data recovery from "dead" drives, there will be specialists in the future who will practice the reanimation of frozen brains or bodies or at least in the recovery of the information they contain and its restoration onto an alternate substrate. One might even envision possible paths for data recovery from embalmed or dessicated human brains. Unless one takes explicit measures (e.g. cremation or burial without embalming) to destroy the information content of a current human mind it is questionable whether someone who meets the clinical definition for "dead" is really in fact dead.
It used to be that once ones heart stopped beating one was considered "clinically dead". But that definition has changed over the years as our understanding of human physiology and biochemistry improved to the point where we could restart hearts.
If one accepts things like mind uploading and the technological singularity enabling things like the evolution of current human beings into "distributed replicated intelligences", then many people alive today might live trillions of years. Given that possibility an assertion that "We're *all* going to die sometime" is highly questionable.
Instead of building this huge arc and going there using fusion power (fusion reactors are not small or lightweight), you would build a large space based mass driver (nanotechnology cares significantly less about high-g accelerations than human bodies) and launch a carrier at 0.1c or 0.5c (increasing v if you are willing to expend the energy, decreasing v depending upon the mass required for shields to defend against damage caused by encountering interstellar dust at high velocities). The carrier contains either its own mass driver or moderately large chemical rockets that launch the probe in the opposite direction at -0.9999... * v of the carrier entering the system so as to result in the probe having a net velocity that will result in its capture by the gravity of the destination system. The first probe can then go about constructing an reverse mass driver so future probes can be decelerated using power from the destination system (allowing most of the subsequent mass transfered to be "information content" rather than power systems or velocity control systems [2]).
If most of humanity hasn't undergone mind uploading several hundred years from now I'd be very surprised. So those early pioneers who decided on the "ark" approach are going to very surprised as they approach the destination system and discover that it has been converted into a Matrioshka Brain [3] and there is nothing left to explore or colonize [4,5].
No matter *how* pessimistic you are about molecular nanotechology developing in the next two decades -- you have to make a *very* strong argument that it will not be developed over the next fifty years [6]. So any future planning scenarios involving 100+ year time frames should be left as virtual reality exercises.
Its only a few billion years after nature evolved the bacterial flagella or maybe a billion after the mitochondrial F0-F1 ATPase evolved.
i on=com_content&task=view&id=60&Itemid=57
Now when someone builds a 25,374 atom Worm Drive Assembly [1] -- then I'll be impressed.
1. http://www.nanoengineer-1.com/mambo/index.php?opt
You have to keep in mind that it doesn't matter whether ionizing radiation is destroying the atomic bonds within nanorobots (and therefore gradually disrupting the normal function of the nanorobots) so long as there is either (a) sufficient redundancy in the nanorobot to tolerate gradual loss of functional components (as is the case in many biological systems); or (b) the nanorobot can remanufacture damaged parts faster than the radiation can destroy them. That is something which should be possible for relatively sophisticated nanorobots (though not the most simple variants). Even simple "bionanorobots" such as E. coli, if supplied with sufficient materials and energy, could replicate to the mass of the Earth in less than 2 days. So having nanorobots (or microscale nanofactories) recycling radiation damaged nanorobots and replacing them with functional nanorobots doesn't seem to present a significant problem.
1. http://www.ornl.gov/sci/isotopes/
2. http://www.nanomedicine.com/NMI/6.3.7.1.htm
The "problem" isn't a "real" problem. In 20-30 years when we have robust molecular nanotechnology you simply sort all of the "waste", atom by atom, into nice little isotopically pure piles. Then you feed them into breeder reactors (or accelerators) that are designed to breed each isotope into Gadolinium-148 which in turn makes for a really nice power source for nanorobots. The problem isn't that the waste is radioactive, or that there is a lot of it. The problem is that we don't have inexpensive molecular sorting capabilities that would allow efficient nuclear transmutation disposal methods. Long before one is worried about the decay of the nuclear waste storage vessels one should be worried about the nanofactories sucking all of the carbon out of the atmosphere (to build huge nanoyachts) and as a result killing all of the plant life on the planet. Now *there* is a *real* problem.
While others have commented on the fact that the oceans are not rising (and will not ultimately rise very much) it is useful to note that the land on which the island rested could be sinking. You have both (a) the problem of sea floors being driven under the continent plates (subduction) as well as (b) the fact that islands which are built out of sedimentary material are going to be compressed (and sink) over time. So before everyone runs off to cite this as an example of global warming at work it would be useful to know whether other processes may be contributing.
Generally speaking you have to be very careful about the precise material as well as its size. Iron and copper ions for example can be very toxic due to their ability to contribute to the production of free radicals (which will damage proteins and DNA). Zinc ions on the other hand are essential and play important roles in the structure of all zinc finger regulatory proteins. Organisms have protein systems that control the transport and storage of iron and copper ions to a much greater extent than zinc ions.
Now it seems likely that metal oxides, being noncharged, are less likely to be involved in chemical reactions (its usually very hard to get oxides to interact at all). So I would expect zinc oxide (in contrast to iron particles) to be relatively benign. The question becomes whether the body has effective mechanisms for binding to and either degrading or removing nanoparticles. If it does not then exposure is potentially cumulative and may be harmful. The normal reaction of the body to something it cannot degrade or remove is to form a granuloma (a collection of cells designed to isolate the problem) surrounding it. So depending on the precise size of the particles they might either penetrate cell membranes and accumulate within cells (which is probably not good) or potentially accumulate until the point where granulomas may form. On the skin surface that isn't bad since you are sheding the skin anyway. Within the lungs however it can be a much larger problem (as silicosis and black lung disease show).
Nanoparticles are not new -- coal miners, blacksmiths and cooks have been dealing with them for centuries. What may be new is greater exposure to a larger variety of nanoparticles by a greater fraction of the population. That is worth being careful about but does not translate into throwing out the baby with the bathwater.
Anytime I startup a Java program I want to run and hide due to fear that the pages being swapped out to make room for it will crush me where I stand.
Maybe as open source software people will be able to look at it and ask *why* does it have to take up so much memory to do such simple jobs? Compare for example Azureus (in Java) to bittorrent (in Python).
It is not that it might not be happening -- the growth of CO2 levels in the atmosphere over the last 300 years (industrial civilization) are clear. The probable consequences are also clear (planet gets warmer, ice caps may melt, etc.) What is not clear is that the time frame makes the debate irrelevant. You can take apart the planet (Earth) in far less time than global warming would occur. (Since I'm sure many will find the statement objectionable let me repeat it -- you can take the planet (Earth) apart in far less time than global warming would occur.) The problem is whether we will apply the tools we have (based on biotechnology) or the tools we might have (based on nanotechnology) to mitigating the negative consequences of the path we are currently on? *Everyone* involved in this debate is engaged in it from the standpoint that it is "destiny" -- rather than accepting that humanity has reached the point where it can write the script.
We can apply solutions much faster than the problem is developing if we choose to do so.
And I would like to point out that there seems to be a rather universal perception that global warming is "bad". But having a fair understanding of the amount of land in Canada and Russia which is currently "uninhabitable" but might become "inhabitable" should the global temperature increase I tend to view it as nothing more than a population relocation problem.
Should we not instead be asking questions like "What should the global average temperature be?" and "What is the best way to set that?"