This isn't precisely a pc on a chip (the core is MIPS-based), but Microchip's PIC32 offerings gives you a fully 32-bit processor with integrated RAM, ROM, and some peripherals for about $5 per unit. Perhaps not useful if you need x86, but plenty useful if you just want to compile and run ANSI-C applications (GCC has an appropriate MIPS target).
#1: It's done with javascript, as someone else already said.
#2: The Deriver system's video encoding was the attempt of a few people (usually one, sometimes two, occasionally three, often zero) to get something that would work at all with as much of the content as possible. If a change improved output for some items, while causing new problems for others, it tended to not be adopted. The Archive has always been bad about getting back to volunteers. It takes manpower to reply and incorporate third parties' efforts, and often we didn't have the manpower to even read the messages people were sending us.
If you seriously want to help, though, physically show up at one of The Archive's friday lunch meetings at 116 Sheridan Avenue in the Presidio of San Francisco (they're open to everyone), say your piece, then talk to Brewster and/or Tracey afterwards. If you can get your foot in the door, you may be allowed to contribute. It's insane that it isn't easier to give useful stuff to The Archive, but sanity was never its strong suite.
#3: Some parts of The Archive's web interface scales better than others. The web server pool is load-balanced and self-correcting (via ipvs/KeepAlived), and the main datacenter has oodles of bandwidth, but every single goddamned hit on the site also hits the central database so that the content can be generated dynamically (sans some caching). Somehow Brewster got it into his head that this was what Web2.0 means, and that it had to be a good thing. The database is chronically overloaded, and those in charge of it more or less refuse to look at how other companies have solved this problem.
So, yeah, expect the website to be flaky for the foreseeable future. It's nothing directed personally towards you. Just pigheadedness getting in the way of good engineering.
The transition from Debian to Ubuntu was driven by developers' desire for more and newer features. We originally went with Debian-Stable because it was, well, stable, and did everything we needed the PetaBox to do at the time. But programmers whined and moaned that such-and-such package wasn't supported, or was too old, and claimed that this held back development of features which Brewster wanted to see made into reality.
Brewster was never much for stability anyway, so the transition was made. It bit us several times, as Ubuntu is not as stable as Debian-Stable (which is to be expected when releases happen more often and newer software is deployed without extensive testing), but the developers were a lot happier with it. And, to be fair, while some of the problems have been substantial (like kernel bugs which interacted with the forcedeth device drivers to make servers freeze ~10% of the time when power cycled), afaik it has not contributed directly to data lossage (which is the bottom line at an archive).
New material is always being added to The Archive's web archive, and (afaik) unlike the collections archive it is never deliberately deleted. Most of what appears to be "pages going AWOL" is indexing errors. In order for newly archived stuff to become visible to the wayback machine interface, the entire web archive needs to be periodically re-indexed. Unfortunately the indexing process is error-prone, and stuff that might have been accessible before the index might disappear afterwards (and appear again after the next indexing).
Other things that can make data temporarily unavailable are:
* Downed servers. There are over a thousand on the web archive's end of the cluster, and if a server "only" crashes once a year, that's about three servers crashing per day on average, but it doesn't happen at a low constant rate. Traumatic events at the datacenter (like AC failures, power cycles, etc) tend to knock a bunch of hosts onto their asses at a time, and they don't always come back up when rebooted. The Archive runs at a deficit of system administration manpower, so it takes a long time (weeks, sometimes months) to get humpty-dumpty back together again.
* robots.txt. In order to avoid getting their asses sued off, The Archive uses the live site's robots.txt to control which pages are publicly viewable. Every time you hit up a wayback machine URL, it downloads the real site's robots.txt and parses it to see if the owners have rendered the desired content unviewable. So if a site owner changes their robots.txt, archived content that was viewable yesterday might not be viewable today. When a website is abandoned, there isn't a robots.txt to download anymore, so at least entirely "lost" sites are viewable by everyone.
* Genuinely lost data. When I worked at The Archive (a few months ago, now), most of the web archive was on "SOLO" nodes, meaning there was no on-site replication of the content. The data servers lack RAID-level redundancy as well, so if a SOLO loses a disk, and nobody copied the data off it first, and there isn't a copy tucked away on our sister sites (some in Amsterdam, some in Alexandria Egypt), then the data is lost forever. To prevent this from happening, disks are tested hourly for a variety of symptoms (like nonzero sectors reallocated in SMART), and if a disk shows early signs of ill health, its contents gets "shuffled" off onto other machines in the cluster, and the disk itself is replaced.
But the system isn't perfect, not by a long shot, and lossage occurs. It's possible to do a lot better. Numerous people within the archive have tried to put better practices into place over the years, but for various reasons getting those practices into.. well, into practice has proven futile. Fortunately around the time I left, there was a push underway to get more of the web archive onto paired storage (so that all data was stored in duplicate on different physical machines). We can hope that moves forward.
The last time anyone tried seriously measuring the rate of lossage, iirc it ran into the 10-20 Mbits/sec range. That's not even a slow drip against the ~1.1PB in the web archive, but loss is loss.
Anyway, the *vast* majority of missing pages aren't really missing, they're just not indexed at the moment. The content itself is still tucked away in the cluster, and may resurface in the future.
Slamd64 is very good. I have been using it on my home computer and a few production machines at work.
I ran into a bug in slamd64-10.2 that wasn't in slackware-10.2, but now I can't even remember what it was. The kernel versions will sometimes differ slightly between slamd64 and slackware, but otherwise it's a very faithful, straightforward translation of slackware into 64-bitland.
Having done essentially what the grandparent post described to break into the engineering sector myself, I must respectfully disagree.
To acquire SWE experience, I signed on for a jr. system administration job at FPN. While there I demonstrated that I could write software, and got myself transferred laterally within the company to Engineering. Ta-da, a SWE job on my resume. My jobs after that were all SWE (though I often needed to wear both the SWE and Sysadmin hats in small companies). Even if I hadn't made the lateral move, I think I could have landed a programming gig with the programming-as-sysadmin experience on my resume, but can't say for sure.
Over the years I have witnessed system administrators, technical writers, and tech support do the same thing. There are a few things they all had in common, which I think is necessary to making this work:
They all did their jobs well. If you do not take care of your job's core responsibilities, your boss will not want you working on things peripheral to those responsibilities (like writing code). If you do take care of your core responsibilities, you will get a reputation as someone who performs well, which will make a lateral move much easier.
They all established contacts outside of their own department. You need to get to know the other engineers, both so that they know you, and so that you get to know the problems they are dealing with. This is particularly easy for a tech writer, hard for tech support, and middlin' for a system administrator. If you can get at least one engineer to like you enough that they'll give your code a fair shake when it appears in his mailbox, then they will likely also go to their boss and tell them about this spiffy would-be engineer when the time comes for you to make the departmental switch.
They kept their bosses in the loop and made management part of the solution. It's important that your management knows if the engineering department wants a few hours of your time on tasks not part of your core responsibilities, else they will "put you in your place" when they do find out. On the flip side, if you bring it to their attention that you are wanting to put in some programming time (an hour or two a day is about what most managers are comfortable with, in the beginning) to solve a problem pertinent to your department's responsibilities, and they see that you have performed well on your other tasks and solved a lot of problems, then they should be willing to let you do it.
I'd suggest you keep the GRAND PLAN under your hat; techies low on the totem pole who yammer about ambitious plans for the future tend to garner contempt. Just do it, and people will want to help you.
This takes some effort above and beyond what your job actually requires of you, but it can be made to work and work well.
In 1999, the Russian Army evacuated the city of Grozny of civilians, leaving (obstensibly) only the dug-in insurgents in the city. Russian forces then cordoned the city and laid waste to it with massive barrages of fuel-air munitions, delivered via TOS-1. The city was totally destroyed.
That was using Fuel-Air Explosives (FAE's), which use aerosolized hydrocarbon-based fuel. Judging from the mass-to-yeild ratio reported for this new bomb (~5.5x that of TNT), it's an aluminum-based thermobaric munition. Thermobarics use aluminum (or less commonly boron) based fuel, distributed and usually detonated by high explosive charge. Compared to fuel-air bombs this results in greater reliability, more energy released per unit mass, and much more energy released per unit volume (since 75% aluminum + 25% composition-B HE is about 2.5x denser than hydrocarbon-based fuels).
For what it's worth: (1) the old-generation american fuel-air explosives used ethylene oxide as their fuel, which increased reliability but at the expense of energy density. (2) the american armed forces have aluminum-based thermobaric munitions in their inventories, too.
And yeah, comparing FAE's and thermobarics to nukes is misleading. Thermobarics can offer up to ~8x the energy density of conventional high explosives, but even small nukes generate thousands times more boom per unit weight. Nukes are the cheap and easy way to destroy a city, but the Russians decided the political price would be too high, and used FAE's instead (which are much cheaper than equivalent-yield high explosives, but nowhere nearly as cheap per unit yield as nukes).
OpenLibrary is a lot more complete, for one.. searching on "Ogorkiewicz" in IPL yielded no hits, while OL gave me several. The Archive is well-connected to various institutions like the Library of Congress and Bibliotech, and is able to pull a lot of help from these other organizations into making a more complete service.
OpenLibrary is also a catalog of metadata, providing information for each book like physical format, publisher, ISBN#, number of pages, and so on. This metadata has a lot of holes for now, but hopefully that will change as publishers and/or people who own copies of these books fill in the blanks, much like the Internet Movie Database.
Finally, OpenLibrary has its own staff which is dedicated to working with Internet Archive partners to make this the most complete catalog on the planet. IPL is cool (I like it!) but it does not seem to be very actively maintained.
(disclaimer: I work for The Internet Archive, but I do not speak for it, and the OpenLibrary team is in a completely different department from mine so DO NOT treat this post as necessarily any more authorative or correct than any other slashdot post.)
A competent sysadmin wouldn't assume that MAC white-listing provides any sort of security. It's just as secure as NFS's uid "security" - it isn't.
Okay, you have a point. A black-hat could use an ethernet card with a programmable MAC, obtain the MAC of another system already whitelisted, and then obtain a lease while the spoofed system is offline. It would take some effort and/or luck, but it's doable. It might even be doable without physical access to the would-be-spoofed hardware and quality time alone (say, to open the case and read the MAC off the NIC -- though at that point why not just yank the hard drive, mount it on your own system, and plant trojans?), but I'm not sure how.
NFS is relatively very efficient, especially compared to SMB - a single linux client can easily saturate a GigE link with a single process.
I guess you've never watched it trying to open a bunch of files, especially in deeply nested directories?
NFS client says: "may I open/foo, please? *sends UDP packet* great! may I open/foo/bar please? *sends UDP packet* great! may I open/foo/bar/baz please? *sends UDP packet* great! may I open/foo/bar/baz/yin please? *sends UDP packet* great! may I open/foo/bar/baz/yin/yang please? *sends UDP packet* great! may I open/foo/bar/baz/yin/yang/glom.xml please? *sends UDP packet* great! diddle diddle, all done"
Windows on the other hand, has a hard time surpassing roughly 30MB/s per client (roughly a 1/4 of the link). This is very possibly an implementation limitation on Windows and not an inherent protocol problem with SMB. However, since Windows is SMB is Windows, it's a moot point.
If we're going to assess technologies, let's not compare them to Windows. We can set a slightly higher bar than that. Please.
NFS is way more reliable than SMB because it is stateless. If either the client, server or link goes down, the protocol can continue exactly were it left off once all the components are back up.
You've never seen stale NFS file handles? A server doesn't need to be down (or even balky, or on a degraded network) for very long for them to show up, and good luck recovering short of killing all of the processes with the file handles and remounting the filesystem. I've also seen sick NFS mounts, where the filesystem persistently appears on the client as zero length, or some insanely huge length, until it is remounted. They don't happen enough that you'd notice on a LAN of a few dozen systems, or an office full of workstations that get turned off at night and remount everything in the morning, but on a nontrivial cluster they pop up annoyingly often.
Because of this same lack of state, it is much easier to failover NFS than it is to failover SMB.
I did say it was possible to failover NFS. I have no idea what failing over SMB would take, and will take your word for it that it's harder than NFS failover.
And in a world where network jacks are in every wall, it is trivially easy to bring in an "insecure client" and even easier to bring in a LiveCD with you favorite flavor of Linux, NFS is secure how?
If your corporate network doesn't refuse to route packets from MACs which haven't first obtained an IP through DHCP, and doesn't whitelist MACs for DHCP, then you're in a whole world of hurt. Hurt that goes way beyond the insecurity of NFS. Here's a nickle, please go hire a competent sysadmin.
That having been said, NFS is truly horrible -- inefficient, brittle, unreliable, poorly scalable, lacks POSIX semantics, and hard (though not impossible!) to make failover. Something better is needed, something like what EMC and Rackable ships on their boxes to make them look like one big remote filesystem with failover etc, but based on open standards, and with an implementation which is portable, and preferably open-source. Someone mentioned AFS, but it doesn't really cut it.
bacon, eggs, and sometimes sausage. Usually washed down with some lightly or un-sweetened iced tea.
Something similar works well for me. The key seems to be protein, and avoiding carbohydrates (including sugars) and caffeine. This morning, in fact, I'm enjoying about a pound of lean grilled chicken, and some water, but pork and eggs are also good. I know that beans and corn are rich in protein, but they're also loaded with carbohydrates, so I avoid them for breakfast (but love them for lunch and/or dinner).
The protein digests slowly and evenly, giving me steady energy through the morning, and preventing me from feeling hungry again in a few hours like carbohydrates often will. I'll usually take my caffeine sometime after lunch, well after I've established what I'm doing and how I'm doing it. Taking a stimulant during the morning setting-up/settling-in phase just shoots me in the foot.
The second issue I have is that the full image display at both Google and the OCA/live.com (and PDF downloads of full images) is not particularly useful on low resolution displays, like PDAs, mobile phones, tablets, and dedicated ebook readers.
What formats do these devices understand? The OCA's books are available in a variety of formats, including text, xml (which is just the text annotated with positional information), and high- and low-resolution jpeg. Click on the "FTP" link to the left in the details page to see all formats:
It shouldn't be too difficult to write a little software that takes the xml + jpeg and combines them into a cohesive html document.. converting the xml to html would be easy, but recognizing the "garbage" where an illustration goes would be harder. Once you had code that recognized it, though, cropping and inserting the appropriate jpeg region would be trivial (the garbage's positional information is noted in the xml along with all the rest of the text).
x86-64's main use is its address space. 32 bits places a 4 million word limitation on your addressing.
This is exactly my experience, too. Whatever small advantage there is to eight more GPR's is not visible to me, but I greatly appreciate the ability to run large processes. I commonly need to process largish datasets which all go into a monster hash table, and then process other datasets which annotate the hashed records incrementally. Perl is great for this, but sometimes perl's per-record memory overhead proved too expensive. I'd often have to recode something in C or split the hash across multiple processes (or machines) when I either ran out of logical address space or simply ran out of physical memory and thrashed the swap too hard to make good progress. A script that took fifteen or thirty minutes to write in Perl could easily take a day or a week to write in C. Writing just part of the script in C, and stitching it to the perl parts of the software through PVM works, and is less effort than rewriting all of it in C, but is still more work than just rattling off a couple hundred lines of perl and being done with it.
Since I got access to some Athlon64 X2 3800+'s, though, that's all put behind me. I have SLAMD64 (a straightforward port of Slackware Linux to AMD64) on them, and maxed out the motherboards with memory, and now I'm writing less C than ever before. So far all of the software I need "just works", either out of the box or after compiling it myself. For what I had to compile, "./configure ; make ; make install" (or "perl Makefile.PL ; make ; make install") has done it for everything (except for a few perl modules which needed extra cajoling). SLAMD64-10.2b has been wonderful, exhibiting the same rock-solid stability as the "real" Slackware. Apache, MySQL, qmail, Perl, Python, PVM, GPG, CVS, rsync, ProFTPD, OpenSSH, and BIND (and probably others, but those are the ones I've used) behave exactly the same as before, they just have a larger logical memory space to play in.
I have not yet personally experienced 64-bit Linux as a desktop environment, but some of my co-workers have. They seem happy enough with it. Three of them like whatever that 64-bit Ubuntu distrib is called, and one likes SuSE but he's a weirdo;-) well, I'm the token Slackware weirdo, so can hardly be casting stones..
I totally, totally agree with the parent. Find as many interesting projects as you can, and either develop them (small projects from scratch) or make complete contributions to them (someone else's existing open-source project). Writing code is the best way to learn how to write good code.
If I were to add anything to that, it would be to get some good books, and refer to them as you write your code. Richard Stevens wrote the definitive bible(s) on UNIX Programming -- _UNIX Network Programming_ and _Advanced Programming in the UNIX Environment_ are the baseline (don't let the "Advanced" fool you -- you need this knowledge to write many UNIXy apps). If you get those and learn his programming style (including the ways he names his variables, and the levels at which he breaks down programs into functions) then you will be well-equipped to understand other UNIX programmer's code too. O'Reilly makes some good books on a variety of subjects, too.
Enter a descriptive identification string following the simple syntax rules given, and it will present you with an ftp server to which to upload your game's files. After you have completed uploading your files, click on the "done" link and then fill out the web form for your item's metadata.
I realize our item creation interface sucks, but finding the spare cycles for rewriting it is problematic. We're a nonprofit with a tiny staff, dealing with huge content on a shoestring budget. Please bear with us. Revamping this interface is in fact on our to-do list.
-- TTK, Software Engineer, Data Collections Group, The Internet Archive
Without government you would only have the "rights" that you could defend for yourself. If someone bigger, stronger, and meaner came along your "right" to life, liberty, and property would disappear completely.
No. A right is a condition which must be present in a society, in order for life in that society to be just. The act of "someone bigger, stronger, and meaner" infringing on your rights does not make that right go away. That infringement does not render the infringed condition any less necessary to justice. It is merely creating an unjust situation.
All rights have to be defended. Having a right does not guarantee you the power to resist infringement. Rights have no power, none whatsoever. Power -- be it power to defend a right, or power to infringe upon a right -- comes from our own resourcefulness, from community efforts, or sometimes even from government. If you want to enjoy your recognized rights, then you'd better empower yourself.
Maybe, but these objects are an order of magnitude faster than an RPG round. And they work by firing off a charge to intercept the incoming round. You think the debris problem is bad not? Try setting off a few of these in the ISS's orbit. "Cleanup in aisle 5"...
Yes, the anti-missile grenade systems (like Russia's and Ukraine's ARENA and Drozd, and Israel's Trophy) are not a very good fit. These systems cannot deflect anything moving faster than a few hundred meters per second. I was thinking more in terms of the Electric Effect armor, Explosive Reactive armor, and "spoiler screens" which utilize the Edge Effect (these could be very useful when used in conjunction with whipple shields, since they induce tumbling in the threat, which means part of the threat is moving faster and is therefore interacting more energetically with the whipple shield).
I don't buy the argument (which has been posed all over this discussion) that firing projectiles makes the debris problem worse. The projectiles are moving very fast (and we can make them move as fast as we need), and will therefore be boosted into a significantly different orbit than the spacecraft firing them. The hubble is moving at about 7000 m/s, so let's use this as an example. Explosively-forged projectiles can be fashioned to launch its penetrators at this velocity easily. If you adopt a policy of just firing them towards the fore and aft of your orbit, then the penetrator will be boosted to either zero orbital velocity (in which case it will plummet straight down to the Earth), or to twice your velocity (in which case it's way the hell out there).
That's an extreme case, but projectiles launched using more conventional means (powder propellant) can still be made to move 2000 m/s or so, which should also be enough to put it in a sufficiently different orbit to not be a worry.
We'd need to be careful to make it work, but that's why engineers are paid to do careful work.
The idea behind whipple shields is that you put several thin barriers in front of a hypervelocity threat, and the shock waves induced inside the moving body (from rapidly loading and unloading it with compressive forces) tears it apart. What emerges from the other side of the whipple shield is a cloud of dust rather than a rock (or steel bolt, or whatever), and this cloud of dust is incapable of penetrating the side of your spacecraft.
The document linked above describes research which demonstrates that the strength and thickness of the individual barriers is much less important than the number of barriers, and the ratio of barrier thickness vs space between the barriers. Thus whipple shields can have extremely high mass efficiency against hypervelocity threats, equivalent to 0.6 of the same thickness of hardened steel. A foamed polystyrene solution (where the cell foam wall thicknesses are tuned to the correct ratio of foam cells' widths) could therefore provide the same level of protection as ~135 times its weight in hardened steel plate.
This technology is being actively developed for protecting battletanks from shaped charges (which generate explosively-formed penetrators moving at high hypervelocity speeds of 8,000m/s and more), but its relatively low thickness efficiency (0.6x, as opposed to ~3x-4x for some modern composite armor systems) limits its usefulness in this role, as battletanks have limited space to play with. Spacecraft are much less limited in this respect.
How old is too old is up to you
on
How Old is Too Old?
·
· Score: 5, Insightful
You're too old to do it when you personally cannot do it.
A friend of mine is in his early 50's, and he recently landed his first "real" (paid) linux system administration job. Prior to this he had worked in construction his entire life. If he can do it at fifty-plus, you can do it at thirty. If you can't, there's a reason for it other than age.
People generally have more power than they think they do, and are limited not by what they can do, but by what they allow themselves to accomplish. So, be bold! Thrust your trepidations aside and throw yourself in the direction you want to go. You may surprise yourself.
There's also the entirely different matter of stiffness (rigidity) and its relationship to mass. Steel, Aluminum, and Titanium are all plenty strong for building a laptop, but because their densities are dramatically different, a given mass of each translates to different thicknesses, which becomes the dominating factor in determining the plate's stiffness.
The stiffness of a plate is approximately proportional to the cube of the plate's thickness multiplied by the material-specific flexural modulus. Most steel alloys have a flexural modulus of 205GPa, while cheap construction-grade Aluminum (alloy 6063, temper grade 6) has a modulus of only 69GPa. So a given thickness of steel is stiffer than the same thickness of aluminum, but steel is three times more dense than aluminum. This means that for the same mass budget, you can get an aluminum plate three times as thick. The cube of this ratio of thickness is 27, which when multiplied by the aluminum's modulus gives you an overall stiffness nine times greater than that of steel. This higher rigidity is highly desirable in products such as laptops, which you do not want to have flexing under the user's hands, or in the owner's backpack. The casing could have plenty of strength (ie, not break), but fail to protect the internal components from damage due to insufficient rigidity.
An annealed high-strength titanium alloy (Titanium Ti-8Al-1Mo-1V) is only 55% as dense as most steels, is as strong and resilient as hardened steel (about 50% stronger than mild steels like the kind your car and laptop are made from), and has a modulus of 121GPa, betwixt that of steel and aluminum 6063-t6. So for a given mass budget, a plate of this titanium alloy would be about 1.8 times thicker, and 3.4 times more rigid, than a steel plate, but only 0.38 times as rigid as the aluminum 6063-t6 plate.
I am thinking the main draw of titanium for laptops is probably scratch resistance (some titanium alloys are much more scratch-resistant than both steel and aluminum), which I guess would be a big draw for some customers. Personally I'd rather want the tougher aluminum laptop. (Better heat dissipation too, and probably somewhat cheaper, though the material costs of a laptop are a small fraction of its actual cost.) It's not like the aluminum laptop would be that much bulkier. 1.5mm steel is more than enough strength for such a product (your car's body is probably made from 1.5mm steel), and a triple thickness of this of aluminum would be only 4.5mm -- about 1/6th of an inch. I could totally live with that.
How about approaching the problem from another direction, and always keeping your applications open? Works for me. I've had this Mozilla process running since June 28th, my mail client running since June 11th, OpenOffice running since July 6th, and various others.
(It helps, of course, if you run versions of software which are stable, which often means foregoing the bleeding-edge latest versions of your favored software. A stable operating system that will keep running for months without a reboot might help too.)
Optimizing John Doe software to take advantage of more cores is nearly impossible.
Well, putting aside for the moment that AMD is marketing this 4x4 towards "enthusiasts" and not "John Doe", I disagree with your statement. Does John Doe use Google Video or similar? Multiple cores may be used to decode that video faster, for smoother playback. Does John Doe play games? Many games can be made to take advantage of multiple cores. Does John Doe browse sites which deploy Macromedia Flash based services? Each shockwave application (many of which will eat CPU whether their window or tab is open or not!) can run in its own thread, at the very least. Does John Doe search his email folders? Searches on multiple distinct datasets are really trivially parallelizable. Does John Doe browse large webpages? Many webservers are configured to transmit content in compressed form (the page you are reading right now was transmitted in gzipped format by Slashdot's server) to ease their network load, and the browser could pretty easily stick the decompressor in a different thread.
I could go on for a while. In theory, all of these (and more) can be re-implemented to take good advantage of multi-core technologies. It "just" takes more code-monkeys mashing their fingers down on keyboards to write the necessary code. Unfortunately, in practice, getting code-monkey resources allocated to such tasks doesn't happen often enough. Perhaps in that respect getting John Doe software into a multithreaded state is "nearly impossible", but that could change as soon as John Doe starts buying multicore hardware (which he might, if at least one of his favorite programs can take advantage of it).
Slashdot Mirror
This isn't precisely a pc on a chip (the core is MIPS-based), but Microchip's PIC32 offerings gives you a fully 32-bit processor with integrated RAM, ROM, and some peripherals for about $5 per unit. Perhaps not useful if you need x86, but plenty useful if you just want to compile and run ANSI-C applications (GCC has an appropriate MIPS target).
#1: It's done with javascript, as someone else already said.
#2: The Deriver system's video encoding was the attempt of a few people (usually one, sometimes two, occasionally three, often zero) to get something that would work at all with as much of the content as possible. If a change improved output for some items, while causing new problems for others, it tended to not be adopted. The Archive has always been bad about getting back to volunteers. It takes manpower to reply and incorporate third parties' efforts, and often we didn't have the manpower to even read the messages people were sending us.
If you seriously want to help, though, physically show up at one of The Archive's friday lunch meetings at 116 Sheridan Avenue in the Presidio of San Francisco (they're open to everyone), say your piece, then talk to Brewster and/or Tracey afterwards. If you can get your foot in the door, you may be allowed to contribute. It's insane that it isn't easier to give useful stuff to The Archive, but sanity was never its strong suite.
#3: Some parts of The Archive's web interface scales better than others. The web server pool is load-balanced and self-correcting (via ipvs/KeepAlived), and the main datacenter has oodles of bandwidth, but every single goddamned hit on the site also hits the central database so that the content can be generated dynamically (sans some caching). Somehow Brewster got it into his head that this was what Web2.0 means, and that it had to be a good thing. The database is chronically overloaded, and those in charge of it more or less refuse to look at how other companies have solved this problem.
So, yeah, expect the website to be flaky for the foreseeable future. It's nothing directed personally towards you. Just pigheadedness getting in the way of good engineering.
-- TTK
The transition from Debian to Ubuntu was driven by developers' desire for more and newer features. We originally went with Debian-Stable because it was, well, stable, and did everything we needed the PetaBox to do at the time. But programmers whined and moaned that such-and-such package wasn't supported, or was too old, and claimed that this held back development of features which Brewster wanted to see made into reality.
Brewster was never much for stability anyway, so the transition was made. It bit us several times, as Ubuntu is not as stable as Debian-Stable (which is to be expected when releases happen more often and newer software is deployed without extensive testing), but the developers were a lot happier with it. And, to be fair, while some of the problems have been substantial (like kernel bugs which interacted with the forcedeth device drivers to make servers freeze ~10% of the time when power cycled), afaik it has not contributed directly to data lossage (which is the bottom line at an archive).
-- TTK
New material is always being added to The Archive's web archive, and (afaik) unlike the collections archive it is never deliberately deleted. Most of what appears to be "pages going AWOL" is indexing errors. In order for newly archived stuff to become visible to the wayback machine interface, the entire web archive needs to be periodically re-indexed. Unfortunately the indexing process is error-prone, and stuff that might have been accessible before the index might disappear afterwards (and appear again after the next indexing).
Other things that can make data temporarily unavailable are:
* Downed servers. There are over a thousand on the web archive's end of the cluster, and if a server "only" crashes once a year, that's about three servers crashing per day on average, but it doesn't happen at a low constant rate. Traumatic events at the datacenter (like AC failures, power cycles, etc) tend to knock a bunch of hosts onto their asses at a time, and they don't always come back up when rebooted. The Archive runs at a deficit of system administration manpower, so it takes a long time (weeks, sometimes months) to get humpty-dumpty back together again.
* robots.txt. In order to avoid getting their asses sued off, The Archive uses the live site's robots.txt to control which pages are publicly viewable. Every time you hit up a wayback machine URL, it downloads the real site's robots.txt and parses it to see if the owners have rendered the desired content unviewable. So if a site owner changes their robots.txt, archived content that was viewable yesterday might not be viewable today. When a website is abandoned, there isn't a robots.txt to download anymore, so at least entirely "lost" sites are viewable by everyone.
* Genuinely lost data. When I worked at The Archive (a few months ago, now), most of the web archive was on "SOLO" nodes, meaning there was no on-site replication of the content. The data servers lack RAID-level redundancy as well, so if a SOLO loses a disk, and nobody copied the data off it first, and there isn't a copy tucked away on our sister sites (some in Amsterdam, some in Alexandria Egypt), then the data is lost forever. To prevent this from happening, disks are tested hourly for a variety of symptoms (like nonzero sectors reallocated in SMART), and if a disk shows early signs of ill health, its contents gets "shuffled" off onto other machines in the cluster, and the disk itself is replaced.
But the system isn't perfect, not by a long shot, and lossage occurs. It's possible to do a lot better. Numerous people within the archive have tried to put better practices into place over the years, but for various reasons getting those practices into .. well, into practice has proven futile. Fortunately around the time I left, there was a push underway to get more of the web archive onto paired storage (so that all data was stored in duplicate on different physical machines). We can hope that moves forward.
The last time anyone tried seriously measuring the rate of lossage, iirc it ran into the 10-20 Mbits/sec range. That's not even a slow drip against the ~1.1PB in the web archive, but loss is loss.
Anyway, the *vast* majority of missing pages aren't really missing, they're just not indexed at the moment. The content itself is still tucked away in the cluster, and may resurface in the future.
-- TTK
Slamd64 is very good. I have been using it on my home computer and a few production machines at work.
I ran into a bug in slamd64-10.2 that wasn't in slackware-10.2, but now I can't even remember what it was. The kernel versions will sometimes differ slightly between slamd64 and slackware, but otherwise it's a very faithful, straightforward translation of slackware into 64-bitland.
-- TTK
Having done essentially what the grandparent post described to break into the engineering sector myself, I must respectfully disagree.
To acquire SWE experience, I signed on for a jr. system administration job at FPN. While there I demonstrated that I could write software, and got myself transferred laterally within the company to Engineering. Ta-da, a SWE job on my resume. My jobs after that were all SWE (though I often needed to wear both the SWE and Sysadmin hats in small companies). Even if I hadn't made the lateral move, I think I could have landed a programming gig with the programming-as-sysadmin experience on my resume, but can't say for sure.
Over the years I have witnessed system administrators, technical writers, and tech support do the same thing. There are a few things they all had in common, which I think is necessary to making this work:
They all did their jobs well. If you do not take care of your job's core responsibilities, your boss will not want you working on things peripheral to those responsibilities (like writing code). If you do take care of your core responsibilities, you will get a reputation as someone who performs well, which will make a lateral move much easier.
They all established contacts outside of their own department. You need to get to know the other engineers, both so that they know you, and so that you get to know the problems they are dealing with. This is particularly easy for a tech writer, hard for tech support, and middlin' for a system administrator. If you can get at least one engineer to like you enough that they'll give your code a fair shake when it appears in his mailbox, then they will likely also go to their boss and tell them about this spiffy would-be engineer when the time comes for you to make the departmental switch.
They kept their bosses in the loop and made management part of the solution. It's important that your management knows if the engineering department wants a few hours of your time on tasks not part of your core responsibilities, else they will "put you in your place" when they do find out. On the flip side, if you bring it to their attention that you are wanting to put in some programming time (an hour or two a day is about what most managers are comfortable with, in the beginning) to solve a problem pertinent to your department's responsibilities, and they see that you have performed well on your other tasks and solved a lot of problems, then they should be willing to let you do it.
I'd suggest you keep the GRAND PLAN under your hat; techies low on the totem pole who yammer about ambitious plans for the future tend to garner contempt. Just do it, and people will want to help you.
This takes some effort above and beyond what your job actually requires of you, but it can be made to work and work well.
Good luck!
-- TTK
FWIW, I wasn't trying to call the russians "bad", merely describing their tactics.
-- TTK
The Russians seem to think so.
In 1999, the Russian Army evacuated the city of Grozny of civilians, leaving (obstensibly) only the dug-in insurgents in the city. Russian forces then cordoned the city and laid waste to it with massive barrages of fuel-air munitions, delivered via TOS-1. The city was totally destroyed.
That was using Fuel-Air Explosives (FAE's), which use aerosolized hydrocarbon-based fuel. Judging from the mass-to-yeild ratio reported for this new bomb (~5.5x that of TNT), it's an aluminum-based thermobaric munition. Thermobarics use aluminum (or less commonly boron) based fuel, distributed and usually detonated by high explosive charge. Compared to fuel-air bombs this results in greater reliability, more energy released per unit mass, and much more energy released per unit volume (since 75% aluminum + 25% composition-B HE is about 2.5x denser than hydrocarbon-based fuels).
For what it's worth: (1) the old-generation american fuel-air explosives used ethylene oxide as their fuel, which increased reliability but at the expense of energy density. (2) the american armed forces have aluminum-based thermobaric munitions in their inventories, too.
And yeah, comparing FAE's and thermobarics to nukes is misleading. Thermobarics can offer up to ~8x the energy density of conventional high explosives, but even small nukes generate thousands times more boom per unit weight. Nukes are the cheap and easy way to destroy a city, but the Russians decided the political price would be too high, and used FAE's instead (which are much cheaper than equivalent-yield high explosives, but nowhere nearly as cheap per unit yield as nukes).
-- TTK
OpenLibrary is a lot more complete, for one .. searching on "Ogorkiewicz" in IPL yielded no hits, while OL gave me several. The Archive is well-connected to various institutions like the Library of Congress and Bibliotech, and is able to pull a lot of help from these other organizations into making a more complete service.
OpenLibrary is also a catalog of metadata, providing information for each book like physical format, publisher, ISBN#, number of pages, and so on. This metadata has a lot of holes for now, but hopefully that will change as publishers and/or people who own copies of these books fill in the blanks, much like the Internet Movie Database.
Finally, OpenLibrary has its own staff which is dedicated to working with Internet Archive partners to make this the most complete catalog on the planet. IPL is cool (I like it!) but it does not seem to be very actively maintained.
(disclaimer: I work for The Internet Archive, but I do not speak for it, and the OpenLibrary team is in a completely different department from mine so DO NOT treat this post as necessarily any more authorative or correct than any other slashdot post.)
-- TTK
Okay, you have a point. A black-hat could use an ethernet card with a programmable MAC, obtain the MAC of another system already whitelisted, and then obtain a lease while the spoofed system is offline. It would take some effort and/or luck, but it's doable. It might even be doable without physical access to the would-be-spoofed hardware and quality time alone (say, to open the case and read the MAC off the NIC -- though at that point why not just yank the hard drive, mount it on your own system, and plant trojans?), but I'm not sure how.
NFS is relatively very efficient, especially compared to SMB - a single linux client can easily saturate a GigE link with a single process.I guess you've never watched it trying to open a bunch of files, especially in deeply nested directories?
User's /usr/bin/find says: "Open /foo/bar/baz/yin/yang/glom.xml"
NFS client says: "may I open /foo, please? *sends UDP packet* great! may I open /foo/bar please? *sends UDP packet* great! may I open /foo/bar/baz please? *sends UDP packet* great! may I open /foo/bar/baz/yin please? *sends UDP packet* great! may I open /foo/bar/baz/yin/yang please? *sends UDP packet* great! may I open /foo/bar/baz/yin/yang/glom.xml please? *sends UDP packet* great! diddle diddle, all done"
User's /usr/bin/find says: "Now open /foo/bar/baz/yin/yang/glorum.xml
NFS client says: "may I open /foo, please? *sends UDP packet* great! (etc)"
Windows on the other hand, has a hard time surpassing roughly 30MB/s per client (roughly a 1/4 of the link). This is very possibly an implementation limitation on Windows and not an inherent protocol problem with SMB. However, since Windows is SMB is Windows, it's a moot point.If we're going to assess technologies, let's not compare them to Windows. We can set a slightly higher bar than that. Please.
NFS is way more reliable than SMB because it is stateless. If either the client, server or link goes down, the protocol can continue exactly were it left off once all the components are back up.You've never seen stale NFS file handles? A server doesn't need to be down (or even balky, or on a degraded network) for very long for them to show up, and good luck recovering short of killing all of the processes with the file handles and remounting the filesystem. I've also seen sick NFS mounts, where the filesystem persistently appears on the client as zero length, or some insanely huge length, until it is remounted. They don't happen enough that you'd notice on a LAN of a few dozen systems, or an office full of workstations that get turned off at night and remount everything in the morning, but on a nontrivial cluster they pop up annoyingly often.
Because of this same lack of state, it is much easier to failover NFS than it is to failover SMB.I did say it was possible to failover NFS. I have no idea what failing over SMB would take, and will take your word for it that it's harder than NFS failover.
-- TTK
If your corporate network doesn't refuse to route packets from MACs which haven't first obtained an IP through DHCP, and doesn't whitelist MACs for DHCP, then you're in a whole world of hurt. Hurt that goes way beyond the insecurity of NFS. Here's a nickle, please go hire a competent sysadmin.
That having been said, NFS is truly horrible -- inefficient, brittle, unreliable, poorly scalable, lacks POSIX semantics, and hard (though not impossible!) to make failover. Something better is needed, something like what EMC and Rackable ships on their boxes to make them look like one big remote filesystem with failover etc, but based on open standards, and with an implementation which is portable, and preferably open-source. Someone mentioned AFS, but it doesn't really cut it.
-- TTK
Something similar works well for me. The key seems to be protein, and avoiding carbohydrates (including sugars) and caffeine. This morning, in fact, I'm enjoying about a pound of lean grilled chicken, and some water, but pork and eggs are also good. I know that beans and corn are rich in protein, but they're also loaded with carbohydrates, so I avoid them for breakfast (but love them for lunch and/or dinner).
The protein digests slowly and evenly, giving me steady energy through the morning, and preventing me from feeling hungry again in a few hours like carbohydrates often will. I'll usually take my caffeine sometime after lunch, well after I've established what I'm doing and how I'm doing it. Taking a stimulant during the morning setting-up/settling-in phase just shoots me in the foot.
-- TTK
What formats do these devices understand? The OCA's books are available in a variety of formats, including text, xml (which is just the text annotated with positional information), and high- and low-resolution jpeg. Click on the "FTP" link to the left in the details page to see all formats:
details page
FTP index
It shouldn't be too difficult to write a little software that takes the xml + jpeg and combines them into a cohesive html document .. converting the xml to html would be easy, but recognizing the "garbage" where an illustration goes would be harder. Once you had code that recognized it, though, cropping and inserting the appropriate jpeg region would be trivial (the garbage's positional information is noted in the xml along with all the rest of the text).
-- TTK
This is exactly my experience, too. Whatever small advantage there is to eight more GPR's is not visible to me, but I greatly appreciate the ability to run large processes. I commonly need to process largish datasets which all go into a monster hash table, and then process other datasets which annotate the hashed records incrementally. Perl is great for this, but sometimes perl's per-record memory overhead proved too expensive. I'd often have to recode something in C or split the hash across multiple processes (or machines) when I either ran out of logical address space or simply ran out of physical memory and thrashed the swap too hard to make good progress. A script that took fifteen or thirty minutes to write in Perl could easily take a day or a week to write in C. Writing just part of the script in C, and stitching it to the perl parts of the software through PVM works, and is less effort than rewriting all of it in C, but is still more work than just rattling off a couple hundred lines of perl and being done with it.
Since I got access to some Athlon64 X2 3800+'s, though, that's all put behind me. I have SLAMD64 (a straightforward port of Slackware Linux to AMD64) on them, and maxed out the motherboards with memory, and now I'm writing less C than ever before. So far all of the software I need "just works", either out of the box or after compiling it myself. For what I had to compile, "./configure ; make ; make install" (or "perl Makefile.PL ; make ; make install") has done it for everything (except for a few perl modules which needed extra cajoling). SLAMD64-10.2b has been wonderful, exhibiting the same rock-solid stability as the "real" Slackware. Apache, MySQL, qmail, Perl, Python, PVM, GPG, CVS, rsync, ProFTPD, OpenSSH, and BIND (and probably others, but those are the ones I've used) behave exactly the same as before, they just have a larger logical memory space to play in.
I have not yet personally experienced 64-bit Linux as a desktop environment, but some of my co-workers have. They seem happy enough with it. Three of them like whatever that 64-bit Ubuntu distrib is called, and one likes SuSE but he's a weirdo ;-) well, I'm the token Slackware weirdo, so can hardly be casting stones..
-- TTK
I totally, totally agree with the parent. Find as many interesting projects as you can, and either develop them (small projects from scratch) or make complete contributions to them (someone else's existing open-source project). Writing code is the best way to learn how to write good code.
If I were to add anything to that, it would be to get some good books, and refer to them as you write your code. Richard Stevens wrote the definitive bible(s) on UNIX Programming -- _UNIX Network Programming_ and _Advanced Programming in the UNIX Environment_ are the baseline (don't let the "Advanced" fool you -- you need this knowledge to write many UNIXy apps). If you get those and learn his programming style (including the ways he names his variables, and the levels at which he breaks down programs into functions) then you will be well-equipped to understand other UNIX programmer's code too. O'Reilly makes some good books on a variety of subjects, too.
Good luck!
-- TTK
Use this: http://www.archive.org/create.php
Enter a descriptive identification string following the simple syntax rules given, and it will present you with an ftp server to which to upload your game's files. After you have completed uploading your files, click on the "done" link and then fill out the web form for your item's metadata.
I realize our item creation interface sucks, but finding the spare cycles for rewriting it is problematic. We're a nonprofit with a tiny staff, dealing with huge content on a shoestring budget. Please bear with us. Revamping this interface is in fact on our to-do list.
-- TTK, Software Engineer, Data Collections Group, The Internet Archive
Without government you would only have the "rights" that you could defend for yourself. If someone bigger, stronger, and meaner came along your "right" to life, liberty, and property would disappear completely.
No. A right is a condition which must be present in a society, in order for life in that society to be just. The act of "someone bigger, stronger, and meaner" infringing on your rights does not make that right go away. That infringement does not render the infringed condition any less necessary to justice. It is merely creating an unjust situation.
All rights have to be defended. Having a right does not guarantee you the power to resist infringement. Rights have no power, none whatsoever. Power -- be it power to defend a right, or power to infringe upon a right -- comes from our own resourcefulness, from community efforts, or sometimes even from government. If you want to enjoy your recognized rights, then you'd better empower yourself.
-- TTK
Maybe, but these objects are an order of magnitude faster than an RPG round. And they work by firing off a charge to intercept the incoming round. You think the debris problem is bad not? Try setting off a few of these in the ISS's orbit. "Cleanup in aisle 5"...
Yes, the anti-missile grenade systems (like Russia's and Ukraine's ARENA and Drozd, and Israel's Trophy) are not a very good fit. These systems cannot deflect anything moving faster than a few hundred meters per second. I was thinking more in terms of the Electric Effect armor, Explosive Reactive armor, and "spoiler screens" which utilize the Edge Effect (these could be very useful when used in conjunction with whipple shields, since they induce tumbling in the threat, which means part of the threat is moving faster and is therefore interacting more energetically with the whipple shield).
I don't buy the argument (which has been posed all over this discussion) that firing projectiles makes the debris problem worse. The projectiles are moving very fast (and we can make them move as fast as we need), and will therefore be boosted into a significantly different orbit than the spacecraft firing them. The hubble is moving at about 7000 m/s, so let's use this as an example. Explosively-forged projectiles can be fashioned to launch its penetrators at this velocity easily. If you adopt a policy of just firing them towards the fore and aft of your orbit, then the penetrator will be boosted to either zero orbital velocity (in which case it will plummet straight down to the Earth), or to twice your velocity (in which case it's way the hell out there).
That's an extreme case, but projectiles launched using more conventional means (powder propellant) can still be made to move 2000 m/s or so, which should also be enough to put it in a sufficiently different orbit to not be a worry.
We'd need to be careful to make it work, but that's why engineers are paid to do careful work.
-- TTK
qv: Whipple Shields
The idea behind whipple shields is that you put several thin barriers in front of a hypervelocity threat, and the shock waves induced inside the moving body (from rapidly loading and unloading it with compressive forces) tears it apart. What emerges from the other side of the whipple shield is a cloud of dust rather than a rock (or steel bolt, or whatever), and this cloud of dust is incapable of penetrating the side of your spacecraft.
The document linked above describes research which demonstrates that the strength and thickness of the individual barriers is much less important than the number of barriers, and the ratio of barrier thickness vs space between the barriers. Thus whipple shields can have extremely high mass efficiency against hypervelocity threats, equivalent to 0.6 of the same thickness of hardened steel. A foamed polystyrene solution (where the cell foam wall thicknesses are tuned to the correct ratio of foam cells' widths) could therefore provide the same level of protection as ~135 times its weight in hardened steel plate.
This technology is being actively developed for protecting battletanks from shaped charges (which generate explosively-formed penetrators moving at high hypervelocity speeds of 8,000m/s and more), but its relatively low thickness efficiency (0.6x, as opposed to ~3x-4x for some modern composite armor systems) limits its usefulness in this role, as battletanks have limited space to play with. Spacecraft are much less limited in this respect.
Other so-called "Active Defenses" developed for battletanks might also be applicable.
-- TTK
You're too old to do it when you personally cannot do it.
A friend of mine is in his early 50's, and he recently landed his first "real" (paid) linux system administration job. Prior to this he had worked in construction his entire life. If he can do it at fifty-plus, you can do it at thirty. If you can't, there's a reason for it other than age.
People generally have more power than they think they do, and are limited not by what they can do, but by what they allow themselves to accomplish. So, be bold! Thrust your trepidations aside and throw yourself in the direction you want to go. You may surprise yourself.
-- TTK
There's also the entirely different matter of stiffness (rigidity) and its relationship to mass. Steel, Aluminum, and Titanium are all plenty strong for building a laptop, but because their densities are dramatically different, a given mass of each translates to different thicknesses, which becomes the dominating factor in determining the plate's stiffness.
The stiffness of a plate is approximately proportional to the cube of the plate's thickness multiplied by the material-specific flexural modulus. Most steel alloys have a flexural modulus of 205GPa, while cheap construction-grade Aluminum (alloy 6063, temper grade 6) has a modulus of only 69GPa. So a given thickness of steel is stiffer than the same thickness of aluminum, but steel is three times more dense than aluminum. This means that for the same mass budget, you can get an aluminum plate three times as thick. The cube of this ratio of thickness is 27, which when multiplied by the aluminum's modulus gives you an overall stiffness nine times greater than that of steel. This higher rigidity is highly desirable in products such as laptops, which you do not want to have flexing under the user's hands, or in the owner's backpack. The casing could have plenty of strength (ie, not break), but fail to protect the internal components from damage due to insufficient rigidity.
An annealed high-strength titanium alloy (Titanium Ti-8Al-1Mo-1V) is only 55% as dense as most steels, is as strong and resilient as hardened steel (about 50% stronger than mild steels like the kind your car and laptop are made from), and has a modulus of 121GPa, betwixt that of steel and aluminum 6063-t6. So for a given mass budget, a plate of this titanium alloy would be about 1.8 times thicker, and 3.4 times more rigid, than a steel plate, but only 0.38 times as rigid as the aluminum 6063-t6 plate.
I am thinking the main draw of titanium for laptops is probably scratch resistance (some titanium alloys are much more scratch-resistant than both steel and aluminum), which I guess would be a big draw for some customers. Personally I'd rather want the tougher aluminum laptop. (Better heat dissipation too, and probably somewhat cheaper, though the material costs of a laptop are a small fraction of its actual cost.) It's not like the aluminum laptop would be that much bulkier. 1.5mm steel is more than enough strength for such a product (your car's body is probably made from 1.5mm steel), and a triple thickness of this of aluminum would be only 4.5mm -- about 1/6th of an inch. I could totally live with that.
-- TTK
Normally I don't feed the trolls, but taken at face value your request is reasonable, so ..
http://www.petabox.org/ (note contributors list on left)
http://www.ciar.org/ttk/images/petabox/
http://workstation20.archive.org/ttk/tools/manifes ting
http://workstation20.archive.org/ttk/tools/researc h
http://workstation20.archive.org/ttk/wp/
http://workstation20.archive.org/ttk/wp/software/2 006-04-11/
My Resume
-- TTK
Well you probably won't see this since it is kind of a late reply,
Most /. articles aren't very interesting, so I go back to older ones and pick up late replies. :-)
but just in case you could still make your machine a PVM master, just use ssh port forwarding to bypass the port block.
(embarrassed silence) . . . you're absolutely right. Why the hell didn't I think of that? Thank you! I think I will.
-- TTK
How about approaching the problem from another direction, and always keeping your applications open? Works for me. I've had this Mozilla process running since June 28th, my mail client running since June 11th, OpenOffice running since July 6th, and various others.
(It helps, of course, if you run versions of software which are stable, which often means foregoing the bleeding-edge latest versions of your favored software. A stable operating system that will keep running for months without a reboot might help too.)
-- TTK
Optimizing John Doe software to take advantage of more cores is nearly impossible.
Well, putting aside for the moment that AMD is marketing this 4x4 towards "enthusiasts" and not "John Doe", I disagree with your statement. Does John Doe use Google Video or similar? Multiple cores may be used to decode that video faster, for smoother playback. Does John Doe play games? Many games can be made to take advantage of multiple cores. Does John Doe browse sites which deploy Macromedia Flash based services? Each shockwave application (many of which will eat CPU whether their window or tab is open or not!) can run in its own thread, at the very least. Does John Doe search his email folders? Searches on multiple distinct datasets are really trivially parallelizable. Does John Doe browse large webpages? Many webservers are configured to transmit content in compressed form (the page you are reading right now was transmitted in gzipped format by Slashdot's server) to ease their network load, and the browser could pretty easily stick the decompressor in a different thread.
I could go on for a while. In theory, all of these (and more) can be re-implemented to take good advantage of multi-core technologies. It "just" takes more code-monkeys mashing their fingers down on keyboards to write the necessary code. Unfortunately, in practice, getting code-monkey resources allocated to such tasks doesn't happen often enough. Perhaps in that respect getting John Doe software into a multithreaded state is "nearly impossible", but that could change as soon as John Doe starts buying multicore hardware (which he might, if at least one of his favorite programs can take advantage of it).
-- TTK