Midar

And yet, they dropped updates for my Shield Tablet basically immediately after I bought it…

If you keep reading on, that was not the problem ;). The problem was missing glue code that would actually register the frames.

I remember your comment from back then :D. Great news: Since then, I actually did make it a library. The runtime has been a library for a long time now, and ObjFW itself is also almost there in the amiga-library branch.

Yes, it does not protect the running system from being compromized, but that was never the idea behind Secure Boot anyway: You could just backdoor a binary, why even bother with the kernel.

As for evil maid, yes, it does help: You can't just change keys if you have a UEFI password. Sure, a determined attacker could externally reprogram your SPI flash. But that is a lot more effort. Absolute security doesn't exist, but you can make it as hard as possible :).

Another use case is actually dual booting with Windows: You can add Microsoft's cert to the DB and only the DB. This way, Windows can not add any new certs. And you can only load bootloaders signed by Microsoft (no shim etc, as MS was clever enough to use a different key for that). That way, Windows could only compromise your Linux if Microsoft signs a malicious Linux kernel. I would hope they have their key on an HSM and don't sign everything lightly ;).

This is exactly what intrigued me and made me switch to Fossil. I don't want to have my issues, wiki etc. held hostage by some company. And if someone wants to fork it, they should be able to fork it including issues and wiki.

This is running on a server with super slow single core performance and slow I/O (Sun Fire T1000 with full disk encryption, giving ~ 2 MB/s for the disk), and yet it feels fast and I've never encountered any performance issues. As long as your repo is not as gigantic as https://pkgsrc.fossil.netbsd.org, you'll be fine, no matter what slow hardware you throw at it.

Yeah, I'm just running `fossil server --scgi` in a chroot and then use nginx for TLS.

That is only true for projects where you need to deploy. In that case, yeah, you of course can only close the bug once you fixed production. But for normal software development, you can fix the bug in the software and you can update the bug tracker, and then push everything once you're back online.

For example, on a flight, I can look at the bug tracker (since it's part of the clone), pick a bug I want to work on, create a few commits to fix it, then update that bug (set it to closed, reference the commits that fixed it), and then upload it all when the plane landed again.

I'm using it for a while now for https://objfw.nil.im/ and am quite happy with it. I wrote a little bit about that at https://blog.nil.im/?78.

It's quite sad to see that so few projects use it. The idea of having everything in one repo, incl. bugs, is just great. I can create new bugs while offline, update bugs while offline, etc. and then just sync everything once I'm back online.

It also has pretty good support for incrementally importing from and exporting to Git: https://blog.nil.im/?79

That all sounds too familiar. When I was still a little kid going to school, I was using Linux and found Objective-C. Really liked the language and concepts, but lacking a framework for Objective-C on Linux. So I started ObjFW a few years later. Seems you had the same experience before I was even born, except on Amiga :).

Hm, Omega2 seems to run OpenWrt, if I see it right? In that case, it should even just work.

Alternatively, if you want to avoid OpenWrt, there's also ObjFW on bare-metal ARM: https://heap.zone/blog/?68

This is actually a port to the real Amiga, and not one of those new exotic Amigas. But if you want to run AmigaOS 3, you can just use FS-UAE. In fact, that screenshot is from FS-UAE, as always copying things over to a real Amiga can be quite annoying during development :).

Well, I know it's used for some internal things at a Russian AV company according to some bug reports that have been made :). And Microsoft used it for their WinObjC for a (not very long) while when they initially released it.

It actually is on GitHub: https://github.com/Midar/objfw

I offer both, self-hosted and on GitHub, because I believe in decentralization. It's Git after all! :)

Yup, I was the guy who pushed an app using ObjFW to the store: https://webkeks.org/blog/?74

Hum, excuse me, but since when is the ObjFW runtime old? It supports modern ObjC quite fine and is still in active development with the last changes being from this year. However, the one used here seems to be from 2012 for some reason, instead of one from 2015.

But the runtime has a faster dispatch than Apple's ;).

Actually, I don't get all this "Messaging is slow". In the ObjFW runtime, it's just 12 instructions for x86_64. That's barely noticable. I even used ObjC in an HPC application and compared it to the C version, just for fun. There was no measurable difference in performance.

What's more important in the average application is that the foundation classes are fast. For example, C#'s and Cocoa's dictionaries are really slow (but I don't know why). While C# and Cocoa both need 1.2 sec to insert 1 Mio objects into a dictionary and retrieve them, ObjFW only needs 0.3.