I will beat loudly on the "Attention is a reinvention of Kernel Smoothing" drum until it is common knowledge. It looks like Cosma Schalizi's fantastic website is down for now, so here's a archive link to his essential reading on this topic [0].
If you're interested in machine learning at all and not very strong regarding kernel methods I highly recommending taking a deep dive. Such a huge amount of ML can be framed through the lens of kernel methods (and things like Gaussian Processes will become much easier to understand).
Nearly this entire HN comment section is upset about VLC being mentioned once and not recommended. If you can not understand why this very minor (but loud?) note was made, then you probably do not do any serious video encoding or you would know why it sucks today and is well past its prime. VLC is glorified because it was a video player that used to be amazing back in the day, but hasn't been for several years now. It is the Firefox of media players.
There is a reason why the Anime community has collectively has ditched VLC in favor of MPV and MPC-HC. Color reproduction, modern codec support, ASS subtitle rendering, and even audio codecs are janky or even broken on VLC. 98% of all Anime encode release playback problems are caused by the user using VLC.
And this pastebin doesn't even have all the issues. VLC has a long standing issue of not playing back 5.1 Surround sound Opus correctly or at all. VLC is still using FFmpeg 4.x. We're on FFmpeg 8.x these days
I can not even use VLC to take screenshots of videos I encode because the color rendering on everything is wrong. BT.709 is very much NOT new and predates VLC itself.
And you can say "VLC is easy to install and the UI is easy." Yeah so is IINA for macOS, Celluloid for Linux, and MPV.net for Windows which all use MPV underneath. Other better and easy video players exist today.
We are not in 2012 anymore. We are no longer just using AVC/H264 + AAC or AC-3 (Dolby Audio) MP4s for every video. We are playing back HEVC, VP9, and AV1 with HDR metadata in MKV/webm cnotainers with audio codecs like Opus or HE-AACv3 or TrueHD in surround channels, BT.2020 colorspaces. VLC's current release is made of libraries and FFmpeg versions that predate some of these codecs/formats/metadata types. Even the VLC 4.0 nightly alpha is not keeping up. 4.0 is several years late to releasing and when it does, it may not even matter.
I don't indulge in the SUNW autopsy parlor game often, but coincidentally, I've already played it twice today (for the first time in many months), and I'm waiting on a build -- so perhaps the third time's a charm...
Disclaimer: I was one of the ones who tried like hell to right the ship. So I am not only suffering from the same hindsight bias that everyone else will inevitably suffer from, I am further biased by the lens of my own actions and experience.
That said, I think Sun's problem was pretty simple: we thought we were a hardware company long after it should have been clear that we were a systems company. As a result, we made overpriced, underperforming (and, it kills me to say, unreliable) hardware. And because we were hardware-fixated, we did not understand the economic disruptive force of either Intel or open source until it was too late. (Believe me that some of us understood this: I worked extensively on both Solaris x86 and with the SPARC microprocessor teams -- and I never hesitated to tell anyone that was listening that our x86 boxes were starting to smoke the hell out of UltraSPARC.)
Now to be honest, I (and others on the software side) played a role in enabling bad hardware behavior: we spent too much time trying to help save microprocessor management from an unmitigated disaster of their own creation (UltraSPARC-III, cruelly code named "Cheetah") when we should have been more forcefully advocating cutting them off. Personally, I feel I only started to really help the company turnaround when I refused to continue to enable it: I (and we, really) stopped trying to save the hardware teams from themselves, and focussed on delivering innovative systems software. And indeed, the software that resulted from that focus bought the company time and (I believed) an opportunity for renaissance: when coupled with the return of Andy and the open sourcing of Solaris, there was reason for great optimism around 2005 or so...
Unfortunately, it wasn't enough. One could argue that our technological pivots were too late, and they may well have been, but I think that the urgency and focus that we felt in the engine room (aided by the bone-cold water that was at our knees and rising) was simply not felt or appreciated in the wheelhouse: I feel that we could have made it had there been more interest at the top of Sun in the mechanics of running and managing a multi-billion dollar business...
Or maybe it's not so unfortunate: thanks to the fact that we open sourced the system, I still get to work everyday on the technology that I devoted my career to -- and I'm loving it more than ever, and having more fun developing it than I have in a long, long time. (And, it must be said, I'm working with many of the same engineers that made working at Sun great.)
So when I look back on those years, I believe it will ultimately be with fondness, not regret; for me personally, Scott nailed it: "Kicked Butt, Had Fun, Didn’t Cheat, Loved Our Customers, Changed Computing Forever."
- Optionally extract images/graphs within the page and include them in the same LLM call.
- Optionally add a bit of context from neighboring pages.
Then wrap everything with a clear prompt (structured output + how you want graphs handled), and you’re set.
At this point, models like GPT-5-nano/mini or Gemini 2.5 Flash are cheap and strong enough to make this practical.
Yeah, it’s a bit like using a rocket launcher on a mosquito, but this is actually very easy to implement and quite flexible and powerfuL. works across almost any format, Markdown is both AI and human friendly, and surprisingly maintainable.
A bit of the history as I've been told by 2nd Quadrant/EDB people (my teammates):
BDR1 [0] came first and was, and is, open source. pgactive is based on BDR1. BDR2 was a closed-source rewrite of BDR1 that was later abandoned.
pglogical v1 and v2 (PGL1, PGL2) were, and are, open-source [1].
pglogical v1, after heavy modification, was eventually merged into Postgres 10.
Based on learnings from this logical replication in Postgres 10, 2nd Quadrant started pglogical v2.
pgEdge is based on pglogical v2.
Then later 2nd Quadrant started pglogical v3 (closed source) and BDR v3 (closed source). They were merged into just BDR v4. At some point the BDR product was renamed to Postgres Distributed (PGD) [2].
2ndQuadrant was acquired by EDB. We (EDB) just released PGD v6.
My favourite algorithm is generic cell rate algorithm (GCRA). It works like token bucket in this post. The implementation is dead simple and requires no background tasks and needs very minimal state.
Instead of storing the current number of tokens, you instead store when the bucket will be full. If you take a token from the bucket, you increment the timestamp accordingly by 1/rps. The only complication is it the filled timestamp was in the past, you have to first update it with the current timestamp to avoid overfilling.
What's even nicer is that it doubles as a throttle implementation rather than just a rate limiter. You know the bucket is empty if you compute empty_at=filled_at-(max_tokens/rps) which is still in the future. From that calculation you now know when it will have capacity again, so you can sleep accordingly. If you use a queue before the gcra, it then starts sowing down new connections rather than just dropping them.
You should still have a limit on the queue, but it's nice in that it can gracefully turn from token bucket into leaky bucket.
This sounds big enough to require a black start. Unfortunately, those are slow and difficult.
If an entire nation trips offline then every generator station disconnects itself from the grid and the grid itself snaps apart into islands. To bring it back you have to disconnect consumer loads and then re-energize a small set of plants that have dedicated black start capability. Thermal plants require energy to start up and renewables require external sources of inertia for frequency stabilization, so this usually requires turning on a small diesel generator that creates enough power to bootstrap a bigger generator and so on up until there's enough electricity to start the plant itself. With that back online the power from it can be used to re-energize other plants that lack black start capability in a chain until you have a series of isolated islands. Those islands then have to be synchronized and reconnected, whilst simultaneously bringing load online in large blocks.
The whole thing is planned for, but you can't really rehearse for it. During a black start the grid is highly unstable. If something goes wrong then it can trip out again during the restart, sending you back to the beginning. It's especially likely if the original blackout caused undetected equipment damage, or if it was caused by such damage.
In the UK contingency planning assumes a black start could take up to 72 hours, although if things go well it would be faster. It's one reason it's a good idea to always have some cash at home.
"Make good new things" overlooks a critical tension: that goodness itself remains contested territory. The most transformative innovations reveal that creation's power cuts both ways. The printing press spread knowledge and literacy but also enabled propaganda wars and religious conflicts. Nuclear fission powers cities with clean energy but also destroyed Hiroshima & Nagasaki and created existential risk. The internet connects billions across continents while weakening community bonds and fragmenting our shared reality. Each breakthrough that advances humanity also challenges our moral certainties.
This suggests we need a fourth principle: "Cultivate discernment about goodness." Not merely as an afterthought, but as an essential companion to creation. Such discernment acknowledges that innovation contains both medicine and poison in the same vessel—and that our capacity to create has outpaced our ability to foresee consequences. And perhaps equally important is recognizing that meaningful contribution isn't always about creating anew, but often about cultivating what already exists: preserving, interpreting, and transmitting knowledge and practices in ways that transform both the cultivator and what is cultivated.
Yet Graham's framing—"What should one do?"—contains a deeper limitation. It positions ethics as an individual pursuit in an age where our greatest challenges are fundamentally collective. "What should one do?" seems personal, but in our connected world, doesn't the answer depend increasingly on what seven billion others are doing? When more people than ever can create or cultivate, our challenge becomes coordinating this massive, parallel work toward flourishing rather than conflict and destruction.
These principles aren't merely personal guideposts but the architecture for civilization's operating system. They point toward our central challenge: how to organize creativity and cultivation at planetary scale; how to balance the brilliant chaos of individual and organizational impetus with the steady hand of collective welfare. This balance requires new forms of governance that can channel our pursuits toward shared flourishing—neither controlling too tightly nor letting things run wild. It calls for institutions that learn and adapt as quickly as the world changes. And it asks us to embrace both freedom of pursuit and responsibility to others, seeing them as two sides of the same coin in a world where what you bring forth may shape my future.
The question isn't just what should I do, but what should we become?
> discoverability (55) There were lots of comments about this, which all came down to the same basic complaint – it’s hard to discover useful tools or features! This comment kind of summed it all up:
> How difficult it is to learn independently. Most of what I know is an assorted collection of stuff I’ve been told by random people over the years.
This is all too true, the discoverability aspect is one of the reasons why we exist (0), and there is lots to improve here for discovering terminal tools, how to install and use them.
Also thanks for running this survey Julia.
Also, let us know on what we can improve on the site if you find Terminal Trove useful for you.
function lm {
local input="$*"
llm -s 'Answer as short and concise as possible' ${input} | glow
}
Here's an example,
$ lm "ssh command to forward the port 5050 on user@remote to my localhost:7001"
ssh -L 7001:localhost:5050 user@remote
$
Now for a sophisticated use-case I have a small tmux program where I can capture what's on the pane, enter a prompt and it will query an llm so I can say things like "How do I fix this error" or "what debian package do I need to get this to run right?" ... both these are recent patterns I've started and they've been real game changers
Some lesser game-changers:
* tmux extrakto - opens an "fzf" like search of all the text on the screen. So after a "git status", I can do git add (run extracto - enter partial path, press tab) and continue: https://github.com/laktak/extrakto
Yeah, I made a mistake with my config. I had setup SWAG, with Authelia (i think?). Got password login working with 2fa. But my dumbass didn't realize I had left ports open. Logged in one day to find a terminal open with a message from someone who found my instance and got in. Called me stupid (I mean they're not wrong) and all kinds of things and deleted everything from my home drive to "teach me a lesson". Lesson painfully learnt.
But before that happened Webtop was amazing! I had Obsidian setup so I could have access on any computer. It felt great having "my" computer anywhere I went. The only reason I don't have it set up is because I made the mistake of closing my free teir oracle cloud thinking I could spin up a fresh new instance and since then I haven't been able to get the free teir again.
I believe that most of the papers presented here focus on acquiring knowledge rather than deep understanding. If you’re completely unfamiliar with the subject, I recommend starting with textbooks rather than papers. The latest Bishop’s "Deep Learning: Foundations and Concepts (2024)" [1] is an excellent resource that covers the "basics" of deep learning and is quite updated. Another good option is Chip Huyen’s "AI Engineering (2024)" [2]. Another excellent choice will be "Dive into Deep Learning" [3], Understanding Deep Learning [4], or just read anything from fast.ai and watch Karpathy's lectures on YouTube.
"By chaining chipStar¹ (a HIP and NVIDIA® CUDA® to OpenCL compiler), Clspv² (an OpenCL to Vulkan compiler), and Tint³ (among others, a Vulkan shader to WebGPU shader compiler), you can run CUDA code in the browser!"
Lovely. In about 1974 I was paid to write a function, in IBM 360 assembly language, to compute square roots. I was asked to make it as efficient as possible. I was in my last year as an undergraduate student. I used a Chebyshev approximation for the initial guess (after scaling the input to lie between 0 and 1), and then used two (or was it three) unrolled iterations of Newton's method to get the solution. First money I ever received for writing code!
Hey HN, we recently fine-tuned the llama3.1 405B model on 8xAMD MI300x GPUs using JAX instead of PyTorch. JAX's advanced sharding APIs allowed us to achieve great performance. Check out our blog post to learn about the cool sharding tricks we used. We've also open-sourced the code: https://github.com/felafax/felafax
We're a small startup building AI infra for fine-tuning and serving LLMs on non-NVIDIA hardware (TPUs, AMD, Trainium).
Problem: Many companies are trying to get PyTorch working on AMD GPUs, but we believe this is a treacherous path. PyTorch is deeply intertwined with the NVIDIA ecosystem in a lot of ways (e.g., `torch.cuda` or scaled_dot_product_attention is an NVIDIA CUDA kernel exposed as a PyTorch function). So, to get PyTorch code running on non-NVIDIA hardware, there's a lot of "de-NVIDIAfying" that needs to be done.
Solution: We believe JAX is a better fit for non-NVIDIA hardware. In JAX, ML model code compiles to hardware-independent HLO graphs, which are then optimized by the XLA compiler before hardware-specific optimization. This clean separation allowed us to run the same LLaMA3 JAX code both on Google TPUs and AMD GPUs with no changes.
Our strategy as a company is to invest upfront in porting models to JAX, then leverage its framework and XLA kernels to extract maximum performance from non-NVIDIA backends. This is why we first ported Llama 3.1 from PyTorch to JAX, and now the same JAX model works great on TPUs and runs perfectly on AMD GPUs.
We'd love to hear your thoughts on our vision and repo!
So much of our “ship fast” culture is based around end-user application development, where it’s a reasonable and defensible approach.
But the further away you go from end users toward libraries, then internal services, then even further toward infrastructure, the slower and more thoughtfully you should move. These things often have far less rapidly changing requirements, and getting it right pays dividends. Or more realistically, blasting something half-baked out results in drag on your organization that you end up having to support for forever.
On a slightly different axis, APIs should be built with more thought and care than internal implementations. Backward-incompatible API changes are hard. So start out by building an API that expresses the logic your consumers want to implement. README-driven development works great here: literally write the README that showcases how people would use your API to do a variety of tasks. Then you can iterate as many times as necessary on the code, while having to iterate on the exposed surface area far less than if you just exposed today’s internals as the API (which is sadly the norm).
I went through sweat and tears with this on different projects. People wanting to be cool because they use hype-train-tech ending up doing things of unbelievably bad quality because "hey, we are not that many in the team" but "hey, we need infinite scalability". Teams immature to the point of not understanding what LTS means have decided that they needed Kubernetes because yes. I could go on.
I currently have distilled, compact Puppet code to create a hardened VM of any size on any provider that can run one more more Docker services or run directly a python backend, or serve static files. With this I create a service on a Hetzner VM in 5 minutes whether the VM has 2 cores or 48 cores and control the configuration in source controlled manifests while monitoring configuration compliance with a custom Naemon plugin. A perfectly reproducible process. The startups kids are meanwhile doing snowflakes in the cloud spending many KEUR per month to have something that is worse than what devops pioneers were able to do in 2017. And the stakeholders are paying for this ship.
I wrote a more structured opinion piece about this, called The Emperor's New clouds:
This is great! The one thing I'd say is that the market is rife with non-mainstream brands. As an example "Beelink" [0] and "Minisforum" [1] are very commonly referred to and have a lot of great models, but they're not well represented here and often times offer better value depending on what the buyer is looking for. My recommendation would be to expand the vendors into the popular non-mainstream brands. Easy ask, but harder to execute on your side - so I get it.
Also, AMD is crushing this market - but AMD is pretty under-represented here. There are also some great N-series Intel machines that are highly popular and you can get on AliExpress [2]. Or even more US focused brands under this umbrella like Protecli [3]
Azure Kubernetes Wrangler (SRE) here, before I turn some LLM loose on my cluster, I need to know what it supports, how it supports it and how I can integrate into my workflow.
Videos show CrashLoopBackOff pod and analyzing logs. This works if Pod is writing to stdout but I've got some stuff doing straight to ElasticSearch. Does LLM speak Elastic Search? How about Log Files in the Pod? (Don't get me started on that nightmare)
You also show fixing by editing YAML in place. That's great except my FluxCD is going revert since you violated principle of "All goes through GitOps". So if you are going to change anything, you need to update the proper git repo. Also in said GitOps is Kustomize so hope you understand all interactions there.
Personally, the stuff that takes most troubleshooting time is Kubernetes infrastructure. Network CNI is acting up. Ingress Controller is missing proper path based routing. NetworkPolicy says No to Pod talking to PostGres Server. CertManager is on strike and certificate has expired. If LLM is quick at identifying those, it has some uses but selling me on "Dev made mistake with Pod Config" is likely not to move the needle because I'm really quick at identifying that.
Maybe I'm not the target market and target market is "Small Dev team that bought Kubernetes without realizing what they were signing up for"
I have seen many people downplaying the complexity of a datetime library. "Just use UTC/Unix time as an internal representation", "just represent duration as nanoseconds", "just use offset instead of timezones", and on and on
Stuffs like DST arithmetic (that works across ser/de!), roundable duration, timezone aware calendar arithmetic, retrospective timezone conflict detection (!), etc. all contribute to a making the library correct, capable, and pleasant to use. In my experience, chrono is a very comprehensive and "correct" library, but it is also rigid and not very easy to use.
People have asked me to write something like this many times and one of the main reasons I haven't is because it's so open-ended.
With Crafting Interpreters, I felt like there was a reasonably small self-contained language I could come up with that covered almost all of the concepts I wanted to teach: variable scope, functions, closures, classes and dynamic dispatch, control flow, etc.
With type systems, there are a lot of forks in the design space and no clear "best" path:
* Does the language have subtyping or not?
* Are generics erased or reified?
* Is generic code specialized at compile time or not?
* Is type inference local or Hindley-Milner?
Any choice I make here would miss out on a lot of important material from the unchosen branch and disappoint readers who wanted me to take the other path.
Maybe the right answer is a broader survey-style book that tries to cover a bunch of different options (like Types and Programming Languages). But then you lose the fun of building one coherent thing.
The one you could build for under 2K is last gen hardware.
* Chenbro Rackmount 4U Server Chassis RM42300-F (rack mount case Remove the air filter on 120mm fan. Put two decent 80mm exhaust at rear).
* Two used air cooled 3090s. About $650 a piece on ebay. Check slot width and make sure everything will fit on your motherboard. Do a burn in when you get them cause used GPUs can be hit or miss.
* 5950x CPU (overkill just had it)
* 128GB DDR4
* Motherboard with x570 chipset and dual pcie x16. These will birificate to x8 pcie 4.0 lanes to each GPU. This is enough bandwidth to push GPUs to max IME
* 1200W+ ATX power supply.
* ebay "u.2 pcie 3.84TB" and adaptor for m.2 NVME slot. (again what I had & it is cheap)
If you're going to really beat the thing I would power limit the 3090s to 320w (from 350w). Perf change is not really notable and keeps temps better.
Does "CTO" mean you are the tech lead of a small (single team) engineering organization? Then everything written for staff engineers applies. E.g I've heard good things about "Staff engineer's path" by Tanya Reilly.
Does "CTO" mean you are leading an org that is too large to be hands-on with tech, and need to build an effective structure and culture? Then I second the recommendation for "an elegant puzzle" by Will Larson.
Or does "CTO" mean that you switched from being an engineer to managing a team of engineers? Then everything for new managers applies, for starters I'd recommend "Becoming an effective software engineering manager" by James Stanier, or "Engineering management for the rest of us" by Sarah Drasner.
For some good general material, I'd also recommend the resources that Gergely Orosz makes available for subscribers to his "pragmatic engineer" newsletter. Those are templates for the kind of documents and processes you will most likely need - if you're new to the role, you will not go too wrong by using them, and if you want to create your own they are excellent starting points.
FWIW, I've seen stronger performance from gpt-4-1106-preview when I use `response_format: { type: "json_object" },` (providing a target typescript interface in context), vs the "tools" API.
More flexible, and (evaluating non-scientifically!) qualitatively better answers & instruction following -- particularly for deeply nested or complex schemas, which typescript expresses very clearly and succinctly.
Stay away from Lua and use Python, Go, Node, Rust or even C in new projects. This is going to be a lengthy rant for a comment; apologies in advance.
Having written a ton of networking code in Lua I can tell it has a lot of design defects that most other programming languages have avoided. Especially the deeply embedded one-based indexing and lack of a separate integer type (chars are strings, ints are floats) make it wearing to type any code that has to parse any binary data. Even bit manipulation requires going through the FFI. Considering that Lua is often touted as the optimal lightweight solution in small embedded systems, these features are must-haves.
The builtin string pattern matching library attempts to mimic regular expressions, but bites the user in the leg every time they attempt to use it for anything remotely regex-y. Unfortunately most usual string manipulation seems to revolve around them and the string.gsub function.
The inconvenient string library is also largely irrelevant. The developers call their language eight-bit transparent which in reality means that the programmer needs a separate Unicode library, rendering the whole standard string library mostly useless. One cannot even format UTF-8 text, because the string library doesn't differentiate between characters and bytes.
The official documentation mostly revolves around C bindings. The actual Lua language documentation is provided by another web site that looks like it has been written by an attention-deficit child. Instead of getting to the point, the articles often first provide a list of ways on how not to implement things, or they are actually benchmarks of fifteen different ways to call the standard library to get the same effect. Sometimes, the provided code does not even work – for example, the given XML parser code crashes when it hits one of the error paths.
The small runtime and fast VM do not really matter when the language itself is lacking and requires a metric ton of external libraries to achieve even the simplest things that are possible in standard C and Rust, which provide the same level of performance and better type safety.
If you're interested in machine learning at all and not very strong regarding kernel methods I highly recommending taking a deep dive. Such a huge amount of ML can be framed through the lens of kernel methods (and things like Gaussian Processes will become much easier to understand).
0. https://web.archive.org/web/20250820184917/http://bactra.org...