I noticed that it wasn't the best comment, I was only concerned with the tone, and I feel like dang has enough going on that we also need to help elevate the conversation. I admit there's some delicious irony in the accuser committing the same crime, but it doesn't improve the discussion to revel in that.
Your reply would have been much better without the first line [0]
> Please don't comment on whether someone read an article. "Did you even read the article? It mentions that" can be shortened to "The article mentions that"
Very cool story. I'm interested to do a similar transition, though I was thinking it would be mecessary to go back and do a masters. It's interesting that that might not be required
I do the same. But the benefit to me is that by the time I've written out the message and checked my work I've usually solved the problem. So it's like rubber-ducking but with social consequences attached which makes my brain actually pay attention.
The latest post from the very interesting exe.dev project (previously of 'I am building a cloud' [0]). They have a lot of interesting work that goes in to making SSH work with their system (eg previously [1]), and this is a continuation of that.
Using Unix sockets to transfer file handles is not a new idea, but using for SSH connections is interesting to me. I wish it were a little heavier on the details here, but otherwise this is an interesting approach to handling network traffic while maintaining zero-downtime upgrades
The article mentions that you typically have to longjmp within the same function as setjump (or a descendant function) otherwise your stack gets cleared and you longjmp to a garbage stack. I believe this counts as memory safety? Though I don't quite understand your comment about sigaction, so maybe there's some context I'm missing.
How interesting! I thought that setjmp and longjmp were probably incompatible with Fil-C. And I'd somehow never heard of ucontext at all.
I suppose managing the stack is still managing memory after all, even if we typically don't think of it that way, so Fil-C has something to add here.
It's really worth reading the section here about the complexity of setjmp/longjmp and how they interact with register allocation and stack spilling. I knew they're tricky, but going in to the specifics is delicious.
I think because good writing is easier to read and understand than bad writing, there's almost an inverse relationship between how easy writing seems and how easy it is to read. So you read something and think "well, this is obvious" but the magic trick is how much work went in to making it so.
Interestingly the earliest capacitors were glass jars (called Leyden Jars) [0]. I was taught that early inventors thought that charge was accumulated within the jar, and it wasn't until much later that it was realised that the shape was irrelevant, only the area and the distance between conductors.
And sometimes you click a permanent action ('ignore' or 'accept' or 'decline') out of muscle memory or an imprecise click. Just this morning I _think_ I allowed some telemetry on a system I use (but don't want telemetry on) because by the time I had registered the text I'd already clicked it and now I can't work out which setting I need to toggle back
My go-to for this is to screenshot and use the built-in text extraction in the screenshot tool (I'm on a mac), then pass on that text data to whatever processing. It's a pretty good tool so long as the PDF is in OK shape (I've had errors in scanned images).
I feel like any problem that Postgres can't handle is a good problem to have. Either you've got so many customers that you're hitting sharp edges, or you're working on such an interesting problem that you're out of the domain where Postgres is helpful. That I should be so lucky
The latest in the 'Mars for the rest of us' series that covers a host of issues with space travel. This one covers the issue of food and nutrition in space.
Including this charming little tidbit -
> Officially there is no alcohol allowed on board, but every once in a while NASA spends a few months trying to run down a spike in atmospheric ethanol that is inevitably traced to obscure origins somewhere in the Russian half of the station.
This was a lovely tribute. As much as we like to complain about windows, there's clearly a lot of love and care that has been put in to it by people like Tony
I find it charming that to distinguish Fil-C from the K&R language they use the term 'Yolo-C'. I have never used inline asm before, I actually didn't realise how much behaviour it's specifying! (When I've needed asm it was on non-gcc compilers)
Edit to add: If I'm understanding this correctly we should be able to run this against projects and detect asm violations, I feel like this would be very valuable to be able to feed these back to maintainers
This is very cool! I've wanted to do something like this for Sydney but never got around to it. Are you scraping your data sources or building them yourself?