PeterWhittaker

From what I can tell, those options make the GPU available to podman, but without any form of host isolation/separation: the GPU is fully available without restrictions.

Since none of the existing namespaces treat GPUs directly (though perhaps this could be accomplished with cgroup?), this lack of isolation doesn’t surprise me.

While this may be useful for some workloads, the apparent lack of separation gives me pause from a security PoV.

One would hope that podman containers accessing GPUs are otherwise properly constrained to prevent their workloads from using GPU access to gain undesirable access to other hosts resources.

So I am left with my original question: what equivalency to podman, other than invocation convenience, is missing from nspawn? If none, it seems to me that having an awkward invocation in nspawn helps alert the user to the risks hidden by podman's convenience.

Your comment intrigued me so I read the issue, but I don't follow how his comments re a potential security concern and being able to overmount from inside the container lead to a conclusion of not seeing the point.

As a cybersecurity guy, my interpretation is that the requested change could introduce a vulnerability and that there is another potential path to achieve the same result, which should likely be explored first.

Any change that can compromise security needs significant justification, and should come with guards to allow it to be used in those cases where no other alternatives exist, without impacting other cases.

I've mostly used podman and am far from expert, and have long been intrigued by nspawn, so I really would like to understand the rationale.

Any other examples of nspawn mount limitations impacting operations without "workarounds"? Thanks!

If lifestyles support it, and parents are so inclined, I'd worry less about teaching the first few years and more about reading to them and with them, esp. with some silliness and improvisation, hiking, camping, and shopping as a family, especially at local markets.

Spend meaningful, loving time together, and out in the world, as much of the small scale natural world as you can. Listen to their questions, answer when you can, learn the answers together when you can't.

If they are accustomed to hiking and camping, especially wild camping, they will learn much from you and will ask for more.

If you shop together at markets, they will start to develop a more complete relationship with their food supply and with the people working it.

Empathy and kindness and resilience will develop in those experiences.

Later, when they are closer to school age, be as honest with them as you can about the different personalities they will encounter, the conformist teachers and students, the rebels, the do gooders, the no goods, etc., and comfort them that their people may be there right away or may not be there for decades.

Oh, flashback to learning queueing theory decades ago!

In principle, token ring was faster than Ethernet (which was CSMA/CD in the day): the mathematics of token ring were exact and analytic, and, when solved, gave higher speeds and better reliability than Ethernet, the mathematics of which were so complex (think three-body-problem) that analytic solutions were available only for bounding equations, which resolved to slower than token ring.

In practice, Ethernet was much faster.

A classic "the model is not the territory" problem.

Sounds like the school needs to wrap things in a seccomp denylist. Potentially non-trivial, but potentially interesting.

And this is exactly why dependency on single-source energy is anti-sovereign.

What's sovereign? Electricity-only to the home, subsidized battery packs in every home, as much solar as possible everywhere, full-spectrum centralized generation (including gas, oil, solar, wind, nuclear) all decentralized as much as possible, etc.

It's already bad enough that several major economies concede energy reliance to potential adversaries, but when one concedes critical financial controls, well, one is F'd AF. I know Ghalibaf won't get the Nobel for Economics, but he should.

Naive question, since this isn't my area of expertise, but Rust has RwLock: Why wouldn't one simply use RwLock to allow many readers and a single writer?

How does this approach outperform RwLock (for arbitrary interpretations of outperform) and how does RwLock outperform this approach (ditto)?

Yeah, no: We use recursive make extensively with a mix of "just normal makefiles" and autoconf schtuff, and it all works fine and reliably.

It's like any programming: Understand your tools, understand your requirements, understand your design and implementation (code carefully), test, review the design and implementation, test, repeat as necessary.

Still a big fan of make all these decades later. One day I may reach BJJ blue belt level.

Examples, preferably academic?

> That turd just ain't right

Best thing on the Internet this week. Thank you.

