stsp's comments

Many years ago I was using fossil for OpenBSD development to manage my patches.

Around that time I tried to import the entire OpenBSD src repository into fossil, by importing the CVS-to-git conversion of src, as published on Github. I was following the official git->fossil migration guide. I left this running for a week (or two?) at which point the fossil git loader was loading OpenBSD commits from somewhere around the 2000s. At that point I stopped the process. Performance might be better today, I don't know. And perhaps post-conversion run-time performance is much better, but I never got that far. Anyone can try to reproduce these results by running the same conversion today.

I don't think I ever talked about my attempts with fossil to anyone at the time. But I recall the topic coming up somewhere when the Game of Trees project became public, and someone suggested I should be using fossil instead.

I am now using Game of Trees for all my OpenBSD development work and I am happy with it.

Git is not insufficient. For various reasons, Git is not a good match for what OpenBSD needs. OpenBSD needs an implementation that uses privsep, pledge, unveil, fits the mindset needed for Theo to accept running it on his own infrastructure, doesn't carry more baggage than necessary, and is a joy and easy to work on for OpenBSD developers independently from third parties. So the options were forking Git or writing something else, and I chose to do the latter.

See the goals page for more: https://gameoftrees.org/goals.html

There is also a more recent presentation about the server implementation:

https://www.openbsd.org/papers/fosdem2023-gotd.pdf

https://fosdem.org/2023/schedule/event/game_of_trees_daemon/

Hi, I am the Game of Trees project founder and main author of the code.

If there is anyone here who would be interested in seeing this project advance faster and has funding available, please talk to me. I am a freelancer with an EU VAT ID.

Progress since the beginning in 2017 has been steady but slower than I would like. I have occasionally applied to various open source funds (prototype fund, NGI zero, and the like) but was never lucky enough to get funds allocated (which is fair: many other great projects are being funded instead, so I am not bitter about this).

And I don't want to bother the OpenBSD Foundation since they are already partly funding unrelated work I am doing in the OpenBSD wifi drivers and 802.11 stack. I also believe that the ability to run this alternative Git client on any nix, and the alternative Git server on OpenBSD (though there are plans to port the server to any nix as well) can be useful for many communities and organizations beyond OpenBSD.

Some things I would like to work on in particular are:

- SHA256 object ID support, enabled by default, with repositories running either SHA256 or SHA1, without the ability to mix different hashes in the same repository. The server could offer a read-only repositories converted to SHA1 for legacy clients which do not support SHA256. Git itself does already support SHA256 so this won't break compatibility with regular Git clients. Though it might not be possible (yet?) to push SHA256 repositories to many hosting sites but that is not Git's fault.

- Server-side "trivial-rebasing" of changes, such that clients could push changes to servers without having to fetch first, provided pushed changes can be merged tree-wise, ie. without any file content clashes or unclean additions/deletions of files.

- Performance improvements; Got currently spanws one privsep child process per pack file on disk, cycling children in and out as needed when there are too many pack files. This can cause a lot of forking during random access across the entire history, which occurs when computing deltas while packing. Small pack files should be stored in memory instead, and each child process should be able to handle multiple packs to reduce the amount of forking.

You can skim the man pages to see all the work that has already been done: https://gameoftrees.org/manual.html And of course you can read the source code; see the web site for details.

Hi, I am the person you are accusing of mischief.

I didn't break any agreement. I agreed with Mathy on what to do, and that's what I did.

The fact that Mathy decided to get CERT involved and subsequently had to extend the embargo has nothing to do with me.

(edit: typo)

OpenBSD wifi maintainer here.

I was informed on July 15.

The first embargo period was already quite long, until end of August. Then CERT got involved, and the embargo was extended until today.

You can connect the dots.

I doubt that I knew something the NSA/CIA weren't aware of.

Your impression that nothing ever happened does not align with the facts.

The project applied 2 years in a row, and mentored several students. Some developers mentored more than one student.

https://www.google-melange.com/archive/gsoc/2014/orgs/openbs... https://www.google-melange.com/archive/gsoc/2015/orgs/openbs...

