Shamar @Shamar@qoto.org

@fudgel

Did you noticed your aggressive tone?

That's the usual approach of people supporting #CoC, #workplace like management (aka exploitation) of highly specialized #volunteer work, and #hacker marginalization.

I have no time for you. 😘

@ambrevar

@ambrevar

PS: I noticed you didn't signed such statement. I really appreciate it.

But still, your work is contributing to that same project. Even if you don't like it.

@ambrevar

I followed a bit the debate on the mailing list. But frankly, since it's still on the website and nobody published a "Joint Statement fix", #Guix last word is written down there.

I'm a #Debian #GNU #Linux user since "Potato", but after the #systemd outcome I was looking for an alternative.

I like some of the technical features of Guix / #Nix but honestly... I can't support a project joining the lynching of a man for what he _said_.

So in fact, all I can appreciate the concept, that "joint statement" really deter my usage of Guix.

#Software is a form of #expression.

#FreeSoftware IS #FreeSpeech.

I know there are #OpenSource people who pretend to ignore what happened and celebrate it like a #CoC success or so.

What I find very daunting is seeing this happening within #FSF and #GNU.

#Google is winning. 🤮

@snow

I have another idea. 😉

The "#trolley problem" is a trick to spread the idea that human lives can be priced.

It force people to accept to kill AND to give a comparable value to people.

Then the #MoralMachine from #MIT went on: what if you have to choose between the life of a kid and that of a executive? What if you have to choose between one pregnant woman and a homeless? What about a "criminal" or three dogs?

Human lives are not comparable.

Each person is unique: his value is not a scalar, but a vector orthogonal to the value of each other.

But the trolley problem has a simple and obvious solution: design and build safer tracks and trolleys, so that people CANNOT be killed.

Once you think about it, it's the obvious solution. And an optimal one.

Some will argue that such safe system is expensive, so you have to choose.

But guess what?

These are those who want to sell them. And those who want to sell #Capitalism. Because this is not, actually, #philosophy, but #politics.

@ambrevar

To be honest, since https://guix.gnu.org/blog/2019/joint-statement-on-the-gnu-project/ I feel uncomfortable with #Guix.

What I've read there and on https://freesw.org/ puzzles me.

Looks like #OpenSource that finally replaced #FreeSoftware inside the #FSF is attacking the #GNU movement, now.

@ohyran

I don't know where you studied #Latin, but "firmitas" had nothing to do with performance.

It's stability.

@xj9

@grainloom

Sounds very interesting, but consider you are trading read() time for lookup time.

With your fs, file lookup would be faster than in kernel as the kernel would have to try every bound package until it finds the desired program.

But then, each read will need to pass through your file server.

I don't think it would be a large overhead, but it would be linear to the number of reads.

It should also be noted that the #Plan9 kernel caches (for a while) .text pages from binaries, so this read-time overhead would probably be almost invariant on successive executions of a binary.

BUT scripts are not cached in kernel (they are text, after all), so such read-time overhead would be larger.

Also Plan9 memory page is 4096 bytes, so on a large binary the number of reads might be high.

@ekaitz_zarraga

@grainloom

Lookup tables for the file path?

@ekaitz_zarraga

@dgold after reading this https://lipu.dgold.eu/original-sin.html I think you might find interesting #HESSLA http://www.hacktivismo.com/about/hessla.php and my #HackingLicense http://www.tesio.it/documents/HACK.txt

I've found particularly interesting your insights about #individualism and #Capitalism in #FreeSoftware.

I reached a similar conclusion, but I noticed that one of the issue is that corporations have legal personhood, so that such individualism somehow works in their favour instead of the whole humanity.

Thus the restrictions to organizations in the Hacking License.

Do NOT use #Google #Analytics.

Why should I #trust you, your products or your #Web site if the first thing you do when I enter is to inform stranger of anything I do there?

If you use #GoogleAnalytics (or any other Google service that can track your customers) you don't deserve trust.

Nor #money.

@grainloom

Yes, for each bind/mount on a certain "mount rock", the kernel sends at least one Twalk to the bound server/device.
So, on average, it should be roughly O(n) in the number of bind/mounts.

But since the path is hierarchical and you could have to traverse several mount point before reaching the rock, I'd say the actual time complexity can be much bigger as the file's path grows.

This shouldn't be an issue for conventional mount points such as /bin (/cmd in #Jehanne) or /lib, thus O(n) should be an appropriate estimation (as long as each bound server/device doesn't do funny things).

Anyway, your project sounds cool but I can't get why immutable packages is relevant in this context.
How are you going to exploit this condition?

@ekaitz_zarraga

@grainloom

uhm... in the general case, it probably is pretty ugly.

But ideally, each package would contain few folders that require merge to be run.

In the perfect world, only $pkg/bin would need to be merged (#Plan9 and #Jehanne only support static linking).

$pkg/lib would only be required to be merged if you need to _build_ software based on such library.

If we consider scripting languages things becomes more convoluted (as @ekaitz_zarraga noticed with #Chibi) but still, the shape of a package and it's impact on the namespace should be based on few conventional directories.

My approach becomes ugly only if each package violate such conventions.

Or maybe I'm missing something?

@grainloom

"mount rock" is simply the name used in the kernel for the Chan* that correspond to the "old" in bind(2) http://man.cat-v.org/9front/2/bind

I suppose it's called "rock" because it's the fixed point on top of which you "build" your namespace.

Suppose you have two packages A and B each containing a d directory, that contains different files.

You might have the packages extracted in directories like this:

A/
A/d/
A/d/file1.rc

B/
B/d/
B/d/file2.rc

if you overlay B over A, you'll have into the mount point M

M/
M/d/
M/d/file2.rc
M/d/file1.rc

But you could get the same effect by binding A before M and then B/d/ before M/d/

This can results into ugly tree but looks like the simplest solution (to some extent).

@grainloom

Thanks a lot!

I was considering to write something like that for #Jehanne's package manager.

But honestly I also like the obvious alternative: add to each package a importIntoNS.rc script that take care of

- importIntoNS dependencies
- recursively bind every clashing folder

The package manager would invoke the importIntoNS.rc of the packages you want to use (potentially using different versions in different rio windows/namespaces).

In the example at https://www.cs.cmu.edu/~412/history/2004S/chaokul.html the `b` packages would not bind b/ over the mount rock that already contains aa/ from the a/ package, but bind b/aa/ over mountrock/aa/.

What's your opinion on such design?