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).

Nowhere is it written that your critique can only be taken seriously if you fix the problem you discover, propose an alternate model, or solve the problem outright. By your logic, all the people from the 1800s on into the early 20th century who said, "You know, Newtonian mechanics has a serious problem: it cannot correctly describe the precession of Mercury" were doing a poor job of critiquing Newtonian physics.

Rubbish. They were doing a superb job of critiquing Newtonian physics by pointing to something in the Newtonian model that was clearly, unambiguously, wrong. They may not have been able to realize why it was wrong or able to construct a better model, but they pointed out an important anomaly. Later on, Einstein came along and proposed General Relativity, and one of GR's greatest initial successes was its ability to correctly model the precession of Mercury.

If John Christy's reading of the facts is in error, then that's ample grounds to say he's made a poor critique. But to say that he's made a poor critique just because he hasn't fixed the models, put forward a new model, or explained the differences between model and observation, betrays you as a very poor scientist.

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 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

If you yell "fire" in a crowded theater where there is no fire, you have taken a safe situation and turned it into an immensely dangerous one.

If you yell "fire" in a crowded theater where there is a fire, you are attempting -- as best you can -- to mitigate the risk of an immensely dangerous situation.

The law prohibits shouting "fire" in a crowded theater where there is no fire present. There is no law against alerting your fellow patrons to the fact the building is on fire.

I agree with you. I get quite irritated when people in the UK tell me we should emulate them in gun control laws, healthcare laws, or their habit of dropping random 'u's in words where they clearly don't belong. Courtesy requires I refrain from telling the UK how they ought pattern their free speech laws on our First Amendment.

It is enough to say that I am pleased to live where I do, and that I believe the evils of generally-unregulated free speech are far far outweighed by the good.

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

Thank you for being a physician. Seriously. It's appreciated.

(-- would've been dead in the '90s except for someone like you)

The reason why progress has been so slow is because there is no one single disease, "cancer." Instead we have a few thousand different diseases which we collectively call cancer. Many of them look extremely similar, even to professional oncologists. First we have to identify all of these different cancers, and then we have to discover effective treatments against them. Some cancers will have common weaknesses; many (most?) do not.

There's a reason why cancer is called "the Emperor of Maladies". Cancer is probably the hardest scientific problem the human race has ever wrestled with. It makes the moon shot and the internet look like pikers by comparison.

Cancer is hard, and every day we don't have a cure more people are going to die in horrible ways. The first part makes us want to give up on cancer research, or to say that it's too hard, or to say that we haven't made any progress... but the second part will always keep us coming back to do more research and make another attempt.

My dream is that cancer might be cured in 100 years. I think it's a dream worth working for.

I'm reminded that when President Truman had his heart attack in 1956, the official prescription from his physician was bed rest accompanied by Mrs. Truman to keep him warm.

That was the whole, complete prescription.

Anyone who says medicine hasn't improved since 1952 simply isn't paying attention.

Not only am I from the United States (born in Iowa, currently live in Virginia), but I've spent enough time in emergency rooms (pursuant to EMT work) to know this is the law. Sorry, kid. :)

Check the bankruptcy declarations. The City of Detroit made various statements under penalty of perjury, and one of the most shocking was their admission that emergency response times averaged 58 minutes.

I can't explain the discrepancy between what Detroit says on a web site and what Detroit says in a courtroom. What I can do, though, is point you to my reference. :)