nhecker

Because I wasn't familiar with it and others might be curious too: that prompt is available at https://cdn.openai.com/pdf/04d1d1e4-bc75-476a-97cf-49055cd98... and is just below 5 KiB of text.

The Art and Skill of Radio Telegraphy by N0HFF[1][2] is also an interesting read, and goes into a lot of the history. I recommend it if you want to know more on the subject.

[1]: https://www.qsl.net/w9aml/documents/TheArtandSkillofRadioTel...

[2]: You can also find it elsewhere; the title is distinctive enough.

As did OOO.

I agree; it's very pleasing to read.

No comment of value other than to say thank you for putting (and keeping) your art out there. Genuinely beautiful, some of it. And the generative towers gave me a chuckle; that was fun. GL with the family. I do believe I'll have a few new desktop backgrounds after today : )

+1 for V3 support, and if there's anything I can do to help with V4 support, let me know. I've not got the most free time, but would be happy to contribute if possible.

https://safedep.io/miasma-worm-ai-coding-agent-config-inject... seems to describe the same symptoms, for what it's worth.

If you're saying it only impacts public repos, I don't think that's quite right. It appears to impact private ones as well. Source: first-hand experience. If you're claiming that the only export vector is via public repos then I can't refute that. But just trying to clarify here.

And after a quick glance I'm not seeing any correlation between "Hades - The End for the Dammed" and this worm; would also love a source for this claim.

There's also Horde or Koboldai.net or Koboldai.com or whatever their project is named, if you want a community-driven version of this. You can play with it via a WebGUI at https://lite.kobaldai.net, or with an API token of all zeroes. (Or, an actual API key associated with your user.)

> The AI Horde is a service that generates text using crowdsourced GPUs run by independent volunteer workers.

The ARRL has some good writing on RF exposure. Basically everything I've read comes down to treating radiated RF energy as thermal risk. So it's not magic stuff that will give you cancer or cause your cells to turn inside out or something, it's just going to raise the temperature of whatever region of your body the signal is going to interact with. Could be 0.003 degrees C, could be 30 degrees C -- all that depends on the energy involved.

But that's at HF frequencies and above, not this VLF stuff which is somewhat of a different beast. Risks there are probably similar to AC mains power distribution, I would guess: touch it and get a nasty shock, don't touch it and you're fine.

"Transferring one time digitally" DRM-free audio files is possible and above-board (i.e., you pay and the artist gets paid) through services like bandcamp.com and their ilk. Of course your artist needs to have their music there first.

Neat article.

I'd love to know more about how candle-flicker LEDs are assembled, because that source of [apparent] randomness is very interesting to me. I'm not sure if it's an LFSR or true HRNG, and I'm sure there are lots of different designs out there for the simulcrum of natural candle light.

You can get a better sense of their operation if you wire up the LED to an audio circuit where they'll make a pleasingly happy beep boop sound.

