mcmatterson

Joined 16 years ago

Karma
515
Submissions
128
Member since
Jun 8
Free-range hacker. iOS to pay the bills, rails & product bootstrapping to grow the mind. Runner of runs, baker of bread, father and husband of awesome, doer of good.

Specialist in net-negative commits.

t: @mattrudel h: http://mat.geeky.net e: [email protected] p: TO/Waterloo

View on Hacker News

Recent submissions

Comment · 1 month ago
All good friend! I'm as guilty as anyone. It's a super cool project though.

Now that I have you on the hook, is there any benefit to this over virtio for a single KVM passthrough situation? I previously ran a proxmox based gaming PC setup (docs here: https://github.com/mtrudel/rabble/tree/4d9329f3dd0fb09123a8f...), and was lucky enough that the GPU passthrough part of that build 'just worked'. I'd started down a path of trying to share the GPU between VMs based on a naive 'one VM owns it at a time' setup, but never really got it off the ground.

Comment · 1 month ago
Amazing project! But man, that README is just a textbook example of LLM word salad. It's wild how these tools are so incredibly capable at many things, but their writing sticks out like a sore thumb
Comment · 5 months ago
The thing that really gets me as a small-time OSS maintainer is that none of us asked for this. The social and technical millieu where most of us started our projects is not the one we find ourselves in today, and the forces behind this are wildly asymmetric.

Security findings are one place where we as maintainers simply do not have the choice to not play ball, whether we like it or not. It seems likely that the only way that we meet the moment is to adopt these tools ourselves -- once again -- whether we like it or not. Reconciling this with the ground truth that 'OSS doesn't owe anyone a goddamn thing' is proving to be really hard for me.

Comment · 1 year ago
As an HTTP server author, this doesn't surprise me.

We've ceded HTTP specification development to the big guys, and in so doing have made it more or less impossible to implement without resources on their scale. Have you looked at RFC 9000 et al? They're monstrously big, far larger than most independent shops could ever hope to economically pull off. The only way to comprehensively implement something of that scale is to have Google level resources to throw entire teams of engineers and years of focus at it.

I've long said that any protocol worthy of being foundational should be reasonably implementable as a fourth-year term project. It doesn't have to be production ready or ergonomic or even generally useful, but if a group of fourth year CS students can't pull an end-to-end implementation together in a semester, the protocol is just too complex. It's not perfect, but it's as good of a yardstick as I've found.

HTTP/1 passes this test easily; you can make a working version of it in about ninety seconds right in your terminal. HTTP/2 looks intimidating at first glance, but it's so much better specified than HTTP/1 that it's almost easier to get to a reasonable implementation. HTTP/3 on the other hand is...... well, weeks (if not months) of work just to get a QUIC foundation working reasonably well enough that you could hope to start iterating on connections from a 'real' peer, and THEN you have to start on RFC 9114. Not to mention that the way it's structured you end up doing most of that work in the dark, hoping that you line everything up just so so that your first Hello World actually works. It's a way of working that is completely at odds with the hacker ethos that the best foundational protocols have in spades, and ends up looking and acting like what it is: a tool by the big guys, for the big guys. The rest of the internet need not apply.

Comment · 2 years ago
I'd just mitigated this exact thing in Bandit last month!

https://github.com/mtrudel/bandit/blob/main/lib/bandit/http2...

TBH, from an implementors perspective this is a super obvious thing to cover off. It had long been on my radar and was something that I'd always figured other implementations had defended against as well.

Comment · 2 years ago
Comment · 2 years ago
Comment · 3 years ago
BMath (CS) 2002 here. This description is spot on the way I think about development, and is a bit of a superpower to be able to do well. I'm not totally sure it's a UW-ism though. I can certainly recall a couple of very formative Tompa courses where he impressed the importance of taking a data-first view of design, and I think we had a stronger bias towards data structures than most other schools whose grads I've worked with. But overall I think that sentiment grew weaker in my upper years, when a more conventional algorithms approach took over.

I will say though, that I've also noticed the contrast before with MIT grads, who tend to have a very strong LISP bent to their styles. It's true that each school has their own unique flavour, and much like accents it may just be that you don't notice your own.

Comment · 3 years ago
Bandit author here. Correct! The byline of Bandit is ‘a web server for Plug applications’ and being able to focus on that narrowed set of requirements is a large part of where the perf boost comes from (less code, easier to reason about, fewer processes, etc).
Comment · 3 years ago
The PR you linked to adds support for generating new phx apps with the relevant change already incorporated; it’s just a generator change. We’re waiting a bit to incorporate this change to ‘soft launch’ Bandit support.
Comment · 3 years ago
Bandit author here. We’re fully supported on phx 1.7+; it’s a one line change to your existing app, described on the Bandit readme!
Comment · 4 years ago
Comment · 4 years ago
Comment · 4 years ago
Comment · 5 years ago

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton