Terminating them is certainly your prerogative as a manager. However you have to ask yourself what the opportunity cost is to losing that talent... what did it cost to replace them and all the institutional knowledge they carried. Sounds like you really need to think about what's best for your company and not what's about turning the screws to prove you can. If I were your manager, I'd seriously consider demoting you for your lack of perspective.

Maybe being on-site is necessary for your projects. IDK, but the way you present yourself is as a "BOSS", not a manager of a high-performance team. And if you don't understand the difference, you really shouldn't be managing anyone.

Also, I wonder if any of these companies, especially those that use contractors, could run afoul of labor laws. IANAL but I recall reading a statue somewhere that exempt (salaried) people, and especially contractors, in order to maintain that classification of employment status and not become "employees" or non-exempt (hourly) need to have wide latitude as to independent execution of their work. This was one central aspect of the Uber suit in California IIR.

Now that remote work has been proven at large scale for multiple years, it's a tough sell to say that dictating an in-office work site is necessary for many positions.

After reviewing this (https://www.youtube.com/watch?v=S4W-P5aCWJs) very good youtube video about the energy storage problem I decided to work some quick numbers on my own.

Diesel is roughly 35.86MJ/L energy, which is about 43.1 MJ/kg.
A Generic Panasonic 18650 that I found data for is 12.2Wh/46g which converts to about 0.954 MJ/kg.

Now, you can argue if energy per mass or energy per volume is more relevant for a vehicle, but the crux of the matter is that diesel fuel is roughly about 40x as energy dense as a lion battery.

I'd argue energy/weight matters more b/c of rolling resistance. I'll offer up the "low rolling resistance" tires on the Prius as ad-hoc evidence. (And also why Prii are trash in winter driving)

That's a huge difference to make up in efficiency gains.

Not saying that it's impossible, but the battery scientists have some work to do.

This is of limited use. Vpns and cloud providers with IaaS. It's near trivial to setup acess around it.

You'd have to block so much of the Internet... not much would be left.

Google seems to have this compulsion to introduce/push new languages and stacks without regard to the serious overall product lifecycle concerns that go along with them.

As a software engineer (not developer) and team lead, I care about not just the language, but the libraries, run-times and people and tools that go along with them.

Oracle's absolute IP bullshit aside, which could be solved in any number of creative ways. Kotlin means that I have to retrain my team. Revalidate my tools, compiler and software stack and possibly double my overall dependency foot print if I need any legacy Java inter-op. This also means substantially higher license compliance efforts amongst other things.

The entire thing has to be seriously compelling to justify the long-term cost. The "programmer productivity" go-to argument just doesn't hold water. Almost every software engineer is taught in school (and it holds in industry in my experience) that initial creation of the software is a small fraction of the overall cost to produce and maintain that software.

In short, I'm not buying what Google is selling. Especially after the whole Eclipse vs IntelliJ Android Studio switch over debacle.

w.r.t. the availability of OSS compilers for Embedded PPC:

I worked on several very large and complicated embedded PPC projects using UBoot and GCC from DENX (http://www.denx.de/en/Software/WebHome).

As long as you have a stage-0 bootloader and a serial port, the rest is very workable with OSS tools.

In another life, I also wrote all the multistage bootloaders for an ARM926EJS based part from stage-0 to up to Montavista Linux entirely with GCC and Binutils.
Using LD to generate embedded software images can be tricky b/c the linker script language is complicated, but it is very doable once you get a feel for it.

Having a spectrum digital JTAG pod to debug the stage-0 bootloader was necessary, but once you get the serial port working, the rest is usually gravy. Those pods were about $1500 with software. These days, tin can tools do a decent job for some parts.

I also disagree with notion that a RaspPI wouldn't survive very long as a limiting factor. While the whole board isn't rated for industrial temp range, the BCM2836 is supposedly -40C to 85C. It's not a huge stretch to believe that a similarly priced board (even 2x or 3x the cost) could be completely wide-temp rated.

What would be of concern is possible peripherals that are sometimes used in automotive ECUs, such as advanced timing modules, that are used to provide very precise hardware based timing of things such as injector control and (in spark ignition applications) spark plug firing not being available in generally available consumer parts.

Now, if you have regulatory compliance requiring signed images, crypto, etc. Then it goes more complicated, but not unworkable. There are a number of vendors that offer hardware crypto chips commercially for such applications to assist. These are not prohibitively expensive either.(http://www.atmel.com/products/security-ics/cryptoauthentication/)

I deal with this frequently with sub-contractors (and firms) doing development.

It's actually very simple.
The understanding starts out as: This is a work-for-hire. All work product is property of the company.

Which eventually leads to a contract containing:
All source-code, build scripts, documentation, keys, any other materials required to use or reproduce the deliverable item are exclusive property and proprietary information of the company.
The contractor shall not release, reuse or redistribute any component of this work in any other business. This includes any custom libraries, headers or other application work-product.
This does not apply to off-the-shelf open-source tools and libraries, however such items shall be documented and approved in advance to avoid GPL contamination.

I don't see a problem here.
I expect to pay through the nose if i want exclusive rights and ownership to someone's special library, for exactly the reasons the article dictates.
Otherwise a non-exclusive source-code license that I may do with as I please is cheaper. A binary-only license might be cheaper still.

They devs have to make a living and if it wasn't cheaper/faster to use them in the first place I'd just write it myself.

Just try explaining these legal subtleties to someone who doesn't understand software.

Perhaps NOTHING was the wrong choice of words.

I write driver level embedded code for a living. Everything from bootstrapping embedded linux to SoC level power management.

Power management is usually the last thing to get done (if at all)... why? Because management usually sees it as icing on the cake. Attitudes are typically just make it work and we'll ship a bigger battery to make it last. Or we'll ship an upgrade in 6 months, if the product starts to take off and we decide to fund further development.

Time to market is everything.

Power management is also really hard to get right 100% of the time. It's really hard to debug code/hardware where stuff is shutting itself off, or worse, a controller uP is shutting you off unexpectedly.

It has NOTHING to do with 'bad code' or 'shitty programmers'. It's just management grinding down on the engineers to do it: better, faster, cheaper, pick two. Usually faster and cheaper win.

I hate to state the obvious, but a hash by nature is breakable. You are (typically) distilling a large number of unique bits down to a smaller number of bits.

Of course there will be more than one set of inputs that generate the same output.

Its more an issue of:
1. How hard it is to find colliding inputs.
2. What the hash is used for.

Passwords typically generate more bits, so different rules apply.