5 ms·

It's not always about the complexity of the solution. This is a great example of something annoying a lot of people here can identify with (myself included). I'

It's not always about the complexity of the solution. This is a great example of something annoying a lot of people here can identify with (myself included). I'd say this annoys a lot of people whose job it is to automate things, and this is the first proposed solution I see. Who cares it's a hacked together small program with if statements? It's not any less interesting than a proposal for a new standard in a 50 page PDF document to me.

therein 8y ago
(1) There are many flags to these commands that you will need to know on a per platform basis anyway. (2) Package names aren't always identical across platforms, at least not enough that you can rely on that. It is a low-cost attempt to solve a problem that in my opinion doesn't really exist and it doesn't even do a great job doing that due to the points above. For instance if you want to use pacman without knowing what -Ss stands for, at the slightest conflict, you'll be going back to using pacman without this wrapper. Perhaps people who need to have package managers abstracted away could be a good target for Docker. Maybe a web UI to dynamically bake a docker image with required packages.
- Aeolun 8y ago
  Don’t let perfect be the enemy of good (or bad, in this case). The fact that everything is different makes it a problem worth solving. Docker just abstracts the problem.
- askmike 8y ago
  Yes, abstractions do leak sometimes. I'm not saying I'm running this on all my production servers right now. For me the problem this tool solves is real (although not big), and I'm interested to see what other people think of both the problem and the solution. That's why I upvoted it, I guess other people had similar ideas.
  - nsomaru 8y ago
    What problem does it solve? Just use the package manager provided by the platform...right? Especially given the problem of package naming, it’s different even between Debian and Ubuntu :/
    - askmike 8y ago
      > Especially given the problem of package naming I haven't encountered this for all the standard applications I end up installing on my machines (things like htop, nginx, etc). > What problem does it solve? It solves the problem of me having to think about what OS I am on before I can install something (and if it's something I don't use a lot I might need to google the package manager syntax).
      - mclehman 8y ago
        How common is this? I use 2.5 different package managers day-to-day (homebrew/pacman/pakku) and a few more occasionally (portage/pkg/apt). I can't really think of a situation where I had to really think about what I was running to install something. I'd imagine a scenario in which you're often dropped into a box you don't usually interact with would typically also come with a more homogenous environment as far as operating systems go.
        askmike 8y ago
        It's not very common for me. I maintain a few boxes at different hosting providers for different projects that have been running for a long time. Sometimes I ssh in and update everything. Right now I have to google everytime I ssh into a centos box because I keep forgetting the yum syntax.
- qznc 8y ago
  I started something like this. Your second reason is why I stopped. The additional layer creates more problems than it solves.
- franga2000 8y ago
  I don't see this as a replacement for knowing package manager syntax. As someone who works with many machines running many different distros at the same time, I appreciate being able to open a terminal and run "install htop", without using even a single brain cell to think about which distro it's running and instead focus on doing whatever I need to do (which is often time-sensitive). When I need to do package management, I'll use a package manager. But for when I need to quickly install one tool to get something done, my giant shell function "ji" (stands for "just install") has saved me precious time. In its current state, this project is equivalent to a bunch of command alises, but that doesn't mean it can't be useful.
aequitas 8y ago
But it often turns out there is more complexity in the problem that is ignored/forgotten in the solution. So the solution seems simple and complete at first but can never gain adoption beyond all but the most basic use cases, so it ends up useless as a standard.
xaduha 8y ago
> I'd say this annoys a lot of people whose job it is to automate things, and this is the first proposed solution I see. If your job is to automate things and you're not using containers, then you're doing it wrong.
- franga2000 8y ago
  You sound like someone who hasn't had Docker shit itself and lose track of a container's data which you then had to find and manually migrate...
  - xaduha 8y ago
    No, that didn't happen to me, because I know what I'm doing and how Docker works. I used it since AUFS days.

therein 8y ago

(1) There are many flags to these commands that you will need to know on a per platform basis anyway. (2) Package names aren't always identical across platforms, at least not enough that you can rely on that. It is a low-cost attempt to solve a problem that in my opinion doesn't really exist and it doesn't even do a great job doing that due to the points above. For instance if you want to use pacman without knowing what -Ss stands for, at the slightest conflict, you'll be going back to using pacman without this wrapper. Perhaps people who need to have package managers abstracted away could be a good target for Docker. Maybe a web UI to dynamically bake a docker image with required packages.

Aeolun 8y ago
Don’t let perfect be the enemy of good (or bad, in this case). The fact that everything is different makes it a problem worth solving. Docker just abstracts the problem.
askmike 8y ago
Yes, abstractions do leak sometimes. I'm not saying I'm running this on all my production servers right now. For me the problem this tool solves is real (although not big), and I'm interested to see what other people think of both the problem and the solution. That's why I upvoted it, I guess other people had similar ideas.
- nsomaru 8y ago
  What problem does it solve? Just use the package manager provided by the platform...right? Especially given the problem of package naming, it’s different even between Debian and Ubuntu :/
  - askmike 8y ago
    > Especially given the problem of package naming I haven't encountered this for all the standard applications I end up installing on my machines (things like htop, nginx, etc). > What problem does it solve? It solves the problem of me having to think about what OS I am on before I can install something (and if it's something I don't use a lot I might need to google the package manager syntax).
    - mclehman 8y ago
      How common is this? I use 2.5 different package managers day-to-day (homebrew/pacman/pakku) and a few more occasionally (portage/pkg/apt). I can't really think of a situation where I had to really think about what I was running to install something. I'd imagine a scenario in which you're often dropped into a box you don't usually interact with would typically also come with a more homogenous environment as far as operating systems go.
      - askmike 8y ago
        It's not very common for me. I maintain a few boxes at different hosting providers for different projects that have been running for a long time. Sometimes I ssh in and update everything. Right now I have to google everytime I ssh into a centos box because I keep forgetting the yum syntax.
qznc 8y ago
I started something like this. Your second reason is why I stopped. The additional layer creates more problems than it solves.
franga2000 8y ago
I don't see this as a replacement for knowing package manager syntax. As someone who works with many machines running many different distros at the same time, I appreciate being able to open a terminal and run "install htop", without using even a single brain cell to think about which distro it's running and instead focus on doing whatever I need to do (which is often time-sensitive). When I need to do package management, I'll use a package manager. But for when I need to quickly install one tool to get something done, my giant shell function "ji" (stands for "just install") has saved me precious time. In its current state, this project is equivalent to a bunch of command alises, but that doesn't mean it can't be useful.

aequitas 8y ago

But it often turns out there is more complexity in the problem that is ignored/forgotten in the solution. So the solution seems simple and complete at first but can never gain adoption beyond all but the most basic use cases, so it ends up useless as a standard.

xaduha 8y ago

> I'd say this annoys a lot of people whose job it is to automate things, and this is the first proposed solution I see. If your job is to automate things and you're not using containers, then you're doing it wrong.

franga2000 8y ago
You sound like someone who hasn't had Docker shit itself and lose track of a container's data which you then had to find and manually migrate...
- xaduha 8y ago
  No, that didn't happen to me, because I know what I'm doing and how Docker works. I used it since AUFS days.