It makes sense that if you’re designing a language, you’d like the language you made and would want to use it. It’s fine for compilers like that to exist, and even be the main one used, but ideally it shouldn’t be the only compiler.

But there are technically ways to bootstrap a language without writing it in another language (other than a small core in assembly or something). You could design a tiny compiler that only handles a small subset of your language, then write a better compiler using only the features available in that subset. You can do this for several layers of compilers until you have the full language.

That’s already how it is now, we just don’t usually think of it that way. You can’t compile rust unless you already have a rust compiler. The current version was compiled in a previous version, which was compiled in a previous version, going through a chain of older versions and other languages. Anything along that chain could’ve theoretically had an influence on the current compiler.

It’s not about the code itself being more trustworthy. The point is that when you bootstrap, you don’t have to blindly trust any of the binaries, since it’s source code the whole way down. Someone could bootstrap rustc like this, compare it to the binaries that already exist, and ideally they would be identical.

A lot of this bootstrapping stuff comes back to the ‘trusting trust’ attack. You could write a compiler that adds some malicious code to programs it compiles. But the thing is, it could also insert it’s own malicious code when compiling a compiler. So you look at your code, and the code of your compiler, and everything looks fine, but the exploit is still there. Someone wrote an example in rust.

Theoretically there could also be bugs that propagate this way. So to fully trust your code is doing what you think it is, you’d need a chain of compilers back to hand coded assembly.

Yeah, I wrote the wrong language. I tend to lump those together in my head as ‘big multi-paradigm languages I haven’t bothered to learn yet.’

You can technically do it, but it’s a convoluted path. The article talks about it. Basically to bootstrap that way you need to go through a lot of versions of rust, compile rust 0.7 in ocaml, compile ocaml in scheme, and compile scheme in C using gcc. For gcc you need to compile a chain of versions back to when it was written in C instead of C++, plus the whole TinyCC bootstrapping path.

edit: had listed scala instead of ocaml

The main thing is that TinyCC has already been bootstrapped.

Check out this page on bootstrappable.org. Basically they start with a 200 something byte binary (hex0) that can act as an assembler, then using a bunch of layers of tools and compilers you can bootstrap a whole system. I think they use stage0 to build M2-Planet, use that to build GNU Mes, and use that to build TinyCC.

So a project like this fits neatly into that bootstrapping path. It could be done other ways, but starting from a fairly complete C compiler makes it a lot easier than building an entire path from scratch.

The biggest thing is probably non-destructive editing, so you can do stuff like apply filters without them changing the underlying image. Gtk3 should add better support for tablets and wayland. There’s also better layer tools and font support. A lot of it was on the backend, which should eventually allow for using other color spaces like cmyk natively.

It’s too bad that GLIMPSE fork never took off.

They’ve been working on porting it since back in 2012, and didn’t want to redo a bunch of the porting work before they even released it.

The creator of pixelfed is working on a tiktok alternative loops, although for now it’s in private beta.

For a starting point that is available now, you could look at Pixeldroid, an open source pixelfed app.

Besides the ones already mentioned:

• The FSF has some channels at https://framatube.org/a/fsf

• There’s a bunch of KDE related channels at https://tube.kockatoo.org

• Blender has several channels at https://video.blender.org

• https://peertube.touhoppai.moe/a/shichimi has Krita tutorials from the creator of the Pepper and Carrot webcomic.

• https://tilvids.com/a/martin_owens from someone who works on Inkscape.

• https://tilvids.com/a/togglejam looks at the science behind fictional games and shows.

• https://diode.zone/c/andrewtropin has a bunch of scheme and guix related videos

• There’s some anarchist channels on https://kolektiva.media like CrimethInc and subMedia.

A couple of gaming related accounts/channels:

• https://subscribeto.me/a/gbryant

• https://peertube.linuxrocks.online/c/boilingsteam

There’s also sepiasearch.org for PeerTube videos.

There’s a list of people that have agreed to block it at https://fedipact.online/

You might find a few, but it’s not really possible long term. Either you block instances that are run by fascists or child abusers, or you get blocked by instances for allowing that on your server.

About 20k are probably from hexbear, which migrated from their own distant fork of lemmy to the current version, so now they show up in a lot of trackers. They still haven’t enabled federation yet though.

Captchas are mostly useless nowadays against any well designed bot. The only ones that sort of work are those ridiculously hard ones like several page math problems. And at that point a large portion of people can’t solve it either.

They also tend to be full of trackers and are terrible for privacy. Plus they’re used to train corporate AIs.

It can help temporarily, because a lot of bots don’t bother with captcha solvers, but all the spammers need to do is include a pre-made solver library and the bots are back.