Orphaning bcachefs-tools in Debian • Hacker News Board

Re: Orphaning bcachefs-tools in Debian

#141

Post by mananaysiempre » Sat, Aug 31, 2024, 4:13 PM UTC

AshamedCaptain wrote: post #77

rfoo wrote: post #75

Earlier quoted context omitted.

> And your GPU driver is only going to be at one version, no matter how many statically linked executables you have. This is a non-issue. libcuda.so (which is part of the NVIDIA driver, their userland part) can not be statically linked into anything, since it's closed-source and no .a shipped at all, so no possibility of misconfigure it to be statically linked. And NVIDIA drivers, as a whole (including a pair of libc…

That is hardly true for NVIDIA over the years, as I have experienced personally, and it's definitely not true for about every other GPU driver in existence -- particularly AMD's RoCM, which even recommends specific Python versions to go with each ROCM version. In addition, replace "GPU" with any other piece of hardware, such as NPU. Or even software, such as your desktop environment. Do you think a statically linked…

> Do you think a statically linked binary will run with Wayland+1 ?

Yes, yes it will. The baseline stuff (the base protocol and xdg_shell) has been stable for years. Of course, one might argue that the caveman byte poking provided there turns a modern machine into a slightly faster 15-year-old one, and I agree it does. (It’s still fun to do as an experiment.)

But the moment you try to actually leverage the GPU the modern Linux desktop forces you to abandon static linking in order to load pieces of the graphics driver into your address space, and unfortunately those pieces will in turn force you to dynamically link the distro’s preferred libc (likely Glibc) and libwayland (as opposed to any other protocol implementation).

So either you poke pixels into a byte buffer by hand, and your question gets an answer in the affirmative simply because that foundational layer is fairly small, or you take advantage of the hardware, and your question becomes moot because you can no longer statically link.

Re: Orphaning bcachefs-tools in Debian

#142

Post by rlpb » Sat, Aug 31, 2024, 4:19 PM UTC

orra wrote: post #68

rlpb wrote: post #14

Earlier quoted context omitted.

Maintenance is much more practical if everything in your dependency tree uses the same version of every dependency. Achieving this in practice is much of the work distribution maintainers have to do. Doing this has a couple of key advantages: 1. when a security vulnerability needs patching in a stable distribution release, the security team only have to patch one version instead of a dozen or more different versions…

> 2. a library that depends on dependencies A and B, both of which depend on X, can actually work properly if it needs to pass API objects created by X across between A and B, since X is of the same version That feels like an advantage for the developer, not the distro maintainer. I find that amusing, because you're saying it's easy if they can use one version of the library. Well, that's also true if they're writing…

> That feels like an advantage for the developer, not the distro maintainer.

It's an advantage for the ecosystem, yes. Not the developer of the library (X in my example), but a different developer. Someone who is trying to write an app to do something interesting with A and B.

> ...because you're saying it's easy if they can use one version of the library. Well, that's also true if they're writing an application

I don't think that's true.

