The idea is cool. The quality of the data is very questionable, though. The color swatches appear more or less random. What does that orange have to do with Google and that maroon with Microsoft? And yet they are in the spotlight of the demo page.
Agreed. I wonder if a wiki interface may be better for this, while maintaining the option for someone with a corporate email address to "own the page".
The things I'd want to see in a brand are
Values, Mission statements, and how those have changed over time.
Potentially current and past advertising campaigns, etc etc.
Just logo and a selection of colours isn't that helpful.
I don't think systemd has a built-in load balancer. Also, running multiple copies of the same service isn't typical PID-1 stuff, so maybe doing that with systemd involves some friction.
I know about templates, but I don't believe they are designed for fungible copies. You can run a bunch of my-app@a-random-port.service, but it's not the same UX as `pm2 start my-app -i number-of-copies`.
They work very well for "worker" processes. The default ssh package on Debian uses systemd template units for the user process; I've used them extensively for job queue workers, in combination with max execution time and a separate timed job to monitor queue load (essentially automatic scale up/down of queue workers).
Realistically if your prod environment relies on you manually running `pm2... ` or whatever, you're doing something wrong. User Experience should have about 0% impact on how your service daemons run.
I'm fascinated by C. I agree that using almost anything else automatically eliminates entire classes of bugs and vulnerabilities, but it's so much _fun_ to be close to the machine and avoid those bugs and vulnerabilities myself. Judging by the fact that even some greenfield projects are still written in C, I'm not alone.
I am as much of a rust shill as you'll ever meet, but I agree that there is something beautiful and alluring and simple and engaging about C that few other languages match. It's basically an advanced macro assembler for an abstract machine, so there's all of the allure of using 6502 or 68000 assembly language but with none of the portability problems, and a vast ecosystem of libraries and amazing books to back it up.
I've enjoyed writing a few projects in x86-64 assembly as well, for what it's worth. Even though I'm sure that any C compiler would generate better assembly than my handwritten one. Flat assembler is great, by the way.
Any C compiler can generate better assembly for a function. But there's often some whole program optimizations that you can make, which the C compiler isn't allowed to do (because of the ABI/linker).
For example, a Forth interpreter can thread its way through "words" (its subroutines) with the top-of-stack element in a dedicated register. This simplifies many of the core words; for example, "DUP" becomes a single x86 push instruction, instead of having to load the value from the stack first. And the "NEXT" snippet which drives the threaded execution can be inlined in every core word. And so on.
You can write a Forth interpreter loop in C (I have), and it can be clever. But a C compiler can't optimize it to the hilt. Of course it may not be necessary, and the actual solution is to design your interpreted language such that it benefits from decades of C compiler optimizations, but nevertheless, there are many things that can be radically streamlined if you sympathize with the hardware platform.
The ideal data protection law would prevent most of the data from being collected in the first place. Cybersecurity, on the other hand, is about protecting what you have collected anyway. So, maybe cybersecurity is broken, but fixing privacy is a great first step.
By being generic and customizable it will have the potential to become a great new game in its own right. Let the community begin with something they already know and love (MtG) and watch them coming up with cool new stuff.
Thanks! The time for which TXT records are cached is determined by their TTLs. When publishing a DNS TXT record, you can usually set the TTL to be as low as 1 minute or even less, so any changes to the content would be picked up really quickly. (https://developers.cloudflare.com/dns/manage-dns-records/ref...)
I know that it's all configurable, what I meant is that some DNS providers may apply a long TTL by default, and it may be desirable to let users of Triweb know about this possible source of confusion.
The DNS name resolution is actually not done by your system or ISP, but by a DNS over HTTPs (DoH) service (Cloudflare 1.1.1.1 resolver). Cloudflare seems to be respecting the TTL as returned by the authoritative name server for your domain, so if you are able to specify a short TTL for a TXT record in your domain control panel, any changes made to the website should be live within that time.
> so if you are able to specify a short TTL for a TXT record in your domain control panel
Triweb users are able to do that, but they don't necessarily know that they need to do that. For example, the Cloudflare DNS dashboard displays "auto" as a TTL by default, and one has no idea how many seconds "auto" is for a TXT record.
This would enable some advanced merge conflict resolution strategies, I suppose. However, it can also be done by building the ASTs on demand and still storing plain text.