
Ask HN: What do you want to see in Debian 10 (“buster”)? - lamby
Hey,<p>Chris Lamb here, Debian Project Leader. As a bit of background, I&#x27;ve been around the &quot;startup&quot; scene on and off, even participating in YCombinator during S12. I have a few side projects here and there and I also do a lot of full-stack web development using Python&#x2F;Django.<p>I&#x27;m very much interested in soliciting your feedback and feature requests for the Debian 10 (&quot;buster&quot;) development cycle which opens up tomorrow after the release of &quot;stretch&quot; today. This is obviously a shameless appropriation of Ubuntu&#x27;s post a few months ago and some requests would definitely overlap but I feel we could get some interesting replies nonetheless.<p>Please include in your replies the following bullets:<p>- HEADLINE: 1-line description of the request<p>- DESCRIPTION: A lengthier description of the feature. Bonus points for constructive criticism...<p>- DISTRIBUTION: (Optional) [stable, testing, unstable, or even a Debian deriviative]<p>- ROLE&#x2F;AFFILIATION: (Optional, your job role and affiliation)<p>We would be exteremely interested in your feedback! Everything is fair game -- kernel, security, community, default settings, architectures, init systems (!), desktop, Docker, documentation, default packages, cloud images, etc. etc.. Feel free to comment even if you are using a Debian derivative such as Ubuntu, Mint, etc. too.<p>Thanks, HN!<p>—lamby<p>https:&#x2F;&#x2F;twitter.com&#x2F;lolamby
======
ATsch
\- 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

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

~~~
kasabali
Send a mail to the contact link in wiki, I'm sure they'll help.

------
gub09
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!

~~~
coma_
Seconded.

One often has to rely on stackoverflow (and the likes) to get info because the
doc/wiki is outdated.

That being said, the info provided on theses websites aren't necessarily
correct.

There is for instance no clear, up-to-date, doc on how to install some
packages from testing and keep them updated (pinning ? no pinning ? what
values ? what sources ?)

