I run a single 4K monitor setup with a fixed grid of 8 x 8 virtual desktops to work on a lot of projects. Sloppy focus is a requirement: so much natural and efficient. Using alt-tab of upper left corner to switch application is a total vast of time. Either you better have to put widows side by side to not switch at all, or use the taskbar/taskmenu to directly raise the one you want, because on a machine with close to 100 windows the "always changing position in the list" of the atl-tab menu is a nightmare. I use Ctrl-Up/Down/Left/Right to quickly switch between virtual desktop with a single hand. Add Shift to move the focused window across the virtual desktop. There is absolutely nothing floating, moving, growing or shrinking dynamically: no effect at all. This make all the operations immediate, blazing fast, and perfectly predictable in my brain without looking at something other than the task I am working on. In addition, I have found that no effect is the best setup to lowering visual fatigue.

I have tried multiple times to get the same comfort and efficiency with Gnome 3, but it's actually not possible to reach the level of xfce4 or mate. From a high level Gnome 3 look like it can do it, but so many details are broken/unconfigurable that in fine it's just a vast of time.

I don't known what work you do with your Gnome 3, but for anything more than basic task it's a complete failure.

The panels management, something that reached the perfect stage in Gnome 2 after a decade of effort, was completely trashed away with nothing close to replace it. The upper right corner application switch is totally ineffective on big resolution screen like 4K. Removing the trivial application menu is not a simplification at all. The virtual desktop management completely broke the fact that the human brain work mainly with spatial representation. The window management is full of bugs that make too many applications a frustration to use. Almost any good panel plugin was either trashed or replaced by a inferior and unstable version.

I actually work with Debian Xfce4 and it's a usable replacement of Gnome 2 after a full day of configuration tricks. I have a others machines: one with Ubuntu Unity, one with Debian Gnome 3, one with Debian Jessie Xfce and Mate, and a last one with Mint Mate to be able to test different systems. Mate will certainly be my choice when I will switch to Debian Jessie on my main workstation.

My girlfriend use maily the Gnome 3 machine but also regret the Gnome 2. My children use manly the Ubuntu Unity and Debian Jessie with Xfce or Mate. The vastly prefer Mate or xfce desktop. That said there even more prefer Mint Mate because of the innovative well designed application menu and application installer, even if it is a bit slow from my point of view. If there is a future in the desktop usability, you should look in that direction instead of degrading a computer to the usability of a mobile phone like Unity or Gnome 3 do.

It's not realistic to get a such deb-pkg error from a python wrapper is you wanted to create a package containing only a binary application.

I have packaged many binary applications without any problem, this is in fact the most easy way to create a package. The tools to do that are well tested and reliable.

This process is nothing related on how you have compiled and linked your binary application. In some project this includes some horrible hack to link proprietary binary libraries compiled with old or unusual compiler. If you get the stage where the result work, then packaging it is trivial.

You don't need to use backend script to package a binary. The *.preinst , *:postinst , *.prerm and *.postrm scripts are all optional. Many packages contains only a compressed archive and a simple "control" file.

Well, the problem is not that Gnome try to develop a new innovative desktop, the problem is that is forced the users to use it innovative experimental hack by stopping the development of the loved and stable Gnome 2. If only Gnome 2 have transited to GTK+ 3 like MATE is actually doing, the Gnome 3 fiasco would have been only a failed experiment without much negative consequence.

Forcing users to Unity or Gnome 3 was an abyssal error at the time when potential for users switching because of Windows 8 was high like never before. Those desktops was too limited, too unstable, and new potential users found a lot of complain from old users. This was not coll at all.

Linux distributions enjoy the possibility to let the user choose his desktop from multiple options. It's tragic that this feature was not used on that problematic switch. Now XFCE and Mate have bring back full usable desktop. Maybe Unity and Gnome 3 will someday get usable. The whole story have just fragmented the effort at the risk of loosing valuable contributors in each projects.

Making Debian package of your application never require that it is accepted by the Debian project. You can maintain your own packages repository where you can publish your Debian packaged applications. If your application became popular and is open source, you will certainly get new contributors motivated in maintaining your application into the Debian distribution.

Packaging is a very big achievement. Even Android use packaging with APK file. Really, packaging is not the problem. I remember systems before packaging, this was a nightmare. Never return to this hell...

The problem is to have popular tools able to build and publish proper *.deb package as easy as for *.apk packages. For example a good IDE where you find a "new C++ Debian package" button (and others language option of course), fill a simple form and start coding your application from a functional template. Then a "build" button should create the *.deb package and you should be able to debug it. The IDE should have a "Add Debian repository" button with a simple form to create a remote Debian repository using FTP or SSH. Finally the IDE should be able to publish your packages in your remote repository. Like for Android, the IDE should be able to build package compatible with a choice of releases.

From my point of view, the packaging is not the problem. The lack of competitive developers tools advancement in the Linux distribution compared to Android is in my opinion far more the root cause if the problem. While structured very differently, *.deb and *.apk packages target almost the same goals from the system and user point of view.

The situation in creating and publishing *.deb package is actually like if you create and publish *.apk packages all by hand using a lot of command line, instead of a easy and shiny IDE.

Actually Chrome OS or Android are toys compared to a full desktop experience. Gnome 3 and Unity has go into the direction of toys for simple applications resulting in the frustration if so much users that projects like XFCE and Mate get attention like never before.

I lost a opportunity to moderate you insightful (you already got a 4 anyway) to take a chance to say thank you very much for your explanation. Your second paragraph is just so clear and simple. I think that I have understand a new aspect of the physic in a minute. Great.

Sometimes a simple phrase open a mind so quickly that I wonder how fast we can progress is we got the chance to read a lot of them...

Yes firewall has bugs. It's still simple to swap firewall model in case of a successful attack against one of them. If the infrastructure is really so critical, adding layers for packet monitoring and for packet validation should probably be a good idea.

You simply don't know the future security bugs that will affect your infrastructure. Just look at http://www.cve.mitre.org/ or any distribution security announcement like https://www.debian.org/securit... . Security bugs are discovered all the time. With this fact in mind you realize that you need more than a single protection layer to get a chance to detect and drop a harmful traffic. The bug could be deep into the kernel, making almost any magic possible from the application point of view. Having only a few ports open is not enough to protect against this, as the kernel structure and notion of port could be corrupted.

This will make the failure looking like a thing of the past and make hope for a successful new future.
But this don't grant that this will work as expected. Especially after you use the same plan almost each 6 months for more than 3 years now !

There exists a more cynical possibility: some entities could have buy enough share to impose key members into the board, fully knowing how the story will end. The cost of destroying Nokia could have be lower than the risk of losing others long term investments of the same entities.

Very true. How the board was misinformed to the point of doing a such clear suicide is still part of the hidden story. Even more strange is the constant support the board give to the CEO even after all the alarms was turning full red. The "No plan B" concept was the biggest mistake ever from a board.