611 karma · joined July 18, 2019
https://x.com/filpizlo/status/2053351119095791995
And "Rust let’s you corrupt memory / Fil-C doesn’t.":
https://x.com/filpizlo/status/2079253367587737841
These are false claims. The following compiles and runs fine with Fil-C, happily corrupting memory in a way that a safer language like Rust would not allow:
#include <stdint.h>
#include <stdio.h>
struct Account {
unsigned char name[8];
uint32_t privileged;
};
void write_name(struct Account *account, size_t index, char value)
{
account->name[index] = value;
}
int main(int argc, char* argv[])
{
struct Account acct = {
.name = "foobar",
.privileged = 42,
};
write_name(&acct, 8, 1);
printf("privileged = %d\n", acct.privileged);
return 0;
}
His claims about Fil-C being safer than Rust seem to hinge on Fil-C's ability to make safe-er an entire application stack, compared to a hypothetical Rust application that links to C dependencies which (currently) can't be compiled with Fil-C. This is true as far as it goes, but it's a far cry from justifying a blanket statement like "Fil-C is safer than Rust".It's by far the best primary computer I've owned. The tradeoffs in battery life, speaker sound quality, and so on didn't matter much for my use case, so I was happy to take them; but this new model seems to fix those issues too, so I think it'll appeal to a much wider audience.
FYI, the existing Framework 13 Intel motherboards do support Thunderbolt 4: https://knowledgebase.frame.work/usb-port-definition-matrix-... There's an additional, optional retimer update that's officially Thunderbolt certified, but I haven't bothered with that because my Thunderbolt dock was already working: https://knowledgebase.frame.work/en_us/framework-laptop-bios...
No, it explicitly is not, and this "deepity" doesn't change any rational analysis. The injection of politics into every aspect of society must and should be refused.
In the acknowledgments section,
> Thanks also to Ray Bradbury.
> After changing, Google details that your original email address will still receive emails at the same inbox as your new one and work for sign-in, and that none of your account access will change.
But back in the early 2000s I got access to a free Unix shell account that included Apache hosting and Perl, and if I'm not misremembering, it was running on FreeBSD and hosted by an ISP in the UK using the domain names portland.co.uk and port5.com.
That was formative for me: I learned all of Unix, Perl, and basic CGI web development on that server. I don't know who specifically was running that server, or whether they have any relation to the current owner of that domain. But if you're out there, thanks! Having access to FreeBSD was a huge help to a random high schooler in the U.S., who wouldn't have been able to afford a paid hosting account back then.
And when running a Samba server, it's helpful that FreeBSD supports NFSv4 ACLs when sitting between ZFS and SMB clients; on Linux, Samba has to hack around the lack of NFSv4 ACL support by stashing them in xattrs.
You can arguably get even better ZFS and SMB integration with an Illumos distribution, but for me FreeBSD hits the sweet spot between being nice to use and having the programs I need in its package library.
(I walk a good deal and also bike with the phone in my pocket, so it's possible my phone gets above average wear in this department.)
The way I do this, my internal DNS resolves hosts to their fixed ULA addresses. For the handful that are accessible externally, public DNS resolves to their address on the current public prefix.
The (occasionally, on Comcast) changing dynamic prefix was a pain for me too, when accessing things externally. For internal use I additionally set up a fixed ULA prefix.
This is fixed by adding an explicit `touch ~/.zcompdump` in the branch that runs a full `compinit`.
Also check out Wails if you'd like something along these lines with Go substituted for Rust