Many Intel NUCs also require hacks to install on them anything non-Windows (for example Linux).

My point being: Intel NUCs are also not very friendly to the alternative OSs.

Really?

Author apparently hasn't seen the crazy monstrosity the Rust's preprocessor is.

Otherwise, IMO, Rust and this type of languages - "the perfect cage" - to me are dead end.

(A) I want an utilitarian language. I want language which provides me with strict and weak typing, static and dynamic binding, compiled/jitted/interpreted execution with eval() function. At the same time. Probably all that in different scopes - but the scopes should be able to inter-operate. Think Objective-C++ - but with something better than Objective C on the weak side of things, with bits of Perl-ness built-in.

I want a language which gives me choice. Not another language with dozen theoretical papers why I can't do something and I'm better off for it.

(B) For security, I would rather want an language which can be easily validated and proofed. Rust tries to create a perfect cage - for developers - while the main security vulnerability is the user input. Compilers still can't guess whether I have properly validated the input or not. The Rust went in a different direction: annihilating C/C++ bugs. The problem is that all other bugs programmers make - still remain.

People keep bringing up the Swift in context of system programming, but so far I haven't seen any concrete info about features of the language which make it even suitable for the system programming.

The thing is, even C++ was/is used for system programming, but its C++-ness is so castrated that it is hardly can be called C++ anymore.

I personally do not see any reason to replace C with another language, which I can't use to its fullest. On top of it, lots of C extensions are needed to make the system development efficient: code/data section assignment, untyped/unchecked memory access, memory/IO barriers, assembler intrinsic. None of that is part of C standard - all of it are vendor/compiler extensions. While Swift documentation is devoid of the similar features.

P.S. If Apple folks want to push the Swift into the embedded area... Good luck. Even C++ still struggles. Higher-end embedded system require proof of validity and literally all of the solver software is C-only. Most static/dynamic code analyzers - C-only too.

By the looks of it, they are talking about new rail track.

If there is a problem of delays with the current one, that means the rail system doesn't have redundant tracks to route the traffic around a problem.

One more track, less chance of one broken train holding up the whole traffic.

I haven't ignored it.

I simply can't understand your condescending tone about it.

It is pretty normal for gov't to jump start industry by helping it one way or another. It happened (and happens) in a lot of important industries.

But you are acting here as if it was something weird and unusual.

R&D gets money from the sales. Subsidies help lower the entry barrier and grow the market. Larger the market - more money gets into the R&D.

Lots of things were not viable initially without gov't help. Public transportation, metallurgy, telecommunications, energy - are all the industries gov't helped to jump start by giving subsidies and tax breaks. Because there is no single party - or group of parties - large enough to finance the whole thing till it becomes, as you put it, "compelling economic option".

And in your opinion, where from come the R&D money? From Santa Claus?

You need to read about economies of scale.

It's pretty stupid to compare economic viability of 50+ year old industry (covering 90+% of market) with 10+ year old industry (striving to gain a percent or two).

I like how pragmatically Germans went after the solar: it makes sense in long term, thus it makes sense to start R&D sooner than later. And apparently it is going well enough that they are even planning to repel the subsidies (to much chagrin of some).

What does that mean? From the official Debian wiki:

Something tells me that we have another weirdo ARM board with its own "Debian" distro, joining the disarray ranks of dozen others: poorly supported, barely maintained, and soon forgotten.

Considering the total amount of effort invested (and wasted) by developers into building the custom distros, I'm surprised (and disappointed) that nobody has actually stepped up, organized and standardized booting/etc on the ARM SoC yet. (IMO ARM Ltd itself should have done that a decade ago, since IMO it is one of the major roadblocks to the broader adoption of the ARM.)

Hotter, but not so hot as to cause problems.

N.B. Historically, I actually had more termal problems related to the Intel's than to AMD's CPUs.

But it is true that in the power efficiency department, the Intel i-series are better than the AMDs.

Though it is not a clear cut, if you take the whole system power consumption. Intel CPU + nVidia GPU would draw about the same (or more) power as AMD's comparable integrated CPU/GPU.

ARM CPUs still do not have proper pipe-lining. Out-of-order execution is castrated too. That basically kills ARM CPUs in any workload with lots of math (think games and encryption).

And how about the CPU cache? 1MB of cache for ARM is still a high-end feature, while most desktop CPUs have 4 or more MB of cache. Huge HUGE difference for the memory bandwidth.

ARM has its niche (which if ARM really wanted could have been very very broad and not niche at all) but as soon as you start gaming or do any real work, they simply pale in comparison.

P.S. The use case I was researching in the past was the VPN. Most modern ARM SoCs hit around 1-2MB/s of sustained traffic encryption (on single core). My very old Intel CPU easily hits ~8MB/s (probably more, don't have bandwidth to test) on single core. And the ARM SoCs with quad-core >1GHz CPUs, which can do more than 1MB/s, cost more than $20. (E.g. ODROID U3 - $70.)

Cheaper. AMD always was and is cheaper than comparable Intel parts. Ditto AMD vs nVidia.

For the lower price you lose some performance, especially in the edge cases. But for most tasks, the difference is almost negligible.

P.S. Though the case is different in the gaming, where pretty much the whole market optimizes exclusively for the Intel/nVidia.

Easily believable if PassMark was compiled using icc (Intel C Compiler).

Because MSFT provides a stable base API which changes rarely/slowly. All extra bells and whistles are separate APIs. One can still compile natively 20yo Win32 WinAPI application and it would run without any problems.

That's also a part reason why Windows is relatively bloated: there are multiple APIs/API versions available simultaneously for backward compatibility.

That's what makes Window not fragmented: lots and lots and lots of hard work on part of Microsoft.

In comparison, the Google is like a spoiled child: grabs new toy, plays with it for a minute, breaks it, throws it away 'cause it's broken and moves on to the next toy.

The article is 5 years old, which is in the Google universe is like couple millennia. They have changes pretty much everything since then.

AFAIK that's how it worked - till 4.x series.

But with 4.x series Google has broke the pattern: almost every 4.x release was a major release with incompatible interface.

Effectively of Android 4.x, the Android OS is on a rolling releases.