I have read an interview couple of years ago, where Russian(?) reporters have grilled local Samsung rep about the updates. He was trying to avoid any direct answers, but as far as I have understood the source of the problem is the Google itself. Google has basically no predictable H/W platform roadmap and decides on the H/W requirements for every version separately. That's why many older devices didn't get the Android 4 update: the version was improved specifically for low-power and low-memory devices, yet at the same time the minimum memory requirements of the OS were increased. And as such the OS version couldn't be installed on them since that would violate the conditions of the license from Google.

A number of Google's apps are actually services with front-end.

Some 3rd party apps are using the services and as such require the apps to be installed.

Well known example is the maps/location service.

That way, Google can update the service, while updating the apps, regardless of the Android version.

I wish they were...

The problem with Google apps is that they are basically on "rolling release" schedule. In real life that means that pretty much all of them (the commercialized services to lesser extent) are "work in progress" and always slightly unfinished, have problems and bugs, occasionally reset settings or have stupid battery-draining bugs. The QA of rolling releases is pretty much impossible. By the time you get anywhere with a long-term test, it gets invalidated because... - oh, look! we have a new release!! For a device which is expected to run 24/7 non-stop, this is just a moronic non-strategy.

That's why I have stopped updating Google apps altogether. I got tired that I can't even rely on my phone mid-day to have the charge. I got tired to, after every botched update, wait for another update which fixes the problems.

Now, almost a year without updating Google apps, experience is quite good, actually. Though few month after that I have realized that Google apps can also become broken on the server-side. Twice in the last year+ (often shortly after an announcement of big feature release) I had Google servers constantly "pinging" my phone and preventing it from going to sleep. Was pretty bad experience: first time it took me a night of (uninstalling everything) hugging for hours the wireshark before I have localized the problem to the Google itself (and then reinstalling everything.) Problem disappeared few days later, as unexpectedly as it had appeared in the first place.

Back to the "crapware" remark. In my experience, the quality of Google apps if pretty low and as such they fully qualify for the "crapware" moniker. The lack of the usual features doesn't help.

Very unlikely. Most CGI engines have built-in support for gzip compression, since it could be used for compression/decompression of the content.

Also, most "CGI" nowadays is only "CGI" by the name. Zend/PHP, RoR, mod_perl - are all either FastCGI or Apache plugins, and do not use the environment to pass information around.

But that is so idiotic.

Why would anybody in their sane mind do it??

Most of the software will not fail.

Commercial *NIXes, BSD, MacOS and most recently Debian do NOT have /bin/sh symlinked to /bin/bash.

Pretty much everybody who uses the shell seriously in production environment is acutely aware of the differences between /bin/sh and /bin/bash. Distro packagers even more so.

At the bottom of the page, click on the "Classic" link.

New instance, new OS, new browser - but it really took 2 minutes to find how to deactivate the bucking feta.

If the systems really had the /bin/bash exposed, then they were insecure from the day one. It is just that nobody had realized that before.

Otherwise I wonder whether the Debian's /bin/sh being the dash somehow mitigated the problem for the Debian system?

It is good for finding. But not a replacement for the Alt-F2 "Run" dialog.

Every time on my old Ubuntu 12.02 I did press Super, typed "gvim" and pressed Enter, every damn time, it was something else launched instead. Namely, it was always staring the first application displayed.

Because the "proper" sequence is:press Super, typed "gvim", wait ~1 second for search results to appear and only then pressed Enter.

Now, on 14.04, I have switched to Xubuntu and I have my "Run" dialog back. (It was initially misconfigured and taking few seconds to appear, but after googling and disabling "dbus something" it started to work as expected. (Isn't it funny that to make stuff "just work", one often has to disable the "new and better" stuff? Dbus my ass.))

You just bought it.

Give it 2-4 weeks.

As you would start taking advantage of the larger screen, you would get used to the size. Or not.

We are very happy for you. You have finally gotten something from iCupertino.

Back in the day, Note 1's resolution was actually a typical resolution for an entry-level 10-12" laptop - 1280x800. Basically normal HD.

Almost the same as, for example, early MacBook Airs. Or were they too totally unusable due to such incredibly low resolution? (On mucch larger screen, no less!)

Except for those people who actually wanted to have a phone with a bigger screen. I see more glass wearer getting those as a phone they do not need glasses for. Bump up the font size - and you do not have to squint at the phone anymore, you do not have bring it closer to your face. And the on screen keyboard is finally of a usable size for fingers of a human hand. IOW, just like you say, pointless.

What this guy is looking for is called BSD. In the past, base system was bit less than 30MB. Useless, but still less than base setup of most modern distros.

Among Linuxes, probably only Slackware stayed relatively close to the roots and still can be stripped to the bone. And Debian isn't that far off, really, if you are willing to go on rampage with the rm command (remove man pages, documentation, supplemental files, localizations, etc).

Othereise, this guy has probably missed completely that people are already for years building their own "lean and slim" special-purpose distros using the Gentoo as a factory distro. Because what he asks is really "special-purpose". In most real-world cases, the disk space is cheap and the users want to be able to install new software with just few clicks.

Wrong. Linux kernel has modular architecture, but monolithic design. The precise opposite of the systemd.

I know that the uninitiated see the kernel as a big black box. But actually Linux very well structured and highly hierarchical.

The question here is about the case when systemd itself "stops talking".

Some time ago that would have been theoretical question, but actually there were already such bugs in systemd where it was simply stuck because the daemons which compromise it couldn't understand with each other. This is precisely the consequence of monolithic architecture in combination with modular design: the singular logic is spread across many "modules" (the *-systemd binaries) and when the modules do not agree with each other, things go south pretty quickly.

Yes. No. Wait - yes. No... no. Uh....

The systemd has modular design.

But monolithic architecture.

Literally everything inside systemd is intertwined using the D-Bus.

So yes, a crash of one of the systemd daemons might cause deadlock/hang or even crash of the rest of the systemd, and consequently affect the processes running under it.

The systemd's design is pretty bad. This is not an exaggeration, when people call it Windows-like: MSWindows OS has very very similar atructure as the systemd. Windows "Event Log" is really cherry topping.

On-topic: uselessd doesn't fix this problem. It lessens it, but doesn't fix it.

Adding support for another file format is really a trivial task.