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
On a related note, the way that repos can only be secured as a whole (and require each package to effectively be present when creating the signature) makes adding a single authenticated package to an existing repo much harder than it needs to be.
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...
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.
I understand that expecting something from free and open source software beyond bare necessities can sound like being entitled. And yet, I believe that documentation is not optional. Software with better documentation wins. All the time.
Sorry for this completely irrelevant interruption :)
You can quickly piece together a snapcraft.yaml, push it to GitHub, and turn on auto builds and publication (https://build.snapcraft.io). Then anyone can install your package with a single command - no PPA/repo needed.
Then a linter could tell you that a changelog.Debian.gz, man-pages and debtags are still missing, but for internal redistribution that is enough for now.
And can failed build commands continue from where they were interrupted? Always cleaning everything is terrible for iterative exploration of the package creation process. The final package should be marked as tainted of course, but always starting a minute long compile process should be skippable.
The idea seems perfectly sound, but the implementation needs a lot of work. The UI needs to be better (e.g. saving your answers to the questions about title, author, etc.) And there are also some straight up bugs. It has crashed for me many times. And not even for a sketchy program- I'm talking like llvm.
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
I really love debian because of its principles (and I would love to contribute), but I feel that new contributors (like me) have problems because of the many (and some old) tools and outdated and non-friendly documentation.
Also, I don't know how many contributors come and stay, but even in unstable I see some outdated packages in weeks, and also some useful software that is not packaged.
The difficulty gradient of onboarding is a significant contributor to attracting folks.
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!
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 ?)
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.
ROLE: Upstream browser developer. (Not speaking on behalf of affiliation.)
> rename testing to something with a positive
> connotation that doesn't suggest it's for
> testing only.
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.
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.
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.
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.
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.
Have you tried running `sid`? It sounds like exactly what you're looking for. ;)
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.
From the FAQ (https://backports.debian.org/FAQ/):
"Q: Is there security support for packages from backports.debian.org?"
"A: Unfortunately not. [...]"
Python 3 as default
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.
> * 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.
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?
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: 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.
tar xfvz foo
./configure --prefix aze
make install DEST_DIR=qsd
1. find the info explaining me how to do this
2. understand it
3. effectively do this
This does not even involve step 4 (contributing the package back if it's not for internal use)
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.
We should discuss some of this at some point on debian-devel.
Is there anywhere to read more about this?
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).
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.
Like with non-free firmware, and other such things, I get the licensing and taint issues, but it would be good to see this evolve and be supported in the installer, someday, if only on a "forked" installer like with non-free firmware.
Decent support for ZFS in general, especially during installation already.
Ideally, ZFS root filesystem support (snapshot before upgrade, yay!).
I've been using ZFS for six(?) years now, on both Debian and Ubuntu, and while ZFS root is so important to me that I'm willing to jump through the necessary hoops to install it, it's kinda grating and perhaps riskier. And not for the faint of heart.
- 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)
This is definitely one of the defaults that I think RPM gets right over debian packages.
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.
I do the same with my Debian packages.
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.
Starting on install is more intuitive for people new to linux, but it's bad as an overall practice.
> but it's bad as an overall practice.
I agree with you, but only in the case of non-interactive use. Different use cases demand different defaults. Tooling should be able to make the appropriate distinction automatically. Currently, the tooling does not, but that (IMHO) is a design flaw in the tooling, which Debian does not produce.
In the interactive case, I'm torn, but I do see the logic.
In the general case, then, I maintain that tooling should use policy-rc.d to adjust the default as necessary, and that failure to do so is in the tooling, not in Debian.
Except that if a sysadmin installs a package that provides a daemon, this
daemon usually needs to be configured first, so starting it with semi-broken
config (and debconf-generated one is still semi-broken) is counterproductive.
- 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.
Even if you can rollback updates, a lot of the time that's no help - your user data format was upgraded, rendering your data useless (especially for web browsers, which you can't really downgrade).
That said, it's trivial to use file system snapshots. Ubuntu has apt-btrfs-snapshot to do this automatically, but it was never provided in Debian AFAICT.
But even with snapshots, you also need to snapshot user state, not just the installation, otherwise you end up with upgraded incompatible data again.
One of the reasons I'd prefer not to go back to apt-based distros.
Does Fedora also have transactional rollbacks?
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.
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:
$ dpkg -c firmware/firmware-iwlwifi_20161130-3_all.deb|grep -c ucode
$ ls firmware/*b43*
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.
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?
DESCRIPTION: AppArmor improves security by limiting the capabilities of programs. Ubuntu has done this years ago . 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  and SubgraphOS  have already committed to it.
'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.
- 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).
100% reproducible packages
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.
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.
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.
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.
DESCRIPTION: If you are using Debian, especially stable, you have to put up with outdated packages. This is especially a problem with browsers, although you do include security updates and track Firefox ESR, if I understand correctly. But things like Webkitgtk do not recieve updates, and lack feature and security wise after a while.
I think keeping up-to-date versions and having a stable distribution is not per se a conflict. Stable means to me no breaking changes, no need for reconfiguration when I update. It shouldn't mean frozen in time.
It would be great if certain packages would recieve frequent updates even in stable:
- packages that are not dependencies, have a good track record of backwards compatibility, and are unlikely to break
- packages that have to be updated because of security issues (which I think is already addressed now)
- or because of a fast moving ecosystem - even if it was safe, it is frustrating to use a very outdated browser component. I think many networked packages could fit in this category, e.g. Bittorrent or Tor clients, if there are protocol changes.
I think the situation has improved a lot (https://blogs.gnome.org/mcatanzaro/2017/06/15/debian-stretch...), and it would be great to have a stable basis in future and still have up-to-date applications on top as far as possible.
DISTRIBUTION: stable (but also others)
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.
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]
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).
As well, because snaps bundle their dependencies you don't have that problem you mention of adding a repo and getting busted library versions.
DESCRIPTION: a consensus on the next generation of package management.
We have had decades of fragmentation (not to mention duplicated innovation) around the RPM vs DEB ecosystem. Which is why it is still hard for beginners to want to use Linux - try explaining to anyone who comes from a Mac about rpm vs deb vs whatever else. Which is why they would pay for the mac rather than use Linux ("its too hard to install software").
Its not just my opinion - PackageKit (https://www.freedesktop.org/software/PackageKit/pk-intro.htm...) was invented for this reason. So you could have Gnome Software Manager that can work the same on every flavor of Linux. Its time to build this the right way.
You have an opportunity now - but again the camps are getting fragmented. We now have snap (ubuntu/deb) vs flatpkg (redhat) all over again. And pretty strongly divided camps are beginning to form around them. It seems that the new rhetoric is snap for servers and flatpkg for desktops... which absolutely doesnt make sense.
Debian is the place to make this stand - systemd was adopted from fedora despite Ubuntu making a strong push for something else. Debian made Ubuntu adopt systemd. I dont think anyone has anything but respect for that process. Debian 10 must take a stand on this.
I thought the creators of snaps/flatpaks would be upstream developers, so they themselves will vote on the package management system by using either. There is no duplication of effort here.
Myself I prefer AppImage , because of its simplicity and the fact that they are already supported on all Linux distributions, without installing any explicit support.
>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.
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.
Homebrew and Macports are OS X, not Linux.
Flatpak exists for one and only one reason -- because Red Hat, Inc. refuses to work with technology of any kind led by Canonical, period.
How does that make any sense whatsoever? You have three different systems to choose from ... and you choose one of them because the other two are different from one another?!
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.
Is mbp retina supported? All my attempts to get things to look right (using XUbuntu) failed :( Any cheat sheets?
On jessie, using one external screen results in the problems I described. Using two external screens additionally results in one of the monitors not working at all (even though the same configuration works fine on OSX).
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.)
First-class init that is not systemd
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)".
buster+1 given the expected effort
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.
To replace PID 1 with sysvinit, run:
apt-get install sysvinit-core systemd-sysv-
Pin: origin *
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
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.
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.
- 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.
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.
> "- 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.
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
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.
I realise that integration could be better, but most of these things do already exist:
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. :-(
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:
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.
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.
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 exist just for the purpose of packaging and building software for Debian. If you want to package and build software for a distro, you'll naturally have to learn how to use the packaging tools of that distro, and if you are just interested in the upstream source of some software that just also happens to be packaged for Debian, then why bother with any of the Debian stuff?!
> A github-like system is much more intuitive.
Are you sure you don't just mean "I am more familiar with github"?
I find github just annoying in that it's constantly trying to get me to use their user interface instead of just giving me easy access to the raw data and letting me use my own tools (and I am not interested in using github for anything, I just am confronted with it when other people choose to host their software on it).
> many open source projects have old infrastructure,
I still don't see what's wrong with old infrastructure?!
> that's hard to use.
Well, hard to use infrastructure is bad, whether old or new, isn't it? Github, for example, is relatively new, and just terrible. I can't even report a bug in projects hosted there, I'd first have to create an account with them just to post a simple bug report, it's just such a terribly complicated workflow (not to forget I'd probably have to accept their TOS?).
I still don't really see any similar problems with how Debian operates from what you have written!?
> And I fully understand how that infrastructure came to be, and why migrating away is super hard.
Well, I still don't see why one possibly would want to migrate away in the first place!? I mean, not that there is nothing that could be improved, but I don't really see anything that "switching to" would somehow make things better.
> My point is: github-like development flow have dramatically better usability and, hence, lowered the bar for participation.
Did it? I guess it depends on what you mean by "github-like"? My experience with github specifically is completely the opposite.
I have contributed to quite a few projects, with usually very low barriers to get involved. Usually, you just send an email with the patch (or a pull request for more complex changes) to the mailing list or maintainer, and that's it (or maybe a few more mails back and forth to discuss some improvements or whatever, but no up-front cost before you can get started, no need to create accounts, no need to learn additional user interfaces, ...).
On the other hand, I had a few bug fixes for projects that were hosted solely on github where I couldn't find any way to submit them without first making an account with github and learning their proprietary user interface, so I just ended up dropping them on the floor.
How is the latter an improvement?! Or is it?
> I wish more of the big open source projects would embrace the importance of these advancements in usability.
But ... what are those advancements in usability? Really, I still don't see any. I mean, not that usability couldn't be improved here and there, but what you write so far mostly reads to me like "if you know github and don't know non-github, then github is easier to you than non-github" ... which might be true, but would generally be equally true for anything else, and in particular doesn't really have anything to do with usability!?
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.
% apt-get install dgit
% dgit clone foo-package
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".
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.
Secure Boot in Stable
UEFI Secure Boot Support in Debian.
Debian does not run on systems with Secure Boot enabled.
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...
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 - 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.
- 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
- 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' 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'!
And of course, odds are that they won't be reading this thread!
I've often been in this situation myself.
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.
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.
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.
Wayland as default display server
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.
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
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"?
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: 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  for more details.
- DISTRIBUTION: Any and all!
- ROLE/AFFILIATION: CS program analysis researcher with MIT/CSAIL.
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.
> 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.
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: Continue with the values that make debian great. E.g.
- DISTRIBUTION: (Optional) [stable, testing, unstable, or even a Debian deriviative]
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. :)
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: At 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
DISTRIBUTION: Debian 10 stable & Debian 9 backports.
ROLE/AFFILIATION: http://fosdem.org staff (= all year round volunteer), responsible for video streaming & recording since FOSDEM 2017
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.
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?
Also get rid of all interactivity during install and upgrade. It's deadly for managing big fleets.
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.
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
- 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.
- ROLE/AFFILIATION: (software developer, mostly fullstack webdev)
Maybe we could add support for Debian packages?
Description: More KSP security features enabled by default, perhaps even Firejails pre-installed, Wayland as default along with flatpaks, etc
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).
- 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.
- ROLE/AFFILIATION: (Optional, your job role and affiliation)
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".
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: 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.
ROLE: full stack web developer
Unstable isn't built from bleeding-edge nightlies, but it's generally up-to-date.
- 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
- 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.
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
These are just selected samples. There is many little rooms for improvements on this point.
DISTRIBUTION: stable and sid
- 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
- 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
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.
It would be great if Debian finished its LXD (container hypervisor)
packaging and got it up to a decently complete level (per Ubuntu).
- 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.
- 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.
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.
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.
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.
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.
- ROLE/AFFILIATION: Lead Product Developer at Cetrez
It’s straightforward to spin up fresh local virtual machines, and you get access to the full KVM infrastructure if you need it.
- 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: 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.
- ROLE/AFFILIATION: Software developer, Germany
I wholeheartedly agree with removing Perl. Also a lot of other questionable packages in the essential set.
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.
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.
You mean like "apt install <deb package>"?
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.
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
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" (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)
- 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
- 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
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).
(check the whole thread)
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.
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.
Systemd failures are under our eyes
and are not acceptable for a server distribution.
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!
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.
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.
>"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)."
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.
DESCRIPTION: Please disable pcsprk by default :-)
No systemd (and pulseaudio if desktop) for me.
Tool to log process spawns, kills, network connection start/stop, file modifications etc. onto event logs for review.
- DISTRIBUTION: Kali
- ROLE: Security Analyst
SELinux installed by default
Not sure what else to say...
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.
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
SELinux is one of the reasons I switched from Fedora to Debian.
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.
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.
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.