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

Armbian and Devuan = Armvuan

github.com

Post reply on HN
Print view View original

51–55 of 55 posts

Re: Armbian and Devuan = Armvuan

#51

Post by nor-and-or-not »

ilyt wrote: post #34
nor-and-or-not wrote: post #25

Earlier quoted context omitted.

Does it matter how many users there are if the people who made it are happy with their work?

Are they ? Because all of that looks like posturing on principles. Like, I have plenty of issues with systemd but still on span of 461 systems we manage (mostly Debian with some centos here and there) with variety of use cases (from "legacy" to k8s running on ceph cluster) it saved us tens of thousands lines of code and allowed some tricky use cases to be far more reliable than before. Because apparently despise vehe…

Why do systemd proponents always compare it to SysVinit?

Compare it to Runit (Void Linux, antiX, Devuan package, as well as packages for all BSDs), OpenRC (Alpine, Gentoo, Devuan package, compatible with FreeBSD and NetBSD), … with S6, which many folks (including me) do use on their Linux and BSD systems.

I, too, operate a fleet of servers without any trouble using Runit and OpenRC.

Re: Armbian and Devuan = Armvuan

#52

Post by lmm »

oneshtein wrote: post #50
lmm wrote: post #46

Earlier quoted context omitted.

It evidently isn't working well enough - why are snap and flatpak a thing at all if source packages are good enough? Why do users want programs to get picked up as part of a distro's repositories?

As user, I want application to be tested and integrated with my distro by a competent maintainer. As application developer, I want to deliver latest version of my application to all users without additional testing, integration, and discussions with maintainers of all Linux distributions.

> As user, I want application to be tested and integrated with my distro by a competent maintainer.

Do you though? Most users just want the latest upstream release, packaged up so they don't have to deal with compiling or dependency management themselves (and have a chance of a clean uninstall), not any extra testing or integration. Hence the popularity of PPAs, Snap/FlatPak, etc..

Re: Armbian and Devuan = Armvuan

#53

Post by oneshtein »

lmm wrote: post #52
oneshtein wrote: post #50

Earlier quoted context omitted.

As user, I want application to be tested and integrated with my distro by a competent maintainer. As application developer, I want to deliver latest version of my application to all users without additional testing, integration, and discussions with maintainers of all Linux distributions.

> As user, I want application to be tested and integrated with my distro by a competent maintainer. Do you though? Most users just want the latest upstream release, packaged up so they don't have to deal with compiling or dependency management themselves (and have a chance of a clean uninstall), not any extra testing or integration. Hence the popularity of PPAs, Snap/FlatPak, etc..

Most users just want the properly working latest upstream release, which just works from the first try. It means that somebody must properly recompile, test, fix bugs, integrate, and package the software package into existing distribution. Fedora often publishes even pre-release versions of some software packages, if you want to talk about "latest" version.

Re: Armbian and Devuan = Armvuan

#54

Post by lmm »

oneshtein wrote: post #53
lmm wrote: post #52

Earlier quoted context omitted.

> As user, I want application to be tested and integrated with my distro by a competent maintainer. Do you though? Most users just want the latest upstream release, packaged up so they don't have to deal with compiling or dependency management themselves (and have a chance of a clean uninstall), not any extra testing or integration. Hence the popularity of PPAs, Snap/FlatPak, etc..

Most users just want the properly working latest upstream release, which just works from the first try. It means that somebody must properly recompile, test, fix bugs, integrate, and package the software package into existing distribution. Fedora often publishes even pre-release versions of some software packages, if you want to talk about "latest" version.

> It means that somebody must properly recompile, test, fix bugs, integrate, and package the software package into existing distribution.

Recompile, yes. The rest, probably not - upstream usually does that better than any distro. Distro-specific bugs are usually caused by that distro's changes made to "integrate" the package into the distro, which are usually not something the user wants. Again, hence the popularity of PPAs and Snap/FlatPak.

> Fedora often publishes even pre-release versions of some software packages, if you want to talk about "latest" version.

Fedora has the resources to do that because they're managed by a huge company, and they're big enough that upstream will likely make changes to accommodate them. Most distros aren't on that level.

Re: Armbian and Devuan = Armvuan

#55

Post by teddyh »

b112 wrote: post #37
teddyh wrote: post #32

Earlier quoted context omitted.

> rsyslogd is not a default install item now, and when you install it, there is no init script. It’s in the orphan-sysvinit-scripts package.

What a strange place to put it, there's loads of sysinit scripts still, but thanks for the heads up. Re: other response... None of those things require systemd under debian, and it's easy to use sysvinit. I run loads of systems without systemd.

> What a strange place to put it, there's loads of sysinit scripts still

Well, apparently the rsyslog daemon itself does not include a sysvinit script; i.e. the rsyslog developers did not write or supply one. So it falls to the distribution, in this case Debian, packager to supply such a script. The Debian packager for the rsyslog package has chosen not to do the work of maintaining a sysvinit script. Debian has further chosen not to require sysvinit scripts for every package. Since maintaining a package is volunteer work, nobody could reasonably expect packagers to do work they don’t want to do which is not required. And thus the rsyslog package does not contain a sysvinit script.

The sysvinit scripts which used to be present in many Debian packages but which the corresponding packagers have chosen to not maintain, are still offered in the orphan-sysvinit-scripts package. The sysvinit-core package “recommends” (a Debian packaging term) the orphan-sysvinit-scripts package, which means that everybody who installs the sysvinit-core package should get the orphan-sysvinit-scripts package installed by default.

Post reply on HN