I'm not an expert either, but I'd expect at least methane emissions to be a lot lower since lab-grown meat doesn't have a digestive system.

I think the point was that McChicken is not all that much like real chicken and still lots of people eat it. It doesn't really matter if lab-grown meat won't replace what is served at Christmas dinner; if it can replace processed meat that's already a huge success.

Even if every host you'd ever plug your device into would support ext3/4, there is still the inconvenience that the partition is exposed at the block device level, not at the file level. This means it has to be unmounted on the device before it can be mounted by the host. This is difficult to implement, since all open files on the partition must be closed before the unmount operation can succeed. Also it is inconvenient for the user: it would mean you'd have to stop a device from playing music when you want to add additional songs, for example.

Yes, since even with current technology it might be feasible to avoid the collision if we know its trajectory decades in advance. For example, if a probe flies close to the asteroid, the gravitational pull of the probe will alter the path of the asteroid a tiny bit, but a tiny bit can be enough if it happens a long time before the asteroid gets too close to earth.

It's easy to run x86 binaries on x86-64, but vice versa is not possible. I don't know of any x86-only CPUs being sold anymore, the last ones I remember were the early Atoms, so maybe in a few years we can bury the arch.

I see internal compiler errors (assertion-style) and crashes quite regularly, as in multiple times per year. Valid language constructs being rejected or invalid ones accepted happens too, although I don't know the language specs well enough to spot most of those. And occasionally a code generation bug (I can remember two from the last 10 years).

How often you find compiler bugs depends a lot on what part of the compiler you're stressing: you'll encounter more bugs on MIPS than on x86, for example, since x86 has far more users. And if you're trying new C++11 features it's far more likely you'll see a bug than when you're compiling plain C.

My e-mail address was harvested years ago: I have to rely on spam filters anyway, so I don't really worry about publishing it in bug trackers.

Registration is a pain, I agree. However, on a project that I participate in (openMSX) we did decide to stop accepting anonymous bugs reports, since the majority of bug reports lacked essential information to be able to reproduce the bug. If there is no way to contact the user who filed the bug, the only thing a developer can do is close it as non-reproducible ("worksforme" in Bugzilla - a very poor choice of words in my opinion).

How well a project responds to bugs differs a lot per project and also per individual bug. Some are fixed years later, some within a day. Some are marked invalid even though they are valid, others are indeed invalid or are duplicates. The compiler projects (GCC, LLVM, Intel C++) have been relatively good with responding to my bug reports, so I will report new bugs to them when I find any. For some other projects, I don't bother anymore unless it's a data destroyer or security issue.

Trolley buses are operational in more than a few cities without supervision or separation. I don't know if the system could scale to a much larger number of vehicles and more routes, but I don't think safety would be the blocking issue.

What about wireless charging: is it feasible to charge a car while it is moving? It might be cost effective on busy roads; cars would still need a battery but a smaller capacity would suffice if it can be recharged while driving.

He said 1% of computers that were used to play Guild Wars gave wrong answers. Gaming PCs are more likely to be overclocked too far, have under-dimensioned power supplies or overheating issues than the average PC. 1% doesn't sound unrealistically high to me.

If you suspect the compiler is generating invalid machine code, try to make a minimal test case for it. If you succeed, file a bug report and add that test case; the compiler developers will appreciate it. If you don't succeed in finding a minimal test case that triggers the same issue, it's likely not a compiler bug but an issue in your program in some place where you weren't expecting it.

There is plenty of useful work to be done: children would benefit from smaller classes, the elderly would like more attention, cities could be made prettier, there are lots of things that can be researched. The problem is that no-one is willing to pay for those things: we're always looking for lower costs, lower taxes, not higher quality of life.

Wouldn't they have to check the systems anyway after discovering they were vulnerable? A break-in points out vulnerabilities in a system, but it is not the cause of those vulnerabilities and if one person can break in, others can as well.

If someone else had found the same vulnerabilities earlier and alerted them without breaking in, would that person be charged for the costs of reviewing the systems?

That depends on how much sun hours you get, whether you can install the panels at a good angle, how much you pay for electricity and whether there are subsidies (either for installation or a feed-in tariff). I've heard from several people who did the math for their own home that their payback was less than 10 years.

Panels typically come with a 25 year warranty and while their efficiency declines over the years, they'll still be producing a significant amount of power after those 25 years. If you can provide numbers showing how much the solar panels save a month in electricity for this particular house, I doubt all potential buyers would ignore that advantage.

If her fridge uses over 300 W average (not peak), I suggest she invests in buying a new fridge.

For a home, I think lead-acid batteries would suffice: you wouldn't need particularly light or space efficient batteries.

If you look only at providing emergency power, a conventional generator is probably cheaper. But solar panels would produce power all year long, reducing your regular electricity bill. And it doesn't have to be all or nothing: you could install some solar panels and during outages you could then cope with a lower capacity conventional generator.

Unless you have outages very often, I doubt the amount of carbon output by the generator would be significant.