You can download every version of Firefox we've ever released here ftp://ftp.mozilla.org/pub/firefox/releases/ . We have no interest in forcing users to run the latest version.
Memory use climbing like that is almost certainly a problematic (leaky) extension. Check out the tail end of Nicholas's slides for the list of the top leaky extensions, which includes/included AdBlock+, LastPass, etc. Once you get near 2.2 or so GB on WInXP the OS starts freezing you for longer and longer as it twiddles page tables and the like, eventually freezing you for more than 30 seconds. (watch user vs system CPU when it freezes).
One other surprising source of a slow browser: Huffington Post. Their pages have a Twitter feed display which progressively slows down your browser, since it keeps adding more data to the scrolling list of tweets. Never leave a HuffPost page up (with a common hashtag for the search, at least).
I can (now) run for weeks with a browser with 850 tabs (though only 50-150 of them loaded, normally).
340 tabs... Piker.:-) I typically run nowadays with ~850 -- there's a handy extension (Tab Stats 0.0.2) that will show you how many tabs you have, how many are duplicates, etc. 64-bit Fedora 15, running FF12 nightlies. Currently using ~ 2GB memory for 855 tabs (60 loaded).
Ironically the biggest memory user in about:memory is facebook (>100MB). Ironic, because I've never opened a tab to facebook, and I don't have a facebook account. This is the result of all those "Like" buttons, each of which takes an insane amount of memory. 100MB for facebook Like buttons. Really.
a) that was a long time ago b) you didn't say 'why' - the quality/performance/etc bar for patches to pass for a browser (now) used by 400m people is pretty high - but that bar is very similar for internal developers (employees or not). Back in the Netscape days, new Netscape employees would frequently get annoyed that they weren't just able to check their code in; they had to get reviews and then have someone with checkin privs do it, just like any other contributer. c) some patches make user or web-visible changes that aren't agreed to d) some bugs (when they get serious look in patch review) aren't ones we'd agree are bugs, or fixing them would cause other problems.
n.b. I work for Mozilla now, and in the pre-FF days I was a 3rd-party mozilla contributor and release 'driver'
Mozilla/Firefox is experimenting with SPDY, as you can see if you read Patrick McManus' blog (http://bitsup.blogspot.com/2011/09/spdy-what-i-like-about-you.html)
SCTP can be run over UDP, but in any case needs the server you're talking to to support it (like SPDY). There are some parallels between them, though SCTP has some advantages in not blocking when a single packet is lost like TCP (which SPDY runs over). A researcher at UDel has some nice examples of HTTP-over-SCTP (and SPDY as well).
Running Firefox on Fedora 11 - I typically have 10-15 windows open with *450* tabs - and it runs for months like that without loading the system. NOTE: Flashblock is a must, *especially* under Linux.
One thing that really does help is BarTab (under 3.x; under 4.x until it's available you can set a simple config var to get a similar result). This keeps it from actually loading tabs when restoring a session until you switch to that tab. The only way you can get away with so many tabs in any browser...
Or look at a couple of Ojo 900's (also SIP) - not large screens, but rock-solid 30fps even at low bandwidth; they'll run 24-7 and the fee is low (and they're cheap). You can dial the bandwidth down if you want; they'll run a nice experience down to 120Kbps, and can do down to 80K@30fps. At 250K they're great. I know someone who had dinner with his fiance every night, 1000 miles apart, using Ojos. They'd leave them on as soon as both of them were home, in the kitchen while they both cooked.
512 byte sectors were known to be a performance bottleneck LONG before the late 90's. At Commodore, I put full support in for any power-of-two HD sector size back around 92-ish (plus the FS supported allocation blocks of powers-of-two multiples of sectors, which most filesystems have for quite a while). Larger sector sizes was a win on performance, much the way larger allocation sizes in the FS was a big win, though more related to low-level overhead. Certainly on the platters larger sector sizes is a win - we experimented with that for floppies, and used a floppy format that got much of the benefit (removal of all inter-sector gaps, replaced with a single gap per track - you lost the ability to write single sectors, but got 10% more storage and faster transfer times - effectively one big sector, but with additional sync/etc headers that let you read data starting at any logical sector, to reduce rotational latency). Similar logic applies to HD platters - larger sectors lets you get more user bits on a track and higher transfer rates, but decreases the granularity for writing data.
Hey dave, that Caps Lock key is the most important key on the PC layout! Mine's used so much is has parallel grooves worn in it from my fingernail. What? You mean it's supposed to do something other than act as an alternate Control key? Never mind....
(From the fingers of a multi-decade Emacs user, who misses the Amiga (and Sun) keyboard layouts).
You believe the theory that has observations to prove it works. Not the scientist. Pretty simple if you ask me.
That's fine, if you can read the papers, and read the papers confirming (or not) the observations, etc. For example, with the whole autism/vaccine kerfluffle, the original paper by a British doctor has been debunked, and apparently he made up and/or mis-represented his data. Plus various doctors (which the public conflates with scientists, which is sometimes true and sometimes not) make all sorts of claims, often based not on scientific methods or verifiable proof, but instead on personal opinion/experience and a few particular cases they've seen. The problem is that it's way to easy to jump to an unwarranted conclusion, or to do what humans are all too good at - picking facts that support what we already believe or want to believe.
The public has little or no understanding of how science works (even many non-scientist academics don't). Combine that with the modern media's preference to not interpret, but instead present all points-of-view as equivalent (or to prefer certain points-of-view based on politics), and it's easy to see how the public can reach the belief that science is just opinion too - that you can pick who to agree with, based on what you want to be true.
Not all that much of the OS was assembler - the biggest piece was FFS (which subsumed OFS), and honestly probably shouldn't have been in ASM - but space was *tight*. Sure, quite a few of the drivers were in assembler, and performance-critical parts of Exec were in ASM, but that was almost required at the time for low-level HW interfacing. Much of the OS was in C. (I was responsible for removing the majority of the BCPL code (look it up on Wikipedia) used in AmigaDOS for OS 2.0.)
It was all fairly carefully designed, and a lot of work went into making it bulletproof and snappy. While there are huge benefits to memory protection nowadays, most Amiga programs and certainly the OS were quite resilient to pressures, such as allocation failures, which would crush almost all apps today. Error paths were much more likely to get tested, and the path wasn't the library calling exit(1) for you when an allocation failed.
That said: it's 15 years behind the times now. No major improvements have been made (some, yes, but nothing major). Dave is basically right - and we were in the last year trying to break with the old hardware design, though there was one last big step left in it that actually got to the early prototype stage (AAA). We hadn't planned out where software would go, but if you look at what Apple did you probably get a hint of what we might have done. It would have been tough, though, since we didn't have the resources to throw at emulation at the time that Apple did. In the last year, the SW group (which I ended up running a good part of) was down to a handful of people ( 10 I think). I think the "OS" group was down to maybe 3 or so. The writing was mostly on the wall by around a year before *poof*, and much of the team left in '92-93 to places like Scala (where many still are, and where I went after bankruptcy), 3DO (which had a strong ex-Amiga and ex-Commodore influence from the start), etc.
I wish it had been open-sourced back in '95 or so. It may not have survived intact, but it might have formed the core for a strong competitor to Linux/etc and at least pushed them to improve their responsiveness much earlier on.
A useful addition to Gnus (it may be part of the distribution now):
;; Provide a function to switch to a *Summary buffer or the *Group buffer. ;; Let the user decide whether to bind it. Written by Randell Jesup. ;; (defun switch-to-gnus () "Switch to a *Summary whatever* buffer if one exists. If none exist, switch to the *Group* buffer. If that doesn't exist, complain." (interactive) ;; (let ((buflist (buffer-list)) (done 0) (saw_group 0)) (while (and (= done 0) (not (equal buflist nil))) (let ((candidate (car buflist))) (let ((candname (prin1-to-string candidate))) (if (string-match "#<buffer +\\*Summary.*\\*>" candname) (progn (switch-to-buffer candidate) (setq done 1)) (setq buflist (cdr buflist))) ;; remember if we saw *Group* (if (string-equal "#<buffer *Group*>" candname) (progn (setq saw_group 1)))))) (if (= done 0) (if (= saw_group 1) (switch-to-buffer "*Group*") (error "Gnus doesn't appear to be running")))))
;; This switches to the a *Summary buffer if one exists, else to *Group* (global-set-key [f9] 'switch-to-gnus)
A couple of other goodies:
;; If invoked from a non-shell buffer, it changes to or opens a shell ;; buffer with the path set to that of the buffer from which this command ;; was invoked. If invoked from a shell-mode buffer, it changes back to ;; the last buffer from which the shell was invoked whith this command. (global-set-key [f3] 'shell-pushd-to-buffer-path)
There are tools for memory failure checking. In the old Amiga days, we had several tools such as "memoration", which would fail arbitrary/random allocations, with all sorts of patterns (from a specific library, of a specific size, every Nth, random, etc). Typically we'd test the OS, libraries and applications with both random failures and increasing values of N for every Nth. In later versions of the OS, we could run the entire system with random allocation failures on for long periods and the only result was occasionally a user action would fail, and the OS certainly wouldn't fail.
Similar tools exist for Linux and I assume Windows, though I suspect they're used a lot less.
I worked on a large, early Ada project at GE Corporate Research. This was the back-end for a compiler for an early RISC processor, the RPM-40. Assembly-language reordering for RISC pipeline (Gross' algorithm with heuristics), NOP insertion, assembling, linking. We were working for a manager who had been on the 'green book' Ada spec team, and using the early Vax VMS Ada compiler. It was one of the few of the era that could handle our code, which had I think 8 levels of inheritance, including something like 6 levels of generics (starting with things like tuples and lists, up through DAGs of instruction nodes for input to reordering algorithms).
One amusing thing that bit us was we kept getting inconsistent results. We finally tracked it down to the fact that every one of us had assumed that local variables with built-in types (integers, etc) would be initialized (integers to 0, etc). In fact they were unknown stack-garbage - we all went to the green book, looked and looked, and finally realized that only derived types have default initializers that will be invoked for local vars. We were amazed this was allowed (given the goal of "correctness"), and even more so that the compiler didn't flag it as a possible problem (at the time, my Amiga Lattice C compiler would warn you of possible uninitialized values).
It did all finally work, and had a very nice overall design. The separation of API from implementation did help. C++ templates produced some of the benefits that Ada generics had, though not all of them, and the syntax (due to the origins of C++) was a little awkward.
After the traditional Chess/Stratego/etc, I discovered wargames (Blitzkrieg, PanzerBlitz, SPI games, etc), and then in 8th grade or so got access to a remote dialup terminal with access to classic StarTrek (and shortly later, access to a room of terminals where I could play Star Trader (or something like that)). I also got hooked on D&D somewhere in this timeframe. Ended up playtesting SPI wargames on Friday nights in 8th/9th grade and taking basic courses in someone's home Saturday mornings in Greenwich Village, and learning about how they used to have to deal with drum memory.
In college I got access to Universe (on a TOPS-20 (I think) machine), Dungeon, Zork (ported it in Fortran to an IBM mainframe), etc, etc. TRS-80 games, Rogue on MSDOS, porting Nethack to the Amiga, working for PlayNet (which became AOL). Also I'd play a real-time multi-player Trek game that was a predecessor of Netrek (which I later ported to the Amiga, and played in online league games in '92 or so), later worked porting games to the Amiga.
Since this about first experiences, I'll stop the stream of consciousness there.
A repository for "all known facts in the universe" is a pretty boring (and largely useless) thing. Effectively that will become a huge bucket for data - think how much random data there is. How many exabytes of raw data (scientific instrument readings, etc) are produced each year? Don't forget, images are data - that includes everyone's snapshots with their cameras (they're a recording of a place at a specific time, and inherently are *full* of (mostly) useless facts).
In a way, what you want already exists, in a very ugly way - it's the web itself.
Much more interesting (and useful) are well-chosen and well-organized data and facts. That's why Wikipedia + WikiMath is overall more useful than Wikieverything. The distinction can be entirely editorial; they can be hosted together, they can link to each other - but retaining a separation is useful to both sides.
Ah, but you're wrong. Wikipedia is a type of encyclopedia. It isn't a book, but it has a set of goals, one primary one of which is to be "encyclopedic". Just because they have a website you can add to, it doesn't mean it's a free-for-all - you shouldn't host your blog there. And, though it may seem so at times, Wikipedia is NOT a repository for all known facts in the universe. Random lists (members of the RPI Science Fiction Club in 1980, 1890 US Census house-by-house data, etc) do not belong there. Not only do they clutter it up (including search listings and providing dusty un-watched corners for vandalism to persist), but it also costs the Wikipedia foundation money. If mathematicians use this, edit them, discuss them - all of that costs the foundation for something that's not part of its goal.
As the grandfather post indicated, the best solution is a separate wiki, such as WikiMath.
Don't dismiss this out-of-hand - there are some seriously good uses for this for some people, just as there are uses for things like CF carrier testing.
For some people, it's very useful and/or comforting knowing if you have (or don't have) the BRCB2 (sp?) gene that predisposes you to breast cancer, or if you have a gene that causes you to be more sensitive to a wide range of drugs (there's a test on the market for this now), or are a carrier for certain nasty genetic diseases.
My family has a history of Type-1 Diabetes, for which a predisposition/risk factor is genetically linked through around a dozen genes, some of which have been identified (and some are shared with MS and Crohn's disease). It would be useful for people in my family to know if they're carriers for some of the genes that increase risk - doubly so since there may be ways to reduce the risk through environmental factors, or the possibility of close monitoring of those at risk in order to enable possible treatments before the immune system has destroyed all the Beta cells.
That said (and there are plenty of other positive uses), there are some serious issues with any test like this.
Privacy is a huge one. Partly from the government (see: Gattaca, Homeland "Security"), partly from insurance companies, partly from the courts (i.e. warrant from a prosecutor or civil suit telling 23andme to release a profile for a court case). And the issues others mentioned - advertising, control in the long future of the info, etc. The current administration (and things like warrant-less, illegal wiretapping and "terrorist databases" have made a lot of people far less trusting of either the government or large businesses that hold our information.
Another is psychological, as mentioned in the story - how much do you *really* want to know about your risk factors? Everyone has a bunch, and most of us know the major ones (family history of heart disease/breast-cancer/CF/yada yada), but there are a lot more we don't know, and most of them will not actually ever affect us (my uncle was convinced he'd die young from a heart attack like my grandfather, retired at 59 - and he's still splitting his own wood with an axe at age 84). It can be very scary, and could cause people to warp their lives based on a poorly-understood risk. (Even if the science behind a genetic risk is well-understood, the user of this report may not understand it.) With regards to procreation, some 'genetic' risks are not part of your genetic makeup - they're due to imprinting issues and/or genetic damage/aging of reproductive cells.
On the flip side - if you were adopted or simply didn't have access to medical records for most of your family, or had very few relatives, you might welcome the chance to find out the same risks that others know from their families.
So I see no problem with offering it. I'd STRONGLY suggest that they do everything possible to minimize the worries over privacy of the records, though no assurance is likely to remove all legitimate fears (or paranoia).
One of the first systems (probably not the first) to make use of filesystem notifications was the Amiga; I added Notification support to the Amiga ramdisk Way Back When for OS 2.0 (3.0?) so that applications could ask for notification on changes to system or application preferences stored in the virtual PREFS: disk (normally stored in RAM: after boot).
The equivalent would be having something in X (perhaps in KDE/Gnome/etc on top of X) watch the xorg.conf file, and when it changed re-read and re-parse it. So "cp xorg_1024x768.conf xorg.conf" could cause an automatic resolution change to a saved 1024x768 configuration (assuming X handled on-the-fly resolution changes) - or that if you wrote a new xorg.conf editing tool, all it had to do was rewrite xorg.conf to get the changes to take effect. And other programs could be watching it as well and react, instead of having to somehow know that programs X Y and Z are interested and need to be HUPed or stopped and restarted or whatever.
All the daemon "HUP-to-reread" stuff would become automatic with this sort of setup.
Ancient history, though many of the abilities mentioned don't exist in many (most) modern OS's. In some cases, more complex and more capable mechanisms have surpassed the old Amiga ideas, such as systems like dbus - but the existing Linux software doesn't always make good (or consistent) use of them!
My "normal" situation is 7-10 Firefox windows open, with 5-25 tabs per window (for normal use, not instances of Mozilla I'm testing). Typically the total number of tabs is 100-150 depending on which machine we're talking about. The one I'm typing on here has been running (on Centos)since July 16th (and that was when it was shut down for an upgrade to Firefox 2), and the run before that had been up since around November (on 1.5.x). 440MB resident; 650MB virtual size, after 3 months of 150 tabs and daily use. When I shut down to upgrade Firefox in July, it was around 500MBish, with 100+ tabs.
Things that help stability/mem-usage:
Don't use Flash (I don't have it installed)- and if you do, use FlashBlock
Don't use every new extension under the sun - I use a very limited set
I don't use RSS (much) - not sure if this helps
PDFs are displayed by external apps, not in-browser-window
You see something similar at the Jersey Shore - most of the workers nowadays aren't kids from North Jersey or Philly/burbs, they're college-age summer workers mostly from Eastern Europe. (Not that I'm an expert, but I've seen it, and others talk about it.) They make good money (compared to home, though exchange rates haven't helped them recently), they can improve their english, and they get a relatively interesting/fun experience compared to summer jobs available at home.
American high-school teens and sometimes college-age students used to fill those jobs; now they *seem* to be either partying, hanging out, or doing "volunteer"/extra-curricular work to spiff up their applications for college (which has become an arms-race with a combination of grade inflation and ever-increasing need to have a zillion non-classroom items to get into top schools). Now, this is a way-over-generalization; even around here (outer Main Line of Philly burbs) local teens man the counters at the local Chester Springs Creamery and at the big/fancy nursery (Waterloo Gardens). And another factor many be less families spending month-plus stints at the shore the way many used to back 20-50+ years ago; no teen there for a week or two will get a local job - and those that can spend a month-plus are well-enough off that the kids don't need to work. The other mainstay, college students, I have less visibility into - they may be working internships, or (also) hanging out, or they may be grinding shave time off graduation (I have heard from friends who visit my old college that current students are much more focused on graduation and earning money post-graduation than we were back around 1980, perhaps because of the increase in tuition).
Spray foam used the way you suggest assumes there's an empty cavity that you can fill - doesn't apply if there's already insulation there (like R11 fiberglass filling the cavity), or if there's no cavity (cathedral ceilings with Homasote panels for the roof/ceiling, cinderblock walls - you can foam the holes if they're empty, but it doesn't help that much). It's also rarely used in on the floor of attics for a number of reasons (including usually having to remove all the existing insulation, though you can spray the rafters and bottom of the deck, converting a "cold roof" to a form of "hot roof").
Trust me, I have ~80 windows (a fair number of them large, 7' x 4', and a lot of 2'x6', all double-pane), and you can not ignore heat loss from windows. South-facing windows with the right makeup and coatings can be net energy-gains - but I guarantee you that north-facing ones don't, and heavily-shaded ones don't, and cloudy days don't help... And they don't help at night (nor would solar, except that you get to "store" the power in the grid via net-metering). Plus you have to size the heating system for winter-nighttime. The *best* window is around the equivalent of R-4.
Add to that in the sunnier places (southern US, CA, etc) you don't care much about heating, but you care a LOT about cooling.
That said - insulation is a better investment in almost all houses, IF it's possible to add without reconstruction - and in some types/ages of house, it isn't.
The problem isn't *no* standards for encryption with SIP; the problem is *too many* ways. Not really the actual data encryption, but the ways for exchanging keys. Someone did a matrix for an IETF meeting a year or so ago; there were something like 15+ methods, mostly incompatible, all with different side-effects on early media, conferencing, forking (having multiple phones ring), processing overhead, etc, etc. And there's no agreement on them. People are trying, however. For the data encryption, mostly that's SRTP
Another point was that offers of RTP/SAVP or RTP/SAVPF are often rejected out-of-hand and killed the entire call with phones that don't support it, since SIP/SDP didn't provide any easy way to say "I'd like to do encryption, but it's not absolutely required". A recent effort has been made to correct this (best-effort-srtp and the work on capability negotiation in mmusic). Doing this makes it more important to signal to the user the encryption status - much easier on a hardphone with a screen or videophone than an ATA acting as translator for older POTS phones.
Yes, I work for a company that does encrypted videophones.
You may be referring to the very recent study of a large number of people (thousands) in the UK using "gene chips" to identify common loci of different genetic diseases. MS apparently shares some susceptibility genes/loci with other auto-immune diseases, such as type-1 (juvenile) diabetes and Crohnes disease (sp). See Science News, or MIT Technology Review I think.
Slashdot Mirror
You can download every version of Firefox we've ever released here ftp://ftp.mozilla.org/pub/firefox/releases/ . We have no interest in forcing users to run the latest version.
Bingo.
Memory use climbing like that is almost certainly a problematic (leaky) extension. Check out the tail end of Nicholas's slides for the list of the top leaky extensions, which includes/included AdBlock+, LastPass, etc. Once you get near 2.2 or so GB on WInXP the OS starts freezing you for longer and longer as it twiddles page tables and the like, eventually freezing you for more than 30 seconds. (watch user vs system CPU when it freezes).
One other surprising source of a slow browser: Huffington Post. Their pages have a Twitter feed display which progressively slows down your browser, since it keeps adding more data to the scrolling list of tweets. Never leave a HuffPost page up (with a common hashtag for the search, at least).
I can (now) run for weeks with a browser with 850 tabs (though only 50-150 of them loaded, normally).
340 tabs... Piker. :-) I typically run nowadays with ~850 -- there's a handy extension (Tab Stats 0.0.2) that will show you how many tabs you have, how many are duplicates, etc. 64-bit Fedora 15, running FF12 nightlies. Currently using ~ 2GB memory for 855 tabs (60 loaded).
Ironically the biggest memory user in about:memory is facebook (>100MB). Ironic, because I've never opened a tab to facebook, and I don't have a facebook account. This is the result of all those "Like" buttons, each of which takes an insane amount of memory. 100MB for facebook Like buttons. Really.
a) that was a long time ago
b) you didn't say 'why' - the quality/performance/etc bar for patches to pass for a browser (now) used by 400m people is pretty high - but that bar is very similar for internal developers (employees or not). Back in the Netscape days, new Netscape employees would frequently get annoyed that they weren't just able to check their code in; they had to get reviews and then have someone with checkin privs do it, just like any other contributer.
c) some patches make user or web-visible changes that aren't agreed to
d) some bugs (when they get serious look in patch review) aren't ones we'd agree are bugs, or fixing them would cause other problems.
n.b. I work for Mozilla now, and in the pre-FF days I was a 3rd-party mozilla contributor and release 'driver'
Mozilla/Firefox is experimenting with SPDY, as you can see if you read Patrick McManus' blog (http://bitsup.blogspot.com/2011/09/spdy-what-i-like-about-you.html)
SCTP can be run over UDP, but in any case needs the server you're talking to to support it (like SPDY). There are some parallels between them, though SCTP has some advantages in not blocking when a single packet is lost like TCP (which SPDY runs over). A researcher at UDel has some nice examples of HTTP-over-SCTP (and SPDY as well).
Running Firefox on Fedora 11 - I typically have 10-15 windows open with *450* tabs - and it runs for months like that without loading the system. NOTE: Flashblock is a must, *especially* under Linux.
One thing that really does help is BarTab (under 3.x; under 4.x until it's available you can set a simple config var to get a similar result). This keeps it from actually loading tabs when restoring a session until you switch to that tab. The only way you can get away with so many tabs in any browser...
Or look at a couple of Ojo 900's (also SIP) - not large screens, but rock-solid 30fps even at low bandwidth; they'll run 24-7 and the fee is low (and they're cheap). You can dial the bandwidth down if you want; they'll run a nice experience down to 120Kbps, and can do down to 80K@30fps. At 250K they're great. I know someone who had dinner with his fiance every night, 1000 miles apart, using Ojos. They'd leave them on as soon as both of them were home, in the kitchen while they both cooked.
512 byte sectors were known to be a performance bottleneck LONG before the late 90's. At Commodore, I put full support in for any power-of-two HD sector size back around 92-ish (plus the FS supported allocation blocks of powers-of-two multiples of sectors, which most filesystems have for quite a while). Larger sector sizes was a win on performance, much the way larger allocation sizes in the FS was a big win, though more related to low-level overhead. Certainly on the platters larger sector sizes is a win - we experimented with that for floppies, and used a floppy format that got much of the benefit (removal of all inter-sector gaps, replaced with a single gap per track - you lost the ability to write single sectors, but got 10% more storage and faster transfer times - effectively one big sector, but with additional sync/etc headers that let you read data starting at any logical sector, to reduce rotational latency). Similar logic applies to HD platters - larger sectors lets you get more user bits on a track and higher transfer rates, but decreases the granularity for writing data.
(From the fingers of a multi-decade Emacs user, who misses the Amiga (and Sun) keyboard layouts).
That's fine, if you can read the papers, and read the papers confirming (or not) the observations, etc. For example, with the whole autism/vaccine kerfluffle, the original paper by a British doctor has been debunked, and apparently he made up and/or mis-represented his data. Plus various doctors (which the public conflates with scientists, which is sometimes true and sometimes not) make all sorts of claims, often based not on scientific methods or verifiable proof, but instead on personal opinion/experience and a few particular cases they've seen. The problem is that it's way to easy to jump to an unwarranted conclusion, or to do what humans are all too good at - picking facts that support what we already believe or want to believe.
The public has little or no understanding of how science works (even many non-scientist academics don't). Combine that with the modern media's preference to not interpret, but instead present all points-of-view as equivalent (or to prefer certain points-of-view based on politics), and it's easy to see how the public can reach the belief that science is just opinion too - that you can pick who to agree with, based on what you want to be true.
Not all that much of the OS was assembler - the biggest piece was FFS (which subsumed OFS), and honestly probably shouldn't have been in ASM - but space was *tight*. Sure, quite a few of the drivers were in assembler, and performance-critical parts of Exec were in ASM, but that was almost required at the time for low-level HW interfacing. Much of the OS was in C. (I was responsible for removing the majority of the BCPL code (look it up on Wikipedia) used in AmigaDOS for OS 2.0.)
It was all fairly carefully designed, and a lot of work went into making it bulletproof and snappy. While there are huge benefits to memory protection nowadays, most Amiga programs and certainly the OS were quite resilient to pressures, such as allocation failures, which would crush almost all apps today. Error paths were much more likely to get tested, and the path wasn't the library calling exit(1) for you when an allocation failed.
That said: it's 15 years behind the times now. No major improvements have been made (some, yes, but nothing major). Dave is basically right - and we were in the last year trying to break with the old hardware design, though there was one last big step left in it that actually got to the early prototype stage (AAA). We hadn't planned out where software would go, but if you look at what Apple did you probably get a hint of what we might have done. It would have been tough, though, since we didn't have the resources to throw at emulation at the time that Apple did. In the last year, the SW group (which I ended up running a good part of) was down to a handful of people ( 10 I think). I think the "OS" group was down to maybe 3 or so. The writing was mostly on the wall by around a year before *poof*, and much of the team left in '92-93 to places like Scala (where many still are, and where I went after bankruptcy), 3DO (which had a strong ex-Amiga and ex-Commodore influence from the start), etc.
I wish it had been open-sourced back in '95 or so. It may not have survived intact, but it might have formed the core for a strong competitor to Linux/etc and at least pushed them to improve their responsiveness much earlier on.
A useful addition to Gnus (it may be part of the distribution now):
;;
;; remember if we saw *Group*
;; Provide a function to switch to a *Summary buffer or the *Group buffer.
;; Let the user decide whether to bind it. Written by Randell Jesup.
;;
(defun switch-to-gnus ()
"Switch to a *Summary whatever* buffer if one exists. If none exist,
switch to the *Group* buffer. If that doesn't exist, complain."
(interactive)
(let ((buflist (buffer-list))
(done 0)
(saw_group 0))
(while (and (= done 0)
(not (equal buflist nil)))
(let ((candidate (car buflist)))
(let ((candname (prin1-to-string candidate)))
(if (string-match "#<buffer +\\*Summary.*\\*>" candname)
(progn
(switch-to-buffer candidate)
(setq done 1))
(setq buflist (cdr buflist)))
(if (string-equal "#<buffer *Group*>" candname)
(progn
(setq saw_group 1))))))
(if (= done 0)
(if (= saw_group 1)
(switch-to-buffer "*Group*")
(error "Gnus doesn't appear to be running")))))
;; This switches to the a *Summary buffer if one exists, else to *Group*
(global-set-key [f9] 'switch-to-gnus)
A couple of other goodies:
;; If invoked from a non-shell buffer, it changes to or opens a shell
;; buffer with the path set to that of the buffer from which this command
;; was invoked. If invoked from a shell-mode buffer, it changes back to
;; the last buffer from which the shell was invoked whith this command.
(global-set-key [f3] 'shell-pushd-to-buffer-path)
;; make switching buffers easy
(global-set-key [f6] 'other-window)
(defun prev-window ()
"previous window"
(interactive)
(other-window -1))
(global-set-key [S-f6] 'prev-window)
;; Windows-ish commands:
;; Block cut, copy, paste:
;;; KEY: [A-x]: Cut region.
(global-set-key [?\A-x] 'kill-region)
;;; KEY: [A-c]: Copy region.
(global-set-key [?\A-c] 'copy-region-as-kill)
;;; KEY: [A-v]: Paste.
(global-set-key [?\A-v] 'yank)
;;; KEY: [ESC A-v]: If you've just used paste, use this key to cycle through
;;; KEY: previous available pastes on the Emacs clipboard.
(define-key esc-map [?\A-v] 'yank-pop)
There are tools for memory failure checking. In the old Amiga days, we had several tools such as "memoration", which would fail arbitrary/random allocations, with all sorts of patterns (from a specific library, of a specific size, every Nth, random, etc). Typically we'd test the OS, libraries and applications with both random failures and increasing values of N for every Nth. In later versions of the OS, we could run the entire system with random allocation failures on for long periods and the only result was occasionally a user action would fail, and the OS certainly wouldn't fail.
Similar tools exist for Linux and I assume Windows, though I suspect they're used a lot less.
I worked on a large, early Ada project at GE Corporate Research. This was the back-end for a compiler for an early RISC processor, the RPM-40. Assembly-language reordering for RISC pipeline (Gross' algorithm with heuristics), NOP insertion, assembling, linking. We were working for a manager who had been on the 'green book' Ada spec team, and using the early Vax VMS Ada compiler. It was one of the few of the era that could handle our code, which had I think 8 levels of inheritance, including something like 6 levels of generics (starting with things like tuples and lists, up through DAGs of instruction nodes for input to reordering algorithms).
One amusing thing that bit us was we kept getting inconsistent results. We finally tracked it down to the fact that every one of us had assumed that local variables with built-in types (integers, etc) would be initialized (integers to 0, etc). In fact they were unknown stack-garbage - we all went to the green book, looked and looked, and finally realized that only derived types have default initializers that will be invoked for local vars. We were amazed this was allowed (given the goal of "correctness"), and even more so that the compiler didn't flag it as a possible problem (at the time, my Amiga Lattice C compiler would warn you of possible uninitialized values).
It did all finally work, and had a very nice overall design. The separation of API from implementation did help. C++ templates produced some of the benefits that Ada generics had, though not all of them, and the syntax (due to the origins of C++) was a little awkward.
In college I got access to Universe (on a TOPS-20 (I think) machine), Dungeon, Zork (ported it in Fortran to an IBM mainframe), etc, etc. TRS-80 games, Rogue on MSDOS, porting Nethack to the Amiga, working for PlayNet (which became AOL). Also I'd play a real-time multi-player Trek game that was a predecessor of Netrek (which I later ported to the Amiga, and played in online league games in '92 or so), later worked porting games to the Amiga.
Since this about first experiences, I'll stop the stream of consciousness there.
A repository for "all known facts in the universe" is a pretty boring (and largely useless) thing. Effectively that will become a huge bucket for data - think how much random data there is. How many exabytes of raw data (scientific instrument readings, etc) are produced each year? Don't forget, images are data - that includes everyone's snapshots with their cameras (they're a recording of a place at a specific time, and inherently are *full* of (mostly) useless facts).
In a way, what you want already exists, in a very ugly way - it's the web itself.
Much more interesting (and useful) are well-chosen and well-organized data and facts. That's why Wikipedia + WikiMath is overall more useful than Wikieverything. The distinction can be entirely editorial; they can be hosted together, they can link to each other - but retaining a separation is useful to both sides.
Ah, but you're wrong. Wikipedia is a type of encyclopedia. It isn't a book, but it has a set of goals, one primary one of which is to be "encyclopedic". Just because they have a website you can add to, it doesn't mean it's a free-for-all - you shouldn't host your blog there. And, though it may seem so at times, Wikipedia is NOT a repository for all known facts in the universe. Random lists (members of the RPI Science Fiction Club in 1980, 1890 US Census house-by-house data, etc) do not belong there. Not only do they clutter it up (including search listings and providing dusty un-watched corners for vandalism to persist), but it also costs the Wikipedia foundation money. If mathematicians use this, edit them, discuss them - all of that costs the foundation for something that's not part of its goal.
As the grandfather post indicated, the best solution is a separate wiki, such as WikiMath.
Don't dismiss this out-of-hand - there are some seriously good uses for this for some people, just as there are uses for things like CF carrier testing.
For some people, it's very useful and/or comforting knowing if you have (or don't have) the BRCB2 (sp?) gene that predisposes you to breast cancer, or if you have a gene that causes you to be more sensitive to a wide range of drugs (there's a test on the market for this now), or are a carrier for certain nasty genetic diseases.
My family has a history of Type-1 Diabetes, for which a predisposition/risk factor is genetically linked through around a dozen genes, some of which have been identified (and some are shared with MS and Crohn's disease). It would be useful for people in my family to know if they're carriers for some of the genes that increase risk - doubly so since there may be ways to reduce the risk through environmental factors, or the possibility of close monitoring of those at risk in order to enable possible treatments before the immune system has destroyed all the Beta cells.
That said (and there are plenty of other positive uses), there are some serious issues with any test like this.
Privacy is a huge one. Partly from the government (see: Gattaca, Homeland "Security"), partly from insurance companies, partly from the courts (i.e. warrant from a prosecutor or civil suit telling 23andme to release a profile for a court case). And the issues others mentioned - advertising, control in the long future of the info, etc. The current administration (and things like warrant-less, illegal wiretapping and "terrorist databases" have made a lot of people far less trusting of either the government or large businesses that hold our information.
Another is psychological, as mentioned in the story - how much do you *really* want to know about your risk factors? Everyone has a bunch, and most of us know the major ones (family history of heart disease/breast-cancer/CF/yada yada), but there are a lot more we don't know, and most of them will not actually ever affect us (my uncle was convinced he'd die young from a heart attack like my grandfather, retired at 59 - and he's still splitting his own wood with an axe at age 84). It can be very scary, and could cause people to warp their lives based on a poorly-understood risk. (Even if the science behind a genetic risk is well-understood, the user of this report may not understand it.) With regards to procreation, some 'genetic' risks are not part of your genetic makeup - they're due to imprinting issues and/or genetic damage/aging of reproductive cells.
On the flip side - if you were adopted or simply didn't have access to medical records for most of your family, or had very few relatives, you might welcome the chance to find out the same risks that others know from their families.
So I see no problem with offering it. I'd STRONGLY suggest that they do everything possible to minimize the worries over privacy of the records, though no assurance is likely to remove all legitimate fears (or paranoia).
One of the first systems (probably not the first) to make use of filesystem notifications was the Amiga; I added Notification support to the Amiga ramdisk Way Back When for OS 2.0 (3.0?) so that applications could ask for notification on changes to system or application preferences stored in the virtual PREFS: disk (normally stored in RAM: after boot).
The equivalent would be having something in X (perhaps in KDE/Gnome/etc on top of X) watch the xorg.conf file, and when it changed re-read and re-parse it. So "cp xorg_1024x768.conf xorg.conf" could cause an automatic resolution change to a saved 1024x768 configuration (assuming X handled on-the-fly resolution changes) - or that if you wrote a new xorg.conf editing tool, all it had to do was rewrite xorg.conf to get the changes to take effect. And other programs could be watching it as well and react, instead of having to somehow know that programs X Y and Z are interested and need to be HUPed or stopped and restarted or whatever.
All the daemon "HUP-to-reread" stuff would become automatic with this sort of setup.
Ancient history, though many of the abilities mentioned don't exist in many (most) modern OS's. In some cases, more complex and more capable mechanisms have surpassed the old Amiga ideas, such as systems like dbus - but the existing Linux software doesn't always make good (or consistent) use of them!
Things that help stability/mem-usage:
You see something similar at the Jersey Shore - most of the workers nowadays aren't kids from North Jersey or Philly/burbs, they're college-age summer workers mostly from Eastern Europe. (Not that I'm an expert, but I've seen it, and others talk about it.) They make good money (compared to home, though exchange rates haven't helped them recently), they can improve their english, and they get a relatively interesting/fun experience compared to summer jobs available at home.
American high-school teens and sometimes college-age students used to fill those jobs; now they *seem* to be either partying, hanging out, or doing "volunteer"/extra-curricular work to spiff up their applications for college (which has become an arms-race with a combination of grade inflation and ever-increasing need to have a zillion non-classroom items to get into top schools). Now, this is a way-over-generalization; even around here (outer Main Line of Philly burbs) local teens man the counters at the local Chester Springs Creamery and at the big/fancy nursery (Waterloo Gardens). And another factor many be less families spending month-plus stints at the shore the way many used to back 20-50+ years ago; no teen there for a week or two will get a local job - and those that can spend a month-plus are well-enough off that the kids don't need to work. The other mainstay, college students, I have less visibility into - they may be working internships, or (also) hanging out, or they may be grinding shave time off graduation (I have heard from friends who visit my old college that current students are much more focused on graduation and earning money post-graduation than we were back around 1980, perhaps because of the increase in tuition).
Spray foam used the way you suggest assumes there's an empty cavity that you can fill - doesn't apply if there's already insulation there (like R11 fiberglass filling the cavity), or if there's no cavity (cathedral ceilings with Homasote panels for the roof/ceiling, cinderblock walls - you can foam the holes if they're empty, but it doesn't help that much). It's also rarely used in on the floor of attics for a number of reasons (including usually having to remove all the existing insulation, though you can spray the rafters and bottom of the deck, converting a "cold roof" to a form of "hot roof").
Add to that in the sunnier places (southern US, CA, etc) you don't care much about heating, but you care a LOT about cooling.
That said - insulation is a better investment in almost all houses, IF it's possible to add without reconstruction - and in some types/ages of house, it isn't.
The problem isn't *no* standards for encryption with SIP; the problem is *too many* ways. Not really the actual data encryption, but the ways for exchanging keys. Someone did a matrix for an IETF meeting a year or so ago; there were something like 15+ methods, mostly incompatible, all with different side-effects on early media, conferencing, forking (having multiple phones ring), processing overhead, etc, etc. And there's no agreement on them. People are trying, however. For the data encryption, mostly that's SRTP
Another point was that offers of RTP/SAVP or RTP/SAVPF are often rejected out-of-hand and killed the entire call with phones that don't support it, since SIP/SDP didn't provide any easy way to say "I'd like to do encryption, but it's not absolutely required". A recent effort has been made to correct this (best-effort-srtp and the work on capability negotiation in mmusic). Doing this makes it more important to signal to the user the encryption status - much easier on a hardphone with a screen or videophone than an ATA acting as translator for older POTS phones.
Yes, I work for a company that does encrypted videophones.
You may be referring to the very recent study of a large number of people (thousands) in the UK using "gene chips" to identify common loci of different genetic diseases. MS apparently shares some susceptibility genes/loci with other auto-immune diseases, such as type-1 (juvenile) diabetes and Crohnes disease (sp). See Science News, or MIT Technology Review I think.