Ask HN: What do you want to see in Debian 10 (“buster”)?

[+] ATsch|8 years ago|reply

- HEADLINE: Simplify contributing to Debian.

- DESCRIPTION: TL;DR: Debian's web pages are hard to navigate and use and it's very hard to see what's happening.

I contribute to FOSS projects whenever I have time and have been wanting to contribute to Debian, but the difficulty is offputting. I'm used to searching for the program name and arriving at a portal page from which I can easily browse the source, see the current problems and instantly start interacting with the community. Unfortunately, contributing to Debian seems to require in-depth knowledge about many systems and arcane email commands. As a would-be contributor this completely alienates me.

One reason is that Debian has many independent services: lintian, mailing lists, manpages (which btw are fantastic and give me hope), Wiki, CI, alioth, the package listing, BTS, etc. To contribute, you need to learn most of them and For example, searching a package name gives me a page at packages.debian.org, but it's very hard to navigate or even discover the other services from there. I can't easily see if there are any lintian issues, critical bugs or current discussions. Additionally, I find most of the systems very hard to use (I still can't figure out the mailing list archives). Ideally, these services would be more tightly integrated.

Another big reason Debian is very hard to contribute to is the main discussion takes place via mailing lists. I understand that many people enjoy working with them, but for light usage they are a big pain. Submitting and history are in completely different programs, there seems to be no real threading, volume is often high and reading large amounts of emails is a chore to me. A solution here would be an improved mailing list archive with options for replying directly integrated to the site.

- DISTRIBUTION: unstable

- ROLE/AFFILIATION: Student

[+] sakawa|8 years ago|reply

Generally I agree with most of the submissions, but this one is the most important.

I really love debian because of its principles (and I would love to contribute), but I feel that new contributors (like me) have problems because of the many (and some old) tools and outdated and non-friendly documentation.

Also, I don't know how many contributors come and stay, but even in unstable I see some outdated packages in weeks, and also some useful software that is not packaged.

[+] vacri|8 years ago|reply

As a parallel, one of the reasons Slack has won in the paid-chat stakes is because of it's buttery-smooth onboarding process. The chat client isn't anything special, really, but it's just so easy to get set up and running.

The difficulty gradient of onboarding is a significant contributor to attracting folks.

[+] K_REY_C|8 years ago|reply

Ditto. In the last 2 years I actually switched to Fedora because of the clearer and easier road to contribution. (Area: design)

[+] confounded|8 years ago|reply

Not banning people behind a VPN would make the Debian wiki useful to me (it's just a static site!).

[+] gub09|8 years ago|reply

HEADLINE: Consolidation of Documentation; Removal of Outdated Documentation

DESCRIPTION: Any time you do a web search for anything regarding Debian, the search results include a huge amount of official but outdated information. Normally for Linux-related questions I refer to the amazing Arch wiki, but there are topics that are Debian-specific, and then sifting through all the detritus is a huge waste of time. There's a wiki, a kernel handbook, a manual, random xyz.debian.org pages, mailing lists, user forums, the Debian Administrator's Handbook...

Granted, it's a huge effort to clean all of that up, but perhaps there's a way to incorporate user feedback, so that pages can be marked as "outdated" by users, or updated by users (wait, there's a log-in page- does this mean I can edit wiki pages? Did not know that...:( ), or otherwise made more systematic.

In particular, it would be great to have more complete information on the installation process: which images to use (RC, ..., or weekly image?), how to put them on a USB stick (why does my 32GB stick now say it has 128GB?; you mean I can just copy the files to a FAT32-formatted drive?), what the options are (for hostname, is any name, a FQDN necessary?), etc. For every single clarification, there will be a hundred, thousand, ten thousand people who are helped; that seems like a worthwhile investment. Everyone is a beginner at the beginning, regardless of knowledge outside this specific domain, so why not make it easier.

All that said, have been using Stretch/testing for a few years, love it, love the Free/Libre Software ethos, love what you guys do, keep it up, thank you!

[+] hsivonen|8 years ago|reply

HEADLINE: Repurpose testing as a rolling release positioned for not-just-testing usage

DESCRIPTION:

There are users who'd like to use a non-corporate community distro but who don't need or want software to be as old as software in Debian stable. The standard answer is "use testing" (e.g. http://ral-arturo.org/2017/05/11/debian-myths.html), but 1) security support for testing is documented to be slower than for stable and unstable (https://www.debian.org/doc/manuals/securing-debian-howto/ch1...) and 2) the name is suggestive of it being for testing only.

Please 1) provide timely security support for testing and 2) rename testing to something with a positive connotation that doesn't suggest it's for testing only. I suggest "fresh" to use the LibreOffice channel naming.

DISTRIBUTION: testing

ROLE: Upstream browser developer. (Not speaking on behalf of affiliation.)

[+] avar|8 years ago|reply

    > rename testing to something with a positive
    > connotation that doesn't suggest it's for
    > testing only.

Isn't unstable what you want to use?

The reason it's called "testing" is because it's a branch of Debian that's "in testing for stable". IIRC packages have to be 2 weeks in unstable without bugs before migrating to testing.

So it's explicitly not a bleeding edge release, but a preparation release for the next stable, which is why testing since late-2016 or so hasn't been getting any new major releases, it's been undergoing release prep.

Maybe there should be a sixth branch of Debian between unstable and testing that doesn't slow down the migration of packages bug-free for 2 weeks from unstable around release, but that seems like a lot of maintenance burden to impose on Debian.

[+] oneplane|8 years ago|reply

A problem would be the security updates. You can't really spend even 'more' people on security updates for a rolling release. The frequency of updates would be too high for this to work.

This is also the reason for only stable (and olstable?) getting security updates. The thing is that if you want to support something, you'll need to scope it. You can't support just any random thing, you'd need an army of maintainers just to do that. So you make a 'release' where that specific version has people watching over it and making sure things are safe and working. Even that process is hard enough as-is.

While it would certainly be nice to have a rolling release, or 'really fast' release, it can only be done if more hours/people/donations are available to fuel it.

[+] allan_wind|8 years ago|reply

Is the concept of a release still important? OpenBSD did away with the CDs for instance, so what is the value of calling a tag for a particular set of packages (versions) a release?

The only time I cared was when I installed from scratch on a new computer (too much hazle to mirror and existing drive and figure out how to switch from bios to efi etc), and last time, stable did not support my hardware, testing and nightly did not work due to being in transit to release. In other words the lack of any suitable installer meant I was forced to use another distribution (Ubuntu).

I have tried both testing and unstable and both broke for me at inconvenient times, usually I was not the first to notice, and with some effort usually able to find a fix or work-around. Stable plus backports work well, although as a rule, you are stuck on old packages unless (at least the way I use it) explicitly upgrade a particular package. It is configuration that I have to manually sync between machines.

Other than varnish (3rd party repo which is going away I believe) I have no issues with automated (i.e apt-cron) updates for many years.

What I would love to see is a rolling release that is non-breaking. If something breaks, roll that particular package back. I don't know what the particular mechanism that would be, but the ticket system (which is a wealth of data) could be an input along with local configuration.

Push upgrades. With stable, security fixes, is a feed, but it would nice if I don't need to jury-rig something myself to minimize my exposure window. With rolling releases, it would be nice to get that faster (or if you prefer delayed by a configurable amount).

[+] ufo|8 years ago|reply

The testing and unstable branches beeing kind of second class citizens is why I eventually jumped ship to OpenSUSE Tumbleweed and Fedora (technically not rolling but things are more up to date) after a long time using the testing branch.

[+] RVuRnvbM2e|8 years ago|reply

Have you seen Backports?

https://backports.debian.org/

[+] vacri|8 years ago|reply

I remember hearing a Debian Developer give a talk where he said that 'testing' can almost be considered a normal rolling distro in its own right, but there are times when it's broken - the example he gave was that at one point the installer itself was broken for a short time.

[+] Dunedan|8 years ago|reply

HEADER

Python 3 as default

DESCRIPTION

Just to quote from the packaging manual:

> Debian currently supports two Python stacks, one for Python 3 and one for Python 2. The long term goal for Debian is to reduce this to one stack, dropping the Python 2 stack at some time.

The first step for that would be of course Python 3 as default Python version and I'd like to see that for buster, as Python 3 nowadays offers way more features than Python 2 and should be the choice for new Python projects.

[+] JoshTriplett|8 years ago|reply

Upstream Python specifically recommends against installing Python 3 as /usr/bin/python; see PEP 394 at https://www.python.org/dev/peps/pep-0394/ . Beyond that, many of Debian's python-using packages are already migrating over, and I'd expect the rest to likely migrate in buster.

[+] problems|8 years ago|reply

But ultimately isn't the first choice for most Python projects to date. So many scripts have python paths expecting python 2 hardcoded and pretty much everything that wants python3 calls python3. I'm firmly against this for compatibility reasons, it breaks too much.

[+] lamby|8 years ago|reply

The "lintian" packaging static-analysis tool has been issuing an info-level message about new packages that introduce Python 2.x packages. I've just upgraded this to a "warning" level, so we should at least curb the influx of additional Python 2 packages unless strictly necessary — I suspect most of them are simply included now out of habit.

[+] JoshTriplett|8 years ago|reply

HEADLINE: Switch to persistent journald by default

DESCRIPTION: Right now, Debian's default install includes rsyslog, and every message gets logged twice. Once in rsyslog on disk, and once in journald in memory. Let's turn on the persistent journal by default, and demote rsyslog to optional. (People who want syslog-based logging can still trivially install it, such as people in an environment that wants network-based syslogging. But that's not the common case.) This will make it easier to get urgent messages displayed in desktop environments as well.

[+] dragonne|8 years ago|reply

This, a thousand times this.

Failing that, though, at least change the default rsyslog configuration such that:

* Timestamps are not ambiguous (the default includes no timezone offset)

* Timestamps are higher resolution (milliseconds at least, but preferably microseconds)

* The syslog severity/priority is not discarded (tools which display these files must use disgusting heuristics like searching for "err" to highlight errors)

* Rate limiting is disabled, as rsyslog sees all messages as coming from journald. This means that a misbehaving (chatty) application can cause critical messages from other apps to be dropped. journald does its own (per-source) rate limiting anyway.

* /var/log/syslog is rotated by size as well as time, so a misbehaving program can't easily fill up the partition which contains that file by accident. The current default is 1/day rotation, with no size limit.

[+] kebolio|8 years ago|reply

HEADLINE: easier, simpler package creation and building

DESCRIPTION: on distros like arch, to a lesser extent void and even gentoo, writing package definition files (PKGBUILDs, ebuilds, templates) is relatively straightforward; in contrast, i don't even know where to start with finding, editing and building debian packages. i think they're built from source packages but beyond that i have no clue. i think visibility of documentation could help here, if not more radical changes to be more similar to the arch/gentoo workflow.

[+] JoshTriplett|8 years ago|reply

HEADLINE: Full audit of what's in "standard" and "important"

DESCRIPTION: There have been numerous detailed analyses posted to debian-devel that go through every package in standard and important and list out which ones shouldn't be. However, actual changes have only ever been made here on a point-by-point basis. (I've managed to get a dozen or so packages downgraded to "optional" and out of the default install by filing bugs and convincing the maintainer.) I'd really like to see a systematic review that results in a large number of packages moved to "optional".

This would include downgrading all the libraries that are only there because things depending on them are (no longer something enforced by policy). And among other things, this may also require developing support in the default desktop environment for displaying notifications for urgent log messages, the way the console does for kernel messages. (And the console should do so for urgent non-kernel messages, too.)

DISTRIBUTION: Start with unstable early in the development cycle, so that people can test it out with a d-i install or debootstrap install of unstable.

[+] guillemj|8 years ago|reply

Please check https://wiki.debian.org/BusterPriorityRequalification, https://wiki.debian.org/Proposals/EssentialOnDiet and https://wiki.debian.org/Teams/Dpkg/Spec/ImportantField.

We should discuss some of this at some point on debian-devel.

[+] voltagex_|8 years ago|reply

I'm interested in this - does this mean the size of a default install becomes smaller?

Is there anywhere to read more about this?

[+] heftysync|8 years ago|reply

HEADLINE: First class ZFS install support on Live CD.

DESCRIPTION: The license conflict between the open source ZFS and open source Linux kernel mean ZFS needs to be in contrib. Unlike a lot of other packages in contrib, ZFS doesn't rely on any non-free software. It just can't be in Debian main because of the conflict of licenses.

However, it would be nice if there was a way to have a more official path to ZFS on root for Debian. The current instructions require a fairly high number of steps in the ZFS On Linux wiki.

The ZFS On Linux wiki also lists a new initramfs file that has to be included so ZFS is supported. It seems odd that Debian couldn't include that as part of initramfs. I realize Debian doesn't want to necessarily promote non-free software, but this is free software that just conflicts with the GPL. It doesn't seem like it should be a second class citizen where you have to manually include files that should already be part of the package.

By the nature of the license conflict, it will be a second class citizen in that it can't be part of the normal installation package and you'll have to compile on the fly. However, it would be nice if there was a mode in the Live CD that could handle ZFS installation rather than doing it all manually.

DISTRIBUTION: currently mixture of testing/unstable but I'd like to use day(s) old sid (see other post).

[+] jasonwc17|8 years ago|reply

I would really like to see ZFS make it into the regular install image. Debian already releases an install image with non-free firmware and ZFS is free software. It just has an incompatible license.

The specific issue you mention about creating the initramfs file is actually not necessary in Stretch since this file already exists. There have been other, more significant changes in Stretch as well. (Note: I've contributed to the Debian Jessie ZFS on Root Howto and have followed this guide for numerous systems on both Jessie and Stretch).

1) ZFS has made it into Debian Stretch, so it is no longer necessary to add the backports repository. You just need contrib.

2) The grub-pc package in Stretch provides ZFS support. In contrast, Jessie required installing the package from Testing, and this could cause issues with prior versions of the Howto, as it would often pull Grub's dependencies from Testing as well, blocking installation of among other things, Gnome. The Howto now ensures that dependencies are satisfied from Stable.

3) Since ZFS and grub-pc can be installed from Stable, there's no need to add the /etc/apt/preferences file for pinning priority.

