Xe Iaso

A Dockerfile is not a reproducible set of build instructions in most cases. I'd guess that the vast majority of Dockerfiles are not reproducible.

Let's look at an example dockerfile for redis (based on [0])

FROM debian:buster-slim
RUN apt-get update; apt-get install -y --no-install-recommends gcc
RUN wget http://download.redis.io/releases/redis-6.0.6.tar.gz && tar xvf redis* && cd redis-6.0.6 && make install

(Note, modified from upstream for this example; won't actually build)

The unreproducible bits are the following:

1. FROM debian:buster-slim -- unreproducible, the base image may change

2. apt-get update && apt-get install -- unreproducible, will give a different version of gcc and other apt packages at different times

Those two bits of unreprodicble-ness are so core to the image, that they result in every other step not being reproducible either.

As a result, when you 'docker build' that over time, it's very unlikely you'll get a bit-for-bit identical redis binary at the other end. Even a minor gcc version change will likely result in a different binary.

As a contrast to this, let's look at a reproducible build of redis using nix. In nixpkgs, it looks like so [1].

If I want a reproducible shell environment, I simply have to pin down its dependencies, which can be done by the following:

let
pkgs = import (builtins.fetchTarball {
url = "https://github.com/NixOS/nixpkgs/archive/48dfc9fa97d762bce28cc8372a2dd3805d14c633.tar.gz";
…

The initial alpha (beta?) release of the project was scheduled for public review, but the developer was accepting payments for early access. I won't comment on the state of the release that some people paid for.

The devs seem to have made a few enemies. Devs of other small projects, specifically Nim and Zig aren't fans of V to say the least. Nim devs allege that the V project has made defamatory remarks about their project. Zig developer, Andrew Kelly, also had some things to say about V. [0],[1]

There have been numerous occasions of the V dev deleting criticism.

There are claims that the V project has been buying stars on github.

The project makes very bold claims about the feature set while not having actually implemented said features.

There is a popular set of blog posts that dives into the issues with claims vs reality [2],[3],[4]

My opinion is that I do find it disingenuous, and borderline scammy, to accept donations and at the same time claim V can do the things it claims. Ultimately, I think the dev is just not great at managing expectations. I highly doubt any of it is malicious intent. Also, somewhere in one of these, Andrew retracts his accusation of fraud, due to the V devs updating the advertised capabilities of the project.

[0] https://github.com/vlang/v/issues/292

[1] https://news.ycombinator.com/item?id=20230351

[2] https://christine.website/blog/v-vaporware-2019-06-23

[3] https://christine.website/blog/v-vvork-in-progress-2020-01-03

[4]…

I find it unfortunate that some of the responses in the mailing list amounted to "don't worry about being discriminated against because of your 'real' name; I pinky-promise that we're all nice people". Members of a cryptography community should know better than to demand that someone explain why their distrust is justified.

Obligatory link to two articles I think everyone implementing a name system should read:

1. "A Model for Identity in Software" [0] describes how people often have more than one identity. Different identities might have different personalities and names, especially on the Internet. For example, one person can go by "Johnathan", "Mr. Doe", "Jonny", "NoobMaster69", and "Dad" and react differently when greeted by each name.

[0]: https://christine.website/blog/identity-model-software-2021-01-31

2. "Falsehoods Programmers Believe About Names" [1] shows that nearly every assumption you make about names is wrong, and it's therefore best to rely upon as few assumptions as possible.

[1]:https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/

Personally, I find my non-anonymous online pseudonym "Seirdy" to be more "real" than my real name. In real life, my physical counterpart doesn't really have anyone to talk to about the things he's most interested in; that's something only I (Seirdy) can do.

This article is interesting, but not for anything having to do with CSS:

1. Start with a given approach, but say you feel something "off" because it doesn't quite fit "best practice xyz".

2. Use another approach, which also doesn't fit "best practice xyz".

3. Argue that the best practice shouldn't be a best practice.

This of course, should mean that the very first approach is just as alright as the second, yet here it is used to defend only the second (sure, there's a token acknowledgement of the first approach being valid too under the new assumption, but everything afterwards is a long "but not really, second one is the true better one").

Back to the topic at hand, the article depicts a circle: let's move away from inline css by... moving it one attribute over, to "class". The token attempt at contradicting this is unsuccessful one because, as much as there's no limit in the inline css you can do, there's no limit to the amount of classes you can add. So it all ends up feeling a bit self-defeating.

Ultimately, this article, IMO, is a good example of this: https://christine.website/blog/experimental-rilkef-2018-11-30.

Then again, I'm a developer first and foremost, maybe I'd like this better were I a designer.

The study methodology apparently involved a sample of high-traffic websites from https://tranco-list.eu. I have a hard time believing that the operators did not have to deal with such requests before. I always add the 30 day statements in my GDPR requests, mostly to make sure the support people set a calendar reminder to reply before the date. The next step if no reply is received is to complain to the data privacy watchdog in the country of the website operator or in your country if the website is operated outside EU (though I always begin with an email follow-up). Nobody would go to court after 30 days of a GDPR request without going through the govt data protection agency first. And to be clear, only requests are entitled to a 30-day reply and the email said that no formal request is being filed at the time [1].

But yes, that was clearly human research and the IRB should have grilled the PI about that.

[1]: https://christine.website/blog/princeton-study-2021-12-17

Edit: as you can see from the replies below, not only the study ethics is questionable but also the technical details about its methodology.

A single server has many Unix accounts! That’s how all servers worked before the cloud and VMs and containers.

The isolation isn’t perfect, but it’s good enough for good sys admins to manage.

File system permissions work, etc. It's much simpler than the cloud.

For a historical perspective, MS-DOS was a single user OS, while Unix was always multi-user. Windows NT / 2000 / XP was more like Unix since networking (LAN and Internet) became more important.

I still run my blog on shared hosting [1] and it works great. (Several of my posts have been on the HN front page and it always handles the load fine. Including one at the #1 or #2 spot.)

https://en.wikipedia.org/wiki/Shared_web_hosting_service

The Twitter pic here is a good analogy for blogs in the cloud:

https://christine.website/blog/the-cult-of-kubernetes-2019-09-07