I second that. Gnome 3 and all releases after that are the worst thing that ever happened to the Linux community. Even after a decade of criticisme there still continue to impose an insanely wrong concept that nobody see as a so good idea that it wanted to copy. On the contrary this started a lot of projects against that wrong concept, notably XFCE that I recommend. Even if the default XFCE settings are ridiculous, it's very quick and easy to configure it like a normal powerful desktop.

Windows is actually the only operating system that don't implement bluetooth host features above version 5.1. Nothing changed in 2 years...

I am old enough to remember that state of the world. Japan was the fast growing player at that time. For China the process did take about 40 years, with the help of what is certainly the biggest total massive money investment ever from USA and Europe over that period of time. The drama is that this was coupled with a quasi systemic dismantling of the USA and Europe industries.

We urgently need to revert that process.

I have done the large part of the engineering of the Koliseum soccer table. It allow up to 4 players, each with a headset, to play a common soccer football game with real mechanical rods that act like on a regular soccer table. Missing players are replaced by robots. Each rods have a handle with buttons that allow specials features like detaching the player from the rod. The game use the virtual reality to bring effects and surprises impossible to realize in the real world.

Technically the Pentium Pro combine cache on the same package, not die. Look at the pictures of the backside of the package where the CPU die and cache die are easily identifiable.

The "old misfeatures" is part of the way too many features of the C++ that make it a such problematic language. Because of the backward compatibility, there is no practical solution to this problem. The name mangling incompatibility across compilers is another C++ long time problem without practical solution. C++ is almost 40 years old now and allowed to test many new ideas on real world applications. It's now time to consolidate all that was learned in something new, clean, secure, and efficient: rust.

The question is especially interesting in the long term.
Will this be just a limited trick to please the developers that like usual console tools on Ubuntu. ?
Or will this be someday included by default on Windows with enough support to allow to run Linux applications ?

For that reason I always wanted that the win32/win64 API will be a international standard managed by an official organization like ISO. That way Microsoft will lost evil control of an API that is actually a very effective tool to kick off any concurrent. This will allow Wine to implement a good implementation based on detailed documentation.

This is curious that no government on the planet require that win32/win64 are international standard, while there usually require standard certification on a tone of less critical parts of there infrastructure. OpenOffice did a genius master move by making ODF an international standard before Microsoft was able to do the same. If only Wine would get enough support to standardize win32/win64 before Microsoft. Seem to be an impossible dream actually.

It's doable, the Wine project prove that point. It's just way more complicated...
In addition to what "KiloByte" have said, Microsoft have the Linux source code as implementation reference to look at, while the Wine project didn't have a chance to look at the Microsoft kernel and libraries.

Whenever it's for hardware or for software, the point to make a project open source is to create a community to support and improve the project, not to make money. Starting from that point I found cheap clone a rater big advantage, because this offload the production problem and make the project accessible to more and more peoples with almost no management. Instead of fighting against clones, it better to take advantage of them.

While you are right about the actual situation, I think that more complicated attacks will be the next mainstream just after the easy attacks will be patched.
And I doubt that modifying a few files of a squashfs image using his block device will require multi-gigabyte images.

Because the squashfs image of OpenELEC is read only and mostly one of the know images already published, the operations you describes could be done on the hacker PC. It can then find a way to generate the hacked image from the original by analyse the difference between the two. This recipe can then be directly applied to the partition of the target device probably without too much processing and memory.

I agree that this is much more work, but maybe not so difficult for a motivated hacker.

Good idea, but what grant our that your firewall is not hacked ?

Actually it could be the case:
http://www.theregister.co.uk/2...

OpenELEC FAQ disagree:
http://wiki.openelec.tv/index....

What is the SSH login?
Shortcut: #SSH Login
Currently the login into OpenELEC has fixed settings.
  Login: root
  Password: openelec

How do I change the SSH password?
Shortcut: #SSH Password change
At the moment it's not possible to change the root password as it's held in a read-only filesystem. However, for the really security conscious advanced user, you can change the password if you build OpenELEC from source. Also you can consider logging in with ssh keys and disabling password logins.