what is your favorite linux distro ?

[tarfeef101]

48 minutes ago, igormp said:

Real devs static link their application and only leave that single binary in that container without any other userland bloat /s

Unless you are trying to deploy it in any sort of professional setting

[igormp]

1 hour ago, tarfeef101 said:

Unless you are trying to deploy it in any sort of professional setting

Joking aside, I've actually deployed many services without any other userland stuff. Doing so with Go/C/C++ applications is a breeze (busybox is a nice example). Good luck trying to do so with other interpreted stuff tho

[tarfeef101]

47 minutes ago, igormp said:

Joking aside, I've actually deployed many services without any other userland stuff. Doing so with Go/C/C++ applications is a breeze (busybox is a nice example). Good luck trying to do so with other interpreted stuff tho

Yeah in my world docker is everything, so that kinda frames how I approach everything. Which does make stuff simple, at least

[maplepants]

On 10/10/2020 at 7:14 AM, tarfeef101 said:

You're missing the point. If your application is lightweight, alpine will allow you to drastically reduce your image size, which is usually something people try to do. One typically reserves heavier distros like debian for when they're the "last resort" due to an incompatibility like I mentioned with musl c.

Image size reduction can be *a* goal of container building, but it's not always the most important goal. I just pulled the current stable versions of debian, ubuntu, alpine and centos to compare.

 

🖥  ~
❯ docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
ubuntu              20.04               9140108b62dc        2 weeks ago         72.9MB
debian              buster              f6dcff9b59af        4 weeks ago         114MB
centos              8                   0d120b6ccaa8        2 months ago        215MB
alpine              3                   a24bb4013296        4 months ago        5.57MB

Alpine is significantly smaller, but as soon as you have one debian/ubuntu/centos container that size difference stops mattering. And if you use a managed service like AKS or EKS then it doesn't matter either. So where I work we do care about container size a little, but we care much more about building a container which is going to be easy for the next guy, or you 6 months from now, to maintain.

[tarfeef101]

3 hours ago, maplepants said:

Image size reduction can be *a* goal of container building, but it's not always the most important goal. I just pulled the current stable versions of debian, ubuntu, alpine and centos to compare.

 

🖥  ~
❯ docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
ubuntu              20.04               9140108b62dc        2 weeks ago         72.9MB
debian              buster              f6dcff9b59af        4 weeks ago         114MB
centos              8                   0d120b6ccaa8        2 months ago        215MB
alpine              3                   a24bb4013296        4 months ago        5.57MB

Alpine is significantly smaller, but as soon as you have one debian/ubuntu/centos container that size difference stops mattering. And if you use a managed service like AKS or EKS then it doesn't matter either. So where I work we do care about container size a little, but we care much more about building a container which is going to be easy for the next guy, or you 6 months from now, to maintain.

Eh that's a pretty broad and poorly represented point.  

 

1) There are slimmer versions of those "big distro" images available, for example debian I know had a slim tag available which is what I use when I need a heavier distro. 

2) Managed services in now way make size irrelevant. Far from it. There are many use cases where that still matters:

- lower image size means less storage costs

- lower image size means CI builds and tests take much less time. In most companies where a single dev may trigger dozens of these pipelines a day, that can mean huge time and resource savings, and much faster prototyping.

 

If you have good DevOps people and learn how to comment, maintaining well-slimmed down images isn't hard. Just comment what you're doing. 

 

There's something you didn't touch on which is relevant to this topic which is effective usage of layers to allow for using layer caching to reduce build times. You so often trade off some size to have layers for your most often changed parts of an image separated out in a hierarchy at the end of a dockerfile to avoid rebuilding layer components which rarely change. But even there, there is a balance to be struck. 

 

By paying attention to these factors I have saved companies double digit percents on their cloud bills, massively reduced the time of pipeline jobs, etc. Image size and composition absolutely matter.

[throttlemeister]

I prefer Debian for my servers, as I prefer apt for package management and Debian is just the most stable and reliable. I vehemently dislike the fact systemd gets stuffed in everywhere these days, but what do you do. Ubuntu is just too bloated to be taken seriously and the rest is just marginal at best. I use just about everything though: Gentoo, Arch, CentOS, Slackware, derivatives of bigger distros. They all have pro's and cons. But Debian will always be my goto distro. Easy to setup and maintain, no fuzz, no frills just run and keep running.

 

