4 ms·

I think this is an arrogant attitude. You may think you would never be stupid enough to force /bin/sh to /bin/bash, but other people who are brand new to Linux

I think this is an arrogant attitude. You may think you would never be stupid enough to force /bin/sh to /bin/bash, but other people who are brand new to Linux may not know that random things on the system behave differently depending on what /bin/sh points to. That's if you even know what the hell /bin/sh is, because maybe you just read some installer instructions that said that this file has to point to this other file. People make mistakes. Not everyone knows everything, especially when they are new to something. I'm sure the package author is sufficiently shamed now.

lucideer 8y ago
I think you're missing my point. This is not about not knowing—I may well not have known not to force /bin/sh to /bin/bash when I was starting out—it's about not blindly going about doing things you don't know about. That is arrogance: to redirect a user's shell binary when you're a novice programmer without much knowledge about what implications that redirection will have.
- peterwwillis 8y ago
  If they didn't understand the implications (read: unintended consequences) then they couldn't know this could cause harm. What were they supposed to do, research shells for 2 weeks? Become expert Linux packagers in two sprints? Just to make an R installer? And by the way, it isn't even that wrong. /bin/sh is the POSIX Shell Scripting standard and points to an interpreter thereof, of which /bin/bash is one. If a user pointed their system's /bin/sh at a non-POSIX-compatible shell, that's just a broken system. And scripts expecting /bin/sh to use non-POSIX semantics are broken scripts. The only problem here is you don't know if the system has bash, but any sane person should assume bash exists on a Linux system.
  - admax88q 8y ago
    > What were they supposed to do, research shells for 2 weeks? Become expert Linux packagers in two sprints? Just to make an R installer? Yes? Or don't ship an R installer if you don't know what you're doing. I don't understand why they're given a pass for shipping a broken installer just because they might be amateurs who don't know what they're doing. At the end of the day this is a giant well known software corporation that is shipping laughably broken software. If you don't know what you're doing, then you shouldn't be shipping it. I don't care if its an application, an operating system, or an installer.
    - peterwwillis 8y ago
      You do realize that Canonical [Ubuntu] has bricked and destroyed Linux systems with their installers and software updates, right? Here's Ubuntu 16.04 bricking systems with patches: https://www.bleepingcomputer.com/news/software/meltdown-and-spectre-patches-causing-boot-issues-for-ubuntu-16-04-computers/ https://www.bleepingcomputer.com/news/software/meltdown-and-... Debian's updates causing PowerPC platforms to see random crashes and data corruption: https://news.softpedia.com/news/latest-debian-stretch-kernel-update-fixes-data-corruption-bug-on-powerpc-systems-520069.shtml https://news.softpedia.com/news/latest-debian-stretch-kernel... Here's Ubuntu 17.10 bricking Lenovo, Toshiba and Acer laptops: https://itsfoss.com/ubuntu-17-10-bios-bug/ https://itsfoss.com/ubuntu-17-10-bios-bug/ There are many open source vendors which ship shitty installers. In fact, virtually every software vendor I have ever used has had a shitty installer, if they even provide one. I don't think your idealistic position on software release reflects reality.
  - JdeBP 8y ago
    > research shells for 2 weeks? This has been a known bug since November 2016, which was supposed to be fixed for version 3.3.3. * https://news.ycombinator.com/item?id=17293450 https://news.ycombinator.com/item?id=17293450
    - peterwwillis 8y ago
      In light of that information, they may be incompetent assholes. But the bug doesn't do enough to inform the devs of the extent of the problem, the severity of the consequences, or a range of solutions. Still, they obviously should have fixed it by now. I'm still not blaming all of Microsoft for this one dev team's screw-up, though.
