@colonelj@bot Still would only remove the "honeypot" part from "tedious GOTIS drama-factory combined with a honeypot that doesn't even post tits and a long history of causing actual problems".
@lanodan I think checking the size of that is probably reasonable for things like memory allocation, though I suspect that it's just a list of all the types in stdint. (And why they can't just use sizeof is a mystery. It is really obvious what's going on if you see `if(sizeof(size_t) == 8)`, and even trivial compilers remove the branch when compile-time constants are compared, but some preprocessor macro for _SIZE_OF_SIZE_T is at least an extra level of indirection, and it is practically guaranteed that they are using `#if` instead of just `if`.)
@e3ea Persistent lunatic that has caused a lot of problems, stuff that's way over the line: cover fire for CP, never more than one degree removed from the swat/dox incidents. Persistent problem even before she turned into a direct liability.
@NEETzsche@theorytoe There's a difference between "good" and "follows all of the rules the pencil-pushers came up with". Arthur Whitney is out there doing these microsecond-response trading bots, writing brilliant code that got him terrible marks in college. Jefferson said "the man who never looks into a newspaper is better informed than he who reads them; inasmuch as he who knows nothing is nearer to truth than he whose mind is filled with falsehoods & errors." There's an analogue here: your hypothetical child writing spaghetti code is probably a better hacker than a guy with a "best practices" buttplug super-glued in place, because the the kid hasn't filled his head with the neuroses, but discounting all of the knowledge and training just because people do it wrong is throwing out the baby with the bath-water. What's that kid doing in 20 years, 30 years, once he's had to actually solve some problems? If you don't give him brain damage, maybe he's doing some really cool stuff.
Great chefs and your grandmother both do things in the kitchen that would be completely forbidden for a line cook at McDonald's, but you don't draw a line and put them on the same side as the guy that serves a plate of eggs with a curly black hair protruding. I wouldn't characterize McDonald's as "autism" and I certainly wouldn't say that it's a mistake to learn. I do think people scolding over "undefined behavior" are making the same mistake as someone that would go into my grandmother's kitchen and insist that she wear a nametag and a paper hat and follow a series of protocols that are designed around assembling food predictably without drawing the health inspector's ire, and that if she doesn't do that, she's not cooking correctly, and that all of the food cooked correctly is strictly better, in an objective sense, than her roast beef or blackberry cobbler. She certainly knew more about cooking when she was 70 than when she was 12,
Good code is a lot like good writing: it says what it was designed to say, the style is a component, etc., parallels abound. People write essays, and the way they teach essay-writing in school (the five-paragraph essay, with an opening thesis introducing three points, then one paragraph per point, then a final paragraph restating the thesis) has absolutely no bearing on the style of an essay anyone wants to read: what gets a gold star on your essay when you still get marks off for "poor penmanship" is nothing like what makes for good writing, and if we move up to the adult world, if you try to apply the AP Style Guide to Twain or Poe, you'll get uninspired tripe. George Orwell illustrated this by butchering a passage from Ecclesiastes; see below.
On the topic of programming, around the time I wrote the bit about Orwell, Seamonkey crashed and dumped core. This doesn't fit any style guidelines, but it just kept me from rewriting what I just wrote:
It's trivial and ad hoc, but to write it, you've got to have learned something about how the machine works: you've got to know what's in a core dump, that the strings are represented as UTF-16 in most browsers, how to turn that into ASCII before you give it to strings(1), etc. I'm certainly better at this than I was when I was 12. (Or maybe not knowing how to get the words back would have been preferable: instead of rewriting this lengthy missive, I might have just cited Sturgeon's Law, pointed out that it applies to people, and left the implications where they were.)
There are code monkeys that don't know shit about shit, there are anal-retentive drones that insist that the compiler could reformat your hard drive if an integer overflows, there are talented 12-year-olds, brilliant hackers, artists, well-read researchers, script kiddies. I don't like the drones, but they are one type of person in this profession, and they don't have much of a say in what I do: they're loud and they give each other titles and appoint each other to chair committees, and anyone with any sense avoids them. they_really_typeset_this_essay_terribly.png jincunabulum.png
@theorytoe The answer is that there's this simple and nice make(1), and then people complicate it, and that introduces portability problems, and then and then people shout at you that your Makefile doesn't work on VMS, and then a one-liner gets bloated into 30 lines of horseshit. The xz vulnerability is more like an autotools vulnerability: shit can sneak right in there because no one even wants to *look* at configure.ac or anything in the m4/ directory. So they think they can have something simpler and easier to manage if they abandon the ball of mud and start over with a new system for expressing a dependency tree, not realizing that when the portability cult arrives, they will have you compiling a million test programs to find out how big uint64_t and int32_t are, because if you put portability checks around types added for portability, you get double the portability. When looking at the code to see exactly what this unholy build system was called, the first thing I saw, near the top of their configure script (which is a bare shim that just invokes other build scripts) was that they override $JOBS, because even if you have taken care to set $JOBS to a number that makes sense on your machine, attempting to execute jobs in parallel triggers Python threading bugs on AIX. I haven't ever even logged into an AIX system and I don't think I know anyone that uses it, so I definitely don't want the build to slow to a crawl for that.
Portability is really nice, but this portability cult formed, and they try to turn the act of hacking on cool shit into a bureaucratic phantasmagoria, and then once those people reach critical mass, it's all "THAT FILE HAS A BASH-ISM IN IT" and "THAT'S UNDEFINED BEHAVIOR PER C11 AND THE DSM-V" and then people fuck off to elsewhere. In the mean time, there are people that throw a fit if your code wouldn't work on 1's complement systems that use EBCDIC instead of ASCII, and they end up producing code that isn't even backwards-compatible with itself, so you try to update a piece of software and there's an entire Gordian knot of dependencies to rebuild because library $x v1.1.0.2 is not compatible with $x v1.1.0.1. Unix people used to be able to joke that Windows users had to reformat and reinstall every month; that joke hits a little too close to home nowadays, when all of this complete shit code goes out of its way to be theoretically compatible with a system that runs Xenix, but is not compatible with a system from a year ago.
Somewhat related, I recently read some commentary :dmr: had about the fan-fiction that X3J11 tries to pass off as a standardization effort, and it seems pretty clear why most of the post-ANSI extensions were completely ignored by the authors of the C programming language:
> The fundamental problem is that it is not possible to write real programs using the X3J11 definition of C. The committee has created an unreal language that no one can or will actually use.
You see this same pattern repeat over and over again: process wonks and "best practices" fascists come in and make a tower of incomprehensible and self-contradictory rules and the effect is to kick people out of the language/ecosystem/OS so that they can be petty bureaucrats and issue memoranda to a depopulated nation as the lords of the tumbleweeds.
@kirby Yes! Went to eat, passed out after dinner; was scrawling an update and had planned to just reply with a link to it. The update is here: https://bae.st/notice/AgV0xzrcEP3URdvtSK .
SPC is down! I don't know for how long, and accounts apparently moved to shitposter.world, so I am also at @p, but because I don't know if people know about that server (I didn't know about it until yesterday, and I just stumbled across it on SPC), Imma be on @p for a minute until FSE's bugout zone comes online (the machine is assembled and booting things and prerequisites installed and whatnot; it is a lot of fun to type `make -j64` and really *mean* it, but most of the packages I built before the hardware arrived). I hope to finish the configuration in time to drive the box down there tonight or tomorrow night, although it may take a minute or two for some things.
Once the machine is back online, some pretty easy stuff will be back in a hurry: things like git.fse and blog.fse and bloat and whatnot. As I said a while ago, I will probably set up a bugout zone instance, just keep the users table so FSE refugees can log in with their regular username/password, same version of Balormo and everything, basically minimal-effort bugout zone. I'll be on the bugout zone server, FSE refugees are welcome (registrations will be closed, so you'll only be able to get in if you already had an FSE account when the machine exploded), but it will be unstable because its primary purpose is to help with Revolver development (there are things that would be much easier to do with current, live data coming in) and it will probably usually be slow or weird and I will not be doing normal server things. Some of the slowness will be a result of a bunch of Revolver stuff getting shoved around through the system, so it will be busy, some of the slowness will be because the machine is spec'd to do Revolver-style things rather than Pleroma-style things like the previous machine (e.g., the dead box had a really massive amount of RAM for Postgres, the way resources are partitioned in this machine, there's less RAM available in one place). But it'll be there if you want it and you don't mind being subject to technical whimsy.
The bugout zone will be on a subdomain or maybe I grab a different domain for a minute, I don't know. I'll announce it. There will be something that is up at freespeechextremist.com but will not be quite usable for a while, as it's software under active development, a lot of parts are missing, some things are stubbed, etc. The media needs to move and that'll be trickier than it would have been if the box hadn't died prematurely, but I expect the old stuff will be able to come back; the newer uploads (and whatever stuff was fetched on demand after the media server moved to Revolver in December) should be exactly where it was, so it'll be visible again when the media.fse redirect is back in place.
The Postgres/Pleroma to Revolver ingestor's slowness is because I've been using a dumb on-disk storage scheme (and partly because while I'm debugging it, it crashes and dumps the failed data instead of continuing and then storing the rejects somewhere, and everything stopping and waiting for me to fix a bug hampers throughput); I was wondering how long I could get away with that storage mechanism, and the answer is "until about now". So far, all of the rejected data comes from in-development software with bugs that were fixed years ago, so data coming out of the big three servers (Pleroma, Mastodon, Misskey) should all be handled correctly. Once an entity is ingested, it's got a normalized representation, but for the sake of the /objects/ proxy feature, currently what we keep around is the original representation, so that what gets returned is exactly what the server reported. This is less than ideal. The current indexing method is really simple and really fast (under 20ms for timelines: TWKN, tags, profiles, etc.) but there's a lot of disk overhead so it needs to be reworked, and part of that might be done by reworking the storage scheme and part of it might be done by just persisting the normalized objects, which are much more compact (there's a lot of redundant information in most activities like "content" and "contentMap", some fields have a fixed value and we don't need to store that, some are repetitive and they can be broken up for storage, things like that), and although the indexing method is very fast, it does consume a lot of blocks (which is a kind of advantage because it makes hunting through the slush harder by introducing noise, though if it bloats storage overhead too much, there's not much point).
I'm also doing it with the IPFS support disabled, as IPFS makes ingestion take about a hundred (SERIOUSLY) times as long. IPFS has been nothing but pain so far; I don't know what they are doing that makes their code behave this way. Just using flat files with split directories would be faster. The idea was initially that we could use IPFS as an extra channel: things could move through Revolver's protocol, or they could use IPFS, or ActivityPub, or stack those on top of Tor, possibly other means.
Also, I would like to mention that I am continuing my trend of using technology that makes people frustrated with me: the ingestor, being glue code between Postgres and Revolver and having to parse JSON, is written in Ruby. (The reason it has to parse JSON is so that it can scan for the string "https://www.w3.org/ns/activitystreams#Public" in the to/cc fields and avoid dumping people's DMs to a public network; it also doesn't ingest followers-only posts, but that is just the ingestor.)
At this point in the update, more things are popping into my head, "Oh, I should include that", and then "Oh, wait, did I account for $x?" and I keep falling down a rabbit hole, at the end of which I produce another paragraph, and it's either more or less information than anyone wants.
> Is that the dev board Level1Tech had on his channel?
I don't know who he is. This is a DevTerm with their R-01 board, an Allwinner D1 RISC-V SOC, single-core, 1GB RAM. ( https://www.clockworkpi.com/devterm The RISC-V chip is not just their cheapest option, I can also legitimately say that I use a cyberdeck with an experimental CPU. Plus it runs cooler with no heatsink than the ARM cores run with the fan blasting, lasts at least 8 hours on battery.) I have produced a Slackware image for it, that's what's running there. ( https://media.freespeechextremist.com/rvl/full/17b30212e33512e8aa6e861a4adb9744b4a70a7b2d6febab72df4b0816f2f0e8 )
Except that I haven't attempted to run a browser on it (besides w3m), it's speedy enough, though most of what I use it for is drawterm to talk to Plan 9 and ssh to talk to Linux and run xpdf (shoved a 128GB uSD onto it), awk-based wiki for note-taking, etc. Like, everything I use compiles and runs fast enough on it because most of the stuff I use was already fast in the 90s. irb takes a few seconds to give me a prompt, that's the only real annoyance, but I already use awk or dc for the 90% case.
> Ampere has some reasonably priced 128 core ARM kits:
$4500 is probably reasonably priced for 128 cores and 96GB of RAM but it's still a little pricier than building out a cluster. A Turing Pi 2 has four slots, 16 of their RK1s would be 128 cores, the 8GB model you'd end up with more total RAM and for four boards and eight chips, it'd run you 4*$200+16*$150=$3200 and you end up with more total RAM. (The 32GB RAM ones are $300, so for 512GB total you'd have to shell out $5600.) That's up-front, though: building it out piecemeal is an option if it's a cluster. you_can_see_a_lot_of_dust_and_beard_hair_if_you_zoom_in.jpg