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 ;).
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
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.
I use fossil mostly as a Customer/Project KB/Documentation tool, when a new project starts i have all the documentation, code snippets/examples in one single file, when the project is finished, i have to give one sqlite.db file over to the customer and that's it. LOVE IT, a really great tool!
> 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.
The bug thing I kinda disagree with... or at least I'm skeptical, shall we say. Bugs are solved when the fix has been deployed and verified fixed in production, not when someone commits/pushes/merges a potential fix to the main branch. Sure you can separate the 'bug-X fixed' change to the bug tracker and the code commits, but then what have you gained over just a 'Fixes: X' annotation in the commit msg?
This could be misunderstanding on my part about the intent/process around bug/issue handling in Fossil, so I'd appreciate if you could expand on what you like about and how it works within the larger 'deploy a fix' context.
(I tried Fossil for a bit on a very small scale -- it was pleasant enough, but ultimately Git's network effects win out big time... at least for me.)
It isn't putting your issue tracking into an equivalent of a git repository. It just contains a rather standard-looking issue tracker, along a wiki for documentation, in the same sqlite. And they are distributed/synchronized just like the repository.
If you include the ticket ID e.g. [ticket-id] in the commit's description, the commit will automatically be linked to that ticket. You can view the list of all associated commits with a ticket by clicking the 'Check-ins' menu item on the ticket's page. When an item is closed - the link appears struck-thru.
I dont automatically close tickets on commits - since our workflow is commits get reviewed before closing an item- but it is straight forward to write a small few line script to do this if thats your workflow.
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.
This is really nice. How have you been hosting this? How well is fossil able to handle the traffic?
I've read so many articles about the advantages of static site generators and serverless implementations for blogs so that they are able to handle traffic and the insane amount of tooling around each of those concepts. It's so great to see a well crafted piece of software being able to take care of all that so seamlessly.
I'm a big fan of fossil personally and use it for all my projects as well as for all the projects in our organization.
A lot of us Fossil users host it on $5 VPSes. It's written in C atop SQLite, so the network is almost always the bottleneck, not the server-side processing speed.
sqlite.org and all of the other repos D. Richard Hipp maintains (Fossil, Pikchr, the separate SQLite docs repo, the forums for Fossil and SQLite...) all run on a $40/month VPS. The page generation time is calculated and displayed at the bottom of non-static pages like this one: https://sqlite.org/src/
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.
Thank you for posting a link to your site. It's really nice to see a live demonstration of Fossil. I notice that your page is using https - does Fossil do that or do you have something else in between (nginx, etc) that provides the https?
Another option is running is behind Apache as a CGI, and let Apache handle the HTTPS part. My repos (fossil.wanderinghorse.net) all run as CGIs on a $7/month shared hoster, and have been since 2008, without issues.
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 :).
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.
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.
I think they took it directly from here: https://webkeks.org/objfw/ which does say 2012 as the last release. I see on GH they have commits from as recent as last month.
The problem is not the syntax support. The ObjC runtime had many changes to it done internally over obscure flags to support Swift and other compiler features. These are not readily documented on Apple open sources. (Perhaps more documentation exists in LLVM.) Once the runtime contains ABI changes, it makes it difficult to port apps that (ab)use the runtime. Not a problem for some apps, but a big problem for others.
reply