If only it were that easy.

One of my daughter's (now former) science teachers (in a private school; previously in a public school) is such a person. But, she is very limited in what she's allowed to let the students do. Mostly she can only demonstrate. And even then she has to obtain approval for each demo (even repeats of past demos), then keep to the approved script.

Despite these restrictions, she manages to inspire her students. I thank her for her efforts. I just hope she won't be driven away from teaching.

A few things:

1. Linux can auto-update.

2. My employer's IT department does not blindly accept auto-updates. All PCs - both mswin and Linux - are configured to update from the company's servers, not any server outside the company. IT vets all updates before making them available on the company update servers.

3. The mswin experts (MS certified) in my employer's IT department have found and reported several "bone-headed obvious holes" in mswin.

4. Just because you are paying fees to receive commercial support does not mean you can setup-and-forget.

Total energy out == total energy in. The energy in is electricity. The energy out is a combination of light and heat. More heat implies less light.

Also, a bulb with more surface area for coupling heat to the air will feel less hot than an otherwise identical bulb with less surface area. The larger surface area has less heat per unit area. Also, the LEDs in the hotter bulb may be above their optimal temperature range, so operating less efficiently, so producing more heat per unit of input energy.

So, for otherwise identical LED bulbs, cooler is better. ("otherwise identical" being a big caveat)

Of course, there is another factor: Not all light is suitable for our use. Ideal would be all light produced be in the visible range with whatever color balance the individual user prefers (I prefer "daylight white"). It is possible for a bulb to produce less heat, but mostly unusable light while another produces more heat but mostly usable light. So, while the overall efficiency of the latter bulb is lower, its effective efficiency is higher.

As usual, YMMV.

The hard drive/data storage device contains a lot more potential evidence than the safe (Except, of course, when the safe contains one or more hard drives / data storage devices). While court orders can limit the scope of evidence obtained thusly, such orders cannot limit what the analysts reviewing the unlocked data memorize.

Seems to me that the encrypted data storage device scenario requires more care than the combination lock scenario.

Which libertarians? The working class ones or the ones who get to tell other people what to do?

Fortunately, I've been enjoying life all along.

As for being able to retire, I'm not sure that we will have a choice to not "retire". We've been seeing more and more "old" people being forced to "retire" over the last few decades. As time goes on, a smaller and smaller percentage of these will be able to find alternative work, not even minimum wage work, no matter how few hours per week.

It does seem most humans live 70 to 90 years. While the known record is 122, we don't really know what the maximum is. I recall reading numbers as low as 125 to over 300, so, by the end of this century, 110+ might be common and 120+ not so rare as now.

FWIW, I have a coworker whose girlfriend's great grand parents all lived past 105 and 3 of them past 110, all in good health and still productively contributing to the family business until their final few months.

I recently had to have the engine in my car replaced. Total was $3000. The best price I could find a similar used car was $8000. Given that the rest of the car was (and still is) in very good and fully operational condition, the $5000 savings made sense.

In my professional career, several projects I have worked on have been canceled despite a good state - not behind schedule nor over budget, or even ahead of schedule and/or under budget. The reasons were usually variations from "marketing has decided to change direction" to "after management re-org, the new managers decided the risks were too high". The latter happened to one project despite us having 5 fully and correctly operating prototypes, and having invested 3 person-years of effort and over half a million US dollars in development tools and licensing of third party libraries. Another project was canceled because the primary stakeholder lost interest despite the first two phases being highly successful.

Back in the 90s, I went to convention in Detroit. I met a fellow who had sensors in his hot tub connected to a webserver so he (and anyone else) could monitor the status of the tub. He also had sensors in a minifridge connected to his server. His website went offline several years ago.

I agree. Except for the first 2 classes (which I bypassed), the CS classes offered at the university I attended (and graduated from) simply expected that we could code. The graders barely looked at our code. If they could compile and run it, then if the results were correct, our programs were correct. There was no feedback, let alone instruction, on readability or maintainability. And the closest we got to software planning was that our term project design documents were 30% of our midterm grades (along with 30% from homework and 40% from test scores).

So yes, universities should add classes on software planning and improve classes on coding practices (while I did bypass the 2 "coding" classes, I did see other students' assignments and code, so I could see that the classes were more about applying coding to problems than coding practices).

Yeah. This, along with "buzz word compliance". This strongly rewards those who are good sales people over actually technical ability. software people seem to especially vulnerable to this. Some times this can be worked around by knowing who's getting ready to post positions so those managers can tailor the requirements to fit. However, more and more HR departments are moving to standardized requirements. Although technical managers actually realize this is happening, the message that gets to the executive suite is "we can't find qualified candidates".

Interesting. My company's execs complain that too many employees are fascinated with social media. And no, the execs are not senior citizens. Also, the older members of the engineering staff are the ones most likely to not wear a tie.

A lot of equipment is more expensive than it could be. Doing more than a cosmetic redesign opens up a vendor to liability issues. Until either the lawyers are comfortable that the cost savings of a new design sufficiently outweigh the potential cost of law suits or they see competitor stealing too much of their business, they won't be willing to take the risk. Right now, these third world countries don't look like good enough markets to bother with.

This reminds me of a CPU fan that is powered by the heat using a tiny Sterling Engine. Maybe not the kind of "practical use" of the waste heat the editor had in mind, but still an interesting idea.

Actually, that's how the testing should be done. Give the requirements to both teams - testers and developers. Developers design/write the product code. Testers design/write the tests. Then let the testing begin. Problems entered into issue tracking. Both teams fix their respective problems. Retest. Repeat as needed.

Unfortunately, many companies fail to adequately fund testing so devs end up writing tests, which, in turn, catch fewer problems