I sympathize with the sentiment, but I have yet to find a workable equivalent for Firefox + NoScript. (Sounds like a motivation for socially conscious techs to finally get Chrome up to the required standards for secure browsing.)

Fable is by Lionhead Studios, home of longtime auteur game designer Peter Molyneux, who has a tendency to promise the Earth and be ultimately be crippled by his own ambition (see the big fat broken monkey-fest Black & White). During the development of Fable, for example, it was promised to have features like rival NPC characters, plants growing in real time, and a system wherein your every slightest choice and action changes your appearance and the world around you. What we ended up with was a buggy action RPG with a great big stiffy for itself.

-- Yahtzee Croshaw

I had only hard of LTO tapes quite recently, and I did a very tiny bit of poking around. The latest generation is LTO-6, whose tapes can hold 2.5TB each (uncompressed). The tapes themselves are quite modestly priced -- an LTO-4 tape cartridge (800GB uncompressed) costs about $30 each.

The drives, however, are not cheap. New drives appear to start at around $1200. Used drives are all over the place -- I've seen some on eBay with an opening bid as low as $350. Also, all LTO drives appear to have either an LVD SCSI or a SAS interface, which means you'll also need a controller card. There appears to be no such thing as a SATA LTO drive.

Plus you get to re-live all the joys of selecting tape vendors, and placing bets on whose tapes are going to last for 20 years.

Mmmm, nope. I'm still seeing ludicrously sluggish behavior on some pages (some of Jira's pages, and on some of Freescale's discussion fora).

Browser: Chrome 33.0.1750.146
OS: Linux Mint 15 ("Olivia"), kernel 3.8.x
GPU: Intel i965
OpenGL Version: 3.0 Mesa 9.1.7

Mind you, if I only turn on HW acceleration in the advanced settings panel, GMail runs sluggishly. If I also then enable your software rendering override, then GMail appears to run normally, but in both cases I still get the sluggish Jira pages. I've no idea what Jira's doing that would run so slowly.

Here ya go: http://www.electronicplus.com/

It's a family-owned and -operated business, with a single retail presence in San Rafael, CA. I used to have a part-time job there when I was in high school. That was (*gah!*) 30 years ago. They're still in business.

There was a Radio Shack in town, too, but you only went there for the pre-fab project kits and the free battery. (And the TRS-80 computers, if you were in to those.)