For desktop, anything with standard KDE Plasma. Yes, you can install KDE or any desktop on any Linux yourself. I do not want that. I want to install and go. Not that I generally run Linux on my desktop. I don't run OS's to play with the OS, I run an OS to use software on top of that OS and the software I need/want runs on Windows so Linux desktop is always just going to be playground stuff, nothing serious.

[maplepants]

23 hours ago, tarfeef101 said:

Eh that's a pretty broad and poorly represented point.  

 

1) There are slimmer versions of those "big distro" images available, for example debian I know had a slim tag available which is what I use when I need a heavier distro. 

2) Managed services in now way make size irrelevant. Far from it. There are many use cases where that still matters:

- lower image size means less storage costs

- lower image size means CI builds and tests take much less time. In most companies where a single dev may trigger dozens of these pipelines a day, that can mean huge time and resource savings, and much faster prototyping.

 

If you have good DevOps people and learn how to comment, maintaining well-slimmed down images isn't hard. Just comment what you're doing. 

 

There's something you didn't touch on which is relevant to this topic which is effective usage of layers to allow for using layer caching to reduce build times. You so often trade off some size to have layers for your most often changed parts of an image separated out in a hierarchy at the end of a dockerfile to avoid rebuilding layer components which rarely change. But even there, there is a balance to be struck. 

 

By paying attention to these factors I have saved companies double digit percents on their cloud bills, massively reduced the time of pipeline jobs, etc. Image size and composition absolutely matter.

I think we're basically agreeing here. The part of your first post that I disagree with was:

Quote

One typically reserves heavier distros like debian for when they're the "last resort"

You bring up the excellent points of layer caching, and debian's slim tag. So I think we're basically on the same page that base images like debian are not some kind of last resort and that alpine isn't really the only way to save on image sizes.

 

Inefficient CI pipelines, and cloud storage are definitely areas which can run up the bills, but in my company none of the cloud costs come anywhere close to the largest section of our bills; man days. The extra time you would need to pay highly skilled developers to build or maintain some application in only alpine or busybox containers is almost never worth the potential Azure or AWS savings for us. That's not to say that we're careless with images or anything like that, just that maintainability and ease are much more important to our cost controls than image size.

 

This kind of thing is really project dependent though. If you're building some applet which you hope to treat basically as a fire and forget service that requires nearly no new features and little maintenance your considerations are different than for high maintenance software with weekly feature releases.

[tarfeef101]

4 hours ago, maplepants said:

I think we're basically agreeing here. The part of your first post that I disagree with was:

You bring up the excellent points of layer caching, and debian's slim tag. So I think we're basically on the same page that base images like debian are not some kind of last resort and that alpine isn't really the only way to save on image sizes.

 

Inefficient CI pipelines, and cloud storage are definitely areas which can run up the bills, but in my company none of the cloud costs come anywhere close to the largest section of our bills; man days. The extra time you would need to pay highly skilled developers to build or maintain some application in only alpine or busybox containers is almost never worth the potential Azure or AWS savings for us. That's not to say that we're careless with images or anything like that, just that maintainability and ease are much more important to our cost controls than image size.

 

This kind of thing is really project dependent though. If you're building some applet which you hope to treat basically as a fire and forget service that requires nearly no new features and little maintenance your considerations are different than for high maintenance software with weekly feature releases.

I brought up the slim versions of those images just as a cool fact, almost, and to provide an example of how Centos/debian/Ubuntu aren't all the same. Even debian slim is orders of magnitude larger than alpine. 

 

About man-hours vs cloud costs, I'm not sure why you are having issues there. Sure, there's always niche cases where a development process is different from the norm and you could be that. 

 

But generally speaking most devs don't interact with the container itself. They just work on the app code and run their tests, and just assume it works. The few devops people and a couple with wider knowledge on the dev team typically are the ones who interact with and modify the container environment. And I do expect a DevOps engineer to be able to handle using an alpine container over a bigger and more common distro, that's part of your job IMO. 