Perhaps library A has pinned dependencies for X such that it is in conflict with unrelated library B that also uses pinned dependencies for X. Both libraries are now less useful to the ecosystem, because they are now inadvertently incompatible with each other (if their APIs expose X's objects).

My example demonstrates why this doesn't work in the general case, and therefore why it's wrong to expect that everyone does it this way.

Re: Orphaning bcachefs-tools in Debian

#143

Post by rlpb » Sat, Aug 31, 2024, 4:20 PM UTC

rfoo wrote: post #72

rlpb wrote: post #14

Earlier quoted context omitted.

Maintenance is much more practical if everything in your dependency tree uses the same version of every dependency. Achieving this in practice is much of the work distribution maintainers have to do. Doing this has a couple of key advantages: 1. when a security vulnerability needs patching in a stable distribution release, the security team only have to patch one version instead of a dozen or more different versions…

No. 1. Rust is as hostile to dynamic libraries as glibc to static. 2. With everything static you have to rebuild every dependent on any security patch anyways. If you meant with multiple versions maintainers have to backport patches to multiple versions. Maybe don't backport at all? Some people appreciate having backports. Users of software written in Rust does NOT. So why bother doing backports for them? 3. > a libr…

> This will be detected during compile (since it's all static! sorry dynamic linking fans) and dealt with.

If it is correctly detected, then the only "dealing with" that can be done is to fail to build.

Re: Orphaning bcachefs-tools in Debian

#144

Post by [deleted] » Sat, Aug 31, 2024, 4:25 PM UTC

jonhohle wrote: post #140

epage wrote: post #120

Earlier quoted context omitted.

We want to make our software available to any system without every library maintainer being a packaging expert in every system. The user experience is much better when working within tkese packaging systems. You can control versions of software independent of the machine (or what distros ship). Or in other words, the needs of software development and software distribution are different. You can squint and see similar…

So every user has to be an expert in every package manager instead? Makes sense. Make life easy for the developer and pass the pain on to thousands of users. 20 years ago you may or may not support RPM and DEB and for everyone else a tarball with a make file that respected PREFIX was enough. (Obviously a tarball doesn’t support dependencies.)

[deleted]

Re: Orphaning bcachefs-tools in Debian

#145

Post by chungy » Sat, Aug 31, 2024, 4:29 PM UTC

jonathanspw wrote: post #133

rubiquity wrote: post #127

Debian is going to look as ridiculous for doing this as Alma Linux is for insisting btrfs isn’t an “enterprise file system” due to it lacking RAID 5/6.

AlmaLinux has made no such statement, for what it's worth.

Red Hat Enterprise Linux excludes btrfs support in its distribution because Red Hat does not believe btrfs to be stable enough to be worth considering. That decision trickles down to recompilation projects that pretty much amount to "RHEL, but without having to pay for it".

Re: Orphaning bcachefs-tools in Debian

#146

Post by complaintdept » Sat, Aug 31, 2024, 4:32 PM UTC

ants_everywhere wrote: post #89

peppermint_gum wrote: post #30

>not even considering some hostile emails that I recently received from the upstream developer or his public rants on lkml and reddit It feels like whenever the author of bcachefs comes up, it's always because of some drama. Just the other day he clashed with Linus Torvalds: https://lore.kernel.org/lkml/CAHk-=wj1Oo9-g-yuwWuHQZU8v=VAsB... My reading is that he's very passionate, so he wants to "move fast and break thi…

Hey at least it's not the worst behavior we've seen from a Linux file system creator... I thought Carl Thompson's response was very good and constructive: https://lore.kernel.org/lkml/1816164937.417.1724473375169@ma... What I don't understand is that IIUC Kent has his development git history well broken up into small tight commits. But he seems to be sending the Linux maintainers patches that are much larger than the…

> Hey at least it's not the worst behavior we've seen from a Linux file system creator...

I think that dubious distinction would go to Hans Reiser.

Re: Orphaning bcachefs-tools in Debian

#147

Post by mrweasel » Sat, Aug 31, 2024, 4:34 PM UTC

h2odragon wrote: post #9

this is "static vs shared libraries" fight again. no one remembers the first iterations, and there's more layers of "stuff" in the way now, so now one sees the actual issue for what it is. "shared libs" was the product of storage constraints; a bobble in the smooth pace of progress that shouldn't be needed now. Our faith in "the way things are done now is the right way" and our (justified) fear of messing with the fo…

Shared libraries also mean that you can patch a large number of programs, simply by updating the shared library.

If you have a large number of statically linked program, you need to recompile all of them, which means that you need to know exactly which applications uses the affected library, when a bug shows up, and recompile all those applications and redeploy them.

Without knowing, I imagine that's also partly why Debian wants to have all programs use dependencies installed via APT, it makes it easier to keep track of which other packages needs to be rebuilt.

Personally I'm a huge fan of having applications ship with all their dependencies, like statically compile Go, Rust or Java jar/war/ear files or even containers. It's super easy to deploy, but you do need to be constantly rebuilding and keeping track of dependencies, and I'm not seeing a ton of people doing that.

For Python programs we use apt as a package manager for libraries, because that removed the burden of keeping on top of security issues, to some extend. We do sometimes need to back-port or build our own packages, but try to push those upstream whenever possible.

Re: Orphaning bcachefs-tools in Debian

#148

Post by ants_everywhere » Sat, Aug 31, 2024, 4:35 PM UTC

koverstreet wrote: post #100

ants_everywhere wrote: post #89

Earlier quoted context omitted.

Hey at least it's not the worst behavior we've seen from a Linux file system creator... I thought Carl Thompson's response was very good and constructive: https://lore.kernel.org/lkml/1816164937.417.1724473375169@ma... What I don't understand is that IIUC Kent has his development git history well broken up into small tight commits. But he seems to be sending the Linux maintainers patches that are much larger than the…

Honesty, I think I just presented that pull request badly. I included the rcu_pending and vfs inode rhashtable conversion because I was getting user reports that it fixed issues that were seriously affecting system usability, and because they were algorithmically simple and well tested. Back in the day, on multiple occasions Linus and others were rewriting core mm code in RC kernels; bcachefs is still experimental, s…

Yeah I see where you're coming from. By the way, I only heard of bcachefs yesterday and I watched a great video where you were presenting about it. I'm excited about the file system and it's super cool to hear from you!

Re: Orphaning bcachefs-tools in Debian

#149

Post by SkiFire13 » Sat, Aug 31, 2024, 4:38 PM UTC

sp1rit wrote: post #78

frankjr wrote: post #28

The list of dependencies doesn't really seem crazy. Logging, parsing command line arguments, band-aiding error traits, working with uuids, reading binary data, "memset_s". All of those should be a part of the standard library as in any other programming language. The fact that you simply cannot build anything but trivial examples without taking a dependency on a third party library is just plain ridiculous and hinder…

Still, if you include transitive dependencies you end up with a total of 90 dependencies[0] which is unheard of in systems programming. This for some reason includes stuff like "winapi-i686-pc-windows-gnu" which really has no place for a set of linux software tools. [0]: https://github.com/gentoo/gentoo/blob/master/sys-fs/bcachefs...

> with a total of 90 dependencies[0] which is unheard of in systems programming

If the comparison is with C/C++ then the comparison is flawed:

- some you would never see in C/C++ because there's no point to them (e.g. safe bindings to system libraries)

- some are the same dependency but split in multiple crates to improve compile times (e.g. `anstyle`, `clap` and `regex`)

- some in C/C++ would just be vendored due to the difficulty of package management (see for example [0])

> This for some reason includes stuff like "winapi-i686-pc-windows-gnu" which really has no place for a set of linux software tools.

I don't know how Gentoo's build system works, but Cargo resolves the versions for *all dependencies*, including those that are conditionally compiled (e.g. based on the target OS). This is because the `Cargo.lock` file, which contains the actual dependencies versions used, is supposed to be versioned in e.g. git, and thus needs to be cross platform and be the same for everyone compiling the crate.

[0]:https://wiki.alopex.li/LetsBeRealAboutDependencies#gotta-go-...

Re: Orphaning bcachefs-tools in Debian

#150

Post by tsimionescu » Sat, Aug 31, 2024, 4:42 PM UTC

rfoo wrote: post #72

rlpb wrote: post #14

Earlier quoted context omitted.

Maintenance is much more practical if everything in your dependency tree uses the same version of every dependency. Achieving this in practice is much of the work distribution maintainers have to do. Doing this has a couple of key advantages: 1. when a security vulnerability needs patching in a stable distribution release, the security team only have to patch one version instead of a dozen or more different versions…

No. 1. Rust is as hostile to dynamic libraries as glibc to static. 2. With everything static you have to rebuild every dependent on any security patch anyways. If you meant with multiple versions maintainers have to backport patches to multiple versions. Maybe don't backport at all? Some people appreciate having backports. Users of software written in Rust does NOT. So why bother doing backports for them? 3. > a libr…

> Some people appreciate having backports. Users of software written in Rust does NOT. So why bother doing backports for them?

This is completely false. First and foremost, people who use applications don't care at all what language those apps are written in, and there is no "community of people who use Rust tools" that could have a different world-view from everyone else.

And beyond that, there is no one in the world who doesn't want backports, because it's never safe to just take the latest version of some piece of software and expect that everything will still work as expected. Having to take even a month of new features just because you need a security fix.

And note that Rust even at the language level has strong support for backwards compatibility and support for older versions. It's definitely not true that Rust people, even developers, live at the bleeding edge and don't need backports.