[+] ryao|8 years ago|reply

I promised a few people that I would do a fresh ZFS port to FUSE that could be merged into ZoL HEAD. While life has delayed that, I hope to make it a reality this year. It was intended to be a development aid, but I know that there are some internal politics in a few distributions about shipping out of tree kernel modules on install media. I am told that a FUSE port will alleviate the internal politics. I imagine Debian et al integration would improve once that is a reality. Conceptually, it should allow for users to make an easy switch to the kernel modules once the system is installed. Keep your eyes open for that later this year.

[+] lscotte|8 years ago|reply

Thirded! I've been building out all my Debian boxes with ZFS root (and everywhere) for a year or more. Not only does this require installing via debootstrap, but there are some subtle things that have to be done just so or the system won't boot. Stretch improves this over Jessie, but it's still clearly not a first order citizen.

Like with non-free firmware, and other such things, I get the licensing and taint issues, but it would be good to see this evolve and be supported in the installer, someday, if only on a "forked" installer like with non-free firmware.

[+] luca_ing|8 years ago|reply

Absolutely seconded.

Decent support for ZFS in general, especially during installation already.

Ideally, ZFS root filesystem support (snapshot before upgrade, yay!).

I've been using ZFS for six(?) years now, on both Debian and Ubuntu, and while ZFS root is so important to me that I'm willing to jump through the necessary hoops to install it, it's kinda grating and perhaps riskier. And not for the faint of heart.

