Why not just put all of portage on read-only NBD volumes?

[nokilli]

[nokilli]

[nokilli]

[nokilli]

Facing the serious prospect that the tarballs won't be stable.

Again, if the plan is to store the package source in addition to the tarballs so that the user only need download the one file as opposed to many, there is still the problem of verifying package integrity since it's the tarball that gets signed by upstream, right?

And while you can expand the package source from a tarball, and then recreate the tarball from that source, and do indeed end up with a tarball that contains the same files, it's maybe not the same bits. Upstream is signing a hash of the tarball. One bit out of place and it all breaks.

Add to the complexity, I bet the underlying file system plays an important role. Projects die on these rocks all the time.

For the moment I'm going to assume there's an answer, perhaps some additional process in addition to expanding all of these tarballs that produces some kind of hint file that can be used better construct the tarball on the user's end? If this really can save significant bandwidth then addressing that complexity would be worth it, no?

(cpio guys are doing picard_facepalm.jpg)
_________________
We are the block device. The kernel is our client.

[nokilli]

We are the block device.

How powerful is that?

Here's an example: I changed my mind. Let's make this a writable NBD volume. Then we can put a CoW filesystem on there and instant multiuser filesystem, right?

Wrong. You can't do that because there is no way for the block device to allow the filesystem to perform a meaningful lock.

But wait.

We are the block device. If it was important to us, we could be aware of the filesystem we are hosting.

We would understand that a CoW filesystem has this one block that holds it all together. When you do any kind of write to a CoW filesystem, it does it to all new blocks that nobody else can see, then at the last moment it swaps out the root of the old btree with the root of the new btree you just created, right?

All we have to do here is serialize access to the root block. That means, in our case, developers giving us new tarballs, which are really file copies to the NBD server, which are really writing a bunch of blocks to the block device (that's us) in the hopes that when they are done, the root of the new btree they've just created is accepted as the new root for the filesystem.

Too slow, somebody beat you to it? You have to try again. At some point your copy goes through and then from that moment on becomes an indelible part of the Gentoo distfiles monolith.

This is as ideal a filesystem at it gets for where you have a few people doing updates and a great many people downloading the files! And isn't this exactly our use case?

Bonus! It's a live filesystem! The user is now mounting it rw, which means, we can add files to the device even while there are 1000 people who have this thing mounted in their mtabs. That does mean more blocks flying around, so we need a filesystem we can tune.

And now look at the potential latency between dev checkin and user access. Do the case that shows this whole system in its best light: the really package with the one tiny file change. Dev can submit that block and user can fetch it in the very next kernel call.

Bonus! You have PORTAGE!!! How absolutely wonderful is this, where you can let individual devs so easily post their stuff unimpeded and still let the community meter access via portage!

The Cathedral and the Bazaar! (sort of)

The LLM insists there's a way to get NBD working over TLS. Does that mean there may be some simple kind of authentication mechanism we can use to grant devs write access? Or would you be willing to drink still more koolaid and join me in my campaign to make block knocking a legitimate authentication protocol? Devs are granted access based on correctly reading specific blocks from the block device. This could also be used as a lock hint.

In the same way we can identify the root block for the CoW tree we're hosting, we can also agree on a convention for communicating status information back to the client by simply returning blocks that are updated with the new information in some convenient format, like json. Status information like, whether you were granted a lock or not. Or what lock contention is looking like.

http, ftp... these are protocols best reserved for people who can't block device.

EDIT EDIT EDIT (are you seeing this?) EDIT: this is not entirely stupid, but is useless for public-facing. Requires a client that we can trust. The kernel is our client... but anybody can pretend to be the kernel. Any process can connect and essentially pose as the kernel and ask the block device (you guys) to write bad blocks. No way to enforce use of a specific filesystem. I can do it here in the home network... I could write to the block device from different machines, and even handle competing requests, because I could trust that I was using a correct implementation of, say, btrfs, but what advantage then over nfs on native btrfs? Zero. Officially giving up on public-facing RW. IT CAN NEVER WORK. THAR BE DRAGONS HERE. KIDS DON'T TRY THIS AT HOME.

(but hey, at school, why not?)
_________________
We are the block device. The kernel is our client.

[nokilli]

I don't have a good feel for how important it is to reduce the time it takes to fix bugs. I'm going to proceed like how I'm looking at bandwidth savings, maybe it's enormous. But then too maybe not.

It could be important.

Does portage have the ability to allow the user to always retain /var/tmp/portage contents?

So user builds a package. All of the build files are allowed to remain. Why? So if this rsync over nbd thing happens in the future, we could conceivably rsync the new version from our local distfiles into the build directory?

What does that do to time from exploit discovery to exploit mitigation? We do the build it's conceivable that it's a compile or two and then a link, right? We could do the build at the same time we're recreating the tarball for package verification, and only on successful verification do the ebuild install?

Fastest gun in the west. Which is pretty impressive when you consider that Gentoos are not known for being gun-wielding birds.

Ok I'll stop.
_________________
We are the block device. The kernel is our client.

[nokilli]

Just one last thought...

Make it a pay service. Gentoo Express. Figure out a better form of authentication.

It's acceptable to pay $5 to a distro to get the CD, right? That's just another block device.

Ok, stopping.
_________________
We are the block device. The kernel is our client.

[pjp]

[nokilli]

[nokilli]

dmraid

mirrorselect becomes mirrorsselect

Gentoo suffers same bandwidth cost, but user gets to enjoy improved latency when accessing the repository.

We we we we are are are are the the the the block block block block device device device device.

And the kernel is our client.
_________________
We are the block device. The kernel is our client.

[NeddySeagoon]

nokilli,

... and things disappearing from the NBD server before they are needed?
How is that addressed?

My Pi5 takes 24 hours to build chromium and a couple of days for a complete update.
My AMD E350 takes over a week for an update.

I would get a bit upset if ebuilds and distfiles vanished after the dependency tree had been calculated, or even in mid dependency tree calculation.
That takes over an hour too.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[John R. Graham]

[nokilli]

[NeddySeagoon]

nokilli,

I'm a retired electronics engineer. Software is close to black magic for me. :)
I did do a lot of systems engineering too. Lesson one there is to start at a high level with the system requirements, then add detail to approach a solution.

You are starting with a perceived solution then trying to fit it to the problem. That won't work.
Poorly defined, or changing requirements lead to cost and schedule overruns, sometimes with big expensive projects being abandoned.

Start with a complete problem definition, then decompose it into lots of smaller problems. That may change the original complete problem definition but thats OK, it an iterative process.

Once you have your problem decomposed and its stable, look at potential solutions to all the smaller problems.
Even make a prototype, which you will throw away.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[pingtoo]

[nokilli]

pjp is right, you guys need to see results and there's nothing out there.

So trying to get the ball rolling.

https://github.com/nokilli/sandbag

Neddy doesn't know tar.
_________________
We are the block device. The kernel is our client.