I really do hate to pile on with negative comments, but there are several at best misunderstandings and at worst errors in this:

1. TFA argues that malloc is for dynamic memory allocation and that arrays are for fixed counts. Sort of. In modern C, you can always char someArray[someValue]; what you cannot do is char someArray[someValue] = { '\0' }; making malloc good for the case where you need some initialization, but then you should probably be using calloc or some other call.

2. TFA indicates that top will tell you how much memory your process is using. Uh, sorta kinda maybe not always? Reporting memory utilization is a black art, top was built before current opacity, and this area is never as clear and clean as it seems. I have a tab group called "true memory usage" which consists of a dozen or more pages to remind how many edge cases there are here. hic sunt draconis

3. TFA kinda sorta implies that malloc means a system call and a change to brk, but TFA also mentions that malloc isn't a system call but a libc call: if you have previously called malloc and freed memory, or if your task's space is large enough, malloc might not involve a system call at all and brk/srbk might not be involved, since libc may have satisified your memory request from your existing task space.

It reads like a fine, clear, and correct article, but it isn't, really. Sad to say, because it did read really well.

The asynchronous behaviour raises interesting questions as to whether or not this is a bug or working as intended, and whether or not the io_uring API should offer controls to allow the calling application to decide.

With synchronous intra-machine calls we mostly take it for granted that pending modifications die with the caller.

But with inter-machine communications we mostly take it for granted that the sending machine and its entire local area can disappear and operations it sent will complete.

Of course, there are exceptions, especially when APIs/systems offer atomicity, consistency checks, etc.

But without express design intent, or preferably caller intent, one can argue both sides of the asynchronous intra-machine case and be right.

I guess my thinking isn't so much that this happens as that it happens implicitly.

But rivers have been mathematical for only something less than ~60 years, no? Mandelbrot's paper on the length of the coastline of Albion was in the mid 60s or so, and the math that made rivers mathematical (fractals, chaos theory) came after that (within my lifetime!).

Rivers are mathematical only because we have so improved our mathematics in recent times (when my parents were born, they were random and non-deterministic, mysterious).

The question of code ownership highlighted in some of the comments herein (e.g., "when you build software, you own it... "No, I specifically don’t. My company owns it...") takes me back to a paper I read years ago on password management and extrinsic risk: The basic idea was that employees have no real motivation to maintain password hygiene because they bear little to no risk of password compromise. They are asked both to be productive and to be secure, they are more likely to be sanctioned for productivity problems than security problems, so they sacrifice company security in favour of employment safety.

We've seen commentary along these lines re AI productivity gains Vs code maintenance costs and quality concerns for months/years now, but somehow, for me at least, viewing this through the lens of code ownership (literal ownership, not metaphorical/moral ownership in the 'take pride in your work and do it well, regardless' sense) makes this extrinsic risk all the more clear.

It also makes me think of the estimated billions lost to spreadsheet errors: non-programmers unaware that they were programming creating spreadsheet macros that appeared to do exactly what they wanted, but that in reality only did so most of the time, with edge cases and error handling omitted entirely, leading to significant financial losses for their employers.

In that case, the lack of sanction is far clearer: They were not programmers, they did their best, no one noticed and it wasn't their job to do so, etc.

The case of AI isn't that different, especially since it is just as available to the non-programmer as it is to the cavalier, or to the pressured junior, or to the responsible, take-ownership-and-maintain developer.

AI without governance and program management leads organizations to assume unqualified and unquantified risk with diffused responsibility; outside the small class of take-ownership-and-maintain professional, all risks are extrinsic to individuals so why should they care if it gets the job (mostly) done?

They don't and they won't.

(Reaches for popcorn to watch imminent train wrecks whilst hoping his water supply remains uncompromised.)

Your last paragraph is pretty much what I said. The sun being white is a recent development in human knowledge, and our recent and very good theory was only confirmed empirically very recently indeed.