[+] miclill|8 years ago|reply

- HEADLINE: Not start services by default

- DESCRIPTION: If I installed e.g. postgresql I would prefer it not starting automatically by default. I would rather like a message: If you want x to start on boot, type 'update-rc.d enable x'

- DISTRIBUTION: (Optional) [stable]

- ROLE/AFFILIATION: (software dev, mostly web)

[+] avar|8 years ago|reply

HEADLINE: Better support for non-free firmware during installation

DESCRIPTION: Long-time Debian user here and free software supporter. One aspect where I don't have any practical choice for free software is my non-free iwlwifi firmware.

It's a huge PITA to install Debian like that when you don't have the fallback of a wired network. You provide "non-free" firmware packages, but these don't have the actual firmware! Rather they're dummy *.deb packages that expect to be able to download the firmware from the installer, which is of course a chicken & egg problem for WiFi firmware.

I end up having to "apt install" the relevant package on another Debian system, copy the firmware from /lib manually, copy it to a USB drive, then manually copy it over in the installer.

I understand that the Debian project doesn't want to distribute non-free firmware by default, but it would be great to be able to run a supported official shellscript to create an ISO image that's like the Stretch installer but with selected non-free firmware available on the image.

DISTRIBUTION: Stable on my server, testing on my laptop.

