Ask HN: What do you want to see in Debian 10 (“buster”)?
Chris Lamb here, Debian Project Leader. As a bit of background, I've been around the "startup" 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/Django.
I'm very much interested in soliciting your feedback and feature requests for the Debian 10 ("buster") development cycle which opens up tomorrow after the release of "stretch" today. This is obviously a shameless appropriation of Ubuntu's post a few months ago and some requests would definitely overlap but I feel we could get some interesting replies nonetheless.
Please include in your replies the following bullets:
- HEADLINE: 1-line description of the request
- DESCRIPTION: A lengthier description of the feature. Bonus points for constructive criticism...
- DISTRIBUTION: (Optional) [stable, testing, unstable, or even a Debian deriviative]
- ROLE/AFFILIATION: (Optional, your job role and affiliation)
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.
Thanks, HN!
—lamby
https://twitter.com/lolamby
328 comments
[ 3.1 ms ] story [ 315 ms ] threadPython 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.
I don't see how older python 2 programs can be supported without updating the hashbang line in a Py3 default system (which is most of the time trivial) - you could also have a dedicated virtualenv for them as well which would work - and which would (looks like to) be an equivalent amount of work as changing the hashbang lines
Switching to default Py3 is a breaking change and that's fine
Not only breaking, but also completely unnecessary
It would be a small change (that could be automated) in packages, and removes any confusion about what /usr/bin/python means.
Shouldn't instead scripts be updated either to be compatible with latest python or to specify the version they demand?
> * 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.
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.
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
Oh wow, it's really not just me...
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.
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"?
You can already try it in Stretch by selecting the proper option in GDM. I'm personally using wayland on both my desktop and (work) laptop for months
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.
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
If there's enough interest, my plan could be to expose just a subset of the current libdpkg as a shared library for buster.
What would be the best way of contributing this sort of information?
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
How does this manifest itself in practice? I don't want to use systemd in Debian 9, what has been done so I can easily change to another init like runit?
In practice it's not possible because of so many (unecessary) dependencies on systemd.
> In practice it's not possible because of so many (unecessary) dependencies on systemd.
Such as? As far as I can tell, almost nothing depends on systemd. A handful of things depend on libpam-systemd (for session management), which functions with systemd-shim.
A lot of people still use sysvinit and it just works.
For that matter, if this is a use case you care about, systemd-shim could use a maintainer or maintenance team: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832508
To replace PID 1 with sysvinit, run:
To prevent it from coming back, create the file /etc/apt/preferences.d/no-systemd.pref containing: This works great on servers and lightweight desktops. As others have noted, if you want GNOME you also need to install systemd-shim. I have no experience with this, but I have no reason to doubt that it works.Devuan spends a lot of time and energy to remove libsystemd, a library that is introduced so that software can function properly with or without systemd. Not necessary for Devuan, true, but why not remove critical services shipped by systemd first? They still ship systemd-free.
But no-one to my knowledge has yet done the work to give the Debian installer this capability without the need for pre-seed hooks, as a menu item/checkbox/question for the administrator to pick/tick/answer. Such work is more than merely writing code, note. It involves testing it too. Thoroughly.
* https://wiki.debian.org/DebianInstaller/Preseed
* https://wiki.debian.org/systemd#Installing_without_systemd
Ironically, this was once a problem the other way around. Attempted changes to enable administrators to select systemd at install time (and indeed upstart, as you can see) failed to make it past a Debian gatekeeper.
* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=668001
* http://uselessd.darknedgy.net/ProSystemdAntiSystemd/
Not really.
In order to 'reunite the community' you need to understand what that will take. Every init system that is supported adds an additional support burden onto the developers and maintainers that work on Debian. In order to minimise that work, it's important to understand the issues with the status quo.
At one end of the spectrum, perhaps a few tweaks to systemd would be enough to satisfy most who had issues with it in the past. On the opposite end of the spectrum you have the distro needing to support 5+ init systems if there's little consensus about what a strong alternative to systemd would look like.
The questions I asked previously are useful in understanding how much work would be required to 'reunite the community'. Feel free to answer them if you think this is a worthwhile line of inquiry.
Dead link. Copy: http://archive.fo/5Gx8C
- 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.
> "- 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""
Is this because the data being passed around is represented in binary form rather than text form (e.g. binary logs rather than text-based logs)?
> "- 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."
Sure, but this doesn't strike me as neccessarily bad. I appreciate the Unix philosophy is based around having a series of tools that serve a single purpose that can be chained together in different ways, but it's still a necessity to have common interfaces over which this chaining takes place. Is this again related to the binary vs. text issue?
> "- 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."
The non-determinism and speed of start up both strike me as major issues, thank you for mentioning them. Does anyone know if there are there plans to tackle these issues?
> "- Unit files can be stored in a minimum of four separate locations on disk, and this can be increased dynamically."
Again, this also seems like a reasonable complaint. Is this issue due to the intrinsic design of systemd or is this solely a flaw in the implementation?
> "- Failures are opaque, and the failure of systemd triggers the failure of the entire system."
Are there no fallbacks in place should a systemd component fail? I see no reason why this couldn't be implemented.
> "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."
I don't disagree with that assessment, but there must be reasons why systemd is proving popular amongst distro maintainers. Why would you suggest that is? What advantages do you gain from having a unified layer that provides the services that systemd provides?
None of my complaints relate to binary vs. text. Both have their strengths and weaknesses, and while binary data requires new set of tooling, I intentionally did not mention it because of how contentious it is to even bring up.
> Sure, but this doesn't strike me as neccessarily bad.
It's just not necessary. This all worked before. Not always perfectly, and sometimes even poorly... but it worked. And importantly, it worked without requiring the authentication system, message bus (tied into the kernel), custom logging, and init all to be tied together.
> What advantages do you gain from having a unified layer that provides the services that systemd provides?
Personally? None - no advantages. Consider where I'm coming from - I've run Linux on the desktop and server for years (perhaps even before systemd was a glimmer in Pottering's eye). I've written software which ran on startup (including the sysvinit scripts), done init troubleshooting... and it all just worked.
Without reasonable gains in speed, and without resolving the determinism problem, and given a world in which supervisord, daemontools, and LXC exist... systemd just doesn't bring anything to the table that I've been asking for. Instead, it's brought a whole new toolset I have to now learn, and a ton more complexity and opacity.
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).
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.
And similarly the journal format is something that can only be read with the journalctl tool. plain ascii you can throw just about anything at.
Not all new things are great and I think Debian made a mistake not supporting a traditional init system alongside systemd or at least until the kinks could be worked out.
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.
Connman appears to be the only GUI option here: https://01.org/connman
If you consider Android to be a GNU/Linux distro, then Android 4.x+ could be a reference for this.
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.
Is there anywhere to read more about this?
We should discuss some of this at some point on debian-devel.
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.
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.
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!
Never had a problem that Debian didn't run 'out of the box' within VirtualBox. Wouldn't even know what that entails.
For example I had to install the "xserver-xorg-legacy" package to get the X server working as X is not running as root anymore.
Description: More KSP security features enabled by default, perhaps even Firejails pre-installed, Wayland as default along with flatpaks, etc
SELinux installed by default
DESCRIPTION
Not sure what else to say...
SELinux is one of the reasons I switched from Fedora to Debian.
In the docker world, it would be a huge improvement.
- The kernel doing the permissions check (called object manager) - The policy telling the kernel what is allowed or not - Some userspace tools and libraries to load and manipulate the policy and the state of SELinux
The kernel and the userspace tools are almost the same across all distributions (Well Fedora/RHEL are carrying some patches).
But for the policy it's a different story. RHEL/Fedora have a gigantic patch applied to the refpolicy (reference policy developed by the SELinux upstream).
The policy allowing docker to work has not been upstreamed so it's not that easy for other distributions to use it
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.
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
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.
This is not a Debian problem. This is an OpenSSL problem where they forced each upstream program author to make changes in order to upgrade. You'll have to wait for each upstream program author to update.
- 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)
Could you elaborate more on your particular use-case? Would be interested if there were also compromise solutions such as smarter binary diffs, etc.
However, having installed a fairly full Debian desktop from DVD1/2 offline it struck me that Debian is the only distribution that could support someone with (say) a desktop PC in a location with dial-up or no Internet or only mobile internet. I imagine a single large .iso image (the BD perhaps?) included on 'El Paquete'[1] and dd'ed to a USB key for installation or DVDs/USB key mailed in the post.
A Debian equivalent to drpm packages would be a really nice idea. I'm glad you said 'also'!
[1] https://www.fastcompany.com/3048163/in-cuba-an-underground-n...
And of course, odds are that they won't be reading this thread!
I've often been in this situation myself.
I'm thinking of ditching the phone line and scavenging in local cafes/public buildings, so yes, weekly access to reasonable speed connection. Tethered mobile connection for emergency email/rdp access.
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...
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.
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.
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.
Firmware is software that runs on the actual hardware itself, in this case it runs on the microprocessor on the WiFi card
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.
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?
I use these when installing on laptops.
Yes the iwlwifi firmware in particular is shipped on the nonfree firmware CD image. But the firmware my other laptop isn't. With the stretch rc5 non-free image mounted:
But instead of providing the b43 firmware there's only a network installer to fetch it: Looking over the packages more closely now it seems only the b43 package[1] uses this approach (although there might be more firmware that's not included at all).1. https://wiki.debian.org/bcm43xx#b43_and_b43legacy
The Debian project already ships that sort of script in the current non-free firmware CD, so clearly it's not a legal issue. What it doesn't ship is the ability to run that on another machine as part of preparing an ISO to install on a fresh machine that needs the proprietary firmware.
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.
This issue could be helped with some tactical updates to the Debian Wiki. I'm in two minds about IRC - I'd hate to see it disappear and go to something like Slack, but I understand it's a bit daunting.
#debian-mentors on OFTC can help with contributions to Debian.
If I google a docker error code, I often end up on a github issue.
I realise that integration could be better, but most of these things do already exist:
CI: 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
I can't think of a valid reason for people to avoid learning git. Is there one?
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.
Sadly, mercurial-buildpackage in Debian is a dead-end. :-(
[1] https://lwn.net/SubscriberLink/724986/90728a14d7a85770/
[2] https://alioth.debian.org/
[3] https://pagure.io/
Bad idea, because you don't want to lock all of Debian into one technology. Suppose Debian had similarly had one cvs repo for each package 20 years ago. Progress happens when people have the opportunity to independently build and test out different solutions without first having to convince the world that theirs is the best.
> with a simple issue tracker
Dunno what you mean by "simple", but there is an issue tracker for all the packages that's as simple to use as it gets, you don't even need to create an account!?
> Also move away from message boards and IRC to more user friendly tools.
I haven't seen message boards used by Debian!? As for IRC, what would you consider a more user friendly tool?
> Currently, it's too hard to report bugs
So, running reportbug on your machine is too hard?!
> inspect debian source packages
So, running apt-get source on your machine is too hard?!
> propose fixes
See bugtracker above?
> many open source projects has old infrastructure
What is wrong with old infrastructure?
But a github-like setup, project package, issues, branches, PRs.
> So, running apt-get source on your machine is too hard?!
Where is the web ui? I honestly feel like these commands are magic because I don't know what they clone from. (and I have to be on debian)
> As for IRC, what would you consider a more user friendly tool?
slack or similar...
> So, running reportbug on your machine is too hard?!
This assumes on a debian machine. Sometimes I find a bug searching on google, it'll be something like this:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=304373
How do you subscribe, comment, propose a PR, where do you find the source.
I have used some of the debian tools like apt-get source, but it takes a long time to learn these things, and I forget them. A github-like system is much more intuitive.
----
Note: I'm not criticizing the debian project, many open source projects have old infrastructure, that's hard to use. And I fully understand how that infrastructure came to be, and why migrating away is super hard.
My point is: github-like development flow have dramatically better usability and, hence, lowered the bar for participation. I wish more of the big open source projects would embrace the importance of these advancements in usability.
Well, how is that supposed to work and not run into essentially the same problem? You can use any version control system, but only after you have integrated it into the Debian meta version control system?!
> Where is the web ui?
Why would you want a web UI, especially if it's supposed to be user friendly? I have a very nice and powerful development environment ... why would I ever want to have a "Debian Web UI" for inspecting a package's source code instead of just using the tools that I know well how to use?
> I honestly feel like these commands are magic because I don't know what they clone from.
Well, there is documentation that explains what they do?! Like ... man apt-get? And it's not really all that complicated either.
> (and I have to be on debian)
Well, you can just download the source packages from the website if you want, but in the common case that you just want to inspect or modify the code of the package that you have installed, what's easier than have apt download and unpack it for you?
Also, of course, that's all only relevant to the Debian packaging, not the upstream source.
> slack or similar...
What do you mean by similar? Proprietary software with a monopolistic supplier that you cannot participate in unless you enter into a contract with that third-party supplier under their terms, and that forces you to use their user interface instead of integrating it with your existing communication infrastructure? How is that more user friendly than "start any free-software IRC client of your choosing if you haven't one running yet, and join the channel (or use some web IRC client if you want)"?!
> This assumes on a debian machine.
Well, it is meant for reporting bugs in a Debian install, so ... yeah?
Also, again, you don't need to use that, but it's the easy way in the common case that you are indeed on a Debian system when you want to report a Debian bug.
> How do you subscribe
You click the "subscribe" link in the line "Reply or subscribe to this bug." at the top.
> comment
You click the "Reply" link in the line "Reply or subscribe to this bug." at the top.
> propose a PR
Same as above, just put the URL of the repo to pull from in the email.
Though in practice just putting the patch into the email is the usual approach, given the nature of packaging bugs (the fix usually is relatively simple).
> where do you find the source.
You click on the "docker" (or whatever the package name is) link in the "Package: docker [...]" line at the top, that gets you to the bug tracker overview page of that package (essentially the list of all bugs related to that package), there you click on the "docker package page" link in the "You might like to refer to the docker package page, [...]" line at the top, which gets you to the list of available related packages and their versions, where you click on the relevant package and version, which gets you to the info page about exactly that package in exactly that version, which, among many other things, contains links to the source package in the right column.
That might seem like a lot of clicks to get from A to B, but if you realize that bugs are not specific to single package versions, but Debian as a distro of course is built on specific versions that are published as packages, it actually makes sense.
> I have used some of the debian tools like apt-get source, but it takes a long time to learn these things, and I forget them.
Well, yeah, it certainly is something you have to learn if you want to use it, just as github is something you have to learn if you want to use it!?
I just don't see how anything like github would be a replacement for Debian package management tools. I mean, the purpose of apt and dpkg and the like is not to be general-purpose software development tools, they...
- 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).
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.
See this other thread: https://news.ycombinator.com/item?id=14579821
DESCRIPTION:
There are users who'd like to use a non-corporate community distro but who don't need or want software to be as old as software in Debian stable. The standard answer is "use testing" (e.g. http://ral-arturo.org/2017/05/11/debian-myths.html), but 1) security support for testing is documented to be slower than for stable and unstable (https://www.debian.org/doc/manuals/securing-debian-howto/ch1...) and 2) the name is suggestive of it being for testing only.
Please 1) provide timely security support for testing and 2) rename testing to something with a positive connotation that doesn't suggest it's for testing only. I suggest "fresh" to use the LibreOffice channel naming.
DISTRIBUTION: testing
ROLE: Upstream browser developer. (Not speaking on behalf of affiliation.)
https://backports.debian.org/
From the FAQ (https://backports.debian.org/FAQ/):
"Q: Is there security support for packages from backports.debian.org?"
"A: Unfortunately not. [...]"
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.
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.
If you haven't tried it, give it a shot. You may be surprised.
But "have you spent the time evaluating it?" is beside the point. My point is that it would be positive to have a Debian release channel with fresh software with 1) explicit security support and 2) naming with positive connotations so that fewer people who don't need to use out-of-date "stable" used "stable" because it is the Debian release channel with the most positive-connotation name.
Asking each user individually to go against the framing of negative-connotation naming ("testing", "unstable") to get empirical data of what the actual level of breakage is wasteful. If "unstable" works so well, it shouldn't be called "unstable". Calling it "unstable" but telling people it's the solution to whatever is wrong with "stable" is a set-up for a blame-the-user excuse if something goes wrong.
What you are asking is basically to switch to a rolling cycle with guaranteed support. This is a huge change and also don't account for the fact that many people choose Debian stable specifically because of it's non-rolling cycle...
* It's generally unpleasant for a user to know their problem has been fixed but they don't get access to the fix in a long time.
* Users using old software when they don't need to has network effects that give rise to negative externalities. See my other top-level reply: https://news.ycombinator.com/item?id=14580042
> don't account for the fact that many people choose Debian stable specifically because of it's non-rolling cycle
My suggestion is based on the premise that there are users who choose or would like to choose Debian because of its community distro brand equity and not because Debian stable has old software. Also note that I suggested a change in the framing of testing and didn't suggest stable be dropped.
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.
Have you tried running `sid`? It sounds like exactly what you're looking for. ;)
On the other hand "unstable" is way too unstable when you need a reliable environment in my experience. Packages breaking randomly etc... Completely expected of course, but I can't take that bet on a work computer for instance.
So as far as I'm concerned on the desktop "debian testing" is the one true debian. I don't even try to install stable first anymore since I'm certain I'll end up moving to testing eventually, I directly ask the setup to use the testing repos.
That's not my experience at all. Which packages have you had breaking randomly?
Of course what everyone wants is something with all the advantages of a rolling release but without the disadvantages. Ie, always have the latest version of everything, but without anything breaking in ways that affect me.
The only time I cared was when I installed from scratch on a new computer (too much hazle to mirror and existing drive and figure out how to switch from bios to efi etc), and last time, stable did not support my hardware, testing and nightly did not work due to being in transit to release. In other words the lack of any suitable installer meant I was forced to use another distribution (Ubuntu).
I have tried both testing and unstable and both broke for me at inconvenient times, usually I was not the first to notice, and with some effort usually able to find a fix or work-around. Stable plus backports work well, although as a rule, you are stuck on old packages unless (at least the way I use it) explicitly upgrade a particular package. It is configuration that I have to manually sync between machines.
Other than varnish (3rd party repo which is going away I believe) I have no issues with automated (i.e apt-cron) updates for many years.
What I would love to see is a rolling release that is non-breaking. If something breaks, roll that particular package back. I don't know what the particular mechanism that would be, but the ticket system (which is a wealth of data) could be an input along with local configuration.
Push upgrades. With stable, security fixes, is a feed, but it would nice if I don't need to jury-rig something myself to minimize my exposure window. With rolling releases, it would be nice to get that faster (or if you prefer delayed by a configurable amount).
This is also the reason for only stable (and olstable?) getting security updates. The thing is that if you want to support something, you'll need to scope it. You can't support just any random thing, you'd need an army of maintainers just to do that. So you make a 'release' where that specific version has people watching over it and making sure things are safe and working. Even that process is hard enough as-is.
While it would certainly be nice to have a rolling release, or 'really fast' release, it can only be done if more hours/people/donations are available to fuel it.
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.)
DESCRIPTION: AppArmor improves security by limiting the capabilities of programs. Ubuntu has done this years ago [1]. I'd like to see profiles for web browsers enabled by default.
I think AppArmor is the right choice of default Mandatory Access Control for Debian because Ubuntu and security focused Debian derivatives like Tails [2] and SubgraphOS [3] have already committed to it.
[1]: https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/AppArmorP...
[2]: https://tails.boum.org/contribute/design/application_isolati...
[3]: https://subgraph.com/
'Metaproxy is not going to work very well with IPv6'
And Debian based distro's like Ubuntu, Tails, and Subgraph also work on AppArmor so choosing AppArmor over SELinux means overall less work for the Debian community.
[1]: https://wiki.debian.org/AppArmor/Progress
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.
This does not even involve step 4 (contributing the package back if it's not for internal use)
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)
- 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.
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).