jewel

I believe it's a reference to a joke meme that goes something like "Write Windows 12 from scratch. Make no mistakes." At least that's the first context I heard it in.

I had an Eye-Fi card in my DSLR years ago and had a python script [0] running on my home server that'd download the photos as they were taken. It'd play a noise over the home audio system to let the taker know that the photo had transferred.

It worked fairly well but at some point I got nervous that it might miss a photo and switched back to a boring SD card.

[0] https://www.returnbooleantrue.com/2009/01/eye-fi-standalone-...

Interesting. Can you elaborate on which harness you've tried it with? I'd love to switch to deepseek for my personal use.

Also, which SOTA western models are you comparing it with? Just to give more flavor.

As an alternative to the VoIP phone: Redpocket has a $2.67/mo plan. We loaded that SIM into a small android phone (Unihertz Jelly phone).

It works great as a home phone but has the additional advantage of being able to wander if a pre-cellularized needs to go somewhere. For example, my 13-year-old takes it when going on a long bike-ride with his friends.

We keep it in our closet and only comes out when needed. They aren't allowed to give the number out to friends.

Also the consumption of AI-generated text could be having an influence on the tone of how people write.

So even if AI was not used to write an article, it could "smell" like AI to someone who consumes less of it.

"If it's not worth writing, it's not worth reading."

  - https://claytonwramsey.com/blog/prompt/

The way I think you'd set this up is you'd create a trust with the millions and then the trustees would pay the company its monthly fee from the trust's funds.

With enough funds, the trust should be able to both pay for your preservation and grow its balance. You'd even be able to inherit the remaining funds when revived.

Of course in practice there is still the possibility of the trustees being corrupt.

Here's a "Walk with me" video of the bridge: https://youtu.be/DA9NPmwWDWE?t=385

Here's a philosophical question. Does anyone account for inflation when looking at their long term history? I've been thinking of looking at everything in 2019 dollars.

It might also be useful to adjust for inflation going backwards, e.g. everything shows in 2025 dollars.

My neighbor just did the exact same thing. The way FAT filesystems work is they change the first byte of the filename to an invalid character to make them a tombstone.

Since he hadn't used the SD card yet, we were able to restore the files with "TestDisk", a companion tool that ships with PhotoRec. Under "Advanced" there is an "Undelete" tool. This will let you browse the filesystem, find your missing files, and copy them to another drive.

For those old enough to remember, MSDOS came with undelete.exe which worked the same way.

In my imagination, I thought that the large GPU clusters were dynamically allocating whole machines to different tasks depending on load.

So, hypothetically, if ChatGPT's peak load and their minimum load were a 3× ratio, they'd reallocate 2/3 of their servers to training when it's not peak time.

Doing the same thing inside an individual GPU seems irrelevant to anyone operating at scale when they can approximate the same behavior with entire servers or even entire racks.

Talk to the other vendors. I know of a place that had about that same amount and decided to have a redundant copy of all of their data in another vendor's S3-compatible product. That vendor paid for all of their egress fees as long as they signed a 12-month contract and used their tool for the migration.

The front-to-back symmetry is interesting. It may cause some confusion for other drivers, in some limited circumstances, when they can't tell which way the vehicle is facing.

It appears, based on my study of the footage on https://www.youtube.com/watch?v=lIRW8bfy4kE, that it could possibly switch which side is the front and the back by just changing the color of the lights. With RGB LEDs that would be pretty easy to do. But my question is, when would that be useful?

It would be neat that it could pull into a driveway and then leave in "reverse", but that doesn't seem like it'd come up that often for a robotaxi.

The back wheels look like they can steer. That's useful for parking in tight spaces.

Yes! That has been supported for a long while. At least on Android, go to Settings -> Chats -> Chat Backups. Set up a schedule and a passphrase and a folder, and it will export your chats every day.

I do that and then sync that folder with another computer using SyncThing.

I used to work at a place that had a second copy of all the git repositories on a server, available over ssh. We could push there and then, at deploy time, instruct the servers to pull from that repo instead of bitbucket.

If I were to set up the same thing again today, I'd add some automation to automatically keep it in sync with github as well as automate the servers so that they'd attempt to pull from both on every deploy.

