Not, if you measure "the progress" by the revenue/profit.

Copyrighting APIs makes no techinical sense, while copyrighting maps and manuals does.

The only thing remotely plausible is patenting APIs. And even that I'm not sure technically feasible.

I've witnessed probably man/centuries of wasted efforts due to crappy APIs - and I've seen single-person projects springing to life and seamingly leveling mountains when the available APIs were good.

Some APIs fit the puzzle of any applications - some force projects as a whole back to the drawing board.

No idea. But the sound works real real good!!!

No PulseAudio, no "committee design" ALSA - the proper OSS.

Low/no jitter - clarity and definition of sound you can't experience under Linux.

If you have hi-fi/better connected to the PC, and your sounds card is supported, you owe it to yourself.

Only technically-illiterate can ask such question.

System console is there because on (almost) totally broken system, it is pretty much the only thing working.

Throwing more software into the system console is pretty much guaranteed to be detrimental to the rate one would be able to get the console working on a broken system to repair it.

Especially nowadays, when systemd, which is very actively developed, breaks systems often enough (by refusing to boot) to require people to drop into the system console and repair system to make the systemd working again.

Ignorance is bliss?

It is not the first time systemd tries to break stuff they have no frigging idea about.

I have impression that only I recognize the trend: the Linux is slowly transforming into the UNIX.

The same crappy attitude. The same crappy unusable bundled software you can't unbundle or replace. Admins are overjoyed with the new shiny toys - users are making teeth screeching sounds.

All symptoms support the diagnosis: it's UNIX.

So a bug in systemd now (or botched update) would be a totally unresolvable, because Linux box wouldn't even have proper console then?

Very very sane plan. Kudos, systemd. /s

RHEL is a golden boy of modern corporate Linux.

You can't replace them because corporate accountants know only the RHEL and RHEL corporate talk the same language as them. And just like the UNIX, you better not touch the RHEL, because RH might simply say (and often do) they do not support the configuration and you are on your onw.

I feel like I'm reliving the piece of the UNIX history. The only difference only is that nobody yet wrote the "RHEL Haters Handbook".

On most systems - number-wise - which are Debian-based - it is not.

But on the RHEL, the golden boy of corporate uni-culture, it is. The UNIX reborn.

Let that be a moment of the appreciation for all the work Debian and Ubuntu people do behind the scenes. (Yes, Ubuntu too: the transition to dash was actively supported by Canonical since they wanted Ubuntu to boot faster and Debian folks were in agreement with the goal.)

P.S. Why RHEL hasn't picked up all the work Debian/Ubuntu has done for them? The usual - NIH - I suspect.

Ever wondered what for the first super-computers were used?

Weather models.

Who are one of the longest-term buyers of the supercomputers?

National weather agencies.

Weather predictions are important (if not crucial) part of the modern agriculture. Without the modern agriculture, the large cities and metropolis wouldn't be able to exist.

The accuracy of the weather models is judged not simply over days or weeks. They are run continuously over years if not decades. Their accuracy is judged over very very long period of time.

The climate change added complexity to it, since the weather models right now are in flux and are not able predict the weather as good as before. IIRC over the past years, a couple dozen new models have been developed which account for the climate change, but they are still being evaluated.

I heard that modern weather models have accuracy above 80%.

Good enough, IMO.

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??