Live data from Hacker News

Winding down my Debian involvement

michael.stapelberg.ch

131–140 of 238 posts

Re: Winding down my Debian involvement

#131
post #105
post #5

The post shares several pain points with Debian's slow, aging change-process and integration-infrastructure. Open question: If Debian contributors feel the need to drop out and move on due to these pain points, are there less-painful Linux-distribution projects out there that are getting more of these pain points right they can flock to? Is this a sign that Debian needs to reform, or that other, newer distributions a…

openSUSE uses the Open Build Service[0] to build, well, openSUSE. OBS also supports other distributions etc., but it makes it fairly easy to put up a package.[1] For RPM-based distros (e.g. openSUSE), you write a .spec-file, check it in via OBS's version control alongside your sources, and off you go. OBS builds the package (and pulls in dependencies as needed etc.) and publishes the result as a repository with GPG k…

I'm a BSD guy but needed a Linux distro last year for a specific project. OpenSUSE was remarkably good, stable, easy to use and update, and apparently free of the political crap that seems to come with many other distros.

I have recommended it to others who need a stable Linux distro with lots of well-maintained packages. Some of them looked at me like I was crazy. Preconceived notions are hard to overcome sometimes. Oh well.

Re: Winding down my Debian involvement

#132

Earlier quoted context omitted.

The original problem with reporting bugs to a mailing list was mails for many bugs were mixed and you couldn't easily get the state of individual bugs. Debbugs, by automatically creating a new mailing list for individual bugs, does solve this problem admirably. The new problem is that new people hate emails. I think the merit of this problem is debatable.

In the long run, everyone who tolerates email is dead.

But do they die before everything else?

Re: Winding down my Debian involvement

#133

Earlier quoted context omitted.

Debbugs is basically a mailing list.

The original problem with reporting bugs to a mailing list was mails for many bugs were mixed and you couldn't easily get the state of individual bugs. Debbugs, by automatically creating a new mailing list for individual bugs, does solve this problem admirably. The new problem is that new people hate emails. I think the merit of this problem is debatable.

Mailing lists have had threads for decades.

Re: Winding down my Debian involvement

#134
debian user for 20 years here, love it.

debain is the base for so many other projects, it needs to keep going strong.

in the meantime debian in many aspects is a bit "old" now, its infrastructure and the way to do things need evolve. I'm not a developer per se, it is not easy to become one either.

There are so many ways to make packages and it's hard to pick the "best" one for example.

I hope Debian can reform its model to make it even better, there are just so many archaic baggage from the past for new comers.

Re: Winding down my Debian involvement

#135
post #46

Instead, currently, all packages become lint-unclean, all maintainers need to read up on what the new thing is, how it might break, whether/how it affects them, manually run some tests, and finally decide to opt in. This causes a lot of overhead and manually executed mechanical changes across packages. I always wondered if Debian/Ubuntu could benefit from a "monorepo". It seems to work for other distributions, e.g. A…

Wouldn't even need to be a monorepo. As a first step, ensuring that all packages use the same system, e.g. git, and one authoritative repository (e.g. a debian-maintained gitlab) would be a great start.

Re: Winding down my Debian involvement

#136
post #47

Earlier quoted context omitted.

All mails I've sent to maintainers of packages regarding issues with them have been ignored. I think they prefer you to use the bug tracker. (Which sucks, so I always end up doing nothing about it.) In the end I switched all my servers to Ubuntu. It's been good and I love PPAs.

Ubuntu bug reporting is just as shitty. No reply for 6+ months was common for me. One time I even tracked down the issue, which was fixed upstream just one commit after the one they used for their package. Still no reaction, but about a year later they asked of the problem still persists with the current release. I didn't bother to reply and stopped reporting to either Ubuntu or Debian.

I had the same experience. After an Ubuntu update, my workstation was suddenly not able to mount an NFS filesystem from FreeBSD when Kerberos was enabled.

The bug was rather quickly marked as confirmed, with absolutely no updates for several years, even though the root cause was known. As far as I know, it still hasn't been fixed.

Re: Winding down my Debian involvement

#137
post #61
post #16

I've been using Debian / Ubuntu for many years, as much due to inertia and familiarity as anything else. And I have a lot of respect for the project. If I wanted to start being a contributor to a distribution, which one would be the best to dive in to?

The smaller ones are often easier to contribute, port some packages to Void!

That's also where you make the least impact.

There is probably an impact graph with popularity * impact of change on the project * probability of change being accepted * log(delay of change reaching 80% of users).

For instance with Homebrew: high popularity, high probability of being accepted and low delay to reach 80% of users, so the impact of the change on the project is the main factor.

Re: Winding down my Debian involvement

#138
post #110
post #101

Earlier quoted context omitted.

Homebrew is effectively a "rolling release" with fast turnover of package versions. So in that sense it's not directly comparable to Debian stable (or even unstable). That rapid turnover has led to numerous breaking bugs over the last five years or so that I've been using it. It's a lot simpler, but it also lacks the sophisticated versioned dependencies which dpkg/apt provide. Both have their tradeoffs, but I wouldn'…

Try macports for a BSD style packaging for the mac.

What's the advantage of using macports over Homebrew?

Re: Winding down my Debian involvement

#139

Earlier quoted context omitted.

I don't think it necessarily needs a monorepo, but having every package on Salsa (Debian's GitLab installation) would help.

The move to GitLab was a glimmer of hope that one day I'll be able to help contribute to the project which I'm a heavy user. I wish they went all in and used GitLab Issues for bugs and GitLab CI/CD to auto-build packages for both validation and pushing new packages into the Debian repositories.

I'm not following the situation but what's stopping them from improving their packaging system, except for being complicated?

Re: Winding down my Debian involvement

#140
In my experience, better tooling always wins in the long run.

I've built Debian packages in the past, and after packaging the same software with Nix, it's very hard to not feel that Debian tooling and packaging is time consuming for no good reason. The nixpkgs model, where all you need to build everything is one `git clone`, all you need to make a change is a pull request and wait for a range of automated tests to tell you it's good (for both build and the _uses_ of a package!), and all you need to land a contributed change is click one button, seems strictly better.

Over the years I've heard many people say "but shell scripts, FTP servers and arcane helper tools is the way we've done it for decades and that will never change" in many projects, but eventually, these projects shrink and those with a good developer experience and clean tooling overtake them.

Similarly, after experiencing automatic, safe refactoring across billion-line typed-checked code bases, you can't help but wonder why people put up with spending their time going through heoric community efforts distributing work across people that a machine could easily do if you used good tooling.

In my opinion, the real strength and legacy of Debian is successfully running a large, diverse, distributed project over decades with (reasonable) cohesion, democracy, and (reasonably) good organisation and project management.

But even some non-technical problems go away with good tooling, and more time gets freed up to solve those hard tasks.

Concrete example: In nixpkgs it is very easy to build overlays for the whole of NixOS that allow you to switch from dynamic to static linking or add hardening flags across all packages, avoiding big debates over which is the "one true way" because providing both is so easy, and both can be merged upstream.

I think any big and successful project should continuously invest into better tooling, and simplify and automate things. That keeps contributors motivated and on board.

(14-years happy Ubuntu [and thus Debian] user, and 10-years i3 user, so thanks for your efforts, Michael.)

Post reply on HN