[m463]

Reminds me of what a friend once told me: The desktop folks want the Latest Software immediately, and the server folks want nothing to change, ever.

If you've ever developed for linux, you might come down on the side of the server folks. You will find that there's a web of dependencies everywhere that you will have to navigate. And the more higher-functioning what you are doing, the more likely this will become more and more complicated.

If people depend on an app, develop for something like Ubuntu 16.04 or Ubuntu 18.04. It is (more) likely that people will be able to use it without trouble for quite some time. It is very stable and it is not likely updates will affect the folks using your software. They will be able to use the software for years.

strangely, I wonder if arch linux might be the counterpoint to all this. You might just do continuous maintenance all the time instead of one-giant-upheaval-update every few years.

[Foxboron]

>strangely, I wonder if arch linux might be the counterpoint to all this. You might just do continuous maintenance all the time instead of one-giant-upheaval-update every few years.

Evidently, one of the people mentioned in the calibre blogpost helping the python3 migration is an Arch Linux contributor :)

[doubleunplussed]

Eli Schwartz is an absolute treasure. Because Arch strongly prefers to ship unmodified upstream projects, Eli pops up all over the place fixing bugs upstream.

I've been using his Arch repo shipping Calibre with Python 3 for I think over a year. My system is updating to Calibre 5 from the main repos as we speak, so I guess I'll remove the custom repo now.

Now I'm only waiting for the Kodi 19 release before Python 2 will be gone from my system forever...

[Foxboron]

>Eli Schwartz is an absolute treasure. Because Arch strongly prefers to ship unmodified upstream projects, Eli pops up all over the place fixing bugs upstream.

Not to diminish the work of Eli, but several Arch package maintainers end up bugfixing upstream projects to keep sources unpatched. Personally done upstream contributions to several upstreams I maintain in the distribution :)

[doubleunplussed]

Of course! I happen to see Eli all over the place, but many others as well.

(I'm not an Arch TU or dev, but I also contribute upstream fixes for AUR packages I maintain)

[AlphaSite]

Docker honestly made the world a little easier. You’re responsible for everything above the kernel.

[m463]

I love docker, but I really wish they would change a couple things.

I wish there was a way to say:

  LAYER foo
  RUN unpack_some_large_package
  RUN build it
  RUN install it
  RUN delete stuff
  LAYER bar

because the normal way of using docker makes really really large images.

and the efficient use of docker is unreadable and hard to maintain:

  RUN unpack_some_large_package && build it && install it && delete stuff

thing is - if you do it this way you can hack gigabytes off your image sizes

This is lots harder nowadays over vpn.

I know there's docker squash, but that is a hack on many levels.

Then there's the firewall thing

and last, I'd like to have my own private repository - where docker wont' and can't pull from other machines.

[searchableguy]

Is the current multi stage build process not sufficient for you?

https://docs.docker.com/develop/develop-images/multistage-bu...

[m463]

thank you! none of the docker files I've seen used this but it has worked since 17.x

[stekern]

Can't you use multi-stage builds to achieve this?

[m463]

thank you, i've never seen this :)

[kubav]

It is easier for developer but risky for end user. Docker runs as root and you have to trust application developer to use latest security patches for all dependencies.

[zaarn]

They run as root per default.

Simply using the "USER <uid/uname>" directory means you run as non-root user with a specified UID. Kubernetes recommends doing that as a baseline security measure. You can also drop caps from a container so even if you are root inside, you can't do a lot of things root can.