With how beholden we are in the US to coal/oil, I am happy to see -any-... yes, -any- progress in the energy field.

I do agree -- nuclear is the way to go for the near and medium term. There is so much to be done with thorium reactors, and it would allow us to do things which would be cost-prohibitive now. Thermal depolymerization for example (which would render plastic trash into usable oil.) Desalination is another.

The ironic thing is that some technologies wind up being embraced by the far left and right. Both the guys with the bunkers, as well as the tree-hugger communes both agree on the use of solar, especially in an off-grid usage capacity.

I am just glad to see someone throwing money into energy R&D. As it stands now, yes, there are improvements in battery tech... but we need batteries at least within an order of magnitude of energy density as gasoline in order to have something effective for transportation across the board, tossing the IC engine completely and moving to electric motors across the board, from the moped to the 18-wheeler.

Battery capacity is the biggest limitation, but after that, it will be getting MPPT charge controllers cheaper and prevalent. As of now, I can buy a PWM charge controller for dirt cheap... but it uses a fraction of the energy that comes off of panels for battery charging compared to a decent MPPT model.

Yep, paying for TV, and finding ads to the show are almost a 1:1 ratio.

Only way to win is not to play.

I find that if I watch stuff, it winds up being YouTube videos, and unless I use an add-on, even there, ads are creeping up, becoming more common, and the "skip at five seconds" button has started disappearing.

It would be nice if YT offered a no ads subscription service... heard talk about it, but nothing seems to have manifested.

The pyramid boom and bust are over. Maybe Bitcoin is valued at what it should be as of now, since various interests have actual value in the currency.

However, I still consider BitCoin a currency for trading, although I'd exchange as quickly as I can. As a currency for storing value, that will take years. The US Dollar took 50 years and was running alongside the Mexican peso before it became a value standard.

I had a HTC Wizard, with its dual-core TI OMAP puttering along at 200 MHz. Doesn't sound like much, but it did well with calls, and could run a week without having to be charged. This was about a decade ago. Now, most of my smartphones won't persist beyond 24 hours unless I have them plugged into an external battery, or like my HTC One M8, enable the extreme battery saving mode, which replaces the Android Launcher default, disables Wi-Fi, and cellular communication, and only runs the absolute minimum of processes. This probably would make the phone's battery last a week, maybe more.

I sort of wish the philosophy behind apps wasn't "lets make these as fast as a gaming computer or console", but the old PalmOS philosophy of "do the job done right, and if it doesn't need CPU cycles, don't do it." Because of demand for ever faster CPUs and GPUs, phones have to get bigger and bigger for heat dissipation reasons. It would be nice for CPU speed to lag a bit to allow for a better battery life, perhaps adding deeper caches. Adding more RAM to a phone might help things as well. This way, phone shape can be dictated by what users want, not having to have ever larger surfaces for engineering reasons.

If you use JuiceDefender, you can prolong the life of almost any Android phone, just because you can schedule it to turn off all communications other than for a certain gap. This does help with some phones that have a short battery life.

Problem with lithium based batteries, in general, are two things:

1: Puncture them, they go boom unless engineering is done to prevent this.

2: If they are not discharged and charged correctly, they go boom.

One place where lithium batteries are starting to make an impact (namely LiFePO4 batteries) is RV-ing. However, Silverleaf controllers tend to be expensive, so if you want this and you like off-grid camping, expect to pay upwards of $120,000 just to play in this ballgame. More useful setups (800-1200 ampere-hours) are available (Advanced RV comes to mind as well as Roadtrek), but expect to pay dearly for those.

What really is needed is a charge/discharge controller that can take a bank of lithium cells and make it appear to existing chargers and electrical loads like the battery is a flooded lead-acid or AGM battery. This would allow retrofitting without having to do major re-engineering of the rest of the electrical system. However, in reality, it will take a re-engineering of charging and discharging eventually because of lithium's different charging/discharging curves.

The Bolt looks like a car that is made to compete against the Mitsubishi i-MiEV. This is a great commute vehicle for an urban setting where you spend most of your time sitting at 0 RPM at lights or in traffic. But for something that might attract Tesla owners? That is like asking Corvette owners to buy a Sentra SE-R, or a Type R Civic.

Here is my dumb question: What is wrong with the Chevy Volt that the Bolt even needs to exist in the first place?