[+] jancsika|8 years ago|reply

- HEADLINE: transactional upgrades and package installs

- DESCRIPTION: This is a feature of the guix package manager. From their website:

"Each invocation is actually a transaction: either the specified operation succeeds, or nothing happens. Thus, if the guix package process is terminated during the transaction, or if a power outage occurs during the transaction, then the user’s profile remains in its previous state, and remains usable."

They also do transactional rollbacks, but I'm not sure how realistic that is for the apt package system.

[+] rahiel|8 years ago|reply

HEADLINE: enable AppArmor by default

DESCRIPTION: AppArmor improves security by limiting the capabilities of programs. Ubuntu has done this years ago [1]. I'd like to see profiles for web browsers enabled by default.

I think AppArmor is the right choice of default Mandatory Access Control for Debian because Ubuntu and security focused Debian derivatives like Tails [2] and SubgraphOS [3] have already committed to it.

[1]: https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/AppArmorP...

[2]: https://tails.boum.org/contribute/design/application_isolati...

[3]: https://subgraph.com/

[+] esjeon|8 years ago|reply

- HEADLINE: Easier DEB repository creation.

- DESCRIPTION: Creating a custom remote/local/CD/DVD repo or a partial mirror is simply a nightmare, mainly because package management internals are poorly documented. There are many tools developed to just solve this problem, but most of them aren't actively maintained. Aptly seems like the best right now, but is way much complicated and inflexible.