------
hsivonen
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](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...](https://www.debian.org/doc/manuals/securing-debian-
howto/ch10.en.html#s-security-support-testing)) 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

        > 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.

~~~
hsivonen
At the very least "unstable" has a name with a negative connotation. It has
the air of it being the user's fault if you use it and stuff breaks.

I don't know what the practical breakage situation is, so I don't know if
renaming and repositioning unstable would make more sense than doing it with
testing.

My point is that it would be good for non-expert end users who like Debian's
community image and who want security​ support to have a Debian release
channel that provides fresher software with security support than stable.

~~~
jlgaddis
Have you actually tried unstable? Granted, I haven't used it for a few years
now (the only Debian boxes I have today are servers running stable), but
"unstable" was actually quite reliable. Yes, it did break occasionally (mostly
just minor issues with package dependencies) but those were usually easy fixes
and "unstable" was actually quite usable as an everyday, desktop Linux.

If you haven't tried it, give it a shot. You may be surprised.

~~~
Karellen
I used a daily-updated unstable for a while, and every so often, like once per
18 months to 2 years or so, I'd hit an early boot (grub/initramfs) bug that
rendered my system unbootable. Early boot is dark magic to me, and without
internet access (because my system wouldn't boot) it would take me a few hours
to fix. By the time I did, someone else had filed an RC bug report which would
have prevented that package from upgrading, and it was generally fixed a few
hours after that. But that didn't help me fix my broken system.

That was the risk I accepted. That's what unstable is for. And you need
somewhere like that to find those bugs.

But that's what you need to be able to handle if you run unstable. So I never
recommend it to anyone; if anything I warn people off. If you can't make do
with stable+backports, try testing. But don't try unstable unless you know
enough about it to understand why you shouldn't, and still want to anyway.

Definitely don't run unstable because someone on the internet told you it was
a great way to get up-to-date packages.

~~~
johnbrodie
I've been running unstable for years, and have had what you mention happen
exactly once. If you're on unstable, use apt-listbugs and don't update every
day, and _generally_ you'll be fine. Don't use giant DE's like KDE that go
through a lot of transitions and you'll be even better off.

------
Dunedan
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
Upstream Python specifically recommends _against_ installing Python 3 as
/usr/bin/python; see PEP 394 at
[https://www.python.org/dev/peps/pep-0394/](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.

~~~
Dunedan
To quote from the abstract of PEP394:

> * for the time being, all distributions should ensure that python refers to
> the same target as python2 .

> * however, end users should be aware that python refers to python3 on at
> least Arch Linux (that change is what prompted the creation of this PEP), so
> python should be used in the shebang line only for scripts that are source
> compatible with both Python 2 and 3.

> * in preparation for an eventual change in the default version of Python,
> Python 2 only scripts should either be updated to be source compatible with
> Python 3 or else to use python2 in the shebang line.

~~~
JoshTriplett
That's just a recognition of the existence of that particular quirk of Arch,
and that people may need to cope with that. It's remarkably painful, in
practice, to deal with the one special distribution that makes
"#!/usr/bin/python" do the wrong thing. And unfortunately, some other
distributions don't have a "python2" or "python3" binary, making it painful to
write portable scripts; you can't write "#!/usr/bin/python2" or
"#!/usr/bin/python3" and expect it to work on every distribution out there.

As mentioned, Debian is working on migrating scripts to support Python 3, and
doing so using /usr/bin/python3 , which already appears in the shebang of a
large number of Debian's Python programs.

~~~
LukaD
Arch has had python2 and python3 binaries for a long time. /usr/bin/python2
has been there since at least 2010
[https://git.archlinux.org/svntogit/packages.git/commit/trunk...](https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/python2&id=616713b07507e4e07547d596686d30d633d4d1d3)

~~~
0xelectron
Yes but not the other distributions. Which makes it difficult to write
portable scripts.

------
JoshTriplett
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
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
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.

~~~
lloeki
Indeed. Typical scenario, I have software X that can follow such a process:

    
    
        tar xfvz foo
        cd foo
        ./configure --prefix aze
        make
        make install DEST_DIR=qsd
    

I want to package this to save build and deploy time as well as increase
reliability. It should be _downright trivial_ to:

    
    
        1. find the info explaining me how to do this
        2. understand it
        3. effectively do this
    

Debian fails even starting with step 1. Even if you manage to go through step
2 with some hair left, step 3 is insane compared to the mentioned
alternatives.

This does not even involve step 4 (contributing the package back if it's not
for internal use)

------
JoshTriplett
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
Please check
[https://wiki.debian.org/BusterPriorityRequalification](https://wiki.debian.org/BusterPriorityRequalification),
[https://wiki.debian.org/Proposals/EssentialOnDiet](https://wiki.debian.org/Proposals/EssentialOnDiet)
and
[https://wiki.debian.org/Teams/Dpkg/Spec/ImportantField](https://wiki.debian.org/Teams/Dpkg/Spec/ImportantField).

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

------
heftysync
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
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.

------
miclill
\- 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)

~~~
tkinz27
I can't thumbs up this enough. Packages that start services when they are
installed can cause so many issues between not giving the user the chance to
fully configure them, to weird interactions with distributed applications
talking to each other before all the configuration is ready.

This is definitely one of the defaults that I think RPM gets right over debian
packages.

~~~
JdeBP
This isn't something that is inherent to Debian packaging. So it´s not an
RPM/DEB thing at all.

There was a proposal a couple of years back by one Debian member to do pretty
much this, and buried somewhere on the Debian WWW sites there is an
explanation by that person. Unfortunately, I mislaid the URL and have
forgotten who it was.

The essence, however, is to do as Gerrit Pape happens to have done all along
with xyr Debian packages. M. Pape split them into daemontools and daemontools-
run, runit and runit-run, and so forth. One package installs the softwares and
the service definitions. The other package enables+starts/disables+stops the
services.

* [http://smarden.org/pape/Debian/](http://smarden.org/pape/Debian/)

* [https://lists.debian.org/debian-devel/2012/06/msg00100.html](https://lists.debian.org/debian-devel/2012/06/msg00100.html)

I do the same with my Debian packages.

* [http://jdebp.eu./Softwares/nosh/debian-binary-packages.html#...](http://jdebp.eu./Softwares/nosh/debian-binary-packages.html#Bundles)

* [http://jdebp.eu./Softwares/nosh/debian-binary-packages.html#...](http://jdebp.eu./Softwares/nosh/debian-binary-packages.html#run)

The most oft-repeated complaints about the current system are that policy-rc.d
requires that administrators have prior knowledge of the internals of a
package, to know what services to whitelist/blacklist _before_ installing the
package and seeing what services it contains; and that both policy-rc.d and
the general body of maintainer scripts in Debian and Ubuntu do not play at all
well with systemd's own _preset_ mechanism.

------
avar
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.

~~~
TekMol
I upvoted this even though I am of two minds regarding this issue.

Missing wifi support is my number 1 reason why I don't use Debian on the
Desktop. On the other hand, I don't like non-free software and like the
concept of Debian to not include it.

An alternative could be to put more effort into supporting all wifi hardware
by writng free drivers for it. I will post that as my Feature Request.

~~~
avar
The drivers are free and already in the kernel. I'm talking about firmware
support.

You can still use Debian on the desktop, it has all the WiFi support e.g.
Ubuntu has. It's just the installer that doesn't have parity since it's 100%
free, working around it is a bit of a hassle as I described, but a one-time
pain.

~~~
TekMol
What does "firmware support" mean? Is it not about installing software?

~~~
kebolio
firmware support involves supplying the binary blobs that the driver needs to
upload to certain peripherals like intel wireless cards.

personally i would like to see non-free software kept out of the main disc
images but the images including firmware being more visibly advertised and it
made clear on the download pages what hardware requires it and who needs it.

~~~
TekMol
So the firmware for a certain WiFi card is the same, no matter if you use
Linux or Windows of MacOS? And it is provided by the manufacturer of the
Hardware?

And some WiFi cards works out of the box with Debian? Is that because the
manufacturers of those cards provided the source of their firmware or because
open source alternatives have been written by somebody else?

~~~
catdog
There are a few models that don't need a firmware blob or where the
manufacturer provided source code for it (mostly pre ac Atheros chips).

------
jancsika
\- 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.

~~~
s_kilk
Fedora/RHEL also has transactional package operations via their package-
manager, `dnf`.

One of the reasons I'd prefer not to go back to apt-based distros.

~~~
jancsika
Thanks, I didn't know that.

Does Fedora also have transactional rollbacks?

~~~
s_kilk
Yep, all installations and upgrades are transactional, and can be undone or
rolled-back transactionally

------
rahiel
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...](https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/AppArmorProfiles)

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

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

~~~
based2
[https://github.com/subgraph/subgraph_metaproxy](https://github.com/subgraph/subgraph_metaproxy)

'Metaproxy is not going to work very well with IPv6'

~~~
kebolio
has nothing to do with apparmor.

------
esjeon
\- 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.

~~~
guillemj
I agree this is currently a problem, the solutions are currently either too
heavy weight, or too limited (
[https://wiki.debian.org/DebianRepository/Setup](https://wiki.debian.org/DebianRepository/Setup)).

What I've been wanting to do is to add a better alternative to the dpkg suite,
something that can generate a fully functional repo, matching current
standards, something like a dpkg-genrepository or similar (which would
supersede dpkg-scanpackages and dpkg-scansources, and perhaps even major parts
of mini-dak, which would avoid the need to rewrite it from scratch).

------
Dunedan
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.

~~~
lamby
We're working on it, we're working on it! I definitely plan for buster to be
100% reproducible.

------
rahimnathwani
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.

~~~
pirocks
I to have this issue on my laptop. Gnome​ is the worst offender but definitely
not the only. I've found that changing the font size in mate to around 6 to 8
does help.

~~~
bkor
GNOME supports different dpi per screen just fine under Wayland and 3.24 or
newer. The dpi support isn't done yet, they're further improving it so
hopefully 3.26 and 3.28 will work better (fractional scaling).

------
CaliforniaKarl
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

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

~~~
CaliforniaKarl
Sorry, I'm not in support of switching from OpenSSL to BoringSSL or LibreSSL
as the default.

On a fairly regular basis, I use alot of the weirder things that I don't think
BoringSSL or LibreSSL support.

For example, I was working on iOS profile stuff that called on OpenSSL's
S/MIME enveloping functionality to make signed/encrypted profiles.

------
sandGorgon
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...](https://www.freedesktop.org/software/PackageKit/pk-intro.html))
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.

~~~
sandGorgon
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](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.

~~~
dozzie
> This is the world of Linux software installation.

You don't get to first choose Arch for its different packaging system and then
act highly surprised that it's different and adds to the variety of package
types. Sorry, no banana here.

------
captainmuon
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...](https://blogs.gnome.org/mcatanzaro/2017/06/15/debian-stretch-
ships-latest-webkitgtk/)), 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)

~~~
icebraining
I disagree. Stable _should_ mean fixed, except for security bugs. You say "no
breaking changes", but the Debian devs can only test the base system, they
can't ensure that it won't break whatever software is running on the user's
machine. In fact, my system may have a workaround for a bug that shipped with
stable, and which might break if the bug is fixed later! Stable is stable,
(non-security) bugs and all.

Plus, the point of the pre-release freeze is to make sure the whole system is
stable. If you're constantly releasing new versions of packages, you can never
guarantee that kind of stability.

Personally, I think people should just try Unstable; it works fine for a
desktop/laptop system. I haven't had a major issue in years.

~~~
captainmuon
I haven't used Debian in a while, so yes, maybe "stable" is not the right
branch for me.

I would have been looking for something that you install once, and then it
just works without intervention for a long time. But at the same time I also
want to have access to some latest software, without relying on third party
repositories (because the chance of breakage is very high) or compiling myself
(because then I have to track versions manually).

When I think of a "stable" system, I expect that the underpinning is stable,
no structural changes. Don't laugh, but Windows XP was a bit like that for
many people. Install it, confirm the occasional update, and it just keeps
running for a decade. (Of course, not with the level of security I would
expect from a Linux system...) If I really want a _frozen_ version of an app,
I can just pin the version or compile it myself.

I think this is a very general problem in the Linux world today, you can
choose between "frozen" (stable, LTS) and "unstable" (frequent releases,
rolling). There is no "stable underpinning, fresh apps" distribution, although
the Linux/glibc undersystem is incredibly backwards compatible. If you compile
all the neccessary libraries, you can install almost everything on a distro a
few generations old. But it is very odious, and would be great if you didn't
have to do it.

Probably you're right and I should give unstable a try next time. Or maybe an
alternative would be to make backports more self-contained, so that they would
pull in dependent packages (thereby breaking other apps)? Maybe containers
like snap etc. are a solution?

[Edit: cut down verbosity]

~~~
evand
I think snaps + Debian stable could be that solution. You get the stability of
Debian at the system level with the reliability of app updates from snaps.

Bad updates automatically roll back, and you can subscribe to a risk level at
a per-application level
([https://www.youtube.com/watch?v=-3b9qkl9Z_k](https://www.youtube.com/watch?v=-3b9qkl9Z_k)).

As well, because snaps bundle their dependencies you don't have that problem
you mention of adding a repo and getting busted library versions.

------
hsivonen
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
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

~~~
ZenoArrow
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?

~~~
falcolas
Not the OP, but:

\- It's effectively a black box that nobody but the systemd team really
understands; and the response by said team to problems with systemd too often
defaults to "you're doing it wrong"

\- Systemd is not just an init system, it's a message bus, authentication
system, logging system, container management system, xinitd system, and any
other number of highly coupled systems.

\- Service startup order can still be non-deterministic and fairly slow; hard
init problems have been made harder, while easy init problems "only" remain
easy.

\- Unit files can be stored in a minimum of four separate locations on disk,
and this can be increased dynamically.

\- Failures are opaque, and the failure of systemd triggers the failure of the
entire system.

The original idea that drove systemd's creation is still fairly sound: create
a simple, deterministic, and parallel init system which is better than initv.
The implementation doesn't live up to those goals, and instead of iterating
against that goal, the team's focus has shifted to take over all aspects of
the Linux runtime which isn't managed by the kernel.

~~~
majewsky
> \- It's effectively a black box that nobody but the systemd team really
> understands; and the response by said team to problems with systemd too
> often defaults to "you're doing it wrong"

I'm seeing this attitude a lot. Just last week, at our Linux User Group
meeting, someone brought in a notebook with Debian 9, which didn't boot up
correctly because drives were not detected.

The issue turned out to be really simple (udevd is started after `udevadm
trigger`, so device files do not get created), and I advised them to file a
bugreport with Debian about this. But it still took over an hour to diagnose
because everyone around me was bickering how impossible it was to diagnose
anything with systemd, whereas I just looked at `systemd-analyze plot`,
`journalctl` and poked around a bit.

So, not something that I would call opaque. It's just that they're not used to
it. I never really learned inits before systemd (I knew how to enable and
disable services on $distro, but that was about it).

~~~
falcolas
So, the "impossible it was to diagnose anything with systemd" comes about
because "systemd-analyze plot" and "journalctl" have no meaning prior to
systemd. It's a whole new toolset which needs to be learned.

It doesn't follow any existing patterns, which makes it harder to learn if
you're already familiar with troubleshooting init prior to systemd
(troubleshooting which would have started with a quick trip to /var/log/dmesg
and stopped with /var/log/syslog).

So yes, it can absolutely be learned. But existing administrators have to
abandon most of their existing toolkit to do so.

That all said, that's not what I mean by opaque. By opaque, I'm referring to
how many (few?) people truly grok what's going on inside of systemd. As an
arbitrary point of measure - systemd (and only systemd) consists of over
500,000 lines of C code. It takes a lot of dedication and time to understand
what is going on in that much C code. There are, by GitHub stats, less than 10
people who have contributed (combined additions and deletions in commits) to
even 1% of the codebase, and only 4 who have touched more than 50%.

In comparison, sysvinit consists of about 9,300 lines, and upstart 115,000.

~~~
EmanueleAina
Doesn't that applies to the kernel, libc, openssl, the X server, desktop
environments, and web browsers?

------
heftysync
HEADLINE: Better package discovery

DESCRIPTION: There are a ton of packages in Debian. I sometimes browse through
all of the packages looking for some gem that I didn't know about before. It's
a time intensive process and I don't have any input into my decision other
than reading the description. Sometimes I'll install it immediately. Other
times I'll check out the website to see if it's still maintained (or if
there's a better alternative). It's all a very manual process.

popcon doesn't fill this void. Popcon tells me what packages are popular
across all users. I'm more interested in what a subset of users with similar
interests or preferences would install. Or maybe I want to see what it's like
to live in someone else's shoes. For instance, maybe I'm learning a new
programming language and I want to setup my environment similar to an
experienced user so I have all of the popular libraries already installed.

It would be nice if there was a better way to discover packages that are
relevant to you. Perhaps you could add this feature as a way of getting people
to install popcon? For example, you could say if you install popcon, then it
will upload your set of installed packages and make recommendations for you.

If people are able to add metadata about themselves (e.g. I'm an expert Emacs
user and I'm a golang developer), then you could use that plus their package
list to make recommendations. I could say "show me what packages golang
developers tend to install". Or you could say "for someone with a package list
similar to mine, find out what packages are popular that I'm missing".

~~~
dsr_
Popcon also has the disadvantage that it has an unconscious bias: if you care
about security, you don't send your package lists out to be part of the
survey.

Corporations setting policy for their systems are also unlikely to install
popcon.

The overall effect is to bias popcon in favor of home users who don't think
much about security.

------
jopsen
HEADLINE: Lower barrier for contributors DESCRIPTION: Have a git repo for each
package with a simple issue tracker, like GitHub/gitlab, a flow for accepting
pull-requests and automated CI. Also move away from message boards and IRC to
more user friendly tools.

Currently, it's too hard to report bugs, inspect debian source packages,
propose fixes, etc. The overhead to making a simple contribution is too high.
Note: this isn't a debian specific issue, many open source projects has old
infrastructure.

~~~
RVuRnvbM2e
The problem with a git repo for each package is that not every maintainer uses
git..

I realise that integration could be better, but most of these things do
already exist:

CI: [https://ci.debian.net/](https://ci.debian.net/)

Tool for reporting bugs: reportbug (CLI) / reportbug-ng (GUI). This is also
the way to submit patches.

Inspect debian source packages: apt-get source

~~~
humanrebar
> ...not every maintainer uses git.

I can't think of a valid reason for people to avoid learning git. Is there
one?

~~~
SergeAx
Is there a valid reason to move to git from any other VCS a person happy with,
regarding time and resources one have to spend on it instead of productive
work?

~~~
humanrebar
I can't contrast git with all the different VCS tools that are available, but
different tools have different capabilities with respect to working offline
and reconciling branches.

At any rate, it was an honest question. I'm not familiar with any salient
reasons to not use git. If the only reason is that some developers still
haven't learned git yet, I guess that's an answer. Not a very satisfying one
to me, but it's worth knowing that's the reason.

~~~
jordigh
There are those of us who have learned git and still prefer Mercurial. It's
really annoying that git is supposed to be what we use across all programs,
distributions, operating systems and hardware. Just about ASCII or TCP/IP are
the only things that are about as universal, and git shouldn't be nowhere
nearly as foundational as them. There should be room for more than one way to
do source control.

Sadly, mercurial-buildpackage in Debian is a dead-end. :-(

------
hd4
\- HEADLINE: An install-time option to set up a barebones WM

\- DESCRIPTION: The installer should offer an option to install a simple WM,
like i3 or awesomewm, in the way that there is an option in the minimal
installer to install a DE like Xfce or GNOME. Bonus points if you make it
aesthetically pleasing to some extent.

\- HEADLINE: Kernels in repo which do more than the mainline/default kernel

\- DESCRIPTION: I'm thinking of specifically of the patches by Con Kolivas,
but any other useful pre-compiled kernels being available in the repo would be
great, it would save me having to figure it out by myself and I'm sure there
are many who would welcome the availability of pre-patched kernels, better i/o
schedulers etc

\- HEADLINE: Look into more optimisation (like Solus)

\- DESCRIPTION: Solus (www.solus-project.com) does some optimisation on their
distro that would be a good-to-have in any other distro

\- ROLE/AFFILIATION: Infrastructure programmer for multinational corp

------
brian_herman
HEADLINE

Secure Boot in Stable

DESCRIPTION

UEFI Secure Boot Support in Debian.

Debian does not run on systems with Secure Boot enabled.

DISTRIBUTION

stable/buster

ROLE

I work at an insurance company and all of our development computers and most
of our servers run debian jessie.

We will probably upgrade to Debian 9 very soon! Thanks for all the hard work
on debian Iamby!

EDIT: grammar and formatting

~~~
lamby
> Thanks for all the hard work on debian Iamby!

Oh wow, it's _really_ not just me...

~~~
brian_herman
:)

------
keithpeter
\- HEADLINE: Continue to provide a mechanism for offline installation of a
large selection of the repository.

\- DESCRIPTION: Debian is the only distribution that I know of that provides
.iso images from which you can install the operating system and subsequently
install a wide range of (libre) software. In addition, Debian provides update
.isos. These affordances make installing and maintaining a desktop computer
without an Internet connection, or with a slow and expensive connection,
viable. I hope that Debian will continue to provide this affordance as we
transition from optical disks over the next few releases.

\- DISTRIBUTION: All Debian distributions.

\- ROLE/AFFILIATION: End user (desktop)

~~~
lamby
> without an Internet connection, or with a slow and expensive connection

Could you elaborate more on your particular use-case? Would be interested if
there were _also_ compromise solutions such as smarter binary diffs, etc.

~~~
debianoffline
The internet is often prohibitively expensive for a small minority of users.
But those users often have infrequent access to a high-bandwidth connection.

And of course, odds are that they won't be reading this thread!

I've often been in this situation myself.

~~~
mhall119
A not so small minority globally.

Only 1.2% of India has fixed broadband, but 20% have mobile data.

Even in the USA, less than 30% of the population has fixed broadband, but
almost 75% have mobile data.

[https://en.wikipedia.org/wiki/List_of_countries_by_number_of...](https://en.wikipedia.org/wiki/List_of_countries_by_number_of_broadband_Internet_subscriptions)

------
ghostly_s
HEADLINE: More user-friendly install process

DESCRIPTION: Recently had to reinstall my Debian system for the first time in
a while, and was struck by how user-unfriendly the installer still is compared
to many of the alternatives. I don't think it's necessarily a problem that
it's ncurses, but it could use some more explicit hand-holding. I remember one
point where I needed to select some options from a list and there was no
indication of what operation was required for selection, for example (I think
I needed to hit '+'?). I'm pretty familiar with command lines and curses-type
UI's and this was unintuitive for me, I can only imagine how frustrating it
might be for a more desktop-oriented user.

I also recall a very confusing UI paradigm where the installer steps are a
modal view and there's a hidden 'overview/master menu' you can back out into
at any time, and it's not clear to me how those two modes are related and what
state it leaves your installation in if you back out and then jump into the
installation at a different step.

Generally the explanatory text is quite good at telling you _what_ decision
needs to be made, and providing necessary info to research that decision if
necessary, but _how_ you make those decisions I think could still be improved.

DISTRIBUTION: Stable

~~~
hd4
I agree with this, one of the few things I miss about Windows is the easy disk
setup in the installer.

------
Dunedan
HEADER

Wayland as default display server

DESCRIPTION

X11 is aging, so it's time to switch to Wayland. It'd be cool if buster would
ship with Wayland as default display server.

~~~
thaumasiotes
> X11 is aging, so it's time to switch to Wayland

I can't say I follow the logic. Wayland is aging too, but I assume you
wouldn't be on board with the idea "Wayland is aging, so it's time to switch
back to X11"?

~~~
manquer
I guess OP is implying it is aging architecturally, technical debt and other
perceived problems with X11 which prompted the development of wayland/mir

------
jl6
HEADLINE: Out of the box support for being run in VirtualBox.

DESCRIPTION: I tested the stretch release candidates in VirtualBox, and while
I did eventually get them working, I had to follow the instructions in several
bug reports from across both the Debian and VirtualBox probably project
websites.

I don't mind following instructions, so if there is a reason why this can't be
achieved seamlessly with zero configuration, then I would at least like to see
some official instructions prominent on the Debian website.

COMMENT: Debian is awesome, thanks for everyone's hard work!

~~~
marmaduke
I seem to recall Jessie working fine as a VBox host. What did you run into?

~~~
preek
I'm running Debian boxes 100% of the time on VirtualBox since 4 years. I run
macOS, but only as a host, I spend about 95% of my time within Debian boxes.

Never had a problem that Debian didn't run 'out of the box' within VirtualBox.
Wouldn't even know what that entails.

~~~
JdeBP
One thing that it entails is that the kernels available in Debian 8 backports
are not compatible with the VirtualBox guest tools for Debian 8 that are
published by Oracle. So one has to make the choice on Debian 8 between a
kernel that supports version 2 control groups and having VirtualBox device
drivers for things like the display.

~~~
stephenr
Isn't that a problem for the VirtualBox team to solve - effectively,
supporting newer kernels?

------
aleden
\- HEADLINE: port pledge(2) from OpenBSD

\- DESCRIPTION: Debian has been a great source of innovation and leadership
within the OSS world. Make the next big move by adopting pledge(2) from
OpenBSD to be the first major mandatory security feature on Linux. There is
little hassle in making programs use it, and the LOC in the kernel is tiny
compared to say SELinux. See [1] for more details.

[1]
[http://www.openbsd.org/papers/hackfest2015-pledge/mgp00001.h...](http://www.openbsd.org/papers/hackfest2015-pledge/mgp00001.html)

\- DISTRIBUTION: Any and all!

\- ROLE/AFFILIATION: CS program analysis researcher with MIT/CSAIL.

~~~
heftysync
This isn't as easy as it sounds. Pledge works in OpenBSD because OpenBSD is
simple and all of the necessary code lives in one tree. Pledge is supported in
the vast majority of OpenBSD base programs but very few ports. If programs
aren't written in a careful manner or with an eye to privsep, you end up with
pledges that don't protect much since they are so broad. There are a lot of
programs you can't pledge even with all options turned on because pledge has a
whitelist on the kernel side for what it allows.

It's not impossible for Linux, but there would have to be a lot more
conditional cases in the Linux kernel to handle all of the various ways that
programs would use it. The Linux ecosystem is massive and the number of
alternatives for even basic daemons is large. Instead of pledge, you may end
up with a syscall filter or something like FreeBSD's capsicum. Both of those
are more complex because it puts all of the effort on the application
developer and also gets in their way.

Straight syscall filters and complex systems like capsicum are designed to
allow for arbitrary programs to be protected. In doing so, it moves all of the
complexity to the application developer. The advantage of pledge is that it
does not attempt to be completely generic. Pledge is designed for how OpenBSD
programs are written and what's in the OpenBSD tree. It may evolve over time
to include some functionality for ports, but the overall design is to make a
subset of well written programs easy to protect. If you try to pledge
arbitrary programs, you'll find it doesn't work out unless you rewrite the
program logic to be more well written.

Pledge is conceptually simple, but the kernel side shows how it was tightly
integrated into OpenBSD's way of doing things and has evolved to make it
simpler (by relaxing some behavior or whitelisting parts) and breaking up
other permissions to make it more fine grained when needed.

~~~
aleden
These are good points. However unlike SELinux / AppArmor, a Debian package
maintainer does not need to do make sure things are set up right for pledge-
programs that aren't pledge'd will run just fine (i.e. all syscalls are
allowed by default, not the other way around). So even though adding pledge to
the kernel does nothing by itself, can't usermode programs (the ones for which
pledge makes since) slowly make themselves more secure?

> It's not impossible for Linux, but there would have to be a lot more
> conditional cases in the Linux kernel to handle all of the various ways that
> programs would use it.

Why would there be a lot more conditional cases in the kernel? I'm just
imagining having a bitvector whitelist[] for each task_struct and then in the
syscall_trace_enter functions one indexes into current->whitelist if it's
__NR_pledge.

[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/x86/entry/common.c?h=v4.11#n60)

------
TekMol
HEADLINE: Support for more wifi hardware.

DESCRIPTION: The #1 reason why I don't use Debian on the desktop is missing
wifi support during installation. I wish Debian could write and include free
wifi drivers for all recent laptops.

DISTRIBUTION: Debian 8 on the server. Mint Mate on the Desktop.

ROLE/AFFILIATION: Founder and CEO of a tech startup.

~~~
jlgaddis
Drivers exist in the kernel already. The issue is the proprietary firmware
that these devices require. Debian can't do much more about that, complain to
the manufacturers.

See this other thread:
[https://news.ycombinator.com/item?id=14579821](https://news.ycombinator.com/item?id=14579821)

------
miclill
\- HEADLINE: Continue being an awesome distribution

\- DESCRIPTION: Continue with the values that make debian great. E.g.
[https://www.debian.org/code_of_conduct](https://www.debian.org/code_of_conduct)
[https://www.debian.org/social_contract](https://www.debian.org/social_contract)
[https://www.debian.org/intro/free](https://www.debian.org/intro/free)

\- DISTRIBUTION: (Optional) [stable, testing, unstable, or even a Debian
deriviative]

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

------
yaantc
HEADLINE: Smarter handling of icons files during updates

DESCRIPTION: This is a nitpick/wishlist item really. I started using Stretch
while in testing, and noticed that most updates would download rather large
sets of icons (few MBs). They look like archive files of icons, and I guess
that if any change happens the whole set is downloaded again. This wasn't the
case in Jessie.

When on a slow Internet link, it can definitely slow down upgrades. It would
only be noticeable for Testing/Unstable, as otherwise these sets of icons
would not change much. But when regularly updating testing, often these icons
sets were a significant part of the downloaded data.

It could be nice to make updating those icons optional, for people behind slow
links. Alternatively, handling them as a versioned list (text, easy to diff
efficiently) + independent files could make their update more efficient than
compressed archive files.

Again, just a nitpick/wishlist item. It's just that I haven't chased down what
this comes from (I guess for GUI package management like synaptic? TBC) and
don't know where this could be reported. You just gave me the opportunity ;)

DISTRIBUTION: Testing/Unstable (any version with frequent changes)

~~~
kasabali
Check [http://debdelta.debian.net](http://debdelta.debian.net)

------
kpcyrd
HEADLINE: Decent rust support

DESCRIPTION: On rolling release distros there's currently a vim version that
ships rust syntax highlighting, rustc and cargo. This is pretty much all you
need to get started with rust development. Debian stable currently ships
rustc, but lacks cargo, which is rather essential if you actually want to
compile your project on a debian server. The vim-syntax thing would be nice to
have. :)

DISTRIBUTION: stable/stable-backports

------
markvdb
HEADLINE: nginx-rtmp support in Debian

DESCRIPTION: At [https://fosdem.org](https://fosdem.org) , we are using the
nginx rtmp module intensively. It seems it is becoming a de facto standard
when an in-house streaming server is preferred, as opposed to an external
streaming platform. It combines excellently with ffmpeg, the recently pacakged
voctomix and several components of the gstreamer framework, to create an
excellent FOSS video streaming stack. Some debconf video people too seem to be
interested. Some positive interest from Debian nginx pacakagers.
Unfortunately, no clear way forward yet.

Hopefully, Buster opening up might create some opportunities to get things
going again!

SEE ALSO: [https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=843777#23](https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=843777#23)

DISTRIBUTION: Debian 10 stable & Debian 9 backports.

ROLE/AFFILIATION: [http://fosdem.org](http://fosdem.org) staff (= all year
round volunteer), responsible for video streaming & recording since FOSDEM
2017

~~~
markvdb
Update: spoke to the nginx maintainers again on irc, and Christos Trochalakis
promised me to work on the packaging himself this week! Really really happy
about that!

------
rkv
HEADLINE: Stabilize dpkg C library (libdpkg)

DESCRIPTION: Any plans to go ahead and stabilize the dpkg library for buster?
Having access to a stable package management library is essential in our
software. Ie. being able to verify package signatures and querying the
database for files. Both of which are not supported.

DISTRIBUTION: buster

~~~
guillemj
This has been part of the dpkg roadmap for some time now
([https://wiki.debian.org/Teams/Dpkg/RoadMap](https://wiki.debian.org/Teams/Dpkg/RoadMap)).
And something I'm slowly but progressively moving towards. But TBH it has been
low priority. Knowing of projects that require it, and specifically which
parts, or that are already using the static libdpkg library are very valuable,
so that those parts can be improved.

If there's enough interest, my plan could be to expose just a subset of the
current libdpkg as a shared library for buster.

~~~
rkv
> Knowing of projects that require it, and specifically which parts, or that
> are already using the static libdpkg library are very valuable, so that
> those parts can be improved.

What would be the best way of contributing this sort of information?

~~~
guillemj
Either here or I guess a mail to the debian-dpkg@lists.debian.org mailing list
would do, whatever is most convenient. :)

------
apenwarr
Eliminate all the scripts that go into a package, moving them to runtime. This
is the only way to eliminate instability caused by buggy scripts that then
prevent upgrades.

Also get rid of all interactivity during install and upgrade. It's deadly for
managing big fleets.

~~~
guillemj
I assume you mean maintainer scripts here. If so we are already going in that
direction:
[https://wiki.debian.org/Teams/Dpkg/Spec/DeclarativePackaging](https://wiki.debian.org/Teams/Dpkg/Spec/DeclarativePackaging)

For interactivity that should in principle be a solved problem with debconf,
if it's not, we would like to hear what's lacking. If there is a problem with
a particular package then a bug report would be appreciated.

------
vinlinux
HEADLINE: Regression fixes from upstream

DESCRIPTION: GCC 6.4 will be released soon (July). I wish Debian will get all
the regression fixes that this update will bring (according to the new
numbering convention, version 6.4 does not mean new features, so no breaking-
changes, only fixes). Same for CUDA 8.0.61 (already available for ~5 months)
which is a maintenance update after version 8.0.44, the one available in
Stretch. I'm saying this because Jessie never got the latest bug fix release
(4.9.4) for the 4.9 series of GCC, not even in the backports (it still offers
the 4.9.2 instead). I wish there was a policy that allowed regression fixes
from upstream to be ported and with the same priority as security fixes. GCC
and CUDA are only examples, the same scheme would be applicable to any other
package as well. In my view, this would foster Debian adoption on desktops at
a higher level. If this can't be done for the current Debian Stable, I hope my
(and other people's similar) concerns will be taken into account in the
future. As a developer, I care about this level of support. We all love
Debian, we'd just like to make it better. Thanks.

DISTRIBUTION: Debian Stable

------
shmerl
\- HEADLINE: improve transitions and out of the box usability of rolling
Debian variants.

\- DESCRIPTION: Since Debian testing / unstable are often advertised as
targeted for desktop usage, they can benefit from some more focus on
preventing breakage. I know it's somewhat counter intuitive to expect
stability from "unstable" or "testing" variant, but at the same time Debian
can benefit from avoiding the stigma of server only distro. Having out of the
box robust desktop experience (which is not falling behind) is the goal here.

In the period between Jessie and Stretch, testing had a number of breakages in
my KDE desktop. Packages fell out of sync (like KDE frameworks and Plasma
packages weren't properly aligned, because some packages were stuck in
unstable because of not building on some archs) causing all kind of
instability issues. It lately became a bit better, but I think desktop
stability can get some more love, especially for the most popular DEs like
KDE.

And if neither testing nor unstable fit that role, may be another branch
should be created for it?

\- DISTRIBUTION: Debian testing / unstable.

\- ROLE/AFFILIATION: Programmer, Debian user.

------
mtgx
Headline: Stronger security enabled by default

Description: More KSP security features enabled by default, perhaps even
Firejails pre-installed, Wayland as default along with flatpaks, etc

------
miclill
\- HEADLINE: Make it easier to use newer software.

\- DESCRIPTION: I think there is lots of ways. Things like flatpak look
promising but also docker. It would be nice if there where less papercuts when
using those things. I also dream about a command named "playground [name]"
which instantly gives me a shell where I can try stuff without interfering
with anything else. When finished I can just "playground remove [name]". I
know that it's possible today but it's a but of a hassle.

\- DISTRIBUTION: (Optional) [stable]

\- ROLE/AFFILIATION: (software developer, mostly fullstack webdev)

~~~
zachlatta
Shameless self-promotion: I've been working on building that playground
command in my free time at
[https://github.com/zachlatta/try](https://github.com/zachlatta/try).

Maybe we could add support for Debian packages?

------
cyberpunk5000
HEADLINE: separate user "apps" from system "packages"

DESCRIPTION: In my use cases, which I think are common, I want a stable base
operating system and user interface, but for the applications I work with
every day (browser, compiler, office suite, etc.) to be cutting edge.

My dream is to separate packages into two tiers with different update
policies, similar to the Android and Apple app stores, and for that matter BSD
ports. Platform software like the kernel, system libc, X11, and desktop
environments release and update like stable. "Apps" like Firefox and
LibreOffice are easily installed and updated on a rolling basis.

I know that I can achieve this now with a custom backports and apt pinning
config, but that's more of a low-level project than I'm envisioning. My
request is for something that's more of a newbie-friendly point-and-click sort
of thing.

------
coma_
HEADLINE: better keychain integration/mechanism for handling PGP/SSH

DESCRIPTION: It would be great to have a central keychain where keys (SSH,
PGP) could be unlocked on a sessions basis (think of a merge between gpg-agent
[who wouldn't scream about being hijacked every other day] and ssh-agent [who
wouldn't be shell-specific and able to handle multiple keys without having to
manually :

> eval $(ssh-agent -s) > ssh-add /path/to/key1 > ssh-add /path/to/key2 > ...

])

As a desktop user, what I would like is, on a session basis, when I first
provide the passphrase for a given key (when I ssh into a server from the CLI
or decrypt a PGP encrypted email from Thunderbird [with enigmail] for
instance) have a keychain securely unlock these keys for the duration of the
session (that is, until I lock the screen, close the lid or log out).

------
justin_vanw
\- HEADLINE: Proper support for installations on GPT partitions

\- DESCRIPTION: I have tried installing debian many times on various machines
and have had huge trouble getting the install usb stick to boot properly (or
in the end for the bootloader to install) with Debian. Ubuntu installs
flawlessly on these machines.

\- DISTRIBUTION: (Optional) [stable, testing, unstable, or even a Debian
deriviative]

\- ROLE/AFFILIATION: (Optional, your job role and affiliation)

------
chungy
HEADLINE: Promote x32 to official status and recommend it as the default
install.

DESCRIPTION: The Linux x32 ABI, for the most part, combines the best of both
worlds in x86: the lower memory footprint of 32-bit software (and likewise,
4GiB process limits to go with it) by keeping pointer sizes and data types the
same as i386, but still allowing applications to take advantage of the
expanded registers, instructions, and features of x86_64 CPUs. For most
systems that aren't database servers, this can result in large memory
footprint reductions and greater performance as a result. Debian has had an
unofficial x32 port for years, that is presently difficult to install and get
running.

DISTRIBUTION: unstable

------
feikname
HEADLINE

WiFi-direct GUI

DESCRIPTION

Using WiFi direct on most debian-based distros is a hassle, requiring a lot of
manual terminal work. A GUI in the network section for WiFi Direct would make
connections easier and faster.

~~~
lamby
Is there an existing such feature in other distributions out of interest?

~~~
voltagex_
[https://stackoverflow.com/questions/31877144/how-to-set-
up-a...](https://stackoverflow.com/questions/31877144/how-to-set-up-a-wifi-
direct-connection-between-android-and-linux)

Connman appears to be the only GUI option here:
[https://01.org/connman](https://01.org/connman)

------
warp
HEADLINE: faster release cycle

DESCRIPTION: In the past I've often ran into stuff in Debian just being too
old for my needs. I don't need the bleeding edge, but two years is a really
long time. I've switched to Ubuntu a few years ago, but not being a fan of
Canonical it would be nice if I could come back to Debian.

DISTRIBUTION: stable

ROLE: full stack web developer

~~~
vacri
Use Debian Unstable on the desktop, and Debian Stable on the server. Despite
the name, Unstable is pretty stable - it's just making it clear that you're
dealing with relatively fresh packages and these often break as they're not
battle-tested.

Unstable isn't built from bleeding-edge nightlies, but it's generally up-to-
date.

------
heftysync
\- HEADLINE: Bring back the standard (console) Live CD

\- DESCRIPTION: Jessie had a standard Live CD. While the HTML still refers to
this flavor, it is not found on any mirror that I checked for Stretch.

I have to use the live CD to install ZFS on Root. I would prefer to not bother
downloading or booting a desktop environment when I don't need one.

I don't know why it was removed, but the name was always strange to me. Name
it textonly or expert or something so people don't choose it. Standard sounds
like it is the recommended image.

\- DISTRIBUTION: Live CD

------
HateInAPuddle
HEADLINE: A way to bootstrap something slimmer than "minbase" for building
images.

DESCRIPTION: When building images (especially container images), there should
be a way to only install the bare minimum to make apt work. No init system, no
bash, no filesystem utilities, nothing. Even `debootstrap --variant=minbase`
is overkill in that regard.

One way would be to create an option for deboostrap that would accept a list
of desired packages (similar to pacstrap from Arch) instead of using
"\--variant".

------
allan_wind
\- HEADLINE: thunderbolt, amt firmware loader

\- DESCRIPTION: The last laptop that I bought from Lenovo had a thunderbolt
port, and I had to use that port to get 3 x 4k monitors to work. The hardware
shipping with non-functional firmware. The only way to upgrade the firmware
was by booting Windows. I was not sure if there were other devices with old
firmware, so I spent hours waiting for a full OS upgrade. Dell was working on
a thunderbolt firmware loader at the time, not sure if they released it by
now.

Similar situation with the AMI firmware security issues (CVE-2017-5689). The
only way to upgrade (afaik) is by running a particular windows installer.

It seems really dumb having to buy a throw-away drive just to be able to boot
windows to upgrade firmware. Obviously, I understand this at the feet of the
hardware vendor. I was going to suggest pre-installed Debian, but Lenovo will
ruin that with pre-installed crapware.

\- DISTRIBUTION: stable

\- ROLE/AFFILIATION: entrepreneur

------
qwerty987
HEADLINE: kindly support "SecureBoot" as soon as possible(for all of us who
are dual booting debian and MSWindows)

------
sherr
HEADLINE: Finalise LXD support

DESCRIPTION: It would be great if Debian finished its LXD (container
hypervisor) packaging and got it up to a decently complete level (per Ubuntu).

[https://wiki.debian.org/LXD](https://wiki.debian.org/LXD)

------
heftysync
HEADLINE: More fine grained meta packages as community recommendations.

DESCRIPTION: There are a few Debian meta packages but they are really broad.
Example: it would be great if there were a few developer leaning packages
grouped into one meta package.

For instance, I always install etckeeper, apt-listchanges and apt-listbugs. I
think anyone following testing or unstable would want to install those and I'm
not aware of any real alternatives to those. I can't imagine using unstable
without apt-listbugs to warn you when there high priority bugs in the packages
that were already uploaded.

DISTRIBUTION: mixture of testing/unstable.

------
cyberpunk5000
HEADLINE: concrete release timelines

DESCRIPTION: For many years I've been fond of Debian and have used it for side
hobby projects. But I've had to use Ubuntu and Fedora for real work because I
need a modicum of certainty about the intervals between releases.

I acknowledge that Ubuntu's rigid release-every-6-months, LTS-every-24 is
impractical for a volunteer project with high standards. But without _any_
firm timeline it's impossible for me to plan and use Debian in production.

For example, a commitment that releases will always be spaced somewhere
between 6 and 24 months, would go a long way.

~~~
kasabali
This myth about irregular Debian releases need to die.

Debian releases every 2 years (give or take few months):

Debian 3.1 Sarge (June 2005) Debian 4.0 Etch (April 2007) Debian 5.0 Lenny
(February 2009) Debian 6.0 Squeeze (February 2011) Debian 7.0 Wheezy (May
2013) Debian 8 Jessie (April 2015) Debian 9 Stretch (June 2017)

This is a more than a decade of track record.

------
Ianp5a
HEADLINE: Installer easy option to separate OS / and /home partitions.

DESCRIPTION: It is often recommended to separate the OS partition from the
users data partition containing /home. This should be available as an easy
option for non IT users. If 1 partition exists, a recommended split MB size is
is default. If 2 partitions exist, they are checked for OS files and home
files, so the user sees which one will be overwritten. This is convenient and
a safety net for most users, and a lifeline for non IT people who may not know
the recommendation, or how to proceed.

~~~
ghostly_s
The installer already provides this option as a suggestion?

------
pksadiq
\- HEADLINE: Try to include gtk4 in Debian 10 GNU/Linux

\- DESCRIPTION: It would be nice if Debian testing freeze is delayed until an
enough stable version of gtk4 is included in testing (and thus eventually in
next stable).

~~~
jbicha
Ubuntu 17.10 Alpha already has an early snapshot of gtk4. Debian will get it
later this year.

------
anguis_fragilis
\- HEADLINE: Aggressive Optimization of PNG Files

\- DESCRIPTION: PNG image files use too much space in Debian's source tree; in
user's install size; and in Debian's website.

All meta-data that does not affect display should be removed and the file
should receive a complete lossless compression run with an optimizing tool.

Just try: find / -name "*.png" 2>/dev/null | xargs -d '\n' optipng -preserve
-o7 -zm1-9 -strip "all"

A byte here, a byte there, and then suddenly your system is now several MB
smaller and runs actually faster.

Upstream should be made aware of this.

Thank you.

------
hultner
\- HEADLINE: Run testing or unstable containers with ease on stable

\- DESCRIPTION: I would absolutely love a well supported container system for
running testing/unstable in a container. I feel that docker requires a lot
upfront work with mixed results.

We often develop software using packages of the next debian version (such as
Python 3.6) and these packages aren't always available in backports or
otherwise outside of testing, in these cases it would be really nice to easily
boot up this software in a container.

\- DISTRIBUTION: stable

\- ROLE/AFFILIATION: Lead Product Developer at Cetrez

~~~
pja
I know it’s not as lightweight as a container system, but I’ve had quite good
experiences on this front with virt-manager (and it’s associated command-line
tools virsh, virt-install et al).

It’s straightforward to spin up fresh local virtual machines, and you get
access to the full KVM infrastructure if you need it.

~~~
hultner
That is what I've been using as well but it would be nice with a more lean and
lightweight system. Otherwise virsh, etc is really good, much more reliable
then Docker from my experience.

------
heftysync
HEADLINE: Latest elixir in Debian

DESCRIPTION: Debian unstable still has elixir 1.3.3. It looks like the
"official" path forward is to add Erlang Solutions as another apt repository
and install packages from there. However, this feels wrong to me as a user. I
want to get packages from Debian.

I can't remember which distribution it is, but IIRC one of the other ones has
developers upload builds from their personal machines and they are signed with
GPG. I don't like this because it is opening yourself up to problems. Perhaps
someone uploads a malicious binary build. Or perhaps their developer machine
is compromised and someone else uploads it for them or infects their upload.

All of this would go away with 100% reproducible builds in Debian and when it
builds on Debian infrastructure. That's not the case when Erlang Solutions is
setup as the provider.

I realize this is a minor point as few people will install it, but I was
surprised that other distributions include the latest Elixir but Debian does
not. The latest is 1.4.4 and I couldn't find anything related to 1.4.x in the
upload queue or bug reports. It seems like the package maintenance has been
outsourced to Erlang Solutions.

------
kimented
\- HEADLINE: Ask all questions in one go

\- DESCRIPTION: I like to install Debian on old computers, and the better way
to do so is to use the netinstall CD. But the installation is quite long,
because of slow network and slow computer. Then, I must watch the computer
every few minutes to respond at some questions (which desktop, software
options...). Sometime I do not respond, and the installation is stuck for a
while. It will be very useful to ask all questions in one go, at the
beginning, and never ask till the end.

\- DISTRIBUTION: netinstall

\- ROLE/AFFILIATION: Draftsman, French free software enthusiast

Off topic: I am pleased that Debian still provide a non-pae kernel, then I can
reuse some old hardware (for example: make a local distro mirror, a file
server, recycling an old computer for someone who would like to test
GNU/Linux...). I don't understand why the non-pae kernel is not the default
for the x86 computers: if someone really need a computer with more than 4GB of
ram, why would he use a 32bit computer? He should better use a newer computer.

~~~
ibaldouy
This is already done through DebConf, but some packages use it wrong so
DebConf can't ask the questions before actually installing the package :-(. If
you see some package asking questions in the middle of the instalation instead
of at the start, please, file a bug report for it. Thanks!!!

------
oanepackino
\- HEADLINE: Remove Perl and Python as dependencies for the base system

\- DESCRIPTION: A minimalist default install as a common base for containers,
servers and desktops should not depend on interpreters except for a POSIX
compliant shell. The FreeBSD project put a lot of effort into removing perl in
2002 and succeeded.

\- DISTRIBUTION: stable

\- ROLE/AFFILIATION: Software developer, Germany

~~~
kasabali
Python is not part of the base system (at least it is not installed nor
required in minbase debootstrap profile and apt recommends is disabled).

I wholeheartedly agree with removing Perl. Also a lot of other questionable
packages in the essential set.

------
zeroheure
HEADLINE: improve Rescue Mode in debian-installer

DESCRIPTION: How to help users who got problems installing Debian ? The bug
reports against d-i shows that problems are various and unpredictible. So the
only way to help is to provide tools for looking around documentation and
breaking system.

1\. in d-i itself : if something goes bad, propose to save logs (and others
output like disk informations) on usb key, on the network, on the internet,
etc.

2\. add some urls where user can found help

3\. look for little improvements when launching Rescue Mode : for example
access it through ssh, display disk information (remember this patch
bug#798465 ?), suggest some config files and log to look in, etc.

4\. provide basical help on d-i tools. For example, why grub-installer can't
show 2 lines about options ?

5\. everything that can't be achieved because of limited space or Ram should
be available in a dedicated page on debian.org

Etc.

These are just selected samples. There is many little rooms for improvements
on this point.

DISTRIBUTION: stable and sid

ROLE: sysadmin

------
based2
[https://www.reddit.com/r/debian/comments/6hye8z/ask_hn_what_...](https://www.reddit.com/r/debian/comments/6hye8z/ask_hn_what_do_you_want_to_see_in_debian_10_buster/)

------
amorphid
HEADLINE: list apt package dependencies

DESCRIPTION: something like 'apt-get deps <package>' returning a list of all
deps for a package. This would be super duper when trying to install a
standalone package file on a system where the deps aren't already present.

~~~
guillemj
There is already «apt-cache depends <package>» or even «apt-cache depends
--recurse <package>». Perhaps those are missing something?

~~~
amorphid
To clarify, I'd love to see a raw text list of just the packages, without
header text and/or other things.

------
johntadd
\- HEADLINE: Kernel and Desktop

\- DESCRIPTION: This request might not be considered in a short term or never
be considered, but personally I hope that can be done.

For Desktop, I wish there exists Debian defined environment or interfaces
which transparently integrates with desktop environment like power manager. So
when switching between different, for instance, desktop environment or window
manager, I don't need to tune for specific setting (particularly non-Debian
way) in order to get it work.

For Kernel, I would like to see integration with seL4.

\- ROLE/AFFILIATION: Software Engineer

------
brimstedt
Headline: better install options

Description: in debian installer you can chose a few standard setups. The
default options are a bit crazy to me and also i miss alot of pkgs by default.

A bit of cleanup would be nice (iirc you can select database server for
example, that ll give you my/maria)

It would be nice if you yould specify a code like "xxx/yyy" that would resolve
to a public repo of predefined templates in which you could also define your
own.

I for one, would define a server, workstation and laptop setup. Server setup
would includr sshd, screen, etc

~~~
Shish2k
A site which allows you to create your own preseed files via GUI, and then
gives you a tinyurl-type-code, seems like it should be a relatively easy CRUD
app for someone who wants to get started contributing to debian :)

Could be done third-party, but with official debian support we could get
support into the installer to type "install di://g3dz" rather than "install
preseed=[http://mypersonaldomain.com/preseeds/g3dz"](http://mypersonaldomain.com/preseeds/g3dz")
(last time I was doing this for myself, typing the full URL of my preseed file
into the bootloader was by far the most annoying part of the process :P)

------
tmaly
HEADLINE: better documentation and cookbook for systemd

DESCRIPTION: I know systemd is very controversial, but if we are going to be
stuck with it, I would like to see more documentation and examples.

------
bodhammer
\- HEADLINE: Support for LXD (And LXC 2.0)

\- DESCRIPTION: XD isn't a rewrite of LXC, in fact it's building on top of LXC
to provide a new, better user experience. Under the hood, LXD uses LXC through
liblxc and its Go binding to create and manage the containers. It's basically
an alternative to LXC's tools and distribution template system with the added
features that come from being controllable over the network.

\- DISTRIBUTION: Stable

\- ROLE/AFFILIATION: Enthusiast and wanna be developer

~~~
_delirium
LXD is being worked on and should be available in unstable soon (and then
subsequently in the next stable release). More info here:
[https://wiki.debian.org/LXD](https://wiki.debian.org/LXD)

------
CiPHPerCoder
I'd like to see packages be handled differently to where nothing is forked.

Instead of pinning to, say PHP 7.1.5, pin to 7.1 and stop backporting fixes.
It's okay to have 7.1.6.

------
coma_
HEADLINE: improve website/doc to ease install process

DESCRIPTION: installing Debian should be a straightforward process for average
Joes and Jannes, that's not the case currently. The process to acquire the
proper ISO and have it on a bootable USB stick/SD card is overly complicated
(because the information is hidden, missing or incomplete).

As an average Joe, when you visit debian.org there is no obvious place to
click to get the latest stable ISO. The default (in a tiny box in the upper
right corner on the homepage) is a net-install ISO. net-install are sub-
optimal for users who require special firmware for their network card (dvd-1
amd64 should be the default).

You should consider that the default install process for most desktop users
will consist of installing Debian from a USB stick on an amd64 system. Once
the the right ISO is properly put forward, you should provide clear and
detailed info on how to properly transfer the ISO to the USB stick and make it
bootable.

Etcher is a free/libre, cross-platform, user-friendly, straightforward GUI
(over "dd" iirc) that takes care of the process of making a bootable drive. It
should be promoted and made part of the install doc.

Same goes for SD-card installs, many single-board computer enthusiasts (who
are not necessarily tech savvy) renounce trying to make a bootable SD card
themselves and simply buy a pre-installed one. Simply because the information
isn't provided in a straightforward fashion on Debian website and they are not
offered with a relatively simple process _.

_ no, using "dd" from the CLI isn't simple: as a Joe you must care about many
concepts that are un-obvious (wait what does it mean "the volume is mounted" ?
how do I unmount it ? how do I identify the proper volume ? fuck I unmounted
the drive, it won't auto-mount anymore ! file-system ? what are you talking
about ? MBR ? DOS-compat...)

ROLE/AFFILIATION: electronics engineer, based in Europe, involved in local
initiatives to promote free software (LuGs, crypto parties, hacker spaces,...)

Thank you for your awesome work, I wouldn't be involved in promoting
free/libre operating systems if it wasn't for Debian (a great community
project that cares for users rights/freedoms and provides an overall simple
desktop experience).

~~~
coma_
Case in point (from /r/thinkpad):
[https://www.reddit.com/r/thinkpad/comments/6goe9h/just_order...](https://www.reddit.com/r/thinkpad/comments/6goe9h/just_ordered_my_first_thinkpadyeah_baby_which/)

(check the whole thread)

------
kurgan
HEADLINE: No Systemd

DESCRIPTION: Systemd is creating far more issues than benfits. Everyone knows
it except for its author, L. P. Still Debian has chosen to go down this road,
and the result is that people had to fork and to move to Devuan. Go back to a
sane, simple, stable init system. This is expecially true for a server-
oriented distribution.

ROLE: Fabio Muzzi, freelance linux sysadmin since 1995, loyal Debian user up
to Debian 7, now Devuan user and supporter.

~~~
sgala
+1.

Systemd failures are under our eyes
[https://twitter.com/systemdsucks](https://twitter.com/systemdsucks) and are
not acceptable for a server distribution.

------
acd
Headline: Light Debian desktop theme

Describtion: Debian should have easy usability to set the desktop theme to a
light color theme. Right now it is quite difficult for users to change desktop
look and feel. Please also make usability testing of changing desktop
settings. The current color scheme which is dark does suit all users. A dark
and light theme should more users covered.

Many thanks to all the Debian developers for creating a great distribution!

~~~
pirocks
Which desktop environment are you referring to ?

------
amorphid
HEADLINE: Create local copy of remote repos

DESCRIPTION: Personally I'd like something like 'apt-get update --local' which
pulled down a remote copy of every repo. That's be super handy for something
like a build machine, and it'd reduce the need to install & maintain an Aptly
repo.

~~~
bigon
Did you look at apt-cacher-ng or the other similar tools?

~~~
amorphid
I'm not sure. I've never used apt-cacher-ng, and it's not in Debian. It'd be
more accurate to say I'd like the ability to create a local mirror of all
remote repos, not just caching repos I've downloaded. Something that would
usable offline.

~~~
kasabali
Try aptly or debmirror.

------
heftysync
HEADLINE: Day(s) old sid as a rolling distro

DESCRIPTION: I think I represent a number of users. We want to use unstable as
a rolling distribution, but we don't want to run into every edge case. Testing
doesn't update fast enough and doesn't have as good of security. There's no
middle ground between absolute bleeding edge and the too conservative testing.

I used to use unstable but there's that annoying race condition where I could
upgrade at the exact wrong time when brand new (broken) package versions were
uploaded and not enough time has passed for even the first round of bugs. I'd
like a day safety buffer so apt-listbugs has a chance to warn me about
catastrophic bugs.

Setting up a true rolling distribution may be too much work for Debian. Actual
Debian developers will be running unstable. It would be nice if there was a
middle ground for non-Debian developers who want a rolling distribution but
don't want to get hit by every edge case in sid.

I think a nice compromise would be to cache the sid packages for a day (or
two) and set that up as another branch. A full day of possible bug reports
from people on bleeding edge sid would give us a chance at missing the
catastrophic edge cases while still being very current.

I think this could encourage more Debian developers. If I wanted to join
Debian as a DD, I would need to have an unstable installation somewhere. It
wouldn't be my daily driver because I don't want to run into those breaking
edge cases. If my daily driver was day old sid, I could have another machine /
VM that runs sid and would almost be identical to what my daily driver is
running. It's not like testing where packages could be entirely different due
to the delay in migrating.

Unlike testing, day old sid would migrate all packages even if there are
release critical bugs. There would be no waiting period beyond the strict day
limit. If there is a catastrophic edge case, people already on day old sid
using apt-listbugs would be able to avoid it. New installations would hit it
but you could warn users (see below).

If you make apt-listchanges and apt-listbugs as required packages for day old
sid, then people could be informed about what broke on the previous day.

It would be nice to integrate apt-listbugs into an installer for day old sid
and fetch the latest critical or high priority bugs before the installation. A
new user could then decide if that's a good day to install. Or you could have
a simple website that says here's the day old sid installer and these packages
currently have critical or high priority bugs. If you would install those
packages, maybe wait another day or two for it to settle down.

Maybe day old sid is too close. Perhaps 2 day sid or 3 day old sid? I don't
feel that testing fills this role already because testing waits for 2-10 days
and won't update if there are release critical bugs. I'm fine with something
closer to bleeding edge sid, but I'd really like to allow a few days for the
bleeding edge users to report bugs so I can decide whether to upgrade. I don't
have an expectation that day(s) old sid is more stable than testing or less
unstable than sid. All it provides is a buffer so I can get bug reports and
make my decision about whether to upgrade.

DISTRIBUTION: day old sid.

~~~
ZenoArrow
[https://www.slant.co/topics/6289/viewpoints/13/~rolling-
rele...](https://www.slant.co/topics/6289/viewpoints/13/~rolling-release-
linux-distributions~debian)

>"Debian is available in three releases (stable, testing or unstable which can
all be installed as a rolling release(by replacing the releases name(eg:
stretch) with the code name(eg: testing)."

~~~
heftysync
It's not really the same thing though. Packages in testing get migrated 2-10
days unless there's a serious bug report and then they get delayed
indefinitely. Not all bug reports are going to affect me. I've run testing
before and packages would get delayed on some bug that didn't affect me at
all.

I ended up running a mixed testing/unstable just to pull in updated versions
of programs from unstable that I wanted. However, that isn't a great situation
either since now you can run into situations where you're using a
configuration that few or no other people are running.

I think if there was simply a sid distribution that cached the packages for a
day or two to allow for catastrophic bugs to get reported, I would have what I
want. I'm fine with working around bugs in sid when the pop up. I just want a
heads up from people following the absolute bleeding edge.

------
ibaldouy
\- HEADLINE: 100% SystemD

\- DESCRIPTION: Currently many packages still ship without SystemD unit files
using LSB init.d scripts instead and of course not using any security measures
like private tmp, capabilities, etc...

\- DISTRIBUTION: Buster

\- ROLE/AFFILIATION: Freelance Linux sysadmin

------
pette
Too late. Switched everything to Devuan.

No systemd (and pulseaudio if desktop) for me.

------
brimstedt
HEADLINE: Disable pcspkr by default

DESCRIPTION: Please disable pcsprk by default :-)

------
omginternets
HEADLINE

SELinux installed by default

DESCRIPTION

Not sure what else to say...

~~~
bigon
This one is (partially) for me I guess.

There is still some work needed for this to happen.

The SELinux support should be added in the debian-installer and the policy
needs to be generic enough to support several (basic?) usecases.

The later is the difficult part, if the policy is not working for them, people
will in most of the case just disable SELinux completely.

Having a list of well tested usecases (LAMP, DNS,...) that we could support
would maybe be a good start.

Help is always welcome of course.

~~~
omginternets
How can I (familiar with linux, but not with the details of SELinux) help?

------
srikwit
\- HEADLINE: Sysmon equivalent for Debian

\- DESCRIPTION: Tool to log process spawns, kills, network connection
start/stop, file modifications etc. onto event logs for review.

\- DISTRIBUTION: Kali

\- ROLE: Security Analyst

------
qwerty987
Please support "Secureboot" ASAP (for all of us who are dualbooting debian
with MSWindows )

------
asbesto
I wish to see systemd eradicated from debian. Back to SysVInit!

------
Immortalin
Headline: Better way to switch between 2.5 and 5GHz wifi modes

------
vasili111
What about OS itself? Is it fully reproducible build?

~~~
kosinus
[https://wiki.debian.org/ReproducibleBuilds](https://wiki.debian.org/ReproducibleBuilds)

------
buster
My picture as avatar! :)

------
JTechno
systemd out

------
pwdisswordfish
HEADLINE: Easier way to create local packages

DESCRIPTION: My first distro was Debian. Then, for a while, I used Arch. But
it kept irritating me with its total disregard for backwards-compatibility
(symlinking /usr/bin/python to python3), coarse-grained packages (want to
install QEMU PPC without pulling in every other architecture as well? too
bad!), lack of debug packages (good luck rebuilding WebKit just to get stack
traces after a SIGSEGV), and package versioning ignoring ABI incompatibilities
(I once managed to disable the package manager by upgrading it without also
upgrading its dependencies... and later cut off WiFi in a similar manner). So,
when I finally trashed my root partition a few weeks ago, I decided to use the
opportunity to return to Debian.

One thing I miss from Arch, though, is having an easy way to create a package.
It's simply a matter of reading one manpage, writing a shellscript with
package metadata in variables and two-to-four functions (to patch up the
unpacked source, check the version, build it, and finally create a tarball),
and then running `makepkg`. And it will just download the source code, check
signatures, patch it, and build it in one step; it even supports downloading
and building packages straight from the development repository. I took
advantage of it to create locally-patched versions of some software I use,
while keeping it up to date and still under the package manager's control.

Contrast that with creating a .deb, where doing the equivalent seems to
require invoking several different utilities (uscan, dch, debuild; though )
and keeping track of separate files like debian/control, debian/changelog,
debian/rules and whatever else. All the tooling around building packages seems
oriented towards distro maintainers rather than users. I'd love something that
would relieve me of at least some of the burden of creating a local package
from scratch.

DISTRIBUTION: unstable, I guess

~~~
vbernat
Creating your own packages with Debian tools is easier now than ever.
Unfortunately, the documentation may be lagging a bit and will also focus of
making state-of-the-art packages.

Last year, I have written some examples on how to do simple packages while
still leveraging Debian tools:
[https://vincent.bernat.im/en/blog/2016-pragmatic-debian-
pack...](https://vincent.bernat.im/en/blog/2016-pragmatic-debian-packaging)

Also, automatic package generation for many languages already providing
package management (Python, Ruby, Java, Go, ...) is already a reality but you
have a different tool for each. The topic comes back regularly but until now,
we don't have a generic tool for that. The last attempt was debdry but it
isn't maintained anymore.

~~~
Corrado
Yes, I think documentation is part of the problem. When I was a heavy Debian
user several years ago I tried to create my own packages but failed. The
problem was that the documentation was too numerous to find anything,
especially the current way to build packages. Every single resource I tried
had 2-3 different ways to build packages and it was difficult|impossible to
tell which one was the "recommended" way. I ended up not creating any packages
and moving on to another distro. :(

------
vacri
HEADLINE: Reconcile and refresh the Debian Wiki

DESCRIPTION: The wiki is frequently stale or incomplete. A lot of people get
information much more readily out of a wiki than mailing lists. Like me, for
example :) Mailing lists have a very high latency (often infinite) and can be
difficult to search.

For example, say you want to host your own apt repo to hold a custom package;
this page is not very clear
[https://wiki.debian.org/DebianRepository/Setup](https://wiki.debian.org/DebianRepository/Setup)
\- how do you choose which of all the software types to use? It's a reasonable
software overview, but not great to help people get a repo set up.

Arch has a fantastic wiki that's clear and concise. It's also more readable
(mediawiki) than Debian format, though I understand Debian aims to work as
bare html for greater device compatibility.

DISTRIBUTION: Primarily Stable, with later sections for non-stable if needed.

ROLE: sysadmin

------
inopinatus
Couldn't be more Debian to ask for our feedback in a key:value structure. The
hilarious part is that some of them are marked optional.

