Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Leaderless Debian

lwn.net

Post reply on HN
Print view View original

111–119 of 119 posts

Re: Leaderless Debian

#111

Post by zaphirplane »

geofft wrote: post #51
ilovecaching wrote: post #32

Controversial opinion warning, and I would love to hear some counterpoints outside of my thought bubble. I've never understood the appeal of Debian or Ubuntu, or I guess I don't understand why people would invest so much time in them compared to Fedora and Redhat. In actual buisness dealings Redhat has always led the way in enterprise (whole data centers), kernel development (a bunch of the maintainers work for them…

For a long while Debian and Ubuntu were the obvious choice for a free-as-in-beer (and not just free-as-in-speech) server OS. Fedora doesn't have an LTS program, and CentOS, Scientific Linux, et al. were unofficial. (CentOS is now more official so that benefit has gone away a bit.) Debian has an enterprise-compatible release cycle - a new release every 2 years give or take a few months, each one gets security updates…

Out of interest how is diversions different from the alternatives command

Re: Leaderless Debian

#112

Post by bionsystem »

lmm wrote: post #91
bionsystem wrote: post #71

Earlier quoted context omitted.

> Watching someone manage their Redhat/centos servers from OSX (or even Windows) is just painful to watch, especially if something is wrong or down (which is usually when you need an admin the most). Why ? (Genuine question, I've been doing that for years (from Windows), never had a particular issue with it, even during crises. Not that I had the choice, if I did I would probably have installed Linux.)

The subtle differences will bite you at the worst possible time. Things like a rarely-used command flag doing something different. I'm more of a developer than a sysadmin, but whenever I've had to use a different distro/OS on my development machine from what the servers were running, eventually I've hit a bug that only occurred on the servers and couldn't be reproduced on my development machine. And sure it's never i…

Oh I see, thanks for your answer. It's mostly a developper issue for you then, and it's your sysadmin job to provide you with the right tools ; but he probably won't take "just install debian everywhere" as a valid suggestion. A sysadmin just needs putty and then he'll build his infrastructure to make his life easier. He will never write or run code on his own machine, but on a machine similar to the production target. And he will rarely write code himself to begin with.

You can ask your sysadmin for a FAAS (such as jupyterhub, or anything that you like) to be deployed on machines that are iso-prod. You can also ask him to provide a proper ci-cd toolchain (start small with the minimum, git to build to test deployment to unit tests). And of course matching your dev machine with the production will be beneficial if you can't get a FAAS, but your native OS may still be windows or macos, simply you will use virtualization or docker to make it compatible.

As a sysadmin I face this problem a lot here. I work with python or R dev and we are providing them with server-side IDE (RStudio and JupyterHub), otherwise they will have something running on their windows laptop (provided by external teams, we have no control over that nor the right to change it), and expect it to run the same in production.

But as a sysadmin I don't face the problem myself, because I don't develop much, that's why I didn't get the initial comment.

Edit : just to clarify a point. Just a few months ago when I arrived, it was indeed really painful to see people write python or R code on their windows machines, and not be able to run their code on the server. Some of them even asked to have windows servers to get rid of that issue. That's the type of miscommunication that I'm talking about, because on the other side of the email, someone gave them the windows servers, not understanding/caring about their actual need.

It was obviously the wrong solution but, in desperation and with the incoming deadlines, it became the right solution. So the problem isn't CentOS vs Debian vs your laptop, it's really about consistency in the toolchain and pipelines. The exact tool doesn't even matter (as long as it works).

Re: Leaderless Debian

#113

Post by bionsystem »

craigsmansion wrote: post #97
bionsystem wrote: post #71

Earlier quoted context omitted.

> Watching someone manage their Redhat/centos servers from OSX (or even Windows) is just painful to watch, especially if something is wrong or down (which is usually when you need an admin the most). Why ? (Genuine question, I've been doing that for years (from Windows), never had a particular issue with it, even during crises. Not that I had the choice, if I did I would probably have installed Linux.)

Apart from having to hunt down things like "putty" off the Internet (Why am I installing a binary directly from the web that I'm going to use to directly type passwords in to?), and not even touching on exotic stuff like suddenly being in dire need of a serial terminal ("Wait, GNU Screen does that? I already have that installed!"), it can range from simple stuff like having "man mdadm" available right there on your l…

I'm going to play devil's advocate here, but when you download debian it's mostly a binary from the web that you're going to type passwords into.

But I totally get your other points. See my other answer above to get a partial solution. I think the main issue overall is the lack of dialogue between sysadmins and devs. I'm a sysadmin in a dev team and we don't have that issue together, because we are deploying the right tools and making it easier for everyone. But whenever we talk to the "others" sysadmin, I see a lot of frustration on both sides because they simply don't talk the same language.

Those "others" sysadmins provide the whole underlying infrastructure, and it's "latest CentOS" and nothing else. They don't have time to explore, maintain and secure other options. They don't have time to be more specific about the tooling they can provide. They just give cpu/ram/storage in the form of a VM that you order from a ticketing system or a self-service portal. And then they spend their day rebooting unresponsive VMs and opening network incidents. So they couldn't care less about your python module that's not the exact same version as your laptop. (Heck, they don't even provide R or python, we have to build it and package it ourselves and include dependancies).

So they get frustrated, and the devs get frustrated, and nobody can ever work together properly. Because the right strategy is not in place. But this has nothing to do with your laptop being this or that OS or the servers running CentOS instead of Debian. It's about your pipeline from your POC to your production code, and how people before you have tackled the issue (hint : most of the time they didn't).

Re: Leaderless Debian

#114

Post by lmm »

bionsystem wrote: post #112
lmm wrote: post #91

Earlier quoted context omitted.

The subtle differences will bite you at the worst possible time. Things like a rarely-used command flag doing something different. I'm more of a developer than a sysadmin, but whenever I've had to use a different distro/OS on my development machine from what the servers were running, eventually I've hit a bug that only occurred on the servers and couldn't be reproduced on my development machine. And sure it's never i…

Oh I see, thanks for your answer. It's mostly a developper issue for you then, and it's your sysadmin job to provide you with the right tools ; but he probably won't take "just install debian everywhere" as a valid suggestion. A sysadmin just needs putty and then he'll build his infrastructure to make his life easier. He will never write or run code on his own machine, but on a machine similar to the production targe…

VMs, remote IDEs, or FAAS are ways to develop on a server-like environment, but they all come with their own overheads; IME none has as good a debugging experience as being able to run the thing directly on your normal dev machine. (even for sysadminly scripting tasks, working via a putty window carries overhead and there are times when you'd rather be on the machine itself, though I'd agree that it's less common for it to be an issue there than for development work).

You're right that the issue is consistency rather than the particular OS. But there is a real point here that Ubuntu in particular is functional as a first-class OS both on developer laptops and on production servers, in a way that none of the other options can quite match. (Windows' administration support/automation is lacking on the server, OSX servers barely exist, CentOS is outdated on the laptop, Debian is too principled to support laptop hardware, Fedora is undersupported on the server...). So it does make for a unique selling point for Ubuntu in practice.

Re: Leaderless Debian

#115

Post by bzed »

bloopernova wrote: post #16
devnonymous wrote: post #14

Earlier quoted context omitted.

Why not Canonical/Ubuntu ? After all they are presumably the most affected by the state of Debian. Just a couple of days ago I made a comment along these lines in a different thread: https://news.ycombinator.com/item?id=19353816 > While this is sad and painful to read, I can't say I'm surprised. > > The problems listed are precisely the kind of problems that Redhat > strategically supports fedora with, in terms of in…

I would hope someone could set me straight if I'm wrong, but I thought that the relationship between Canonical and Debian was mostly one of taking rather than giving back? You're right about Red Hat though, they get a lot of negative feeling from people who may not understand just how much they give back to the community at large.

I think it depends a lot on the relationship between the people who work on some party of the distribution. The canonical people are paid and have their todo list, and they are paid to do that. So if they have a good contact to Debian, they try to get things done via Debian. Some even don't care at all. Some are even Debian developer and do all teir work in Ubuntu and just upload something to Debian at some point. Or they try to force their init system into Debian.... So there are a lot of positive things, but when I think about the biggest issues we had in Debian (or actually have), I consider Ubuntu as evil.

Re: Leaderless Debian

#116

Post by dredmorbius »

xioxox wrote: post #72
oblio wrote: post #33

Earlier quoted context omitted.

The thing is, for a long time, deb/apt were way superior to what rpm/yum offered. Heck, Debian had apt way earlier than Red Hat had yum. If anything, Red Hat should have adopted apt. In terms of sheer number of dumb competing initiatives, Ubuntu > Red Hat > Debian.

Deb/apt might have been nicer to use, but as a packager I found the packaging format extremely horrible to work with. There's a very complex interaction between the various files which define a package. It's extremely hard to find out what debhelper and its associated commands are actually doing and to debug them, particularly if you're trying to split a package into multiple parts. I gave up several times trying to…

That's because APT serves the user rather than the developed.

As a sysadmin, of one box or 100k boxen, I'd have a hell of a lot less apprehension about installing a DEB than an RPM. Thanks largely to Debian Policy, which governs how packaages will behave.

The fact that Debian has an order of magnitude more in-repo, in-distro packages also counts for something.

As well as the fact that I can start with a minimal installation and add to it only what the box actually needs, a process Red Hat and RPM have never adequately supported.

Source: Have run both, personally and professionally, for nearing a quarter century.

Re: Leaderless Debian

#117

Post by bureado »

ilovecaching wrote: post #32

Controversial opinion warning, and I would love to hear some counterpoints outside of my thought bubble. I've never understood the appeal of Debian or Ubuntu, or I guess I don't understand why people would invest so much time in them compared to Fedora and Redhat. In actual buisness dealings Redhat has always led the way in enterprise (whole data centers), kernel development (a bunch of the maintainers work for them…

RPM-based distros certainly led server OEM shipments back in the day, but that didn't mean Debian wasn't being used extensively in the backoffice.

As others have pointed out, APT played a critical role in Debian's popularity as open source software grew and early naive software distribution methods were outpaced by complexity.

I won't weigh in on Canonical's broader presence across verticals, technologies, etc., but Ubuntu is widely recognized as the most popular Linux in cloud platforms. I believe this is a direct result of APT coupled with a more rapid release pace.

RPM-based distros remain extremely valuable and extremely popular in many scenarios, particularly when someone has to run a product from a proprietary ISV or something that has a very complicated certification model.

In some cases, but certainly not all and in my opinion in a decreasing amount, the choice of distro might be tied to how active a particular company is in the upstream kernel. "Buy Red Hat because they contribute to the kernel". Suffice to say as decision makers perceive that their app isn't the kernel, that decision criteria is shifting (thankfully, many RPM-based vendors including Red Hat have many other value items to add)

Re: Leaderless Debian

#118

Post by bureado »

zaphirplane wrote: post #111
geofft wrote: post #51

Earlier quoted context omitted.

For a long while Debian and Ubuntu were the obvious choice for a free-as-in-beer (and not just free-as-in-speech) server OS. Fedora doesn't have an LTS program, and CentOS, Scientific Linux, et al. were unofficial. (CentOS is now more official so that benefit has gone away a bit.) Debian has an enterprise-compatible release cycle - a new release every 2 years give or take a few months, each one gets security updates…

Out of interest how is diversions different from the alternatives command

In alternatives, packages write their files to the disk and then register those as alternatives. A user can decide which one should satisfy the alternative.

In diversions, a package claims a file. When anyone else tries to overwrite the same file, it's diverted elsewhere. It isn't designed for the user to choose between equals.

I built a derivative distro using diversions mainly to prevent "soft-forking" Debian packages as much as possible (maintaining packages is extremely costly for anyone that isn't a decentralized organization like Debian)

Re: Leaderless Debian

#119

Post by bureado »

Tomte wrote: post #26

I've just browsed https://en.m.wikipedia.org/wiki/List_of_Debian_project_leade... There are quite a few names I've never heard of, and some that I've heard of, but not as DPL. The last six (after Hocevar) are total blanks for me. Have my interests changed so much, or did the recent DPLs keep a much lower profile?

Chris Lamb is a remarkably active and outgoing DPL. But yes, I've been active in Debian for well over a decade and I've seen both a lot of people leave and new people that I don't know or get to know as I used to. All 5 DPL candidates ring a bell for me, though.
Post reply on HN