Stop eating... and die already, amiright?

Human bodies need a constant supply of vitamins and minerals, "stop eating" just doesn't cut it. And you DO NOT know how hard it is, to eat just a bit while constantly craving to eat a lot more, 24/7... unless you've been a drug addict, then you may know it. Otherwise STFU.

Unfortunately it doesn't work like that. You'd think severely obese people don't need to eat at all; try that, and you'll end up with lots of dead people.

The human body can't live just on pure calories, there is a constant need for vitamins, minerals and such, without which it just starts dying. Stored fat has none of those, while at the same time using them up in order to get converted into usable calories. Meanwhile, food sources of this stuff are themselves laced with sugar and additional fats, so doing a minimum calorie while at the same time life sustaining diet, means the actual weight loss will be pretty slow.

So, just because you were lazy and didn't "try harder" earlier, you assume everyone is just as lazy, and just needs to "try harder".

Well, guess what, not everybody is like you.

Elective surgery doesn't mean you can wait 20 years to get it done... which, depending on your overweight, is what you may need to get your weight down.

Oh, stop the BS already. You don't have to use Metro if you don't want to (I don't).

Actually, something broke in my "Modern UI" apps while upgrading to Windows 8.1, and I didn't even bother looking to fix it. Still using Windows as usual.

In Windows XP, display drivers run in kernel mode. Any failure, means a system-wide crash at best, or a hang up at worst. There is no way to schedule/preempt driver execution before it finishes.

Since Windows Vista, display drivers get split up, with a minimal piece running in kernel mode, and most of the driver running in user mode. Most failures just need a restart of the user mode part. The user mode part can be scheduled/preempted at any time, kernel mode part only blocks for a single DMA buffer.

Since Windows 8, display drivers can be preempted up to a single instruction level.

Saying that Windows XP is "very much inferior", seems to me like quite a polite way to put it.

Best naming scheme is Write_processMemory_r1_998 and CreateRemote_thread_rev001_2.
No more ambiguity about which part is static and which not.

Bonus: also no need for some silly source control, just change the rev number (or r for release, unless the minor is > 900, which means it's beta), and bam! all the code at your fingertips, all the time!

Has more stuff, works on more devices.

Meaning:
- Some of the extra stuff, you may or may not care about. YMMV
- Gadgets supporting Android, get an Android adapted to them by whoever makes them. When your gadget's maker stops giving you updates for whatever reason (like: laziness, or not caring anymore), you can use CyanogenMod to get the latest version of Android with all the patches, updates... and the extra stuff you may or may not care about.

Anything can be rewritten (backported), as long as it works in a turing-complete language. What you would be missing most probably are the optimizations and tuning, which would make your forked 386-compatible kernel slower and slower as more changes are added with the "new stuff".

For example: some of the config options dropped are CMPXCHG, XADD and BSWAP emulation. This means new patches can use these instructions indiscriminately with no performance impact on 386... since it is no longer supported. Yet if you were to backport, it might well turn out that emulating tons and tons of these instructions would make the kernel nearly unusable.

This remids me of the time when I first tried running a Windows 3.0 demo on a 8086 PC. It was intended for 80286, where it ran smoothly... and yet it DID run on my 8086. Only 100,000 times slower (no kidding, over 2 hours just to show the logo splash).

I see, so you seem to assume logical, rational an mathematically sound beings handling the bitcoins.

Now, how does that hold against a bunch of brainless morons who would rather die of starvation today, than spend a single bitcoin which could earn them more food the next month?

So, you mean like gold?

Yet when I say that "there are people with a vested interest in getting others to buy gold", people look at me like I'm crazy... even though they never dug up any gold themselves.

I've been using BTRFS in production since 3.3.1 with zero problems.

Before that, I did experience a partial fs meltdown on 3.2.x while stress testing a high number of snapshots with several million files/dirs and intense db activity. Then, the same test on 3.3.1 went flawlessly.

So I wouldn't recommend using BTRFS with anything below 3.3.1, but 3.4 or 3.5 should be fine.

Also we're approaching a population of 10 billion.

In the Middle Ages, 30% of European population died to the plague. Yet by 1800 there were about 1 billion people, and it was enough.

So what if 9 billion would die some day. The remaining 1 billion will still be enough.

And now we do have some technology and knowledge that won't be lost just like that. Think of all the people without jobs, or with menial jobs, or with jobs depending on supporting the aforementioned. Now replace them with robots.

I even wonder if "quality of life" wouldn't rather RISE if 90% of the population died. For the remaining 10% that is... but, oh well, you can't have it all, can you?

Then there is that rival company asshole, who pays a thug to steal your laptop so he can spray some ice on your RAM modules and run some silly memory-dump boot app from CD (did you remember to disable booting from CD in your BIOS?) so he can get to all the company data you stored on your laptop.

No kidding, that's as easy as pie.