(Edit: There was an article somewhere that explored the entropy and concluded that their component operated on a LFSR, as they binned all the brightness outputs into integer values and waves hands did fancy math to conclude that the brightness it was likely modulated by a LFSR. I'll see if I can find it.)

(Edit 2: https://cpldcpu.com/2013/12/08/hacking-a-candleflicker-led/ here's that article for those interested. https://news.ycombinator.com/item?id=25530895 was the original submission to HN.)

De-doming these things (as discussed in another comment) is quite a chore; I de-domed 30 LEDs (candle-flicker, of course) in order to diffuse the light and fit under the keys of a small 3x10 keyboard I was building. But the effect is neat when the backlight is on as it almost looks like a shadow is randomly typing away as the entire array flickers.

Wow, what an incredible gift (and privilege) that will be! Receiving a box with a few Klein bottles from you has still been the best thing I've ever gotten in the mail. I just earlier today used a Möbius strip to explain the bottle on my desk to my elementary-school-aged son. Thank you for being such an inspiration (and excuse to teach and learn) to us all, young & old alike.

_nick

>turn around and

Except that each of the parent's chat windows has zero context that the other window's request even exists, so from each window's point of view it's as if one person walks in to a store to buy a fake ID, and then somewhere else in a different universe on a different timeline a different person walks into a different store to hand that same fake ID over to a different cashier for the restricted purchase.

The LLMs are doing the best they can with absolutely zero context. Which has got to be a hard problem, IMO.

Python script that Claude Code wrote and I tweaked for peeking at marked USB-C cables: https://github.com/nhecker/usb-e-marker

Gist of random (human-written) power-related commands to peek at random power info: https://gist.github.com/nhecker/8e850773ff229724ce361967cc22...

For your last point, you're probably looking for something like `ioreg -raw0 -c AppleSmartBattery | plutil -extract 0.PowerTelemetryData.SystemPowerIn raw -` (The source for that last command is from the above gist: https://gist.github.com/nhecker/8e850773ff229724ce361967cc22... ) Or maybe `pmset -g ac | head -n3` is helpful, too. HTH.

_nick

(edit1: formatting)

(edit2: there's also https://news.ycombinator.com/item?id=47677607 which seems pretty cool but is quite complex, and might be overkill)

(edit3: different method for printing adapter wattage)

The terminating device(s) are the ones that do the flipping, not the cable. You can take a cable that works either way between two high-end device, and then connect it to at least one low-end device and it will fail to connect for one of the two orientations.

Why the 10 MHz radio?

Openrouter already does this, unless I've misunderstood the premise.

On one hand, injuries from vehicular accidents in the roadway may decline to AVs being generally safer. On the other, intentional violence due to unrest and unhappy jobless in "the streets" may limit or entirely offset those gains.

I can give a third vote to the rough comparison between a keyboard with brown switches, and a Model M. I've got both, and like both.

I can corroborate this finding -- I think the horn switch is just a logic-level digital switch going into one or more MCUs somewhere, subjected to all manner of latency and (probably) CANBUS jitter. It's not great. Trying to send Morse, or even a quick 'toot toot' results in a garbled mangled mess, and I find that very annoying. My early cars & motorbike had what felt like direct, switched control over power to the horn, those were great to use. I've debated installing a dedicated pushbutton rated for the amperage or at least controlling a solenoid somewhere that would power the horn.

As an experiment, I've found that you can reliably detect the presence of crummy horn control by trying to pulse the horn for the shortest amount of time possible. The shorter my push on the horn button gets, the more likely it is that the timing will feel wrong somehow, or the horn doesn't even sound at all.

I've definitely tried friendly beeps at friends or neighbors and it came out sounding like an angry honk.

Welp, this puts my https://gist.github.com/nhecker/8e850773ff229724ce361967cc22... to shame.

I wonder about the battery SoC being reported with macpow; there are several different ways to calculate that metric and it's not clear which is being used. I may dig into that if I get the chance. Neat tool!

Thanks for the [1] link, I hadn't seen that before.

I can't find it immediately, but I've read about something even sneakier than this. A standard broadcast station was modified such that its carrier signal was modulated by a PSK signal. The intended listener would use e.g., a PSK-31 modem to listen to the carrier signal and would be able to obtain the encoded digital data. Everyday listeners would hear the regular broadcast. The station involved _might_ have been a BBC station, but I don't recall.

Very cool! This is fun to watch.

Now I'm wondering how residential rooftop solar is accounted for... presumably there are houses in these grids which export solar electricity or offset grid power with solar production. The utility supplies data to this site, and the utility would only know about the energy produced by residential solar if each KWh of exported or offset energy were reported somehow. I'd imagine that's a pretty tough problem, particularly in the offset scenario.

I'm starting to believe this is [a] way forward. Or maybe an approach which is on a spectrum between <everything I have is on a phone behind a fingerprint and a four digit pin> and <I don't own a smartphone>.

Unfortunately, it's pretty common to only have a smartphone as your sole compute device, and increasingly onerous not to own one at all.

(edit: I'm broadly in agreement with your comment & observations, so I don't at all mean to come off as argumentative for the sake of being argumentative. You just got me thinking about how that situation might have been handled thirty or a hundred years ago.)

> [...] my doctor can now approve my request for a prescription from anywhere in the world. That just wasn't possible before [...]

I'm picking nits, but wasn't this more or less instantaneous approval possible before with e.g., a fax and a telephone? Or (although this is a bit of a stretch) a telegram and telegraph?

>And your own hardware stays available for non-AI related needs, while paying for these tokens would require you to address these needs separately in some way.

^ Fair. Yep, I agree the calculus changes if you don't have _any_ local hardware and you're needing to factor in the cost of acquiring such hardware.

When I did this napkin math, I was mostly interested in the energy aspect, using cost as a proxy. I was calculating the $/token (taking into consideration the cost of a KWh from my utility, the measured power draw of my M1 work machine, and the measured tokens per second processed by a ~20BP open-weight model). I then compared this to the published $/token rate of a frontier provider, and it was something like two orders of magnitude in favor of the frontier model. I get it, they're subsidizing, but I've got to imagine there's some truth in the numbers.

I wonder, does (or will) the $/token ratio fall asymptotically toward the cost of electricity? In my mind I'm drawing a parallel to how the value of mined cryptocurrency approximately tracks the cost of electricity... but I might be misremembering that detail.

Ditto. My personal equipment includes a home server (128GB DDR3 ECC) and a tablet with a keyboard. It's honestly astonishing what you can do without a full-fledged laptop, if you're willing to go through some gymnastics to get there. And it travels light compared to a laptop! (The tablet, that is. Not the headless box. :-))

In a similar vein: seek efficiency.

I.e., /if/ I am going to consume LLM tokens, I figure that a local LLM with 10s of billions of parameters running on commodity hardware at home will still consume far more energy per token than that of a frontier model running on commercial hardware which is very strongly incentivized to be as efficient as possible. Do the math; it isn't even close. (Maybe it'd be closer in your local winter, where your compute heat could offset your heating requirements. But that gets harder to quantify.)

Maybe it's different if you have insane and modern local hardware, but at least in my situation that is not the case.