[+] Dunedan|8 years ago|reply

HEADER

100% reproducible packages

DESCRIPTION

While having over 90% of packages reproducible already is awesome, 100% would be even better. The stretch release announcement describes best why:

> Thanks to the Reproducible Builds project, over 90% of the source packages included in Debian 9 will build bit-for-bit identical binary packages. This is an important verification feature which protects users from malicious attempts to tamper with compilers and build networks.

[+] rahimnathwani|8 years ago|reply

HEADLINE: Easy way to use multiple screens with different DPI

DESCRIPTION: Many laptops (e.g. Macbook Pro) come with retina screens, but most of us use 'regular' monitors. Even after setting org.gnome.desktop.interface scaling-factor and playing with xrandr, it can be difficult or impossible to get a single external non-retina display set up in the right position and without one screen containing tiny text (or huge text).

Being able to make it work at all, and persist after a reboot, would be great. Having per-monitor scaling in the Display settings panel (or in 'Arrange Combined Displays') would be amazing.

DISTRIBUTION: I've experienced this with jessie. I haven't tried with stretch.

[+] CaliforniaKarl|8 years ago|reply

HEADLINE

Remove openssl1.0

DESCRIPTION

stretch made OpenSSL 1.1 the default openssl package. Unfortunately, OpenSSL 1.0 was kept around, since so many things depended on it.

