NTSYNC is one example, I don’t know what the current progress is https://lore.kernel.org/lkml/20240124004028.16826-1-zfigura@codeweavers.com/

It was supposed to be in 6.10, I don’t know if that actually happened

deleted by creator

For most network share I use /mnt/$server.

I use /mnt/$proto/$server, though that level of organization was probably overkill. Whatever…

I do /volumX for additional hard drives.

A good first approximation.

So where in this setup would you mount a network share? Or am additional hard drive for storage? The latter is neither removable nor temporary. Also /run is quite more than what this makes it seem (e.g. user mounts can be located there), there is practically only one system path for executables (/usr/bin)…

Not saying that the graphic is inherently wrong or bad, but one shouldn’t think it’s the end all be all.

The title says “bcachefs-tools”, the linked kernel thread that the comment referred to was about the bcachefs kernel part and did not touch the bcachefs userspace tools. Debian says they can’t package with these pinned dependencies and explains why. Kent says relaxing dependencies breaks the programs.

The only hint at the other topic I see is this:

(not even considering some hostile emails that I recently received from the upstream developer or his public rants on lkml and reddit)

I guess this is about https://www.reddit.com/r/bcachefs/comments/1em2vzf/psa_avoid_debian/, and while I think the title is too broad, the actual message is

If you’re running bcachefs, you’ll want to be on a more modern distro - or building bcachefs-tools yourself.

I don’t consider Kent’s reasoning (also further down the thread) a rant - it might not be the most diplomatic, but he’s not the only one who has problems with Debian’s processes. The xscreensaver developer is another one for similar reasons.

I think, in fairness, bcachefs and Debian currently aren’t a good fit. bcachefs is also in the kernel so users can rest it and report, but it wasn’t meant to be stable; it’s meant to not lose data unrecoverably.

Anyhow, while I think that he’s also not the easiest person on the LKML, I don’t consider him ranting there; and with the author’s and my judgement differing in these points, I’m led to believe that we might also disagree on what qualifies as hostile.

Lastly, while I’m not a big fan of how Rust packaging works, it ensures that the program is built exactly the same on the developer’s and other machines (for users and distributors); it is somewhat ironic to see Debian complain about it, since they do understand the importance of reproducibility.

You must have missed the last half of the post then. Especially the last two paragraphs.

There’s isn’t much more to that issue than that sentence, while all other paragraphs cover the packaging. It’s tangential at best.

The OP is about packaging issues with userspace utilities due to version pinning in Rust. It’s an issue with Rust in general. Kent is not obligated to lock dependencies in any particular fashion. He could loosen the dependencies, but there is no obligation, and Debian has no obligation to package it.

This is different from the thread you linked in which the bcachefs kernel code and the submission process is discussed, and on which there was a thread here as well in the last days. But your criticism, as valid as it is, only applies there, not in a thread about tooling packaging issue.

Which is a completely different issue than what the post is about, hence my question

Submitting something that is generally problematic and yelling about how it will EVENTUALLY be good is a good way to get your shit tossed out.

What are you hinting at regarding this specific news?

Maybe not, but doesn’t really answer my question what this would be used for.

I’m not hating, just interested; my last knowledge was that if you wanted to play Direct3D 12 games, you’d need the proton fork. But I don’t know many other things Direct3D is used for, so…

Yeah but to my knowledge only limited, when I tried it back then, D2R wouldn’t run with it, you’d need vkd3d-proton.

Is this at this point useful as anything else than being a base for vkd3d-proton?

Don’t know how much this would help you; I did this on NixOS, however the steps for creating the key pair and enrolling is the same on all distributions, while your UEFI steps can vary depending on the manufacturer.

https://github.com/nix-community/lanzaboote/blob/master/docs/QUICK_START.md

https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot for Arch

Microsoft, by default, decides which code is safe to run, yes.

However, that’s not the only way to use Secure Boot; I enroll my own certificates in addition to Microsoft’s, allowing code that I sign to be booted into. This requires some UEFI setup once.

For most machines, Secure Boot should never lock you out completely; you can always disable it, fix your boot chain and reenable.

I think it’s actually sensible technology, but as every security feature, it usually comes at the cost of some convenience.

Thanks for posting peertube content, it’s time people stop using YouTube

Which means you can sell support in addition to the service itself. Mission accomplished!

Some extensions won’t matter in the slightest, especially concerning controllers that use the instruction set. For the vendors selling general purpose CPUs, we’ll see how it shakes out. It’s in their interest to retain compatibility, so I suppose it’ll be similar to how it’s handled for Vulkan: vendors having their own extensions that at one point get merged into a common de facto standard for general purpose computing or something.

The same was true for x86, Intel had SSE and AMD had 3DNow, programs just provided different codepaths per available feature (this is where Intel pulled some dirty tricks with their ICC). It’s not that big of a problem.

VIA also built x86 CPUs for some time, they have a license as well; the issue with modern x86_64 is though that basically, you need licenses from both AMD and Intel. They do have a cross-license agreement, but there’s no single point of contact for all licenses for a modern x86 CPU.

Gentoo, while source-based and having an interesting approach with USE flags, does not come with NixOS’ strengths.

I’d even say that Gentoo’s packaging might be better in some aspects than that of nixpkgs, which does feature options that you can change via overrides but generally isn’t as modular as Gentoo’s system. But the mistake a lot of people – and I’d say you as well – make is that they look at the wrong parts for comparison, and don’t understand what makes NixOS so powerful. It’s not the sheer amount of packages or how they’re built, but rather the module system, the declarative nature and the option for rollbacks at the “package manager” level. Yes, these features come with increased complexity. However, I recommend not to look into what people have published in GitHub as their configurations, as these are rather general and as such more complicated than one needs for casual use.