Also you do not name any particular reasons why not to change it.
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.
Just beeing aggressive and name calling does not bring us further.
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.
they would eventually lose customers if systemd causes all the machines to fail regularly - so they would be shooting themselves in the foot. now do the arithmetic if they lose customers
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".
Because/bin/sh almost always is/bin/bash on Linux [...]
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.
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.
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.
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.
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.
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.))
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.
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.
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.
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.
My sid/unstable doesn't have it yet, but I'm exploring options for leaving Debian since its developers for the most part seem to be pushing systemd.
Switch to what? I want relatively up-to-date Debian based system with relatively good KDE integration.
Anyway, the way I'm using Debian at home, I do not really care what init system it has. In office, systemd and the rest of the RedHat/GNOME aberrations are simply not applicable and not employed.
Slashdot Mirror
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.
Also you do not name any particular reasons why not to change it.
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.
Just beeing aggressive and name calling does not bring us further.
Ignorance is bliss?
It is not the first time systemd tries to break stuff they have no frigging idea about.
like it or suck it users!
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
they would eventually lose customers if systemd causes all the machines to fail regularly - so they would be shooting themselves in the foot. now do the arithmetic if they lose customers
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".
Because /bin/sh almost always is /bin/bash on Linux [...]
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.
Models will NEVER be accurate enough for any real predictions, causes or illustrations.
I heard that modern weather models have accuracy above 80%.
Good enough, IMO.
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.
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.
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.
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.
True, but if you are symlinking /bin/bash to dash, then you will break scripts that explicitly asked for bash.
But that is so idiotic.
Why would anybody in their sane mind do it??
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.
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?
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.))
[...] I've found even the base 6 is a too big.
[...] but not sure I want another large phone [...]
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.
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.
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.
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.
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.
My sid/unstable doesn't have it yet, but I'm exploring options for leaving Debian since its developers for the most part seem to be pushing systemd.
Switch to what? I want relatively up-to-date Debian based system with relatively good KDE integration.
Anyway, the way I'm using Debian at home, I do not really care what init system it has. In office, systemd and the rest of the RedHat/GNOME aberrations are simply not applicable and not employed.
At least they have switch the default desktop to the XFCE.