HN user

tkcranny

237 karma
Posts0
Comments53
View on HN
No posts found.

Infuse is terrific software, and supports jellyfin and smb. I use it for jellyfin and absolutely love my setup.

I ditched plex because of missing Dolby audio support and all the use hostile channels and “features” years ago, and will never look back.

I’m not clear on the difference between atom and RSS. Atom seemed to be the better spec, but for my Astro blog I ended up sticking to the built in `rss` helper it ships with.

There’s a lot to be said about his approach with go for simplicity. Python needs virtual environments, package managers, dependencies on disk, a wsgi/asgi server to run forked copies of the server, and all of that uses 4x-20x the ram usage of go. Docker usually gets involved around here and before you know it you’re neck deep in helm charts and cursing CNI configs in an EKS cluster.

The go equivalent of just coping one file across to a server a restarting its process has a lot of appeal and clearly works well for him.

Their working is exceptionally thorough, all the concerns about additional maths and transformations is well considered. I really have to wonder if introducing any semantic-changing transformations for what I’m guessing are minuscule savings of bytes is worth it though. Safe things like stripping white space and shortening identifiers would be the major contributors to minification surely. How many CSS colours need to be defined for oklab rounding to even affect how many tcp packets are sent for instance?

While it’s hardly insightful that SQL is useful, I would have liked to read more about what the actual workload involving duckdb on a local machine looked like. I’m fully on board that local or single vm workloads can do an awful lot, but I’ve never been particularly satisfied with the pipelines I’ve seen (including my own). Usually they’re piles of scripts and intermediate data files sitting around and are hard to make idempotent and understand if you aren’t the author.

Also fwiw there’s no such thing as an M4 Ultra chip. That detail was either a mistake or hallucinated.

I’ve spent a lot of time with both, and hands down the wired one is far more flakey. Granted I think that’s more a Mazda software issue, but a solid 10% of the time I get “CarPlay failed” and the only way to fix it is to turn the car on and off. Never once had an issue with wireless in a Hyundai.

Looks like Django 6 is getting an offical task system.

There’s no real world brokers or workers supported (at least built in), but still centralising around a standard interface might make things nicer than the celery tentacle monsters Django apps eventually tend to mutate into.

Introducing JIT features has a lot of opportunities beyond numerical numpy/numba vectorisation. There’s endless amounts of hot loops, data shuffling, garbage collection, and monomorphisation that could be done in real world python that would benefit a lot, much like V8 has done for JS.

It’s true that phones cameras are miracles of technology, especially considering their size. But I take a modern Fuji traveling because the modern phone camera look is so over-processed and distinct. There’s no faking the real optics a large aperture and sensor gives, the portrait mode on phones is still a poor imitation of the real thing.

Fuji then has the whole film simulation system with all their colour science from the last century. It’s a ton of fun, and the jpgs it produces are distinct and beautiful, and I believe better than 99% of people could achieve from post processing the raws, myself included.

The middle-age guy part is accurate though, I got it as a thirtieth present.

Oxc js a rust toolkit made by Void0, the mob that makes vite and vitest. These are highly regarded and performant additions to the Js/Ts ecosystem.

Oxlint is a alternative to eslint built on Oxc. It has suffered from not supporting the additional level of type-based linting that typescript-eslint can provide. They’ve now addressed that by patching and wrapping Microsoft’s new go-based typescript compiler.

Hopefully they are up to the task of continually keeping up to date with the go compiler’s internals, and/or Microsoft exposes a programmatic interface for the new compiler’s parser and type-checking.

I also wonder if or how plugins will be possible for this go+rust combination linter – they’re a pretty important part of the eslint ecosystem they’re trying to upend.

That site is misleading. Even putting aside regulations for many of the elements, everything after plutonium does not occur in nature and is made synthetically in individual atomic amounts that usually decay in hours to milliseconds. There is no way to see them, let alone sell them as a commercial product.

It’s a TS/JS to wasm to C tool chain, that runs the same JS a dozen times faster than on node. Very cool approach, and lambda cold starts are definitely where it ought to shine.

That said I wonder if it could ever go mainstream – JS is not a trivial language anymore. Matching all of its quirks to the point of being stable seems like a monstrous task. And then Node and all of its APIs are the gorilla in the room too. Even Deno had to acquiesce and replicate those with bugs and all, and it’s just based on V8 too.

It has native TS and JSX support, excellent spy, module, and DOM mocking, benchmarking, works with vite configs, and parallelises tests to be really fast.

I don’t mind the distinction of it as a map container keeping dot properties/methods separate from the keyed values. But yeah the endless string quoting is painful coming back from JS, bare key literals in constructors like JS would be a welcome addition for sure, as would named key unpacking like this whole post is about.

Yeah I had totally forgotten about this. I remember seeing it around a bit in the python 2 days when UTF-8 wasn’t always assumed. The fact a ~macro system can be bolted on using this is impressive, hilarious, and shockingly terrible.

Respectfully I disagree. I believe what Dijkstra is getting at is that the specifics of modern computers aren’t “relevant” at all. Ultimately it’s the science of information and whats computable. Be that a modern day silicon processor at X gigahertz, a pen and paper, or a universe sized computer, that’s irrelevant for the science itself.

I agree the underlying technology doesn’t ultimately matter, but as user of a lot of fairly modern rust-based cli tools there definitely is something in the air worth mentioning.

I suspect it’s a couple of things. A new generation of programmers are hitting the scene, wanting to do things in new ways. Not inherently good or bad, but the new tools sure usually are at least very _pretty_, and have a lot of affordances and usability improvements over the ancient tools that can never be changed for the sake of compatibility. Rust and Go make this nicer, and are the languages de jour with good cli ecosystems and performance characteristics around them.

I genuinely do like most of my replacements. ripgrep for grep, eza for ls, zoxide for cd, fd for find, podman for docker, and a few more. Developer tooling is a rich and interesting space to be in, but there’s plenty of bandwagons I’m not getting on, like this or zellij for tmux, or jj for git.