The current Volt is a completely electric car. Plug it in at night, and all that. However, having the gasoline engine means no range anxiety, so while the Leaf and the Tesla owner are back at home switching cars, the Volt is on the highway for a long trip. This is definitely a decent compromise between having an EV for commutes, and a second IC based vehicle for long trips.

If we pull numbers off a high precision clock function like Linux's clock_gettime (which has a nanosecond precision rate), it matters less what exact key the user pressed, because the part that rapidly changes (interval between keys, or even the absolute time (year/month/day/hour/minute/second/billionths of a second) can be used by running the output through a hashing algorithm and tossed into the RNG pool.

One you get into microsecond and nanosecond resolution, that is a quite usable random number source, since someone might be able to tap a key (even repeatedly) on a tenth to hundredth of a second scale, but definitely not be able to give repetitive keystrokes on a nanosecond level.

What key they press might give around six bits of random data, but you can get significantly more bits (20-30) per keystroke just from the high precision timer.

What I liked was the original version of PGP when it would ask you to type some random numbers/letters and would use that as a seed.

It depends on the crypto I was doing: For a number of tasks, say if I were rolling dice for a game, /dev/urandom is good enough. For generating a nonpersistant key (like a session key that is used and tossed during a SSL transaction), /dev/random. For a key that is persistant, it might be even better to use /dev/random, but also ask the user to toss in some random keypresses/mouse movement [1], similar to how TrueCrypt and KeePass request it. This way, if there is something defective with the RNG, it is mitigated by a chunk of random bits from the user.

[1]: Take the time down to as precise as possible, plus the keystroke result itself, hash it (using the hash function as a "bit blender"), toss that in. For mouse movements, take measurements every random fraction of a second, hash those, toss those in as well.

Bingo. Blowback is already happening. Yes, TESCO, WM, and other places have stopped selling the CSA items... but small businesses are being flooded with business. Flagmakers are absolutely slammed with requests.

That is the one thing about the US... it seems for something to get popular, it needs to be initially banned.

During the early days of Linux, UMSDOSfs was a quite useful tool, being able to superimpose UNIX file names and ACLs on top of a vanilla FAT filesystem.

With devices that might need to restrict access, but still require FAT32 because of interoperability concerns, would a variant of UMSDOS that works on this filesystem ever be feasible? Take Android for instance. The only way to keep app "A" and app "B" separated when they are granted access to an external SD card is by using SELinux rules (which the default pretty much denies access.) Having the ability to enforce permissions while still preserving interoperability of SD cards would be very useful.

I'm guessing it can be fitted with a remote control or guiding device to function autonomously, as well as with someone atop of it.

Is it me, or is this a variant of the hovercraft? Normal hovercraft are useful in swampy terrain, but something this small requires a lot of engine usage to keep the cushion of air underneath, and unlike most hovercraft which use curtains to keep the air from escaping as fast, this doesn't have this, so it needs to push significantly more air to keep it afloat.

Ada has a very good reputation for security. I know of a few websites that use Ada for the backend. Not as easy as the web language of the month... but tend to be decently bug resistant, and from what I've seen, haven't had any real security issues.

I do wish for a resurgence in Ada's use. Security depends on the programmer mainly (regardless of language), but there are better tools to do it right in Ada than most other languages. This doesn't mean it is a one size fits all language... but for code that is critical to security, it might be wise to use a language designed with security from the ground up. Spark Ada has provable security, for example (as per "SPARK - A Safety Related Ada Subset")

If really worried, do your work in a VM and have something like AutoProtect in VMWare Workstation save a snapshot every few hours. If you go home, find the VM rebooted, it isn't tough to go back to a point in time before the reboot, save one's work then reboot.

If the host machine reboots, it will just suspend the VM before the reboot, so unless one is running an item in real time, the RPO is 0 and RTO is just getting the VM turned back on.

Another option is using WSUS. I have it configured to auto-approve all patches, but if one wants to take the risk at delaying being patched, no machines will reboot until you tell it to.

Finally, you can always set Windows Update to notify you about updates, so you don't get any reboots until you push the button.

No, it isn't fun rebooting, especially when one has been in IT long enough to be proud of system uptimes, but better a low uptime than hacked box, so patches are a necessary evil.