As a separate note, I run Firefox with the NoScript Extension to manage which sites can use Javacript extremely selectively -- anyone who enables the running of unknown source and unknown agenda software remotely via their browser is IMO begging for problems. There should be a site -- IamAJavacriptDummy.Org.
> I generally keep IE as the default browser because I get email with links for > some admin tasks (approvals) that only work in IE.
Hmmm... Can you tell me how I can rune IE7 under Linux? I've heard some rumors that some people can run IE6 under Wine under Linux. I think could pay $$ and install a Parallels emulator (and then pay $$$ for a current copy of XP -- or do I have to install an old vulnerable copy of XP and then go through a lengthy Service Pack upgrade process???). I recently tried upgrading my cousin's original version of XP and it said it wanted to install 67 security upgrades (really!). It was OK because we left the machine running overnight. Then it said it wanted to install Service Pack 2 (but that was from 97 to 250MB of downloads) and over a dial up that would require 1 to 2 more days. Her machine is only 3 years old and I really don't think it can run Vista. In contrast I split the NTFS partition on her hard drive and had Ubuntu up and running in an hour. No more lengthy MacAffee virus update delays for her. Though she likes Firefox (because I've explained how Javascript is a security risk unless only enabled for selected sites) I'm wondering if I should download IE7 and allow her to compare them side by side. But I'd really like her to compare them under Linux since that system seems have many fewer problems with viruses, keystroke loggers, and those other nasties that have generally resulted from Microsoft's attempts to dominate the software market.
Its "bitchy" because the problems (sorry but I consider being able to core dump a program a *problem* [1]) were pointed out *in* Bugzilla in 1.5 and they weren't fixed in 2.0. I took the time to describe the Talkback incidents. I took the time to file the Bugzilla bug reports. I even attempted to build Firefox in debugging mode with symbols to enable better stack traces [2]. That didn't help much because to understand this problem involves not only knowing Firefox in depth but understanding its environment (libstdc++, Glib & Linux) as well. This was done in my free time because I didn't understand how the program could perform so poorly (others get paid to do this kind of thing -- I no longer do). I think I have just reason to bitch.
If you want the "insight" see [3] which was written somewhat after my original post in this thread.
1. I've got 79 (10 GB of compressed(!!)) Firefox core files accumulated over a 5 month period. In normal use I can crash Firefox once or twice a week. If I work at it would take me minutes to hours to crash production (cough) versions of Firefox 1.5 (and now 2.0) -- depending on how "artificial" I make the tests. 2. The developers tend to suggest that this is a "requirement" for people who want to file "serious" bug reports. Why not simply release a *production* debugging version?!? 3. http://it.slashdot.org/comments.pl?sid=203284&pid= 16629912
I intend to do that. The Bugzilla bugs *were* filed and linked to the talkback incidents for the 1.5 examples. I've now reached the point where I understand what precisely is going on. (See my expanded comments regarding new+libstdc++ and GDK/GTK+Glib+g_malloc and throwing exceptions vs. abort() in the "Nine Reasons to Skip Firefox 2.0" discussion [1].)
The problem wasn't addressed in 1.5 and still isn't addressed in 2.0. It is clear that the developers have simply never tested running out of memory under Linux. There were some exchanges in the 1.5 Bugzilla reports (search for ulimit) and perhaps in some email exchanges about how "hard" it would be to fix. I bought that for a while but now that I understand it more fully that excuse isn't flying anymore. It isn't a degree of difficulty problem as much as a not testing & not caring problem. It took me going down into the guts of libstdc++-v3 and glib to see how the memory allocation was actually being handled to be clear about what was going on. As the Firefox developers tend to be Windows oriented (my subjective impression) I doubt they have ever done that (because they are used to not having source?).
Caca. As I pointed out in my long message on the other major/. Firefox discussion -- Firefox 2.0 still has some of the same memory allocation and management issues that are present in Firefox 1.5! These were reported as bugs and the developers have simply chosen to ignore them.
I *crashed* (core dump and all) Firefox 2.0 3 times in the first 30 minutes of using it. All you have to do is use ulimit set the virtual memory limit so that memory allocations fail relatively early during your browsing experience (rather than after 5 days of browsing when you would lose much more browser state information -- or have to take a long time to restore a complex session).
It is *NOT* production level software when it is that easy to produce a core dump.
I have subsequently investigated the cause of this. Its simple. Firefox uses the new memory allocation primitive in its C++ code which in turn ends up either throwing an exception or abort()ing when a malloc() fails (depending upon how libstdc++ is compiled). The supporting graphics libraries (GTK & GDK) use g_alloc() which when malloc() fails calls g_error() which ends up calling abort().
The upper level Firefox code (nsSigHandlers.cpp) will only do something "nice" (setup to do a stack trace and attach the debugger) if Firefox is compiled in DEBUG mode (which is probably not true for most or all 'production-wanna-be' versions). In these cases the abort() terminates the program and produces core dump if you have your core dump ulimit and permissions setup to allow for that.
While the in-browser session saver may fix some of the excessive memory usage problems they still are NOT handling most memory allocation failures in a robust fashion.
Are you sure this is true in the latest releases? I'm using almost the most recent libraries from Xorg & assoc as well as the 4.1.1 gcc libstdc++. With libstdc++ compiled properly I can get programs to throw a "bad_alloc" exception (with it not compiled properly it calls abort()). I've looked at the Firefox code and there are uses of catch(...) but I'm unsure yet whether they are in the right places to catch the failures I am seeing.
Now, when I push 1.5.0.7 up to the point where the heap is right around 1GB one starts getting (on the console output from Firefox) Gtk-CRITICAL, Gdk-CRITICAL and GLib-GObject-WARNING assertion failure messages. As they frequently seem to describe NULL objects I suspect that these libraries may now tolerate memory failures (and simply warn you about them). I have yet to confirmed this in the source code. When these happen Firefox doesn't crash but does get a bit "strange". Tabs which seem to auto-refresh (dynamic HTML?) will get opened in new "untitled" windows. If you are careful to close the tab the window closes and Firfox continues normally. If you close the untitled window Firefox crashes. Not the best behavior but something one can tolerate and you know how to handle it gracefully.
What I can't figure out is whether the problem is happening due to some 1GB memory limit in GTK or X or whether I'm actually hitting the Firefox virtual memory limit (which I typically set at 1.3-1.4 GB) and it is catching the memory allocation failures and handling them strangely.
But it goes without saying that these seem to be areas where the developers haven't run robust unit tests.
Precisely. I have managed to put together C++ and thread libraries that explicitly inform me that at least in some cases Firefox is throwing a "bad_alloc" exception. Older libraries apparently just aborted leaving a core dump and a difficult debugging situation when the libraries are distributed without sufficient debugging information.
Almost everywhere in the code whether its downloading a HTML files, allocating parsed code memory, image display memory, etc. should be happening within a context for a specific tab (or window). The bad_alloc should get caught and handled. It doesn't matter most of the time if you lose track of all of that memory so long as you have a preallocated pop-up that says "You are running low on memory, please close some tabs or windows". In that case most of what one is doing (the browser state information) doesn't get lost and you don't have a state of mind resumption nightmare.
This isn't "rocket science" but convincing the Firefox developers of that seems rather difficult.
Given the $70 I've had to spend for an additional 1GB of memory and the days of time I've spent trying to compile Firefox with debugging capabilities [1] so I could figure out exactly what its problems were I would have to agree.
Just because its free and open source and has all this hype associated with it doesn't mean its actually a well written program.
I very much doubt you could run 100 windows under Win98 because you would exhaust the OS memory. You would need at least Win2K and I've never tried pushing it to 100 windows. Linux & X will handle 100 windows fine on newer Pentiums that can support more than 128MB.
For 100 windows you will probably need 1GB of RAM (or be willing to wait long periods of time while Linux pages the Firefox heap in and out). If it were designed properly it would give you great response in the open tab in your top window and fast tab switching within that window. It would provide reasonable performance (seconds) switching between windows. The implementation quality would be determined by the resident memory size and the tab/window switch time for various amounts of main memory. The actual number of windows would be limited by the amount of swap and/or cache file space you are willing to make available.
Making this fly on 256 or 128MB machines would be possible but would however require very good resource management & coordination between Firefox, X windows and Linux and I doubt even Version 3 will manage to pull it off unless the development team significantly changes is emphasis away from bells and whistles.
I made the Win98 comment to point out that Firefox will at least run on older (even "ancient") hardware and software.
Yep its just like the fancy new Christmas toy that has a few more bells and whistles than last year's toy. Unfortunately it lasted less than a hour before I managed to break it.
I downloaded Firefox 2.0 and installed it under Linux (Gentoo 2.6.17-r7).
Just for the heck of it I tried the same tests I tried in 1.5 and filed bug reports about several months ago. Sure enough Firefox 2.0 does *NOT* handle memory allocation failures. If one limits the amount of virtual memory (e.g. ulimit -Sv 115000) and starts firefox shortly thereafter it will core dump and will open a Talkback Incident window. I managed to file 3 different reports in 30 minutes of using it with memory limits in the range from 100-120MB.
While I anticipate the bookmarks handling may be better (1.5 never should have been released until its bookmarks handling was on par with Netscape 4.72!) I still do not consider this to be production quality software. It will not be until it has decent handling of the various types of resource allocation failures (can't open tab, can't open window, can't allocate memory for image, script, network connection, etc.).
Though I haven't tested it yet I also suspect they haven't handled things like window switching or efficient session restart. The open window (tab) should have top CPU and network priority until it is displayed. Any excess CPU or network resources can be dedicated to non-lead tabs or mininimized windows. They probably also haven't handled the heap fragmentation issue -- so after using Firefox for a week and one has opened 100 windows and 700 tabs (pushing the memory usage up to 1.2GB) it will still take 15 minutes or more to simply close all the windows and exit from Firefox (presumably because it has to merge all of the memory fragments being deallocated). Upon restarting the same session one will find that Firefox only needs 900MB. That is a memory leak and/or heap fragmentation problem.
Please, no comments about how I shouldn't be using my browser this way... You use your browser your way, I'll use it my way. I happen to like to work on multiple things at the same time and when I'm writing research papers it isn't uncommon for me to open hundreds of sources simultaneously. I wouldn't have started limiting the virtual memory and run into Firefox's failings in that area at all if 1.5 hadn't turned out to be such an excessive memory consumer.
The interesting question one might ask is how one releases software and specifies what its minimal memory requirements are if you don't limit its memory to determine that? I can only assume that the Firefox developers picked their numbers out of thin air [1].
As an aside it may be worth noting that Firefox 1.5.0.7 does run under Windows 98 on a 75 MHz Pentium that only has 132MB of memory. It doesn't have the performance that Netscape 4.72 can show on the same machine though. As the 2.0 memory requirements seem to have increased (presumably due to the SQL libraries for bookmarks & history handling) I strongly doubt its performance would be improved over 1.5.0.7.
1. Firefox 2.0 will *NOT* run in the Linux specified Minimum System Requirements of 64MB of RAM [2] unless you also have several hundred MB of swap space. And believe me, having pushed Firefox memory to ~70% of system RAM under Linux -- you would *not* want to try to use it even on a 128MB system due to Firefox's problems with heap memory management and the poor paging performance it generates under Linux. 2. http://www.mozilla.com/en-US/firefox/system-requir ements.html
That may be true (though the word others sometimes use is arrogant). The point would be not whether I am best described by either of those terms but whether my post was informative and enabled people reading it to more clearly think about the relative importance of various aspects of the problem.
Given the basic thermodynamics (higher temperatures ~= high efficiency) oxidizing the energy carrier in a power plant (rather than individual vehicles) is likely to result in higher efficiency. So assuming the electricity transport losses are not too high it is going to be better to use batteries (or high capacity capacitors!) rather than fuel cells. The most efficient approach however would involve direct production and storing of the electrons using solar power as the energy source. I could imagine a standardized quick-change ultracapacitor at the "fuel" stations (or a quick recharge) being the most efficient solution.
People in developed countries have largely been duped by the so called "green" arguments that hydrogen (and indirectly fuel cells) are the solution to their energy problems. This is because you combine hydrogen with oxygen and get nonpolluting water (thus no CO2 and no CO). If done in a fuel cell the secondary reactions with N2 are avoided and thus no NO. This means no pollution. But existing automobiles through the proper management of the air fuel mixture (computer controlled fuel injection) and catalytic converters have minimized the NO problem.
You have to separate the problem of the energy carrier from the energy source. All current existing methods to make hydrogen available start with upstream in-the-ground based energy sources (methane, propane, gasoline, etc.) and involve dumping the CO2 that results from extracting the hydrogen into the atmosphere. So long as the hydrocarbon (or carbon) source is coming out of the ground you have only solved the NO pollution problem -- you haven't solved the CO2 part of the global warming problem. I.e. you have not produced a sustainable solution.
The only sustainable solutions involve producing hydrocarbon carriers using carbon extracted from the atmosphere -- that currently means biodiesel, bioethanol or biomethane. Propane, methane and gasoline in our current economy are energy carriers produced using solar energy harvested in ancient times. Until one switches to an economy based on energy harvested or created in real time one has an unsustainable reality. That means one has to be harvesting solar energy (incident visible or IR energy, wind or hydroelectric) or nuclear energy (in the long term using breeder reactors or fusion). The bio-carrier sources are inefficient (harvesting 1-2% of incident solar energy) but there is a large installed infrastructure designed to produce them. As whole genome engineering and/or mass production of inexpensive photovoltaic cells increase the solar energy harvesting efficiencies it will become completely feasible to migrate from a "steal from the past" to a "harvest the present" sustainable economic framework. It would help if people could keep this straight in their minds (and if people in leadership and press positions would not mislead or misdirect where the emphasis should be placed).
So I agree with comments that better reformers are not particularly worthy of attention. A more efficient catalytic system for splitting water (compared with photosynthetic efficiencies) would be worth getting excited about.
Of course I'm waiting for the day when our fusion reactors are powering the breeding of Gd-148 which in turn is used to power the nanorobots and/or replicators which will sustain our economy. But we are probably a several decades away from that at this time.
I am absolutely serious! I have timed it several times. (I can even send you logged outputs from ps every 10-15 seconds with the wall clock times if you want them.) The typical situation is Firefox having VM more than total RAM (i.e. 500+MB on a 512MB machine) with a resident set more than 65% of total RAM. You are *unlikely* to see it if you have 1GB of memory (it would probably take heavy use of Firefox for a week or more accessing hundreds to thousands of pages to produce a 700-900MB fragmented heap). You may see it if you run large memory consuming programs concurrently with Firefox (running Gentoo portage package recompiles along with Firefox will make the problem happen with lower Firefox memory usage).
The problem is that with a fragmented heap the free() function in glibc will try to reunite all of the little chunks of memory. If the VM system is not tuned properly (and I've tried variations of vm.swappiness with little effect) the system waits doing nothing for a significant fraction of the time until paged out Firefox heap pages get paged in so it can continue merging the heap memory. Firefox will eventually exit cleanly -- it just takes a very long time. This is a mixed source problem -- Firefox poor heap management + poor malloc/free() strategies in glibc for fragmented heaps + poor paging strategies by Linux.
It could be resolved at any of those levels -- ideally it should be resolved at *all* of them. One could view this as a problem of the general midset I suspect exists among many programmers today... "Oh, its running slow, lets buy some more memory and increase the CPU clock speed -- heaven forbid we should actually look at the problem and write better algorithms to manage the resources intelligently." This is the Intel speed mindset vs. the AMD efficiency mindset.
The poor startup times (which are less than the shutdown times but still significant) may be due to single threaded internet access (on a tab/window/browser basis?). This is something I've only read in passing and not verified by looking at the Firefox code. It does take many minutes to restart complex Firefox sessions (15 - 25 windows w/ many dozens of tabs). CPU and/or Network usage during this period can be described as medium-to-high. But since memory isn't a constraint during that period I would expect both should approach 100% if Firefox were properly multitasking.
I run continual System Monitor graphs displaying CPU/RAM/Network/Disk so I can monitor what is going on in real time as well as vmstat & top in separate windows. I've had a lot of benchmarking experience so you should consider the above to be relatively informed opinions.
When Firefox will run for a week without consuming more than say 128MB of memory -- then I will say *maybe* its ready for the public. Until then its poorly written Jabba-the-Hut-ware.
Users should *not* upgrade, or for that matter, probably even *use* Firefox 1.5.0.x unless they plan to routinely stop it and restart it. Firefox 1.5.0.4 does have memory heap, aka memory cache, fragmentation and usage problems! I am runing Linux 2.6.16.1 on a 512MB Pentium 4 and I routinely have to restart Firefox every 1-2 days because its memory usage grows endlessly. Once Firefox is consuming 60-70% of the RAM on the machine (in the resident memory set) the machine performance as well as Firefox will slow to a crawl. The only way out of this is to restart Firefox (which can take 15-30 minutes due to the long shutdown and session restore times). The long shutdown times are due to heap fragmentation and poor Linux paging strategies. The long restart times are due to network access constraints and CPU usage when opening many windows and tabs.
I would only recommend that people switch to Firefox when the memory (heap) management issues are addressed. Netscape 4.72 was a *much* better browser from this perspective. It worked fine on a Pentium Pro with much less memory under Windows 2000 before I made the mistake of deciding to try Firefox under Linux.
I would also suggest that the Linux paging system needs work. If one has what should be a "memory thrashing" situation (95+% of RAM used, mostly by Firefox) one should not see minimal CPU (20%) and minimal disk (20%) activity.
Just because its "open source" (and I am a strong proponent of open source) doesn't mean its *better*!
The people who have read the Sapphire Mansions paper [1] realize that wasting time on the laws Congress passes or doesn't pass is a rather pointless exercise. That is because in the not so distant future it seems likely that if Congress (or *any* other government) has enacted really stupid laws they will only apply to themselves. That is because everyone who isn't clueless will have "left the building" (i.e. moved out of the U.S.) and be living on their yacht or yacht-city in international waters where stupid nation-state laws do not apply. If the power hungry enact some kind of world government which passes and enforces stupid laws it will probably become necessary to relocate to Free-Mars or Free-Titan or Free-Sirus, but we probably have 30-50 years before we have to worry about doing that.
Of course if nobody has to work for a living (one of the points of the paper), one would have to wonder *why* people would seek out jobs as politicians, record or movie industry executives, etc. (I can't imagine those jobs as actually being "fun".) It is interesting to contemplate a Congress or offices in L.A. (or wherever the RIAA & MPAA hang out) which are completely empty... Now of course with so many more people with so much more free time on their hands one would imagine that there will be many more people engaged in creative activities, some of which may include producing many more records and movies. With so many more records and movies available, for artists to get "air time" they are going to have to give them away for free, or perhaps even "pay" people to listen to them. [If we assume each artist has 10 kg of nanorobots available, and one could live comfortably using less than 1 kg, one could "donate" ones nanorobot time to people who are willing to listen to, watch, or play songs, movies or games. This would be a form of virial marketing in the hope that some of the "paid" consumers would turn around and suggest to their friends that the product is decent and people should support the artists with donated nanorobot time (presumably via PayPal in nano-robot seconds or nano-robot kW rather than $ or yen).]
If you want to *worry* about something, worry about a corporation or the U.S. or perhaps China gaining enough of a micro/nanotechnology "edge" to allow things like ubiquitous surveilance & enforcement of their version of a "good" reality. Its bad enough when they try to enforce it in a state or country but they may try to extend it to the world (something that the U.S. comes dangerously close to now) or the solar system. Attempts by Sony & Microsoft to implement various forms of universal surveillance and/or control ("All your computer are belong to us") are examples of the tip of the iceberg in this area. One can only hope that with so much more free time people may become a little more educated and resist attempts to cast reality into a "there can be only one" mold.
Instead of "taking back the government" work towards making its actions irrelevant.
For example, one could support Nano@Home.
It will not stop crashing because the Mozilla / Firefox people have not gotten their act together.
If you bother to limit the maximum amount of memory under Linux (anywhere in the range of "ulimit -Sv 41000" to "ulimit -Sv 350000" (41-350MB) [4]) and try visiting enough web sites you will crash Firefox [1]. I've filed a number of bug reports on this (search the talkback database for "ulimit") or try Mozilla Bug 336807. (If you have Bugzilla votes you might want to vote for it...).
The stack traces suggest that there are multiple problems involved with many different types of memory allocation failures. IMO, Firefox should never made it out of alpha testing with these kinds of bugs [2].
There is a separate problem in Firefox which in some cases shows up as the so-called "memory leak" but which I believe is in fact a "heap fragmentation" problem. This is due to poor use of malloc() & free() and non-explicitly freed memory which is subject to poorly managed garbage collection processes. This is aggravated under Linux because the swapping algorithms do *not* manage programs which continually scan fragmented memory exceeding the available memory (Firefox resident set (RSS) > ~350MB on a 512MB machine). Any minor leaks can aggravate the heap fragmentation problem but solving all of the leak problems will quite probably not solve the problem of heap fragmention leading to increased memory usage the longer the browser remains running. This requires better memory management strategies at higher levels.
The only way this will be resolved is if the Firefox user community make it clear to the developers that they should stop adding features and focus on making the browser reliable and efficient [3].
Under Linux, I made up a simple shell script to run Firefox in limited memory, e.g.
# ulimit -Sc 200000 # uncomment if you want the core dumps...
ulimit -Sv 100000 # why should any browser need more than 100MB? /usr/lib/mozilla-firefox/firefox-bin
the more memory you give it the longer it will probably to crash but I've yet to see it continue running as long as the Energizer bunny... It should be noted that setting a lower virtual memory requirement is no different from say running out of swap space or creating memory bottlenecks which under recent versions of Linux 2.6 will trigger the oom-killer causing memory 'hogs' to be explicitly killed. [I've seen Firefox memory hogging result in the oom-killer kill azureus downloads (azureus (java) is also a memory pig but thats another discussion).]
I was the one of the first 10 programmers hired by Oracle and responsible for a significant fraction of *all* of the early Oracle releases under UNIX. I presumably know something about software being "ready" for release.
It is worth noting that I've tested Firefox running under Windows 98 on a system with 98MB of main memory. It *will* run, it just takes a rather long time to do some things (it will also crash the system from time to time, presumably due to the previously mentioned memory usage problems).
Getting it to load in 41-45MB is tricky (the Firefox code is only ~10 MB but the libraries require a lot of space, as do things like history data, bookmarks, etc.). You have to use a profile with no history, minimal bookmarks, preferences set to minimize memory usage (esp. no javascript & no java), about:blank home page, etc. The minimum usable memory seems to be in the 50-60MB size range. Even then you can crash it by opening too many tabs or windows.
Am I missing something here or do we live in a world where it is impossible to prevent file sharing without a complete disassembly of the Internet?
There seems to be an assumption on the part of the RIAA/MPAA that it is feasible to somehow detect sharing activities. There seems to be technology available to (a) allow one to encrypt all of ones data & (b) choose arbitrary ports on which to share data. So minor extensions to existing file sharing software would seem to make it relatively impossible to detect that sharing was taking place or what was being shared. How precisely do you determine one is sharing the latest Linux ISO vs. the latest episode of Lost? (If one uses encryption and is relatively careful about who one shares things with?) One would presume that anyone who "outed" a within-campus sharing network would be cast to the lions in the center of the campus quad.
So don't current technologies effectively make it impossible to detect sharing of restricted material (or restrict it)? The only way I could see this working is if Universities started charging each user on the basis of bytes sent/rcvd. And even that will soon be defeated by distributed peer-to-peer WANs over 802.11g/n. Or am I missing something?
The problem, IMO, is the extensive use of malloc() which in turn uses sbrk() to continually extend the heap. The problem is *not* leaks so much as heap fragmentation. If the history or bookmarks allocate small chunks of memory they are going to end up scattered across the entire heap due to normal browsing patterns. So each time you malloc(), free(), or garbage collect you are going to have to scan through the entire heap. If the heap data + active code pages exceeds 65-70% of total physical memory on the machine (under Linux) [this can be observed using "top"] the machine will take a significant(!) performance hit. There is a need to split the heap into separate memory pools -- mmap() might be useful in this respect (one pool for history, one pool for bookmarks, one pool for javascript, one pool for images, etc. That way poor behavior in one memory pool will not negatively impact other pools and paging performance can be optimized.
However I'm reasonably certain there is a problem with Linux with paging in general. One can improve it somewhat by decreasing vm.swappiness from 60 to 20-5 but I believe there are other swapping behavior parameters that need to be changed to optimize the performance for "workstation" performance rather than "server" performance. (Its either that or the entire Linux VM/paging system needs to be redesigned because the amount of paging which actually takes place due to Firefox fragmenting the heap is significantly lower than what the hard drive is capable of [at least on my machine].) I think they paging is tuned so that paging rates do not run so high that they lock out other I/O -- but on a workstation one *wants* the active windows (tabs, threads, etc.) to take *all* the I/O they require. If that isn't the problem then one may need an approach which will lock a greater fraction of the "essential" Firefox pages into memory.
It is unfortunate that Turnbull, the Carnegie Institution and NASA chose to affiliate themselves with the Search for Extraterrestrial *Intelligence*. TPF might be capable of locating "water worlds" but there is no experimental information with regard to what fraction of those might have no water or be entirely covered in water (water worlds). It seems obvious that planets like Venus and Mars do not support life or may have only supported it for a brief period (in large part because they are near the edges of the habitable zone). It is also difficult to envision how intelligent life, particularly intelligent life with robust technology (radio transmitters, integrated circuits, rockets, etc.) would evolve on planets entirely covered in water. So one needs to make careful distinctions between systems with dead planets, systems with only water covered planets (pure water worlds), systems with water worlds with primitive life (e.g. those before the Earth's current stage of development), systems with water worlds with intelligent life (our current stage) and those beyond our stage.
Lets do the math. Universe, ~13 billion years old. Earth, ~5 billion years old. Time to develop first sun-like stars perhaps 1 billion years. So there is a reasonable chance that there are (or were) Earth like planets up to 7 billion years older than Earth (at least around stars slightly smaller than the sun which age more slowly). There are some systems with younger Earths (*much* younger for those systems currently in the process of planetary formation). Lineweaver's group has worked on this and has concluded that ~70% of the Earth's in the galaxy are older than ours -- many of them by billions of years.
Based on this it is unlikely that either TPF or SETI (based on its current approaches) will discover "intelligent" life. The statistics dictate that you only have perhaps a 5000 (years) / 12,000,000,000 (years) chance (less than 1 in a million) of finding a planet which hosts "intelligent" life as we know it.
For those systems with terrestrial sized planets and those with water TPF is a reasonable effort -- it might manage to detect water and if lucky atmospheric composition that could hint at life. However pointing the SKA (or any other radiotelescopes) at the stars in the list provided are highly unlikely to be successful because they assume intelligent civilizations which are currently at (and remain at) our stage of development. (This changes the statistics to about 1 in a billion.)
The reasons for this are as follows... Whether you believe in steady state growth (Dyson's assumption in 1960), or exponential growth as "The Singularity" concept proposes the bottom line is that it seems very unlikely that a civilization would actively choose to remain at our state of development (i.e. zero growth for millions or billions of years). If you choose the steady state model the time to develop to a Dyson Shell is measured in a few hundred to a few thousand years. If you choose the singularity model then the time to develop a Matrioshka Brain (also here) is measured in decades. Once either of those states is reached the star goes "dark". So the star list is useless (to either the TPF mission or SETI) for identifying locations of intelligent civilizations with capabilities even slightly beyond our own.
Robert Bradbury
Notes:
For the above calculations I chose 5000 years as the longevity of humans with a reasonable level of technology development. One could limit it to smaller time frames (~100 years for radio or 40-50 years for lasers or rockets). TPF has a much greater chance of being successful than radio or optical SETI because it is working with a much larger time window. Water world longevities range from 100 million to many billion years if they restrict themselves to sun-like (
So, what is the problem? You take the "hot" waste, sort it into specific isotopes using biotech or nanotech sorting systems (one could even use centrifuges as is currently done to enrich uranium, but the bio(nano)tech approaches will be cheaper.
Then you feed the "hot" waste into reactors with isotope specific transmutation paths and "voila" out comes Gadolinum-148 which you then use as a power source for your nanorobots.
Oh yea, I know it can't be done "now" (actually it can be done it would just be really expensive) but within a decade or two when one is looking for long term nuclear power sources for your nanorobots (The nanorobots are ~10 Kg/person before one exceeds the Earth's hypsithermal limit though the Gd-148 requirements per nanorobot are obviously significantly less.)
If none of this makes sense to you then you haven't read Nanosystems and Nanomedicine Vol. I.
Trying to solve long term problems with short term solutions (e.g. burying "waste" inside a mountain) may *not* be the best approach. Particularly when one knows that the current "long term" solution will become completely obsolete due to technology development.
As anyone who has read Nanosystems would know, 1kW is nothing. To power Drexler's 1 cm^3 nanocomputer we need at least 100 kW (Nanosystems, pg 370). Now, that is just the waste heat coming out of a nanocomputer -- one would presume one has to have more power going into it. So show me a power supply with 100+ kW up front -- then I'll be impressed.
Actually no... I haven't touched the Wiki page on Matrioshka Brains (though I might well add some things to it in the future). What is on Wiki today (28 Nov 2005) is entirely the product of others who are familiar with the concepts. I was unfamiliar that the Matrioshka Brain concept had even been mentioned by Charlie Stross and Ray Kurzweil in their recent books until I read about it on/. or in the books themselves.
A good idea doesn't require the inventor to sell it (much):-).
For the record, when the Matrioshka Brain Home Page and related documents were up (as they were for the past several years and will be again shortly) they were frequently requested. The home page alone normally got 400-600 hits a month. The month it was/.'ed that grew to over 10,000 hits. These aren't exactly "unknown" concepts.
As suggested in this paper "Galactic Gradients, Postbiological Evolution and the Apparent Failure of SETI" there are unlikely to be any really advanced civilizations in our galactic vicinity. As pointed out in Ray Kurzweil's recent The Singularity is Near civilizations advance very rapidly (within decades) from our current state to an extremely advanced state we only barely envision. One doesn't communicate (by radio -- or perhaps at all[!]) across interstellar distances because the bandwidth is too low for the information content and thought capacity of advanced civilizations. So the probabilities are that most, if not all, civilizations which are capable of listening to us are thousands of light years away and they have no reason to infect us because it serves no useful purpose. (One would presume that "script kiddies" don't exist in advanced civilizations.)
It is a highly anthropomorphic point of view that traditional space colonization or info-colonization are the paths that will be taken by advanced civilizations. These are concepts based on the relatively limited perspective of a few thousand years of human civilization and even shorter periods of infotech environments. It seems (to me) much more likely that advanced civilizations will replicate through a process similar to the self-replication process one sees in single cells (e.g. bacteria) and not the infectious parasite process one sees with viruses. The problem is that self-replication of advanced civilizations requires extremely close encounters between the developed resource (presumably a solar system, mega-ship or mega-intelligence like a Matrioshka Brain) with a resource of similar or greater mass & energy capacity. Such a resource should be largely undeveloped (like our solar system but much more likely regions of space where new stars are being created). This allows for self-replication over sub-light-year distances. Given the high energy/mass cost of navigating entire solar systems or mega-ships/intelligences as well as the common trajectories of natural objects in our galaxy such "close encounters" are very infrequent (occuring only over millions to billions of years).
(And for those of you who doubt navigating solar systems is feasible you need to go read related papers by Dyson or Criswell.)
While the dishes may be useful for radio astronomy, the concept of radio SETI is so absurd at this point in evolution that its support is entirely unjustified.
The entire concept is over 40 years old and is based on a lack of understanding as to how complex species evolve. If we are to understand SETI there has to be an update of the concepts which integrate them with both modern molecular biology as well as modern computer science. The "traditional" radio astronomy researchers have generally failed to do that.
Slashdot Mirror
As a separate note, I run Firefox with the NoScript Extension to manage which sites can use Javacript extremely selectively -- anyone who enables the running of unknown source and unknown agenda software remotely via their browser is IMO begging for problems. There should be a site -- IamAJavacriptDummy.Org.
> I generally keep IE as the default browser because I get email with links for
> some admin tasks (approvals) that only work in IE.
Hmmm... Can you tell me how I can rune IE7 under Linux? I've heard some rumors that some people can run IE6 under Wine under Linux. I think could pay $$ and install a Parallels emulator (and then pay $$$ for a current copy of XP -- or do I have to install an old vulnerable copy of XP and then go through a lengthy Service Pack upgrade process???). I recently tried upgrading my cousin's original version of XP and it said it wanted to install 67 security upgrades (really!). It was OK because we left the machine running overnight. Then it said it wanted to install Service Pack 2 (but that was from 97 to 250MB of downloads) and over a dial up that would require 1 to 2 more days. Her machine is only 3 years old and I really don't think it can run Vista. In contrast I split the NTFS partition on her hard drive and had Ubuntu up and running in an hour. No more lengthy MacAffee virus update delays for her. Though she likes Firefox (because I've explained how Javascript is a security risk unless only enabled for selected sites) I'm wondering if I should download IE7 and allow her to compare them side by side. But I'd really like her to compare them under Linux since that system seems have many fewer problems with viruses, keystroke loggers, and those other nasties that have generally resulted from Microsoft's attempts to dominate the software market.
Its "bitchy" because the problems (sorry but I consider being able to core dump a program a *problem* [1]) were pointed out *in* Bugzilla in 1.5 and they weren't fixed in 2.0. I took the time to describe the Talkback incidents. I took the time to file the Bugzilla bug reports. I even attempted to build Firefox in debugging mode with symbols to enable better stack traces [2]. That didn't help much because to understand this problem involves not only knowing Firefox in depth but understanding its environment (libstdc++, Glib & Linux) as well. This was done in my free time because I didn't understand how the program could perform so poorly (others get paid to do this kind of thing -- I no longer do). I think I have just reason to bitch.
= 16629912
If you want the "insight" see [3] which was written somewhat after my original post in this thread.
1. I've got 79 (10 GB of compressed(!!)) Firefox core files accumulated over a 5 month period. In normal use I can crash Firefox once or twice a week. If I work at it would take me minutes to hours to crash production (cough) versions of Firefox 1.5 (and now 2.0) -- depending on how "artificial" I make the tests.
2. The developers tend to suggest that this is a "requirement" for people who want to file "serious" bug reports. Why not simply release a *production* debugging version?!?
3. http://it.slashdot.org/comments.pl?sid=203284&pid
I intend to do that. The Bugzilla bugs *were* filed and linked to the talkback incidents for the 1.5 examples. I've now reached the point where I understand what precisely is going on. (See my expanded comments regarding new+libstdc++ and GDK/GTK+Glib+g_malloc and throwing exceptions vs. abort() in the "Nine Reasons to Skip Firefox 2.0" discussion [1].)
= 16629912
The problem wasn't addressed in 1.5 and still isn't addressed in 2.0. It is clear that the developers have simply never tested running out of memory under Linux. There were some exchanges in the 1.5 Bugzilla reports (search for ulimit) and perhaps in some email exchanges about how "hard" it would be to fix. I bought that for a while but now that I understand it more fully that excuse isn't flying anymore. It isn't a degree of difficulty problem as much as a not testing & not caring problem. It took me going down into the guts of libstdc++-v3 and glib to see how the memory allocation was actually being handled to be clear about what was going on. As the Firefox developers tend to be Windows oriented (my subjective impression) I doubt they have ever done that (because they are used to not having source?).
1. http://it.slashdot.org/comments.pl?sid=203284&pid
Caca. As I pointed out in my long message on the other major /. Firefox discussion -- Firefox 2.0 still has some of the same memory allocation and management issues that are present in Firefox 1.5! These were reported as bugs and the developers have simply chosen to ignore them.
I *crashed* (core dump and all) Firefox 2.0 3 times in the first 30 minutes of using it. All you have to do is use ulimit set the virtual memory limit so that memory allocations fail relatively early during your browsing experience (rather than after 5 days of browsing when you would lose much more browser state information -- or have to take a long time to restore a complex session).
It is *NOT* production level software when it is that easy to produce a core dump.
I have subsequently investigated the cause of this. Its simple. Firefox uses the new memory allocation primitive in its C++ code which in turn ends up either throwing an exception or abort()ing when a malloc() fails (depending upon how libstdc++ is compiled). The supporting graphics libraries (GTK & GDK) use g_alloc() which when malloc() fails calls g_error() which ends up calling abort().
The upper level Firefox code (nsSigHandlers.cpp) will only do something "nice" (setup to do a stack trace and attach the debugger) if Firefox is compiled in DEBUG mode (which is probably not true for most or all 'production-wanna-be' versions). In these cases the abort() terminates the program and produces core dump if you have your core dump ulimit and permissions setup to allow for that.
While the in-browser session saver may fix some of the excessive memory usage problems they still are NOT handling most memory allocation failures in a robust fashion.
Are you sure this is true in the latest releases? I'm using almost the most recent libraries from Xorg & assoc as well as the 4.1.1 gcc libstdc++. With libstdc++ compiled properly I can get programs to throw a "bad_alloc" exception (with it not compiled properly it calls abort()). I've looked at the Firefox code and there are uses of catch(...) but I'm unsure yet whether they are in the right places to catch the failures I am seeing.
Now, when I push 1.5.0.7 up to the point where the heap is right around 1GB one starts getting (on the console output from Firefox) Gtk-CRITICAL, Gdk-CRITICAL and GLib-GObject-WARNING assertion failure messages. As they frequently seem to describe NULL objects I suspect that these libraries may now tolerate memory failures (and simply warn you about them). I have yet to confirmed this in the source code. When these happen Firefox doesn't crash but does get a bit "strange". Tabs which seem to auto-refresh (dynamic HTML?) will get opened in new "untitled" windows. If you are careful to close the tab the window closes and Firfox continues normally. If you close the untitled window Firefox crashes. Not the best behavior but something one can tolerate and you know how to handle it gracefully.
What I can't figure out is whether the problem is happening due to some 1GB memory limit in GTK or X or whether I'm actually hitting the Firefox virtual memory limit (which I typically set at 1.3-1.4 GB) and it is catching the memory allocation failures and handling them strangely.
But it goes without saying that these seem to be areas where the developers haven't run robust unit tests.
Precisely. I have managed to put together C++ and thread libraries that explicitly inform me that at least in some cases Firefox is throwing a "bad_alloc" exception. Older libraries apparently just aborted leaving a core dump and a difficult debugging situation when the libraries are distributed without sufficient debugging information.
Almost everywhere in the code whether its downloading a HTML files, allocating parsed code memory, image display memory, etc. should be happening within a context for a specific tab (or window). The bad_alloc should get caught and handled. It doesn't matter most of the time if you lose track of all of that memory so long as you have a preallocated pop-up that says "You are running low on memory, please close some tabs or windows". In that case most of what one is doing (the browser state information) doesn't get lost and you don't have a state of mind resumption nightmare.
This isn't "rocket science" but convincing the Firefox developers of that seems rather difficult.
Given the $70 I've had to spend for an additional 1GB of memory and the days of time I've spent trying to compile Firefox with debugging capabilities [1] so I could figure out exactly what its problems were I would have to agree.
Just because its free and open source and has all this hype associated with it doesn't mean its actually a well written program.
1. It isn't exactly a trivial build.
I very much doubt you could run 100 windows under Win98 because you would exhaust the OS memory. You would need at least Win2K and I've never tried pushing it to 100 windows. Linux & X will handle 100 windows fine on newer Pentiums that can support more than 128MB.
For 100 windows you will probably need 1GB of RAM (or be willing to wait long periods of time while Linux pages the Firefox heap in and out). If it were designed properly it would give you great response in the open tab in your top window and fast tab switching within that window. It would provide reasonable performance (seconds) switching between windows. The implementation quality would be determined by the resident memory size and the tab/window switch time for various amounts of main memory. The actual number of windows would be limited by the amount of swap and/or cache file space you are willing to make available.
Making this fly on 256 or 128MB machines would be possible but would however require very good resource management & coordination between Firefox, X windows and Linux and I doubt even Version 3 will manage to pull it off unless the development team significantly changes is emphasis away from bells and whistles.
I made the Win98 comment to point out that Firefox will at least run on older (even "ancient") hardware and software.
Yep its just like the fancy new Christmas toy that has a few more bells and whistles than last year's toy. Unfortunately it lasted less than a hour before I managed to break it.
r ements.html
I downloaded Firefox 2.0 and installed it under Linux (Gentoo 2.6.17-r7).
Just for the heck of it I tried the same tests I tried in 1.5 and filed bug reports about several months ago. Sure enough Firefox 2.0 does *NOT* handle memory allocation failures. If one limits the amount of virtual memory (e.g. ulimit -Sv 115000) and starts firefox shortly thereafter it will core dump and will open a Talkback Incident window. I managed to file 3 different reports in 30 minutes of using it with memory limits in the range from 100-120MB.
While I anticipate the bookmarks handling may be better (1.5 never should have been released until its bookmarks handling was on par with Netscape 4.72!) I still do not consider this to be production quality software. It will not be until it has decent handling of the various types of resource allocation failures (can't open tab, can't open window, can't allocate memory for image, script, network connection, etc.).
Though I haven't tested it yet I also suspect they haven't handled things like window switching or efficient session restart. The open window (tab) should have top CPU and network priority until it is displayed. Any excess CPU or network resources can be dedicated to non-lead tabs or mininimized windows. They probably also haven't handled the heap fragmentation issue -- so after using Firefox for a week and one has opened 100 windows and 700 tabs (pushing the memory usage up to 1.2GB) it will still take 15 minutes or more to simply close all the windows and exit from Firefox (presumably because it has to merge all of the memory fragments being deallocated). Upon restarting the same session one will find that Firefox only needs 900MB. That is a memory leak and/or heap fragmentation problem.
Please, no comments about how I shouldn't be using my browser this way... You use your browser your way, I'll use it my way. I happen to like to work on multiple things at the same time and when I'm writing research papers it isn't uncommon for me to open hundreds of sources simultaneously. I wouldn't have started limiting the virtual memory and run into Firefox's failings in that area at all if 1.5 hadn't turned out to be such an excessive memory consumer.
The interesting question one might ask is how one releases software and specifies what its minimal memory requirements are if you don't limit its memory to determine that? I can only assume that the Firefox developers picked their numbers out of thin air [1].
As an aside it may be worth noting that Firefox 1.5.0.7 does run under Windows 98 on a 75 MHz Pentium that only has 132MB of memory. It doesn't have the performance that Netscape 4.72 can show on the same machine though. As the 2.0 memory requirements seem to have increased (presumably due to the SQL libraries for bookmarks & history handling) I strongly doubt its performance would be improved over 1.5.0.7.
1. Firefox 2.0 will *NOT* run in the Linux specified Minimum System Requirements of 64MB of RAM [2] unless you also have several hundred MB of swap space. And believe me, having pushed Firefox memory to ~70% of system RAM under Linux -- you would *not* want to try to use it even on a 128MB system due to Firefox's problems with heap memory management and the poor paging performance it generates under Linux.
2. http://www.mozilla.com/en-US/firefox/system-requi
That may be true (though the word others sometimes use is arrogant). The point would be not whether I am best described by either of those terms but whether my post was informative and enabled people reading it to more clearly think about the relative importance of various aspects of the problem.
Given the basic thermodynamics (higher temperatures ~= high efficiency) oxidizing the energy carrier in a power plant (rather than individual vehicles) is likely to result in higher efficiency. So assuming the electricity transport losses are not too high it is going to be better to use batteries (or high capacity capacitors!) rather than fuel cells. The most efficient approach however would involve direct production and storing of the electrons using solar power as the energy source. I could imagine a standardized quick-change ultracapacitor at the "fuel" stations (or a quick recharge) being the most efficient solution.
You have to separate the problem of the energy carrier from the energy source. All current existing methods to make hydrogen available start with upstream in-the-ground based energy sources (methane, propane, gasoline, etc.) and involve dumping the CO2 that results from extracting the hydrogen into the atmosphere. So long as the hydrocarbon (or carbon) source is coming out of the ground you have only solved the NO pollution problem -- you haven't solved the CO2 part of the global warming problem. I.e. you have not produced a sustainable solution.
The only sustainable solutions involve producing hydrocarbon carriers using carbon extracted from the atmosphere -- that currently means biodiesel, bioethanol or biomethane. Propane, methane and gasoline in our current economy are energy carriers produced using solar energy harvested in ancient times. Until one switches to an economy based on energy harvested or created in real time one has an unsustainable reality. That means one has to be harvesting solar energy (incident visible or IR energy, wind or hydroelectric) or nuclear energy (in the long term using breeder reactors or fusion). The bio-carrier sources are inefficient (harvesting 1-2% of incident solar energy) but there is a large installed infrastructure designed to produce them. As whole genome engineering and/or mass production of inexpensive photovoltaic cells increase the solar energy harvesting efficiencies it will become completely feasible to migrate from a "steal from the past" to a "harvest the present" sustainable economic framework. It would help if people could keep this straight in their minds (and if people in leadership and press positions would not mislead or misdirect where the emphasis should be placed).
So I agree with comments that better reformers are not particularly worthy of attention. A more efficient catalytic system for splitting water (compared with photosynthetic efficiencies) would be worth getting excited about.
Of course I'm waiting for the day when our fusion reactors are powering the breeding of Gd-148 which in turn is used to power the nanorobots and/or replicators which will sustain our economy. But we are probably a several decades away from that at this time.
I am absolutely serious! I have timed it several times. (I can even send you logged outputs from ps every 10-15 seconds with the wall clock times if you want them.) The typical situation is Firefox having VM more than total RAM (i.e. 500+MB on a 512MB machine) with a resident set more than 65% of total RAM. You are *unlikely* to see it if you have 1GB of memory (it would probably take heavy use of Firefox for a week or more accessing hundreds to thousands of pages to produce a 700-900MB fragmented heap). You may see it if you run large memory consuming programs concurrently with Firefox (running Gentoo portage package recompiles along with Firefox will make the problem happen with lower Firefox memory usage).
The problem is that with a fragmented heap the free() function in glibc will try to reunite all of the little chunks of memory. If the VM system is not tuned properly (and I've tried variations of vm.swappiness with little effect) the system waits doing nothing for a significant fraction of the time until paged out Firefox heap pages get paged in so it can continue merging the heap memory. Firefox will eventually exit cleanly -- it just takes a very long time. This is a mixed source problem -- Firefox poor heap management + poor malloc/free() strategies in glibc for fragmented heaps + poor paging strategies by Linux.
It could be resolved at any of those levels -- ideally it should be resolved at *all* of them. One could view this as a problem of the general midset I suspect exists among many programmers today... "Oh, its running slow, lets buy some more memory and increase the CPU clock speed -- heaven forbid we should actually look at the problem and write better algorithms to manage the resources intelligently." This is the Intel speed mindset vs. the AMD efficiency mindset.
The poor startup times (which are less than the shutdown times but still significant) may be due to single threaded internet access (on a tab/window/browser basis?). This is something I've only read in passing and not verified by looking at the Firefox code. It does take many minutes to restart complex Firefox sessions (15 - 25 windows w/ many dozens of tabs). CPU and/or Network usage during this period can be described as medium-to-high. But since memory isn't a constraint during that period I would expect both should approach 100% if Firefox were properly multitasking.
I run continual System Monitor graphs displaying CPU/RAM/Network/Disk so I can monitor what is going on in real time as well as vmstat & top in separate windows. I've had a lot of benchmarking experience so you should consider the above to be relatively informed opinions.
When Firefox will run for a week without consuming more than say 128MB of memory -- then I will say *maybe* its ready for the public. Until then its poorly written Jabba-the-Hut-ware.
Users should *not* upgrade, or for that matter, probably even *use* Firefox 1.5.0.x unless they plan to routinely stop it and restart it. Firefox 1.5.0.4 does have memory heap, aka memory cache, fragmentation and usage problems! I am runing Linux 2.6.16.1 on a 512MB Pentium 4 and I routinely have to restart Firefox every 1-2 days because its memory usage grows endlessly. Once Firefox is consuming 60-70% of the RAM on the machine (in the resident memory set) the machine performance as well as Firefox will slow to a crawl. The only way out of this is to restart Firefox (which can take 15-30 minutes due to the long shutdown and session restore times). The long shutdown times are due to heap fragmentation and poor Linux paging strategies. The long restart times are due to network access constraints and CPU usage when opening many windows and tabs.
I would only recommend that people switch to Firefox when the memory (heap) management issues are addressed. Netscape 4.72 was a *much* better browser from this perspective. It worked fine on a Pentium Pro with much less memory under Windows 2000 before I made the mistake of deciding to try Firefox under Linux.
I would also suggest that the Linux paging system needs work. If one has what should be a "memory thrashing" situation (95+% of RAM used, mostly by Firefox) one should not see minimal CPU (20%) and minimal disk (20%) activity.
Just because its "open source" (and I am a strong proponent of open source) doesn't mean its *better*!
Of course if nobody has to work for a living (one of the points of the paper), one would have to wonder *why* people would seek out jobs as politicians, record or movie industry executives, etc. (I can't imagine those jobs as actually being "fun".) It is interesting to contemplate a Congress or offices in L.A. (or wherever the RIAA & MPAA hang out) which are completely empty... Now of course with so many more people with so much more free time on their hands one would imagine that there will be many more people engaged in creative activities, some of which may include producing many more records and movies. With so many more records and movies available, for artists to get "air time" they are going to have to give them away for free, or perhaps even "pay" people to listen to them. [If we assume each artist has 10 kg of nanorobots available, and one could live comfortably using less than 1 kg, one could "donate" ones nanorobot time to people who are willing to listen to, watch, or play songs, movies or games. This would be a form of virial marketing in the hope that some of the "paid" consumers would turn around and suggest to their friends that the product is decent and people should support the artists with donated nanorobot time (presumably via PayPal in nano-robot seconds or nano-robot kW rather than $ or yen).]
If you want to *worry* about something, worry about a corporation or the U.S. or perhaps China gaining enough of a micro/nanotechnology "edge" to allow things like ubiquitous surveilance & enforcement of their version of a "good" reality. Its bad enough when they try to enforce it in a state or country but they may try to extend it to the world (something that the U.S. comes dangerously close to now) or the solar system. Attempts by Sony & Microsoft to implement various forms of universal surveillance and/or control ("All your computer are belong to us") are examples of the tip of the iceberg in this area. One can only hope that with so much more free time people may become a little more educated and resist attempts to cast reality into a "there can be only one" mold.
Instead of "taking back the government" work towards making its actions irrelevant.
For example, one could support Nano@Home.
1. Sapphire Mansions (Understanding the Real Impact of Molecular Nanotechnology)t ml
http://www.aeiveos.com:8080/~bradbury/Papers/SM.h
If you bother to limit the maximum amount of memory under Linux (anywhere in the range of "ulimit -Sv 41000" to "ulimit -Sv 350000" (41-350MB) [4]) and try visiting enough web sites you will crash Firefox [1]. I've filed a number of bug reports on this (search the talkback database for "ulimit") or try Mozilla Bug 336807. (If you have Bugzilla votes you might want to vote for it...).
The stack traces suggest that there are multiple problems involved with many different types of memory allocation failures. IMO, Firefox should never made it out of alpha testing with these kinds of bugs [2].
There is a separate problem in Firefox which in some cases shows up as the so-called "memory leak" but which I believe is in fact a "heap fragmentation" problem. This is due to poor use of malloc() & free() and non-explicitly freed memory which is subject to poorly managed garbage collection processes. This is aggravated under Linux because the swapping algorithms do *not* manage programs which continually scan fragmented memory exceeding the available memory (Firefox resident set (RSS) > ~350MB on a 512MB machine). Any minor leaks can aggravate the heap fragmentation problem but solving all of the leak problems will quite probably not solve the problem of heap fragmention leading to increased memory usage the longer the browser remains running. This requires better memory management strategies at higher levels.
The only way this will be resolved is if the Firefox user community make it clear to the developers that they should stop adding features and focus on making the browser reliable and efficient [3].
Am I missing something here or do we live in a world where it is impossible to prevent file sharing without a complete disassembly of the Internet?
There seems to be an assumption on the part of the RIAA/MPAA that it is feasible to somehow detect sharing activities. There seems to be technology available to (a) allow one to encrypt all of ones data & (b) choose arbitrary ports on which to share data. So minor extensions to existing file sharing software would seem to make it relatively impossible to detect that sharing was taking place or what was being shared. How precisely do you determine one is sharing the latest Linux ISO vs. the latest episode of Lost? (If one uses encryption and is relatively careful about who one shares things with?) One would presume that anyone who "outed" a within-campus sharing network would be cast to the lions in the center of the campus quad.
So don't current technologies effectively make it impossible to detect sharing of restricted material (or restrict it)? The only way I could see this working is if Universities started charging each user on the basis of bytes sent/rcvd. And even that will soon be defeated by distributed peer-to-peer WANs over 802.11g/n. Or am I missing something?
The problem, IMO, is the extensive use of malloc() which in turn uses sbrk() to continually extend the heap. The problem is *not* leaks so much as heap fragmentation. If the history or bookmarks allocate small chunks of memory they are going to end up scattered across the entire heap due to normal browsing patterns. So each time you malloc(), free(), or garbage collect you are going to have to scan through the entire heap. If the heap data + active code pages exceeds 65-70% of total physical memory on the machine (under Linux) [this can be observed using "top"] the machine will take a significant(!) performance hit. There is a need to split the heap into separate memory pools -- mmap() might be useful in this respect (one pool for history, one pool for bookmarks, one pool for javascript, one pool for images, etc. That way poor behavior in one memory pool will not negatively impact other pools and paging performance can be optimized.
However I'm reasonably certain there is a problem with Linux with paging in general. One can improve it somewhat by decreasing vm.swappiness from 60 to 20-5 but I believe there are other swapping behavior parameters that need to be changed to optimize the performance for "workstation" performance rather than "server" performance. (Its either that or the entire Linux VM/paging system needs to be redesigned because the amount of paging which actually takes place due to Firefox fragmenting the heap is significantly lower than what the hard drive is capable of [at least on my machine].) I think they paging is tuned so that paging rates do not run so high that they lock out other I/O -- but on a workstation one *wants* the active windows (tabs, threads, etc.) to take *all* the I/O they require. If that isn't the problem then one may need an approach which will lock a greater fraction of the "essential" Firefox pages into memory.
Lets do the math. Universe, ~13 billion years old. Earth, ~5 billion years old. Time to develop first sun-like stars perhaps 1 billion years. So there is a reasonable chance that there are (or were) Earth like planets up to 7 billion years older than Earth (at least around stars slightly smaller than the sun which age more slowly). There are some systems with younger Earths (*much* younger for those systems currently in the process of planetary formation). Lineweaver's group has worked on this and has concluded that ~70% of the Earth's in the galaxy are older than ours -- many of them by billions of years.
Based on this it is unlikely that either TPF or SETI (based on its current approaches) will discover "intelligent" life. The statistics dictate that you only have perhaps a 5000 (years) / 12,000,000,000 (years) chance (less than 1 in a million) of finding a planet which hosts "intelligent" life as we know it.
For those systems with terrestrial sized planets and those with water TPF is a reasonable effort -- it might manage to detect water and if lucky atmospheric composition that could hint at life. However pointing the SKA (or any other radiotelescopes) at the stars in the list provided are highly unlikely to be successful because they assume intelligent civilizations which are currently at (and remain at) our stage of development. (This changes the statistics to about 1 in a billion.)
The reasons for this are as follows... Whether you believe in steady state growth (Dyson's assumption in 1960), or exponential growth as "The Singularity" concept proposes the bottom line is that it seems very unlikely that a civilization would actively choose to remain at our state of development (i.e. zero growth for millions or billions of years). If you choose the steady state model the time to develop to a Dyson Shell is measured in a few hundred to a few thousand years. If you choose the singularity model then the time to develop a Matrioshka Brain (also here) is measured in decades. Once either of those states is reached the star goes "dark". So the star list is useless (to either the TPF mission or SETI) for identifying locations of intelligent civilizations with capabilities even slightly beyond our own.
Robert Bradbury
Notes:
For the above calculations I chose 5000 years as the longevity of humans with a reasonable level of technology development. One could limit it to smaller time frames (~100 years for radio or 40-50 years for lasers or rockets). TPF has a much greater chance of being successful than radio or optical SETI because it is working with a much larger time window. Water world longevities range from 100 million to many billion years if they restrict themselves to sun-like (
So, what is the problem? You take the "hot" waste, sort it into specific isotopes using biotech or nanotech sorting systems (one could even use centrifuges as is currently done to enrich uranium, but the bio(nano)tech approaches will be cheaper.
Then you feed the "hot" waste into reactors with isotope specific transmutation paths and "voila" out comes Gadolinum-148 which you then use as a power source for your nanorobots.
Oh yea, I know it can't be done "now" (actually it can be done it would just be really expensive) but within a decade or two when one is looking for long term nuclear power sources for your nanorobots (The nanorobots are ~10 Kg/person before one exceeds the Earth's hypsithermal limit though the Gd-148 requirements per nanorobot are obviously significantly less.)
If none of this makes sense to you then you haven't read Nanosystems and Nanomedicine Vol. I.
Trying to solve long term problems with short term solutions (e.g. burying "waste" inside a mountain) may *not* be the best approach. Particularly when one knows that the current "long term" solution will become completely obsolete due to technology development.
Robert
As anyone who has read Nanosystems would know, 1kW is nothing. To power Drexler's 1 cm^3 nanocomputer we need at least 100 kW (Nanosystems, pg 370). Now, that is just the waste heat coming out of a nanocomputer -- one would presume one has to have more power going into it. So show me a power supply with 100+ kW up front -- then I'll be impressed.
Actually no... I haven't touched the Wiki page on Matrioshka Brains (though I might well add some things to it in the future). What is on Wiki today (28 Nov 2005) is entirely the product of others who are familiar with the concepts. I was unfamiliar that the Matrioshka Brain concept had even been mentioned by Charlie Stross and Ray Kurzweil in their recent books until I read about it on /. or in the books themselves.
:-).
/.'ed that grew to over 10,000 hits. These aren't exactly "unknown" concepts.
A good idea doesn't require the inventor to sell it (much)
For the record, when the Matrioshka Brain Home Page and related documents were up (as they were for the past several years and will be again shortly) they were frequently requested. The home page alone normally got 400-600 hits a month. The month it was
It is a highly anthropomorphic point of view that traditional space colonization or info-colonization are the paths that will be taken by advanced civilizations. These are concepts based on the relatively limited perspective of a few thousand years of human civilization and even shorter periods of infotech environments. It seems (to me) much more likely that advanced civilizations will replicate through a process similar to the self-replication process one sees in single cells (e.g. bacteria) and not the infectious parasite process one sees with viruses. The problem is that self-replication of advanced civilizations requires extremely close encounters between the developed resource (presumably a solar system, mega-ship or mega-intelligence like a Matrioshka Brain) with a resource of similar or greater mass & energy capacity. Such a resource should be largely undeveloped (like our solar system but much more likely regions of space where new stars are being created). This allows for self-replication over sub-light-year distances. Given the high energy/mass cost of navigating entire solar systems or mega-ships/intelligences as well as the common trajectories of natural objects in our galaxy such "close encounters" are very infrequent (occuring only over millions to billions of years).
(And for those of you who doubt navigating solar systems is feasible you need to go read related papers by Dyson or Criswell.)
While the dishes may be useful for radio astronomy, the concept of radio SETI is so absurd at this point in evolution that its support is entirely unjustified.
The entire concept is over 40 years old and is based on a lack of understanding as to how complex species evolve. If we are to understand SETI there has to be an update of the concepts which integrate them with both modern molecular biology as well as modern computer science. The "traditional" radio astronomy researchers have generally failed to do that.