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.
You think bland vegetables are your ally? You merely adopted them. I was born in them, molded by them. I didn’t taste flavored veggies until I was already a man, by then they were nothing to me but delicious!
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?
Was ist das für ein Votzenlappen. Da werde ich mal raufscheissenpissen
Thanks for posting peertube content, it’s time people stop using YouTube
Their militia’s (which Wagner group is) strategy is bullying civilians
Encryption? Also you’re assuming there’s only one block device…
assuming the person before did not just mean partitioning, but also all other storage-related tasks
This is the opposite of me. I always get nervous when I don’t have precise control over how the disk layout looks. I explicitly decided for the non-graphical installer when I first downloaded NixOS
Does it? I have two VMs on remote VPS servers that use GRUB because of no UEFI and I had no issues
This is not how NixOS works. Programs directly link against libraries in the store. There is no sandbox by default when running the binaries.
Go to McDonald’s about every 4 years because of some external circumstance
“Yup, still garbage”
Have one in 5 minute walking distance ever since I moved here 5 years ago. Never bought anything there. They’d need to pay me to eat their offerings.
But in fairness shoutouts to the McDonald’s in Madrid airport terminal 4 outside of security. The only place in there not trying to rip you off. Had my share of salads there
Probably both - however I think it’s not unreasonable to assume that organizations as mentioned in the article at least have the Chinese government’s blessing, if they’re not directly controlled by it. So even if the fentanyl itself is not coming from outside the states, the precursors from which it can be made with little effort are.
That and I guess some gangs make it somewhere else and then import it, but that’s another story.
Also technically, I think there’s legal fentanyl being produced in the states, but that’s usually not what’s meant in the discussion.
Asking for a friend
The team also procured secondary ingredients used to process the essential precursors, as well as basic equipment – giving it everything needed to produce fentanyl.
The core precursors Reuters bought would have yielded enough fentanyl powder to make at least 3 million tablets, with a potential street value of $3 million – a conservative estimate based on prices cited by U.S. law enforcement agencies in published reports over the past six months.
The total cost of the chemicals and equipment Reuters purchased, paid mainly in Bitcoin: $3,607.18.
Turning these precursors into fentanyl would have required just modest lab skills and a basic grasp of chemistry. One Mexican fentanyl cook who dropped out of school at age 12 told Reuters he learned the trade as an apprentice at an illegal lab.
“It’s like making chicken soup,” said the cook, an independent producer based in the cartel stronghold of Sinaloa state. “It’s mega-easy making that drug.”
Actually one block in the article
A web browser? There goes my career as a drug lord
I use
/mnt/$proto/$server, though that level of organization was probably overkill. Whatever…