Electronics Plus's prices are nothing to write home about. But their selection is Z0MG!!1! Where did they find all this stuff?!? The only places you'll find an equally astonishing variety of things is HSC and Weird Stuff Warehouse (and maybe Fry's).

Gratuitous plug for my YouTube "Let's Play" playlist.

All the videos I've compiled and uploaded to YouTube have been made using Kdenlive. I don't labor under the notion that it's perfect, but I found it much better and more accessible that anything else I tried.

Kdenlive's most annoying bug at the moment is that the sound in the final compiled video will sometimes drift, i.e. in an hour-long video, the sound will start off in sync with the video but, by the time you get to the end, it's as much as 1.5 seconds off. This drift does not appear when playing back in the editor timeline; only in the final compiled video. I have not been able to reliably reproduce this issue for the developers, nor do I have a notion of what triggers it. Once it appears in a project, it's there and you can't get rid of it. It's possible it's an issue with MLT (the library on which Kdenlive is built) but, again, I haven't isolated the issue.

Other than that, it's worked very well for me. Even on those occasions when it has crashed, it has never destroyed my work; just re-launch and pick up from where you left off.

If something better came along, I would jump to it without much thought. But I haven't found it yet. I'll give 'pitivi' another look, but it looks as if installing it into my generic Debian system will be a pain (v0.92 is only available in the 'experimental' repository).

I was the CEO of a company that sold ringtones and MP3s a la carte for mobile devices. When you added up (1) the licenses paid to record labels, (2) the fees paid to mobile operators for payment processing, and (3) publishing royalties, it was something like 120% of the retail price for the content. So, umm, not a really scalable business model.

I find this fascinating, especially given that the prices charged for ringtones were pure usury. I wonder if you'd be willing to relate a more detailed story of what you were facing.

Security? On a Windows platform?

You must be new here.

15 years ago, nobody "needed" broadband. Dialup was, "good enough."

Today, try doing anything other than text-only email over 56Kb dialup.

Broadband uptake enabled a new class of Internet sites and services. Google is betting that history will repeat itself by kicking speeds up by two orders of magnitude. It also has the beneficial side-effect of lighting a fire under AT&T's slothful ass.

Also keep in mind that GFiber offerings are symmetric. That means you get to upload your photos and videos at 1Gb/sec as well, and not through the 768Kb straw that DSL and cable providers decided was "good enough" for consumer-class Internet.

I should clarify, I don't think Free Software as a movement is a dangerous idea. What I am saying is that there are huge numbers of people out there that truly expect from 100's of man hours of work to simply get done in less than a week for peanuts. Free Software was never about the idea that people shouldn't get paid for their work, and those who think it is were missing Stallman's point.

As someone who has been paid for the last ten years to write open source software (mainly through research grants), what people should understand is that a large (the majority?) of open source projects are funded at least partially by government and large commercial interests so that they can cooperatively meet shared goals. Another source of resources for open source projects is well-paid developers who have enough free time to work for free on projects they enjoy. The training and skills they bring to their hobby is paid for by good jobs. Without a thriving, well-paid community of developers, the huge amount of free software out there simply wouldn't exist. This is a huge factor that drives open source development, and we should keep this in mind when we hear stories about the mythical coders in their mom's basement who are writing tons of free software. I'm not dismissing the many great projects that have simply been created to scratch an itch or do good in the world, just raising the serious point that developers need to get paid, and we can end up screwing ourselves if we paint a picture that gives people the expectation that we work for free.

Right, all those almanac records have just up and disappeared. It's a "conspiracy".

We should also look at who produces most of the code. If we simply slap the label of developer on anyone who writes code, we may come away with the idea that because 40% of DEVELOPERS are hobbyists, that 40% of actual DEVELOPMENT/implementation is done by hobbyists. It would be like saying 80% of authors, defined as someone who spends 10 or more hours a month writing text (could be emails, could be text messages, etc.), are hobbyists.

Considering just how skewed productivity is among programmers, it wouldn't surprise me if this 40% collectively gets much less done than the pro's. That's not saying we shouldn't encourage people to make coding a hobby, but I think it's dangerous to present the idea to the world that code is a freely available resource that can easily be obtained for an extremely low cost or for free. I have to fight this quite a bit as a professional, because the expectations of some customers and employers is just incredibly out of line. Many of them will expect a project that requires 50K+ lines of code (and as a result, potentially hundreds of man hours of work)to take a couple of weeks and cost maybe $500 (to see what I mean look at sites like rentacoder).

I couldn't tell you why, but I haven't (yet) observed the described behavior on my XP system. The auto-updater ususally settles down in a matter of minutes.

No. In my case, it's trying to apply the .NET updates that completely murders my system. Apparently MS wants a gigabyte or so of free disk space on C:\ (and nowhere else) or the update will fail miserably. As it happens, my system partition has about 200MB free space, so the update disappears down a rabbit hole and never completes.

I used to think it was because it needed a bunch of temporary disk space, so last night I changed the TMP and TEMP environment variables to point to a volume with tons of free space, rebooted (because, you know, it's Windows), set just one of the several .NET updates running, then went off to see The Hobbit. When I returned some three hours later, the update had hung, the disk was idle, C:\ had zero bytes free, and the system log was corrupted.

Honestly, I don't know why anyone continues to be surprised by Redmond's rank incompetence...

Schwab

FreeNAS and ZFS are indeed awesome. But before y'all go installing FreeNAS on some spare hardware and think your problem is solved, you need to be aware that ZFS is not a panacea. You can't just drop it on Any Old Box with default settings and expect it to magically keep your data safe unto perpetuity. You need to pay attention to what you're doing.

Some highlights:

• ZFS's design requires RAM to be perfectly reliable, or at least report imperfections. Undetected bitrot in RAM can and will destroy your entire ZFS pool. Thus, a machine with ECC RAM installed is a requirement.
• As if that weren't enough, ZFS eats huge amounts of RAM. The current guideline is 1 GiB of RAM per TB of disk spindles, with 8 GiB as a practical minimum.
• ZFS assumes it has perfect knowledge of disk writes in-flight, and as such doesn't play well with RAID controllers, which can silently re-order writes. If your machine has a RAID controller, the RAID features should be turned off. Don't worry, ZFS has its own RAID features. However:
• Because drive densities are now approaching drive error rates (10**13 bits of storage, with manufacturers quoting uncorrectable errors every 10**14 bits read), ZFS RAID-Z1 is no longer considered sufficient to ensure storage integrity, and you should plan for RAID-Z2 (two parity drives).
• For the same reason as turning off RAID, a "production" FreeNAS/ZFS installation should not be run in a virtual machine. It's okay if you're just test-driving it to get a sense of what it can do, but a live system should run on actual hardware.
• Using ZFS's de-duplication feature is officially discouraged. It may seem like a great idea, but it will gobble all your RAM and return very little benefit. On average, you're better off using compression.

When ZFS dies, it dies in a big and fairly comprehensive way, and ZFS will die if you under-provide it. In any event, you should RTFM before contemplating a build, and know the trade-offs you're getting in to.

Schwab

I don't have time to correct all the errors in the parent post. So very briefly:

• The 6502 had three 8-bit registers: A, X, and Y. A was the accumulator, and received the result of all arithmetic operations. X and Y could hold temporary data, arithmetic operands, and be used as index registers for memory load/store. There was also an 8-bit stack pointer register, SP, hard-mapped to the range 0x0100 - 0x01FF.
• The 8080 had the 8-bit registers A, B, C, D, E, H, L, and a 16-bit stack pointer. In addition, the registers B & C, D & E, and H & L could be used to hold 16-bit quantities for some instructions.
• The Z80 had all the registers of the 8080, plus a shadow copy of the registers for quick use by interrupt service routines.
• The 6502's zero page (0x0000 - 0x00FF) got special treatment by the CPU, using only a single byte to address a location. As such, zero page usually got treated by software as a pile of "slow registers."
• No instruction on the 6502 executed in fewer than two clock cycles. The fastest 6502 I ever saw was 2 MHz.
• By contrast, 4 Mhz Z80 chips were widespread.
• The Z80 helped popularize dynamic RAMs by containing a very basic DRAM refresh counter. The 6502 had no such thing; DRAM refresh was usually provided by custom logic, usually part of the video controller.
• S-100 machines had huge power supplies because they had huge numbers of slots (eight or more being common), and had to have enough reserve power for all of them.
• There was nothing special about the 6502's memory access patterns, and 6502 would get starved out like any other CPU if another device held the bus. On the C-64 in particular, every eight video lines, the VIC would grab the bus for 40 uSecs to fetch the next row of character cells, holding off the 6502 the whole time. This led to all kinds of problems with timing-sensitive operations, and was directly responsible for transfers to/from the 1541 floppy drive to be glacially slow.

Schwab