grumpydba 8y ago
Then it is their managers' fault, what are they doing here packaging for debian ??
scbrg 8y ago
Honest question: Would it be possible for a software company, especially one of Microsoft's magnitude, to produce a bug that would be "not ok" in your book. Is there any kind of technical problem a software package could cause that would make you react in a way that wasn't "oh, that's ok, everybody makes mistakes." I mean, breaking other installed software and potentially making the system unbootable is obviously not severe enough. What would be?
- ksk 8y ago
  Its probably that people think its unfair to single out Microsoft when other developers doing the exact same thing and worse. Sure MS is a juicier target and you get more publicity, and they do make it easy to poke fun at themselves. Titles like "Linux foundation's failed attempt at releasing Linux" for every single Linux security bug would probably not work so well. On a design note, maybe its time to not require full root privileges to install/copy some files. I think Windows did the right thing, and now even the admin user cannot delete critical OS components.
- peterwwillis 8y ago
  No. edit Except for critical systems like medical devices, power plants, car ECUs, etc. I expect due diligence for those, and not doing so would make me upset. A technical problem is a technical problem. I'm not going to get mad at someone for unintentionally introducing a technical problem. People make mistakes. Once we learn from those mistakes, we can avoid making them in the future. We may still make the same mistake again, though, because we're humans! Getting angry at people for making mistakes is emotional garbage and not productive. As I mentioned in another comment, even Linux distributions themselves will crash systems, cause data corruption, and actually brick hardware with their updates. If the distro itself can cause these problems, surely I can forgive a random dev from a completely different system for making a crappy installer for an obscure programming language. If, OTOH, you ship an update that it is demonstrable that you were fully aware would brick a system, then I will get out my pitchfork and torch.
icebraining 8y ago
You may think you would never be stupid enough to force /bin/sh to /bin/bash, but other people who are brand new to Linux may not know that random things on the system behave differently depending on what /bin/sh points to. That makes no sense, because the whole point of the script is to replace what /bin/sh points to, because their application behaves differently depending on what it points to. And I agree we shouldn't castigate the developer, but this wasn't published by a developer, but by a company. It's supposed to have a process to prevent human mistakes like these from getting out to the clients.
ttmb 8y ago
They clearly do know that random things behave differently depending on /bin/sh - because their script changes it to avoid their product behaving differently.
codedokode 8y ago
I think it is a result of Docker-style thinking where you can do anything because you are just preparing an image for a single application. So removing shell won't break anything.

lucideer 8y ago

I think you're missing my point. This is not about not knowing—I may well not have known not to force /bin/sh to /bin/bash when I was starting out—it's about not blindly going about doing things you don't know about. That is arrogance: to redirect a user's shell binary when you're a novice programmer without much knowledge about what implications that redirection will have.

peterwwillis 8y ago
If they didn't understand the implications (read: unintended consequences) then they couldn't know this could cause harm. What were they supposed to do, research shells for 2 weeks? Become expert Linux packagers in two sprints? Just to make an R installer? And by the way, it isn't even that wrong. /bin/sh is the POSIX Shell Scripting standard and points to an interpreter thereof, of which /bin/bash is one. If a user pointed their system's /bin/sh at a non-POSIX-compatible shell, that's just a broken system. And scripts expecting /bin/sh to use non-POSIX semantics are broken scripts. The only problem here is you don't know if the system has bash, but any sane person should assume bash exists on a Linux system.
- admax88q 8y ago
  > What were they supposed to do, research shells for 2 weeks? Become expert Linux packagers in two sprints? Just to make an R installer? Yes? Or don't ship an R installer if you don't know what you're doing. I don't understand why they're given a pass for shipping a broken installer just because they might be amateurs who don't know what they're doing. At the end of the day this is a giant well known software corporation that is shipping laughably broken software. If you don't know what you're doing, then you shouldn't be shipping it. I don't care if its an application, an operating system, or an installer.
  - peterwwillis 8y ago
    You do realize that Canonical [Ubuntu] has bricked and destroyed Linux systems with their installers and software updates, right? Here's Ubuntu 16.04 bricking systems with patches: https://www.bleepingcomputer.com/news/software/meltdown-and-spectre-patches-causing-boot-issues-for-ubuntu-16-04-computers/ https://www.bleepingcomputer.com/news/software/meltdown-and-... Debian's updates causing PowerPC platforms to see random crashes and data corruption: https://news.softpedia.com/news/latest-debian-stretch-kernel-update-fixes-data-corruption-bug-on-powerpc-systems-520069.shtml https://news.softpedia.com/news/latest-debian-stretch-kernel... Here's Ubuntu 17.10 bricking Lenovo, Toshiba and Acer laptops: https://itsfoss.com/ubuntu-17-10-bios-bug/ https://itsfoss.com/ubuntu-17-10-bios-bug/ There are many open source vendors which ship shitty installers. In fact, virtually every software vendor I have ever used has had a shitty installer, if they even provide one. I don't think your idealistic position on software release reflects reality.