I share this as an idea for those who need an emergency or backup deploy mechanism.

I wonder if you could work around this problem by having two EBS volumes on each host, and write to them both. You'd have the OS report the write was successful as soon as either drive reported success. With reads you could alternate between drives for double the read performance during happy times, but quickly detect when one drive is slow and reroute those reads to the other drive.

We could call this RAID -1.

You'd need some accounting to ensure that the drives are eventually consistent, but based on the graphs of the issue it seems like you could keep the queue of pending writes in RAM for the duration of the slowdown.

Of course, it's quite likely that there will be correlated failures, as the two EBS volumes might end up on the same SAN and set of physical drives. Also it doesn't seem worth paying double for this.

If you're using cloud storage for backups, don't forget to turn on Object Lock. This isn't as good as offline storage, but it's a lot better than R/W media.

At work we've been using restic to back up to B2. Restic does a deduplicating backup, every time, so there's no difference between a "full" and an "incremental" backup.

I think you have that backwards; it should decrease latency and decrease throughput.

I don't imagine the overhead will be too bad though, so it may decrease latency while keeping throughput essentially the same.

Of course you'll want to benchmark on your specific load. For example, at my day job it'd make no difference because we don't use threads, each Passenger worker has just one thread and handles one request at a time.

For compiled languages it should be fine, as you're only going to compile the permuted source code, not execute it.

Given a sufficiently bad compiler bug anything is possible, but I think given that it's trying to minimize the size of an input that gives a particular output I don't think it's likely to explore distant branches.

When I give it that same prompt, it writes a python program and then executes it to find the answer: https://chatgpt.com/share/66e35a15-602c-8011-a2cb-0a83be35b8...

I've heard it called "Platform risk". Also "Playing in someone else's walled garden", or something along those lines. I realize that's not a term for the inevitable rugpull, but that's the closest I can think of.

This has security implications! Example exploitable ruby code:

  unless person_id =~ /^\d+$/
    abort "Bad person ID"
  end
  sql = "select * from people where person_id = #{person_id}"

We have a product that uses ChatGPT via the API, using the 3.5 turbo version. Our query involves some dates. Instead of giving back text like it usually does, today it has been giving errors because it does not think 2024-02-29 is a valid date.

This is easy to reproduce with the web interface, at least sometimes [0]. It start out by saying it's not a valid date and then as it's explaining why it isn't it realizes its mistake and sometimes corrects itself.

[0] https://chat.openai.com/share/37490c9f-81d6-499f-b491-116536...

This reminds me of Java Pathfinder, but for distributed systems.

Column-oriented has better performance for analysis but worse for highly transactional workloads. I think standard operating procedure is to dump the whole database every night into a column-oriented database and then do their analysis on the second database.

The terms to look up here are OLAP and OLTP.

As long as the content resets periodically it's probably fine. Right now it's on the front page but in the near future there will probably be only one person on it at a time, who can send it to a coworker and test out the functionality live.

Memory compression (via zswap) has made a big difference for me, on Linux, when on a constrained device. It makes a lot of sense for desktop workloads where most time is spent waiting for user input. For me it was a lot faster than swapping to disk, although with NVME drives that may no longer be the case.

I thought I had read when the M1 came out that they had memory compression turned on by default but I'm not an Apple user.

The disk cache is what lets the second one catch up. It would only happen if the copies were started at nearly the same time; soon enough that what's been copied so far is still in the cache.

I've observed this same behavior on modern operating systems with big rsync jobs and spinning drives. If you have lots of small files then reading the metadata and directory structure takes a while but fits in the cache, so a second rsync will catch up very quickly to the first.

Sure! Here's an implementation of nand and a 2-bit adder that uses it: https://github.com/jewel/nand

SQL NULL can't be far behind.

SQL's NULL is far more useful though, since NULL != NULL. That lets you do things like join two tables with a column and not have the NULLs match.

Consider, for example:

    select * from users where id = null;

It's also really nice for non-ID, non-reference fields to represent N/A. For example, user.birthdate can be NULL if the birthdate is not known.

SQL also lets you choose when you want NULL to be allowed for a column, so it's less likely to be a gotcha.