Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

news.ycombinator.com

Post reply on HN
Print view View original

281–290 of 329 posts

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

#281

Post by ryao »

heftysync wrote: post #124

HEADLINE: First class ZFS install support on Live CD. DESCRIPTION: The license conflict between the open source ZFS and open source Linux kernel mean ZFS needs to be in contrib. Unlike a lot of other packages in contrib, ZFS doesn't rely on any non-free software. It just can't be in Debian main because of the conflict of licenses. However, it would be nice if there was a way to have a more official path to ZFS on roo…

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

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

#282

Post by heftysync »

aleden wrote: post #188

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

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

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

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

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

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

#283

Post by heftysync »

ZenoArrow wrote: post #221
heftysync wrote: post #120

HEADLINE: Day(s) old sid as a rolling distro DESCRIPTION: I think I represent a number of users. We want to use unstable as a rolling distribution, but we don't want to run into every edge case. Testing doesn't update fast enough and doesn't have as good of security. There's no middle ground between absolute bleeding edge and the too conservative testing. I used to use unstable but there's that annoying race conditio…

https://www.slant.co/topics/6289/viewpoints/13/~rolling-rele... >"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)."

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

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

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

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

#284

Post by spwhitton »

jopsen wrote: post #39

HEADLINE: Lower barrier for contributors DESCRIPTION: Have a git repo for each package with a simple issue tracker, like GitHub/gitlab, a flow for accepting pull-requests and automated CI. Also move away from message boards and IRC to more user friendly tools. Currently, it's too hard to report bugs, inspect debian source packages, propose fixes, etc. The overhead to making a simple contribution is too high. Note: th…

There's already a git repo for every package.

    % apt-get install dgit
    % dgit clone foo-package

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

#285

Post by JdeBP »

tkinz27 wrote: post #171
miclill wrote: post #147

- HEADLINE: Not start services by default - DESCRIPTION: If I installed e.g. postgresql I would prefer it not starting automatically by default. I would rather like a message: If you want x to start on boot, type 'update-rc.d enable x' - DISTRIBUTION: (Optional) [stable] - ROLE/AFFILIATION: (software dev, mostly web)

I can't thumbs up this enough. Packages that start services when they are installed can cause so many issues between not giving the user the chance to fully configure them, to weird interactions with distributed applications talking to each other before all the configuration is ready. This is definitely one of the defaults that I think RPM gets right over debian packages.

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

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

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

* http://smarden.org/pape/Debian/

* https://lists.debian.org/debian-devel/2012/06/msg00100.html

I do the same with my Debian packages.

* http://jdebp.eu./Softwares/nosh/debian-binary-packages.html#...

* http://jdebp.eu./Softwares/nosh/debian-binary-packages.html#...

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.

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

#286

Post by evand »

captainmuon wrote: post #260
icebraining wrote: post #240

Earlier quoted context omitted.

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

I haven't used Debian in a while, so yes, maybe "stable" is not the right branch for me. I would have been looking for something that you install once, and then it just works without intervention for a long time. But at the same time I also want to have access to some latest software, without relying on third party repositories (because the chance of breakage is very high) or compiling myself (because then I have to…

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

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

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

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

#287

Post by evand »

rahiel wrote: post #187
sandGorgon wrote: post #98

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

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

This is exactly right. Debs, snaps, and flatpaks will happily coexist. The upstream gets to choose which works best for them while still supporting users of all distros.

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

#288

Post by popey »

mixmastamyk wrote: post #177
pwdisswordfish wrote: post #89

HEADLINE: Easier way to create local packages DESCRIPTION: My first distro was Debian. Then, for a while, I used Arch. But it kept irritating me with its total disregard for backwards-compatibility (symlinking /usr/bin/python to python3), coarse-grained packages (want to install QEMU PPC without pulling in every other architecture as well? too bad!), lack of debug packages (good luck rebuilding WebKit just to get sta…

Maybe snaps can fill this role, I understand they are easier to create.

They're certainly easier to create than debs. For many applications a single yaml file is all that's needed. Snapcraft can use whatever build system the app needs, and produce a snap which can be locally installed, shared privately or more widely via the snap store. I made a short video about it. https://www.youtube.com/watch?v=DLxqdf89hRo

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

#289

Post by evand »

pwdisswordfish wrote: post #89

HEADLINE: Easier way to create local packages DESCRIPTION: My first distro was Debian. Then, for a while, I used Arch. But it kept irritating me with its total disregard for backwards-compatibility (symlinking /usr/bin/python to python3), coarse-grained packages (want to install QEMU PPC without pulling in every other architecture as well? too bad!), lack of debug packages (good luck rebuilding WebKit just to get sta…

All the learning and process needed to create Debian packages has been a big motivator for us to make snap packaging simple and quick. Have a look at the Heroku CLI snap, for example: https://github.com/heroku/cli/blob/master/snap/snapcraft.yam...

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.

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

#290

Post by hd4 »

ghostly_s wrote: post #150

HEADLINE: More user-friendly install process DESCRIPTION: Recently had to reinstall my Debian system for the first time in a while, and was struck by how user-unfriendly the installer still is compared to many of the alternatives. I don't think it's necessarily a problem that it's ncurses, but it could use some more explicit hand-holding. I remember one point where I needed to select some options from a list and ther…

I agree with this, one of the few things I miss about Windows is the easy disk setup in the installer.
Post reply on HN