Aside some very specific use cases, transactional memory does not offer much in terms of performance. Moreover, transactional memory helps a lot with Timing Side Channel Attacks against the kernel. For example: https://www.blackhat.com/docs/...

Also you should compare cars under the similar driving conditions. Currently, autopilots refuse to function in difficult road conditions, while human drivers do.

Linux 2.6 was released in December 2003.

Commercial Unix workstations had a decent desktop for its time, but they were too expensive. Their private hardware was the primary reason of their excessive cost. Still they were not eager to offer their OS for PC, when PC became power enough to run UNIX OSes. Though, there were some commercial UNIX OS for i386 in the early 1990s, they were too expensive for private users. By his own admission, Linus would never write his own OS if he could just buy a commercial Unix OS for a reasonable price.

I use Linux desktop since 1997, and I know people who started to use it before me. However, when it comes to regular people, Ubuntu became the first distro usable by non-technical crowd. (BTW, personally, I still prefer Debian over Ubuntu, but that's another story...)

In this regard, my experience is very different than yours. If I had a machine with pre-installed Windows, it would take me a week to install all software that I regularly use, and then I had to change a lot of default settings, which is really annoying. On the other hand, it takes me one day to install a Linux distro from scratch with all required software, and I am ready to go.

In any case, the reason why we don't have more Linux desktops has nothing to do with the Linux kernel. If you want to have a good desktop, having a good kernel does not really matter that much. On the other hand, if you want to build a supercomputer, the kernel is the crucial part of your system.

Emscripten allows to integrate this javascript directly in your C++ code, so touching DOM from C++ is not a real problem.

AFAIK, the Java bytecode verificator does not handle some corner cases, and it is so complicated that it may contain security bugs. So I would not say that the problem is solved in general...

WebAssembly requires the compiler to do a bit more work, but it makes the verificator much simpler and faster. If practice shows that WebAssembly does not handle switch statements well enough, WebAssembly can be extended in the future to handle it as a special case. I see no reason to support arbitrary graphs.

This sounds an awful lot like browser-based java virtual machine circa 1995.

It only appears so at first glance. WebAssembly is a logical continuation of asm.js, which based on experience of developing of high-performance JavaScript engines. The goal of WebAssembly is to use existing Javascript engines to archive close to C performance within browsers, i.e. something that asm.js already does to lesser degree. In contrast, Java VM was developed to run independently from web browsers, and though you can run it inside a web browser, it's not integrated nearly as well with the browser.

In many ways, WebAssembly is very different than JavaVM. For instance, WebAssembly does not have a GC, while JavaVM relies on it. WebAssembly allows only structured control flow, while you can have an arbitrary control flow in Java. (The restriction on the control flow makes validator for WebAssemply bytecode rather trivial, which helps both with loading speed and security.)

In short, WebAssembly is a VM developed with web browsers in mind, while JavaVM was developed with different priorities.

The idea of AI initiating a pre-emptive strike is B.S. If you want to train AI to do something well, you need a lot of data with known outcome. Usually AI can do better than humans only when they were trained on a much larger set of data than any human can process. So I don't see how you can train AI to make good strategic decisions, because you don't have much data here.

However, AI can contribute to escalation of different proxy-wars. If you send your soldiers abroad, it comes with a heavy political cost at home. Using AI in military can reduce the human cost, which may escalate some regional conflicts supported by different powers, and that may lead to a world war.

The real technical challenge is not how to build a pod that can accelerate to supersonic speed inside the near-vacuum, the real challenge is how to build a very long vacuum tube that would be safe and cost-efficient to operate. So all those hyperloop competitions do nothing to advance the hyperloop idea -- it is just a show for a gullible public.

It is true that Russia places a much greater emphasis on teaching math, physics, and CS than the West. However, it is only possible because of Russian culture puts more value on knowledge of those subjects. Their knowledge means both more social prestige and better prospect of finding a well-paid job.

BTW, many Russians tend to preserve this attitude to math even when they emigrate to the US. As result, their children do better in math on average than American kids. For example, Sergey Brin has never attended any education institution in the Soviet Union, but he was successful in math and CS. Similar, many Asian kids do well in math, because of their parents.

Anyway, Russia has a large pool of young well-educated people, but Russia does not develop as much software as it could given human resources that it has. As result many young people cannot find a legal well-paid job, and some of them get attracted to the dark economy. Usually Russian authorities will not go after them as long as they choose their targets abroad.

But you'd never hear someone say that brain surgery is "fun," or that structural engineering is "easy."

Jeez.. Does the author know anything about programming? Programming is fun, because you don't have to do the same routine over and over again. If you a good programmer, you always write something new, and something innovative, and no one expects you to be perfect each time. As long as you get basic data structures and design right, small mistakes won't matter at the end.

Manic attention to detail is a must

In my experience, good programmers are not those who have the most attention span, but those who know how to write their code in the way that it will be easy to read and verify. Those who often complain that coding requires "manic attention to detail" don't know how to do that properly. It is very common for novices to create ugly overcomplicated solutions, because they don't know how to structure data and code properly, and then they spend enormous amount of time trying to debug that code.

The article starts with a claim "women have higher levels of education than men," which might be true, but it has nothing to do with underrepresentation of women in Information Security. The relevant information would be the percent graduates in computer science. When I googled for that, I found that only 18% of CS graduates were women. (Source: http://www.aauw.org/research/s...). So though there are more women with degrees, most of those degrees have nothing to do with CS.

Then there was a claim that "women make up only 11 percent of the cyber security workforce". I don't know where this number came from. Based on statistics provided by US Department of Labor, there are 18.1 percent of women in Information security analysts. Source: https://www.dol.gov/wb/stats/C...

Where is the link to the original study? The only valuable piece of information in the whole article is: "We do not yet know which came first - the social media use or the perceived social isolation". As to correlation between social isolation and active use of "social media", it is neither new nor particularly surprising.

Google search is not a magic tool to learn the truth. If you feed some nonsense in the algorithm, you should not be to surprise of getting some nonsense back. The Google's Snippets feature says nothing about accuracy of the presented information. So you should not be surprise of getting some nonsense if you search for it. To be able to use Google correctly means being able to validate different online source, and not to rely on what came up in Google search first. What is really surprising is how many university students are incapable to work with online sources and blindly believe in whatever Google says. IMHO, that is a much bigger problem than any imperfection of Google's algorithms.

Rust does not aim to provide you a sandbox to run untrusted code. Its goal is to provide type safety. It means that code written in Rust is as safe as written in Python or in another high-level language, but it runs as fast as if it were written C++.

Obviously, it could be bugs in the Rust compiler or an unsafe library that you use, but the attack surface is much smaller in this way. Take a look at programs written in high-level languages, you do not hear about buffer overflow and other low-level attacks against them very often, though they also rely on some unsafe code and may have implementation bugs.

Most attacks against applications written in high-level languages focus on the application logic. For example, attackers may try to force the application to overwrite some configuration file, which enables them a remote access, or create an executable file, which can be then run remotely, etc.

So for most practical purposes, Rust eliminates certain classes of attacks. This does not mean that applications written in Rust are truly safe, but they are likely to be much safer than written in C/C++.

Apparently, you have never managed any software project for many years. Because if you did, you would realize that people are different, and some far more sensitive to criticism than others. Also a lot depends on the overall culture in your organization. So without any specific context, all those generalizations about what "a wise manager" is supposed to do is UTTER nonsense.

Now if we speak about the Linux kernel, the fact is the success of the Linux kernel is largely due to Linus ability to keep many talented people involved, and he works with same people for many years. So whatever words he chooses to express himself, it does not seem to affect his working relationship with those people. Also I do not remember that he has ever criticized newbies, who are still learning, or anyone like that. Practically, all his harsh words were directed at his lieutenants, who were entrusted to keep the source code to a certain standard, but failed to do so.

Finally, I will never trust you (or anyone else) just because you are willing to work on some stuff. I can trust you only if I know that you can deliver the result that meets certain requirements. I had a developer who tried to be nice and willing to work on almost anything, but his code was nearly always crappy, so giving him nearly any task (aside the most trivial stuff) was completely useless. So we had to part with him. So the question is not what you are willing to do, but what you can deliver in practical terms.