There should now be enough time that a firm stance can be taken toward not allowing OpenSSL 1.0 in Debian Buster.

Once TLS 1.3 is finalized, OpenSSL 1.2 will be released with TLS 1.3 support. Not supporting TLS 1.3 in buster would (in my opinion) make Debian appear less in other people's eyes. That means supporting OpenSSL 1.2, and having three OpenSSL packages (1.0, 1.1, and 1.2) is too much for one distribution.

DISTRIBUTION

buster

[+] heftysync|8 years ago|reply

OpenSSL doesn't follow semantic versioning. This is not a simple version upgrade. They knowingly broke the API between 1.0 and 1.1 and it can require substantial changes. They also refused to provide a compatibility shim to make it easier for developers to migrate.

This is not a Debian problem. This is an OpenSSL problem where they forced each upstream program author to make changes in order to upgrade. You'll have to wait for each upstream program author to update.

[+] zdw|8 years ago|reply

How would you feel about a switch to one of the forks, such as BoringSSL or LibreSSL?

[+] aleden|8 years ago|reply

Android Studio relies on OpenSSL 1.

[+] sandGorgon|8 years ago|reply

HEADLINE: a merger of flatpkg and snap

DESCRIPTION: a consensus on the next generation of package management. Please. We have had decades of fragmentation (not to mention duplicated innovation) around the RPM vs DEB ecosystem. Which is why it is still hard for beginners to want to use Linux - try explaining to anyone who comes from a Mac about rpm vs deb vs whatever else. Which is why they would pay for the mac rather than use Linux ("its too hard to install software").