[Amazeryogo]

My favourite distro is Pop!_OS

[maplepants]

On 10/12/2020 at 5:38 PM, tarfeef101 said:

But generally speaking most devs don't interact with the container itself. They just work on the app code and run their tests, and just assume it works.

I think this line right here shows the difference in my workplace and yours. We deal with some pretty specialized stuff and so a lot of work needs to be done in the container setup. In our workflow we don't actually use FROM alpine:3 or anything like that, usually the containers are based off of a standard dependent on your project, so FROM project:lts or FROM project:latest depending on the feature you're working on.

 

A few friends of mine from the pub work in more general IT consulting though and even for them man days are always a bigger cost that cloud storage for container images. That said I'm in Germany and so maybe that's what makes the difference.

[igormp]

On 10/12/2020 at 2:38 PM, tarfeef101 said:

But generally speaking most devs don't interact with the container itself. They just work on the app code and run their tests, and just assume it works. The few devops people and a couple with wider knowledge on the dev team typically are the ones who interact with and modify the container environment.

Hmmm, that sounds really backwards to me. The whole DevOps idea is to bring the devs and ops people close together, and not be a new fancy name for your regular sysadmin.

 

Where I work we're both responsible for our code and its deploy, CI/CD setup, tests and whatnot.

[tarfeef101]

10 hours ago, igormp said:

Hmmm, that sounds really backwards to me. The whole DevOps idea is to bring the devs and ops people close together, and not be a new fancy name for your regular sysadmin.

 

Where I work we're both responsible for our code and its deploy, CI/CD setup, tests and whatnot.

Idk, I've worked in a good few places over north America, and there's always been a pretty hard line between the DevOps team and the normal dev team (and QA, for that matter). Most devs I talk to have no desire to get into the weeds of CI/CD, and want to just be able to run a script someone made for them or just push their code and let a pipeline do all the work to build, test, and deploy. 

[YellowJersey]

Mint. I love not having to mess around with the terminal much.

[Virixiss]

I love most debian-based distros. I currently daily drive Ubuntu 20.04, but Mint was my first real intro to the kernel. (Mint 13 or 15, I can't remember.) Puppy Linux also sticks out as a very useful tool to have on a thumb drive for stuff like data recovery or running ancient hardware.

[DarkEnergy]

Manjaro running KDE. I had an old laptop I was messing with and Ubuntu's Unity interface was sluggish. Gnome was also sluggish, especially loading image thumbnails and not great for multitasking. Pop!_OS had some weird quirk, MXlinux didn't do well with dual booting and elementry feels very unproductive. Manjaro with KDE felt snappy and looked great.

[MigasTigas]

Despite liking Ubuntu, tinycore is also a fun little distro that i like to have some fun

[Dat Guy]

Gentoo
Void

Slackware

 

none are listed

[mahyar]

16 minutes ago, Dat Guy said:

Gentoo
Void

Slackware

 

none are listed

well they are not that popular but gentoo can be added

[mahyar]

18 minutes ago, Dat Guy said:

Gentoo
Void

Slackware

 

none are listed

 

Just now, mahyar said:

well they are not that popular but gentoo can be added

gentoo added

[Dat Guy]

1 minute ago, mahyar said:

well they are not that popular but gentoo can be added

Distrowatch stats as of now:

 

- Void: 42

- Gentoo: 45

- Slackware: 35

 

Anyway... thank you.

[mahyar]

8 minutes ago, Dat Guy said:

Distrowatch stats as of now:

 

- Void: 42

- Gentoo: 45

- Slackware: 35

 

Anyway... thank you.

gentoo is better known tbh i've never heard of other two 

[Dat Guy]

Slackware is the oldest surviving Linux distribution, first released before Debian was a thing.

[mahyar]

Just now, Dat Guy said:

Slackware is the oldest surviving Linux distribution, first released before Debian was a thing.

added

[themrsbusta]

Ubuntu, but in the Kubuntu side...

(Actually my favorite distro is Android )

[mahyar]

2 minutes ago, themrsbusta said:

Ubuntu, but in the Kubuntu side...

(Actually my favorite distro is Android )

well android has a lot of changes to become android so technically it caant be called a linux distro