Simon Richter
mastodon 4.7.3Geek.
9C43253495E4DCA837945F5BEBF67A846AABE354
Large parts of my timeline are now debating whether resisting the introduction of the "birthdate" column in the user database is part of a fascist takeover and should be resisted.
It is a distraction from the fascist takeover. The walls will come up somewhere else.
If it's not maintained by someone trusted by the government (i.e. an entrenched corporation), it *is* just a database column.
Debating it wastes a lot of energy we would need elsewhere: there is a lot of pending legislation that everyone now treats as if it had already passed, and so the only thing left to do is take a heroic last stand, to at least not be complicit.
We're not at this point yet. There are still things that can be done, but that means organizing against big tech, which means both political opposition, and building out alternate infrastructure if you're too exposed for direct political action.
Even debating whether the people involved are willing collaborators or just politically ignorant is a waste of resources at this point. Their motivations do not matter, they aren't allies either way.
These people aren't in a position to get the database column they created recognized as "trustworthy." Their act was one of symbolic bootlicking, so publicly opposing it likewise only has symbolic meaning.
The actual attestation framework that we will get is most likely some "login with Microsoft/Google/Apple/Canonical/Facebook¹" thing that integrates into the login process and requires no trustworthy components on the user's machine because all it does is forward a token received from one online service to another, and not presenting such a token locks you out from a lot of services, because the services themselves are at risk if they do not require such a token.
*That* is where this is headed, and *that* is what we need to oppose.
Of course open source will be left with local-only accounts. These just won't be able to connect to online fora.
¹ involvement of Facebook still unclear — no good reason for Microsoft and Google to let them have a seat at the table, really. Canonical will be there in the beginning to make it a bit less off-putting to Linux users, but at least their identity management will be merged into Google at some point.
Doing a small prerelease of my tarball validation tool:
https://psi5.com/~geier/tmp/git-treeof-0.0.20260411.tar.gz
The basic idea is that you can feed it a tar file, and it tells you What Would Git Do™, i.e. it is equivalent to
git init
tar -x
git add -A
git commit -m 'irrelevant'
git rev-parse HEAD^{tree}"
but it does not require a local filesystem, git installation or anything -- it's an isolated program that allocates 64 MB of RAM (that should be enough for everyone) and then activates strict SECCOMP mode before looking at any input data.
The main thing I'm unhappy with is the name, in principle it would be easy to extend this to a tar diff tool, and I also want to add some features like "if you supply the commit object via a separate channel, that can be verified too", so it's not strictly "give me the tree ID for this tarball" anymore.
Also, if you have use cases where it doesn't work, I'd like to collect these as well. I already know about submodules, and I also want to have a mode where I also parse gitignore files.
We're restarting #HillHacks this year!
Since we don't have the momentum of a yearly event yet (but want to get there again) this might be a bit smaller than previous editions, but this is still an excellent opportunity to meet people in Northwestern India.
This is an "unconference", where the talk schedule is decided mostly by the participants who are there. If you have an interesting project and would like to present it, a digital rights topic you want to talk about, or are interested in what other people are doing, you are more than welcome to join us.
Other coordination before the even happens mostly on the mailing list, which can be found at https://hillhacks.in/mailinglist/ . There are plans for a school program, for an open source hackathon and for some #OpenStreetMap mapping, and I expect that more ideas will come up in the coming weeks as well.
The main event website is at https://hillhacks.in/
Warm hier, aber waren Sie schon mal in meinem Serverraum?
Running my tar parser on all the tar files in the Debian archive, to find cases I haven't handled yet. It's not done yet, but so far I've collected
2 num_read == sizeof s->buffer
3 symlink_size < LEN_LINK_TARGET
3243 unexpected character in octal
780 unhandled file type
17 unused tar header has data
8 value_len < sizeof s->filename
Basically, I've plastered a bunch of checks all over the code that are like assert(), but remain in Release code. All of these are hard errors so far, and I will need to add more checks and also make the parser less strict in places where it is overly so.
"num_read == sizeof s->buffer" means that the tar file is not a multiple of 512 bytes in size.
"symlink_size < LEN_LINK_TARGET" means that the link target field is used completely and not NUL terminated. That's probably legal, but I'm amazed someone is running into this. Also, I suspect there is an encoding for even longer symlinks.
"unexpected character in octal" seems to be mostly octal numbers that are right-justified in the field with spaces, which should be legal.
"unhandled file type" refers to the file type marker inside the archive -- I handle directories, files, symlinks and extension headers for the whole archive and for individual files. So that's a TODO item.
"unused tar header has data" happens when the first byte of the filename is NUL, but there are non-NUL bytes in that block. Need to investigate what these are.
"value_len < sizeof s->filename" means that there is a long file name with more than 255 bytes.
Getting the full statistics will take a while, and then I need to fix the program and re-run everything.
@regehr I think this should be a kernel feature.
There is a scheduling class, SCHED_BATCH, with low priority and very long (1.5s) slices. I think this could be improved even further, by essentially making the slices infinite, yielding CPU in execve() at the point where the process image is smallest, and on memory pressure, swap out the other batch class processes, smallest first. When there are free CPUs, resume the largest batch process.
Users would just make -j with no limit.
I should add a public graph "Inbox size" to my personal homepage.
Spending the rest of my "lunch" break on improving society somewhat.
Time to order the good biryani and kebap for the fourth time in a week, I guess.
I should put the TalosII into a colo facility.
100Gbps is probably too expensive, but it would be cool to see if it can keep up.
Oh cool, updating the work laptop broke SCIM.
What does one use these days for
- Japanese text input
- ideally, Anthy tables
- needs to work with QT, GTK and XIM
?
The rain is so loud I can't hear the CPU fans anymore.