Its not just my opinion - PackageKit (https://www.freedesktop.org/software/PackageKit/pk-intro.htm...) was invented for this reason. So you could have Gnome Software Manager that can work the same on every flavor of Linux. Its time to build this the right way.

You have an opportunity now - but again the camps are getting fragmented. We now have snap (ubuntu/deb) vs flatpkg (redhat) all over again. And pretty strongly divided camps are beginning to form around them. It seems that the new rhetoric is snap for servers and flatpkg for desktops... which absolutely doesnt make sense.

Debian is the place to make this stand - systemd was adopted from fedora despite Ubuntu making a strong push for something else. Debian made Ubuntu adopt systemd. I dont think anyone has anything but respect for that process. Debian 10 must take a stand on this.

[+] rahiel|8 years ago|reply

I don't think Debian needs to choose. Debian will keep using deb/dpkg as flatpak and snap are not intended to replace a distro's main packaging. They are supplements so users can get newer packages directly from upstream developers. Note that Debian 9 already supports both flatpak [1] and snap [2]. Because of the way snaps/flatpaks are isolated from the rest of the system, they can coexist without issues.

I thought the creators of snaps/flatpaks would be upstream developers, so they themselves will vote on the package management system by using either. There is no duplication of effort here.

Myself I prefer AppImage [3], because of its simplicity and the fact that they are already supported on all Linux distributions, without installing any explicit support.

[1]: https://packages.debian.org/stretch/flatpak

[2]: https://packages.debian.org/stretch/snapd

[3]: http://appimage.org

[+] sandGorgon|8 years ago|reply

Just came to add another comment on how bad it was - I just wanted to download pypy for some experiments.

http://pypy.org/download.html

>download PyPy from your release vendor (usually an outdated version): Ubuntu (PPA), Debian, Homebrew, MacPorts, Fedora, Gentoo and Arch are known to package PyPy, with various degrees of being up-to-date.

This is the world of Linux software installation.

[+] dustinkirkland|8 years ago|reply

Snapd is actually part of Debian 9 (Stretch), which means that Snap packages are also supported on Debian, as well as Ubuntu, Fedora, SUSE, CentOS, Gentoo, Yocto, Arch, etc.

Flatpak exists for one and only one reason -- because Red Hat, Inc. refuses to work with technology of any kind led by Canonical, period.

[+] zAy0LfpBZLC8mAC|8 years ago|reply

> try explaining to anyone who comes from a Mac about rpm vs deb vs whatever else. Which is why they would pay for the mac rather than use Linux ("its too hard to install software").

How does that make any sense whatsoever? You have three different systems to choose from ... and you choose one of them because the other two are different from one another?!

[+] captainmuon|8 years ago|reply

HEADLINE: Keep selected packages up-to-date on stable

DESCRIPTION: If you are using Debian, especially stable, you have to put up with outdated packages. This is especially a problem with browsers, although you do include security updates and track Firefox ESR, if I understand correctly. But things like Webkitgtk do not recieve updates, and lack feature and security wise after a while.

I think keeping up-to-date versions and having a stable distribution is not per se a conflict. Stable means to me no breaking changes, no need for reconfiguration when I update. It shouldn't mean frozen in time.

It would be great if certain packages would recieve frequent updates even in stable:

- packages that are not dependencies, have a good track record of backwards compatibility, and are unlikely to break

- packages that have to be updated because of security issues (which I think is already addressed now)

- or because of a fast moving ecosystem - even if it was safe, it is frustrating to use a very outdated browser component. I think many networked packages could fit in this category, e.g. Bittorrent or Tor clients, if there are protocol changes.

I think the situation has improved a lot (https://blogs.gnome.org/mcatanzaro/2017/06/15/debian-stretch...), and it would be great to have a stable basis in future and still have up-to-date applications on top as far as possible.

DISTRIBUTION: stable (but also others)

[+] hsivonen|8 years ago|reply

HEADLINE: Provide rolling compiler packages in stable

DESCRIPTION:

There are users who simultaneously want to get their infrastructural packages like compilers from their distro and want to build fresh upstream application releases from source.

This leads to pressure for Linux apps and libraries to be buildable using whatever compiler version(s) that shipped in Debian stable, which amounts to Debian stable inflicting a negative externality on the ecosystem by holding apps and libraries back in terms of what language features they feel they can use.

To avoid this negative externality, please provide the latest release (latest at any point in time, not just at time of Debian stable relase) of gcc, clang, rustc+cargo, etc. as rolling packages in Debian stable alongside the frozen version used for building Debian-shipped packages so that Linux apps and libraries aren't pressured to refrain from adopting new language features as upstream compilers add support.

(Arguably, the users in question should either get their apps from Debian stable or get their compilers from outside Debian stable, too, but the above still seems a relevant concern in practice.)

DISTRIBUTION: stable

ROLE: Upstream browser developer. (Not speaking on behalf of affiliation.)

[+] beefhash|8 years ago|reply

HEADLINE

First-class init that is not systemd

DESCRIPTION

I believe it's notorious that systemd is highly controversial, even spinning off a fork called Devuan. It might be more favorable to reunite the community by including one alternative init system that is, fundamentally, a first-class citizen in the Debian ecosystem.

"First-class" implies that the user is given a choice on new installations in a specified prompt. The default should be the option "systemd (recommended)".

DISTRIBUTION

buster+1 given the expected effort

ROLE/AFFILIATION

Individual and hobbyist system administrator

[+] JoshTriplett|8 years ago|reply

Debian is already one of the few distributions that goes out of its way to provide support for non-systemd init systems. Beyond that, it would help if a non-systemd init system as capable as systemd existed; if one did, I'm sure that Debian would include it and support it. This is a case where the problem isn't "please package and support", it's "please develop".

[+] jameskegel|8 years ago|reply

I would love some type of toggle, or "last chance to turn back" during install as far as being able to signal what type of init system I'd like to use.

[+] ZenoArrow|8 years ago|reply

What do you dislike about systemd? Do you disagree with the ideas behind it, or is your discontentment more about the specific implementation of those ideas? Can you give examples?

317 comments