Forgot your password?
typodupeerror

Comment: Google is the source of the problem (Score 1) 383

Earlier this year, Google laid its vision to reduce fragmentation by forcing OEMs to ship new devices with more recent version of Android.

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.

Comment: Re:Disabled (Score 1) 383

Yeah, so they can re-enable them later when you're not looking...

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.

Comment: Re:Android version req - long time coming (Score 1) 383

The apps I listed above are what most people expect on their device and certainly not crapware.

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.

Comment: Re:Already mitigated on Debian, Ubuntu, RHEL, Fedo (Score 1) 322

by ThePhilips (#48021045) Attached to: Bash To Require Further Patching, As More Shellshock Holes Found

Unless your CGI script happens to run zgrep or any of the other things that force bash use for no obvious reason.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762915, apparently just fixed.

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.

Comment: Re:~/.cshrc (Score 0) 208

by ThePhilips (#48009111) Attached to: Apple Yet To Push Patch For "Shellshock" Bug

Rename /bin/bash to /bin/bash.bak then create a link [cyberciti.biz] from /bin/dash to /bin/bash ..

And get ready for a whole lot of scripts failing.

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.

Comment: Re:Commands lines (Score 1) 248

by ThePhilips (#47998371) Attached to: GNOME 3.14 Released

I disagree... I'm not a huge Unity fan, but the search tool is very simple and generic way to find ANYTHING that's installed very simply, then you can pin it to the sidebar or put a link on your desktop if it's something you use a lot.

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.))

Comment: Re:Pixels (Score 1) 277

by ThePhilips (#47995241) Attached to: Phablet Reviews: Before and After the iPhone 6

In 2012, the Note and S3 had the same number of pixels. The iPhone 6 also has the same now as those two did then. In contrast, the iPhone 6 Plus has full HD 1920x1080 resolution.You actually get something for the larger physical size!

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!)

The 2012 Note was pointless.

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.

Comment: BSD (Score 3, Informative) 221

by ThePhilips (#47972709) Attached to: Outlining Thin Linux

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.

Comment: Re:Err... (Score 3, Interesting) 468

by ThePhilips (#47959451) Attached to: Fork of Systemd Leads To Lightweight Uselessd

But the kernel is monolithic, [...]

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.

systemd can monitor dæmons (only if they use the systemd watchdog facilities) and automatically restart them if they stop talking.

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.

Comment: Re:Err... (Score 5, Interesting) 468

by ThePhilips (#47959073) Attached to: Fork of Systemd Leads To Lightweight Uselessd

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.

Never test for an error condition you don't know how to handle. -- Steinbach

Working...