Please note: Starting with Debian 7, the minor number is not part of the Debian release number, and numbers with a minor component like 7.2 or 8.7 now indicate a point release. Basically, only security updates and major bug fixes, with new updated installation media images. This, 8.7, is not a new major release of Debian.
"Please note that this update does not constitute a new version of Debian 8 but only updates some of the packages included. There is no need to throw away old "jessie" CDs or DVDs but only to update via an up-to-date Debian mirror after an installation, to cause any out of date packages to be updated."
Excellent news, and I like all the focus on security fixes in the system.
I do have to say though, it roughly looks like 25% of those issues wouldn't exist in memory safe languages. It's one reason why I'm so excited for Rust in the systems arena.
In general package maintainers only take existing software projects, and apply some glue to make them fit into the Debian distribution (think: build framework, file system location policies, documentation policies, etc.) so that the whole open-source ecosystem can be presented in a uniform distribution.
Rewriting the ecosystem in Rust would require no small effort. Luckily Debian isn't a giant monolith, and you can focus on one package at a time. If you're really serious about digging in, then choose a package that you think would be a good balance between security gain (e.g. something with a history of memory-type security bugs) and effort required, start with that.
The existing maintainer of that project (I mean the software maintainer, not the Debian package maintainer) may or may not be open to a Rust rewrite. But this is open-source, and if they aren't, you can just fork (if calling a rewrite a 'fork' makes sense...) and publish your code somewhere. Then you can work with Debian folks to get your version packaged, and it will be available as a safer alternative for people who want to use it.
Over time, and as this starts happening to more and more software, Debian can start migrating to using these packages by default instead of the older unsafe ones.
And if they don't, again, it's open-source. Someone can make a Debian derivative (there are many already, including most famously Ubuntu) that uses the Rust versions of all packages when possible by default.
Disclaimer: this post presents just one possible version of future events, with the goal of clarifying what steps are required if you really believe in this, and want to see it happen. I am not affiliated with the Debian project other than as a user and software author with packages in the Debian archive.
The reason I want they to be open to it, be it the Debian maintainers or the OSS maintainer, is that while I could fork the world, it might be a completely wasted effort if there is no support in the community to use it.
If on the other hand there was a ground swell, I'd prefer to help it along and scale up the effort. I'm only one person, with limited spare time to focus on these things.
I would love to have a well-tested and fully RFC-compliant DHCP client (IPv4 to start with) written in e.g. Rust, for use both on my dev machines and also on the embedded systems I build.
Many of these rewrite attempts are quick hacks that are abandonded once very basic functionality is present.
For most users Rust vs C/C++ doesn't matter so your rewrite has to be better, not only in security (which is very abstract for users), but better performance / easier to configure / smaller / etc.
It is definitely about time, many small tools and utils that has existed for 15-20 years are very crufty when you open the hood and dive into the source.
This is an open source and community driven project. It is your job/responsibility to improve things and try to submit them upstream and convince people that your solution is better than the existing one.
There is nothing definitive yet. While httpredir is unmaintained, when it works, its reliability and performance are unmatched by deb.debian.org. Using deb.debian.org, I can get sometimes 100kb/s on a 1G connection. And it's not unusual to get a 404 from time to time.
It looks like Wayland is only the default in testing, not yet in jessie. From where I'm sitting, that's mostly a good thing; thanks to Wayland, the default installation for debian-testing just flaps trying to show the GUI when installed in Virtualbox.
Making a major change like that in a stable point release would be unusual for Debian. Since Debian 8 (jessie) shipped with X as default, the 8.x point releases do the same. If that switch happens, it'll be with the release of Debian 9 (stretch).
Switch from X to Wayland won't happen in a Debian point release. So far I haven't heard anything about Debian's Wayland switch although a test Live CD ISO has been made available back in October 2016 -> http://www.phoronix.com/scan.php?page=news_item&px=RBOS-Octo...
Right now, the only Linux distribution ships Wayland display manager by default is Fedora 25 (I am running it on an old Latitude D630 with NVIDIA GPU -> KDE Plasma 5 ;-).
Mesa was the only for a while. (You need libgbm and a DRM+KMS driver to make a compositor and/or EGL_WL_bind_wayland_display for an embedded one). So that only worked with Intel and AMD GPUs.
Nvidia now has EGLDevice and EGLStream for their drivers, and they provided patches for Weston and GNOME has added support as well.
It does, but not as you would expect. Last time I tried with an ATI, I had random freezes. But it was a year ago. There were lots of improvements since then.
Since a package has to be at least 3 years out of date to be included in debian stable, and wayland is only 4 years old, it will take another 10 years.
And it is probably a good thing, i tried switching to wayland but it didnt make much sense. The only tiling compositor that worked for me was sway, but every other app i tried to use worked thru xwayland. no native firefox, no redshift. it did fix tearing in video playback though.
Maybe if i used gnome it would have made more sense.
Some desktop users prefer stable despite its older package set. I use backports on stable for a few things.
HNers will probably prefer Sid as the packages will be newer. debootstrap springs to mind for newer programming language versions &c (I have never used a debootstrap install for that purpose however).
Wayland usage would depend on your DE. For example in KDE, pointer containtment was added only in Plasma 5.9.x, which makes Wayland unusable for games. And 5.9.x didn't make into Debian before the freeze because it's still in beta. I.e. Stretch will most likely come out with 5.8.x and Wayland there won't be really ready.
Am glad. There are a subset of desktop users who will happily forsake following the latest s/w versions for rock solid stability, which Debian stable comes closer to than most other distros. At the end of the day, when you use your system as a tool to get (non-s/w dev related) work done, you want stability, and only the latest versions of a very few select packages. I DON'T want the latest kernel or libs because once I install a distro I stick to it for 2-4 years and by that time I upgrade lock, stock and barrel to new hardware. In the meantime I want those 2-4 years to be as crash-free as possible.
There was a post on HN in the past couple of months pointing out that the list of Toy Story character names is growing faster than Debian can consume them. Should be safe for a while.