- JdeBP 8y ago
  > research shells for 2 weeks? This has been a known bug since November 2016, which was supposed to be fixed for version 3.3.3. * https://news.ycombinator.com/item?id=17293450 https://news.ycombinator.com/item?id=17293450
  - peterwwillis 8y ago
    In light of that information, they may be incompetent assholes. But the bug doesn't do enough to inform the devs of the extent of the problem, the severity of the consequences, or a range of solutions. Still, they obviously should have fixed it by now. I'm still not blaming all of Microsoft for this one dev team's screw-up, though.

grumpydba 8y ago

Then it is their managers' fault, what are they doing here packaging for debian ??

scbrg 8y ago

Honest question: Would it be possible for a software company, especially one of Microsoft's magnitude, to produce a bug that would be "not ok" in your book. Is there any kind of technical problem a software package could cause that would make you react in a way that wasn't "oh, that's ok, everybody makes mistakes." I mean, breaking other installed software and potentially making the system unbootable is obviously not severe enough. What would be?

ksk 8y ago
Its probably that people think its unfair to single out Microsoft when other developers doing the exact same thing and worse. Sure MS is a juicier target and you get more publicity, and they do make it easy to poke fun at themselves. Titles like "Linux foundation's failed attempt at releasing Linux" for every single Linux security bug would probably not work so well. On a design note, maybe its time to not require full root privileges to install/copy some files. I think Windows did the right thing, and now even the admin user cannot delete critical OS components.
peterwwillis 8y ago
No. edit Except for critical systems like medical devices, power plants, car ECUs, etc. I expect due diligence for those, and not doing so would make me upset. A technical problem is a technical problem. I'm not going to get mad at someone for unintentionally introducing a technical problem. People make mistakes. Once we learn from those mistakes, we can avoid making them in the future. We may still make the same mistake again, though, because we're humans! Getting angry at people for making mistakes is emotional garbage and not productive. As I mentioned in another comment, even Linux distributions themselves will crash systems, cause data corruption, and actually brick hardware with their updates. If the distro itself can cause these problems, surely I can forgive a random dev from a completely different system for making a crappy installer for an obscure programming language. If, OTOH, you ship an update that it is demonstrable that you were fully aware would brick a system, then I will get out my pitchfork and torch.

icebraining 8y ago

You may think you would never be stupid enough to force /bin/sh to /bin/bash, but other people who are brand new to Linux may not know that random things on the system behave differently depending on what /bin/sh points to. That makes no sense, because the whole point of the script is to replace what /bin/sh points to, because their application behaves differently depending on what it points to. And I agree we shouldn't castigate the developer, but this wasn't published by a developer, but by a company. It's supposed to have a process to prevent human mistakes like these from getting out to the clients.

ttmb 8y ago

They clearly do know that random things behave differently depending on /bin/sh - because their script changes it to avoid their product behaving differently.

codedokode 8y ago

I think it is a result of Docker-style thinking where you can do anything because you are just preparing an image for a single application. So removing shell won't break anything.