Ah, I didn't realise you wanted buttons for the same app to be splittable; thought you just wanted one button per item.

Right-click taskbar, select Properties, in the "Taskbar Buttons" drop-down, choose "Never Combine"

This goes a bit deeper than just have a single "installer application" that installs everything. For one, that wouldn't cover most entry vectors for malware (webpages, e-mail, etc.).

The root problem is that in the Windows event queue and interrupts systems, there is no accountability for individual events, i.e. it's impossible to determine where any event originated. Since the event queues can be hooked, any application can create and simulate just about any event, including user input, disk I/O, etc., so the event queue cannot be trusted.

Since the OS can't know if an event was user-generated, app-generated, or driver-generated, it will have to ask about things that may be dangerous.

There is a solution to this, which is to make the entire event path, which may start with an interrupt, right up to event-handling, secure, e.g. digitally sign everything every step of the way, building an accountability-trace into the events themselves. At the lowest level in the OS, the kernel and low-level device drivers kick off the first thing that leads to an event and signing can start there (using the TPM chip on the moterboard for security).

To implement such a thing requires a lot of effort: a total revamp of the anything in the OS to do with events, interrupts, etc.; strictly enforced signed-drivers-only just above the hardware level; system- and event queue hooking only allowed by already-installed and securely signed software; faster hardware as performance-impact of something like this will be high, etc.

Such a change would of course also break just about every driver and app out there, so forget about any backwards compatibility. The effort required would also be enormous. This won't happen anytime soon, I don't think...

Note that Linux and MaxOS X suffer from the exact same problem (plenty of event-manipulatings apps around for those as well, albeit not as many as for Windows), but they have the significant advantage that users run by default as non-admins so anything the OS thinks is iffy actually requires them to type in a password rather than just click "Yes", and yes, having a single installer app helps a bit too (but not much).

I agree with the authors that most if not all alternative medicine is junk but on the other hand, when was the last time you heard about a medication or treatment that actually *cured* someone from a disease?

I mean, during the last two decades or so, I've only heard about and seen first hand people getting illnesses that can be "treated" but almost never cured (IBD, cancers, degenerative ailments, etc. and I suffer from a few myself now)

Our biggest successes have been antibiotics and vaccines and most of the ones currently in use are the same as or similar to the once that were discovered/invented years if not decades ago.

Where are all the new *real* cures?

No, its not. Look at Structure and Interpretation of Computer Programs (SICP), which was taught decades ago (and now available on-line for free; google it).

It uses Scheme as its language but rather than present Scheme itself, the course starts with only a few primitives (numbers, symbols and closures/functions) and proceeds to build up to a relatively complete interpreter of the language itself, along the way covering imperative constructs, OOP, meta-languages (including a graphical one), streams (the original magical type; not the contemporary type) and much, much more.

So, to adopt your analogy, it starts students of at a very basic reading level and adds new words and grammar (defined from scratch using only previously covered constructs) along the way, pulling students along.

Note: of course, this is only one of the ways of doing gradually increasing complexity in courses, it's the lambda calculus way. The other way is the engineering way: start with hardware/assembler, work your way up to C and then to some OOP language. Problem with the latter method is that you'd have to find some awkward way of squeezing in functional, set/vector and other programming paradigms in there somehow if you want the course to be complete (and "science"), while the former can incorporate those readily.

If that was the case, the clouds would be subject to the same effect so there would be no difference between clouds and meteor.

Also, even if that was an effect that played here, seeing the thing pass *through* a layer of cloud makes that point if relevant: if it passes through clouds, the clouds and the meteor must be at a similar altitude.