You don't need to. Their business-grade lines (e.g. Thinkpads) include remote administration tools that basically let you do whatever you want to the laptop over Ethernet without turning it on. You can disable it in the BIOS/UEFI, but it's enabled by default.

Generics, as done in some languages, are excellent. Java is not one of those languages, primarily due to how it handles type erasure. Requiring the programmer to use an explicitly boxed type (Integer instead of int) is also rather clumsy, as is the lack of inference for type parameters.

IMO, C#'s implementation of generics is considerably better.

Or if you're impatient, you could just use D - the syntax is virtually identical to C#, but you get the performance of native code. I actually wrote some patches for buildroot a while back that added support for gdc, which make it pretty easy to compile a suitable toolchain for using D on a Raspberry Pi.

It's more than that - people (inexperienced developers in particular) are terrified to break outside of their encapsulated environment. They instinctively assume the standard libraries are flawless and bug-free, and that they don't have to worry about how they work, which is a useful approximation until that's no longer the case. The idea of looking at the source for said library to understand it better simply doesn't occur to them, or they overestimate its complexity. (To be fair, this is a view strongly encouraged by closed source software, which is a black box to even those interested in the internals.)

The kernel is different from userspace because it doesn't have the same protections and isolation. In userspace, (un)locking the wrong mutex gets you an exception with a nice message or a well defined error code. Do the same thing in the kernel and you get an oops with the stack trace pointing to a BUG_ON() assertion with some confusing looking code. It's the very opposite of the encapsulated environment presented by many userspace languages - misusing the mutex results in the developer being forced to look at the workings of it. Once you become used to that, your skill at working with complex systems develops rapidly.

I'll second this. I'm a college* student who's currently picking up kernel programming for this exact reason. (Also, I find file system design interesting.) Whether or not it will help my employability remains to be seen, but it only takes the perception of utility to result in an increase in development.

* called university here

That's a terrible idea. It's not Ubuntu vs Mint vs Fedora, it's Ubuntu vs Debian vs Gentoo vs Arch - there's a massive spectrum of distros in terms of ease of use, stability, customizability, etc. There is no one size fits all solution - a rock solid production system is going to be completely different to a bleeding edge development system.

Separating distros from upstream projects is also important because the upstream projects rely on distros adopting their latest software at different times to maintain stability. Users of bleeding edge distros like Arch effectively test the software for users of more conservative distros like Debian.

It's also worth noting that Kubuntu is probably one of the worst KDE-based distros - IIRC, the 4.0 release mess was exacerbated by their maintainers configuring things poorly. And let's not forget that KDE is leaning towards using systemd internally... (I use systemd myself, but I think the idea of forcing it upon users is ludicrous.)

It would be fine if they were simply removing OC support on new cards. The problem is that they are removing a feature from a product that has already been sold, and even used as an advertising point by some manufacturers. This is no different to Sony removing OtherOS from the PS3.

It's poor style to not indent the inner for, because C family languages do allow one line for-statements, which the body is replaced by a single semi-colon. Someone skimming over the code could easily interpret it as such.

Wayland is a replacement for the X window server. (X is the software the sits between your graphics drivers and your desktop environment.) X is ancient at this point and has fundamental issues with its design that mean security issues which can't be fixed without breaking backward compatibility. X has a lot of features that it is required to support to maintain backward compatibility that no one uses any more - modern systems work by just pushing blocks of pixels to it. Wayland only supports this method of operation, so it's much simpler than X. Wayland's main developers are ex-X developers who are intimately familiar with the problem's X has (see Daniel Stone's talk on youtube for more info).

Wayland has been somewhat controversial because it does not have support for network transparency, unlike X. However, most modern apps don't use X in a network transparent way, and X network transparency is actually slower than VNC. The Wayland developers have advocated an approach similar to VNC for network transparency, but AFAIK there's no major implementation of it yet, so it remains controversial (even though almost no one is actually using it right now).

That's how it's different. If you get a new computer loaded with crapware, you can still uninstall it within Windows, or just reinstall the OS entirely if you wish.
With the Android crapware, you can't uninstall them, and if the phone has a locked bootloader, you can't replace the OS either.
It's very much a question of how much control you have over what runs on your device.

Why not? To take the US as an example, the per capita GDP has increased more than three-fold since the 1950s. That means that it should easily be possible for a population with a 40/90 productive lifespan to sustain itself.

Of course, this assumes that the increased productivity has translated directly to increased wealth for the average person. But that not being the case means you have a wealth distribution problem, not one of resource constraints.

I think the difference is more fundamental - it's to do with how you perceive the system. Someone who sees files as being closely connected to the programs that work with them is more likely to consider built-in encryption features first, while someone who sees files as just being a bunch of bytes would consider a generic approach first. IMO, someone with a Unix background is more likely to fall into the latter category.

Which is a terrible defence when you're talking about a single key used for the entire industry (it has to be burned into the CPU, so good luck updating it.)

Hey, why make it human readable at all? We could encode the program in instructions of word each, and limit the no. of available registers so that they could be represented by a simple 6-bit integer. We could even generate such code from the existing, inefficient code using a compiler...

If most of the code is generated, then the language is broken - the generation should be integrated into the compiler, so as to both formalize the rules of generation, and also to reduce the amount of code that needs to be read when debugging. A good example of this is the property syntax in C# - you can just define it as {get; set;} and the compiler fills in the boiler-plate. Even C's macros are superior to the Java approach of just dumping the generated code among the rest of the source.