Also, all the security flaws in version 1.0 can't be fixed.

Nothing is unhackable, but maybe they can make the price of hacking it (in time/money) high enough, for long enough, to have another generation ready by the time its hacked.

"Of those willing to testify under oath, not a SINGLE ONE could identify a crime that Trump committed." Of course they couldn't get proof of a crime on Trump. He stonewalled every single subpoena to question the people with firsthand knowledge of the events. This, of course, doesn't mean that he is *or isn't* guilty of those crimes. This does, however, mean that he didn't cooperate with the investigation, which is why he is being brought up on obstruction of congress charges, instead of the crimes which were initially talked about. Can you imagine the chaos in our legal system if "they are out to get me" was a valid defense against complying with subpoenas? I mean, that applies 100% of the time, right? We might as well throw the courts away

The total units sold for the C64 are for an almost 100% backwards compatible hardware and software base over the life of the system (nothing happened to the hardware other than cost reductions by consolidating chips / newer processes). No CPU instructions were changed, no system software was changed, and no hardware level registers were changed - the same software which ran on the first C-64 that came out of Commodore ran unmodified, no patches, recompilations or fixes needed, on the last C-64 that came out of Commodore. The units sold for the Rpi are for model 0, 1, 2, 3, 4, and all their subvariants, which can have different memory systems and supervisor instruction streams. They are by and large broken with each other for backwards compatibility. I don't think its a valid comparison. A more valid comparison is the C-64 against a single generation of Rpi.

The exceptions are just a rounding error.

10 times out of 10, its either an outright scam where they are violating rules of physics, or they are hiding the horrible drawback which ensures that it won't be able to sell. In any case, its a bunch of hucksters looking to scam some VC money.

Someone is under the illusion that Windows has an inadequate scripting system for the sysadmin. That may have been true 10 years ago, but things are very different now.

What you should buy depends on what you plan to do, obviously. I've used several of the korean imports (Owon, Rigol) and although the feature set on those is incredible for the price, the units themselves have strange firmware problems that can be maddening when they strike. Also, the knockoff scopes can't seem to get "Automatic" triggering correct (they only sweep 3 or 4 times a second, no matter how fast you crank up the sweep rate, and that can be annoying when you are monitoring a signal), the Tektronix scopes are much better with regard to this feature.

... but seriously, hasn't Windows Server had this stuff (multiple RDP's hosted on a web server) like this for 7+ years now? Is this something new to FOSS?

No, I think you don't understand. Elimination of 2nd hand sales was the real reason they introduced these DRM measures.

Art of Electronics is a great book... but NOT the first book you want to pick up when you're just learning, a point noted by the OP.

Your line of thought is so short sighted that you could be a guest host on the Rush Limbaugh show. 1. Governments are NOT trying to make a profit. If I get a local candidate who promises to use their "business experience" to improve the local government, I almost always RUN AWAY to the other candidate. Governments exist to provide services to their constituents. People like this are the ones who say, "lower taxes and everything will be ok." Reaganomics already proved that this meant "lower taxes and everything will be ok for the rich". Governments need to balance income (taxes) and expenses (services). They've been doing pretty badly for a while now. 2. Pay-for-what-you-use is a nonstarter. Besides the already-pointed-out "how would you determine that", it would turn us into a 3rd World country. Quickly. You know, the kind where you don't have a road system, power & phone service isn't available anywhere besides the capital, and schools are run by charity groups from other countries. Here's a not-too-far-off scenario if this happens: "You know, we wanted to have a highway come near our town, but it had to be built through 4 other towns who didn't have anyone with cars, so we would have had to pay for the highways through them too. But our people didn't want to pay for the highway through the other 4 towns, since its NOT OUR RESPONSIBILITY. So, there's no highway. Actually, there's no paved streets, well, I lied, there is a paved street in the rich section, where the people repave the street in from of their house when they have their driveway redone.."

The last time I checked, wired landlines gave you fantastic voice quality direct to your house. 900mhz cordless phones allow you to roam around wirelessly, without interfering with your wifi connection.

No, most fastloaders actually used only two of the serial lines to transfer data. They worked by transferring byte data synchronously, by synchronizing the instruction stream at the start of each byte so that there was a sequence of 4 reads or writes to transfer each byte. This involved some other blackmagic trickery, since the 1541's 6502 processor was completely unfettered, while the C-64's 6510 processor was stalled for sprite DMA and display memory access (basically, 1 out of every 8 scanlines), meaning that you had to either turn off all of that DMA (turning off sprites and blanking the screen) or make sure you run your transfers when you knew that the DMA wasn't going to take place. A couple of other schemes used asynchronous transfers which were STILL faster than the standard kernel code, then a few systems like Copylock and Vorpal used custom sector formats to minimize the amount of processing needed by the 1541 to decode the data. If I recall correctly, the drive I/O on the C-64 is a stripped down version of an older interface which was actually a parallel 8-bit interface, they simply removed 7 of the lines from the interface but still retained the same control scheme. This resulted in an I/O speed of around 300 bytes/second for a "stock" C64/1541. The 1541's OS itself was able to encode/decode and read/write sectors with an interleave of 3, which is about 7k/second, but the processor-driven serial I/O reduced that by quite a bit. Many fastloaders simplay used the existing read/write routines and accelerated the serial I/O, which easily put the drive at an interleave of 8. Some rewrote the GCR routines too, and I've seen those go down to an interleave of 4. Vorpal rewrote the serial I/O and the sector format, disabled all DMA, and synchronized both processors to +1/-0 cycles to run multiple byte transfers, making it the fastest software based accelerator, with an interleave of 2, reading and transferring an entire track in two revolutions of the disk, or about 12K/second.

Or is that, "'bot time"!