> I would have worked on the same project in the summer even if I was not getting paid

Yes, this is exactly what GSoC can be good for. Ideally, it allows people like you to spend time doing what they love doing instead of working for crappy startups.

The good (and fun!) experiences I had as a mentor all shared this element.

What I think is unnatural is the situation where the student is being paid, and where the mentor has a formal responsibility for the student and acts as the person who ranks the student and thus decides upon their salary (fail the student -> no money).

In a normal situation, new contributors show up and are self-motivated, and receive guidance from others so that over time they become equals. The mentor's role is spread among several people, and it is informal and temporary. There is no money involved.

Many (not all!) GSoC students do not experience what the normal situation in open source feels like.

I am happy that your student is an open source enthusiast and got a job in open source. That is great.

I have seen this kind of good experience, but also more disappointing ones. In one case, a student simply disappeared after the first payment (in the middle of the summer) had been issued.

For this particular open source project GSoC brings no advantage to the table (yes, it may be great for other projects).

OpenBSD does not need GSoC to attract contributors. The project gets a good amount of new contributors on a regular basis, and they get onboarded quickly without causing much distraction, if any.

The mentor/student relationship is atypical for open source projects which are used to operating as a community of equal peers. Mentoring students who expect to be mentored takes a lot of time, and the vast majority of them don't come back. In my experience money is a key incentive for students in GSoC and that makes it hard to keep them as volunteers. Unless you are very lucky as a mentor and pick a student who turns out to be an open source enthusiast, they won't actually care about your project in the long term. And there is no way of knowing that during the application process. Unless in special cases where you already know the student, as I did in one instance, but that's an exception.

(Speaking as an OpenBSD dev, and as a former mentor of several GSoC students, over several years, at the Apache Software Foundation).

+1 -- This is the one and only problem I have to regularly help my non-technical Ubuntu friends (and their friends) with. Every few months they cannot install updates anymore because their /boot fills up and apt fails to install a new kernel package.

The simplest fix would probably be to make /boot large enough by default (in the order of 10GB or 20GB or so -- the current size is 512MB IIRC).

A better fix would be to purge old unused kernels automatically but as far as I understand there were some difficult edge cases around that.

Thanks!

These look nice but they focus on the physical layer.

Do you happen to know any useful English literature that covers the MAC layer of modern wifi standards (n, ac, ax)? Apart from the 802.11 standards, of course.

I would recommend reading books instead of blogs if you really want to understand this stuff.

O'Reilly's "802.11n: A Survival Guide" is fairly OK.

If you read German, I highly recommend "Wireless LANs" by author Jörg Rech.

There have been follow-up fixes to the script and the link above is now stale. See https://svn.apache.org/viewvc/subversion/trunk/tools/hook-sc...

Apache Subversion developer here.

Andreas Stieger (SUSE, SVN) has written a pre-commit hook script which rejects commits of shattered.io style PDFs

https://svn.apache.org/viewvc/subversion/trunk/tools/hook-sc...

This is the first mitigation available. If you are responsible for an SVN server at risk, please make use of this hook.

If somebody could make a similar hook for Windows and post it here or to [email protected] that would be highly appreciated.

(edit: switched script link to HTTPS)

Please don't remove your post. Pointing out these issues is very important, and making one donation should not indemnify people who behave in this way.

I won't defend their demeaning public behaviour towards OpenBSD. I find it revolting.

But they did make one donation to this OpenBSD developer. They sent me 3 rcc-ve boards which I am still using for development: http://cvsweb.openbsd.org/cgi-bin/cvsweb/www/want.html#rev1....

They took much more than they have given (which the source code licence allows them to do, even if it's morally wrong). Claiming they never gave anything at all is incorrect.

It should probably say "On operating systems which support arbitrary locales, ..."

The photos are all from the area around Calgary, where some of the initial ideas were born during an OpenBSD hackathon. IIRC we disabled Latin1 support during this hackathon.

While giving this talk in Belgrade, Ingo apologized he didn't have photos from a Belgrade hike yet so he used the Calgary ones instead.