The cereal boxes in the stores don't have cute cartoon characters on them, and I tried to send somebody a box of chocolates and it got seized by customs.

Candy is labeled like cigarettes.

My experience with embedded stuff is very limited -- just some hobby projects on the Pico.

From what I've read, though, the on-board oscillators (there are a few of them) can drift quite a bit. One data point [says][1] several seconds per day.

On the other hand, if what you want is a microcontroller with an accurate clock, they probably make those (just not the Pico).

[1]: https://forums.raspberrypi.com/viewtopic.php?t=29255

There are a few places to get the current time:

- on-board real-time clock (RTC) connected to a continuous power source (e.g. button battery)

- GPS

- Colorado WWVB signal (60 KHz), Frankfurt DCF-77 (77.5 KHz), Cumbria NPL (60 KHz)

- the internet (NTP, HTTPS servers, etc.)

- mobile internet (e.g. LTE)

- estimate time elapsed between power cycles by tracking and storing IEEE 802.11 timing synchronization function (TSF) timestamps from nearby wifi routers.

All of these are potentially problematic.

The best option is the RTC. Buy a DS3231, hook it up to your microcontroller and a button battery, and forget about it for a few years. The only problem with these (besides the battery) is that they can drift pretty badly. The fancy ones account for temperature fluctuations and are accurate to ~2 ppm, which is one minute per year. Aside from the drift, it sucks to need an always-on dedicated IC just to know the time, especially if you don't always need to know the time.

GPS is nice but it's hard to get a signal indoors, especially in a skyscraper far away from a window, as can happen here in New York. You also need a relatively bulky component and an antenna.

The longwave radio signals (WWVB, DCF-77, and NPL) are neat and old and what "atomic clocks" use, but the signal is tiny and you need a sensitive long-running receiver, either with a gigantic antenna or a slightly less gigantic ferrite rod. Even then, one of those cheap atomic clocks might not sync at all unless it's placed near a window. The WWVB signal is also very weak in certain parts of America and at certain times of day, so your circuit might only get a bit of signal over the noise once or twice a day, which might or might not be enough to deduce the time.

The plain old internet works fine, but then your power budget involves a wifi radio, though you only need to run it for a few hundred milliseconds per hour. You also need a wifi password, which is a pain to configure in an IoT device. Also, you wanted a clock, why does it need the internet? GTFOOH.

Mobile internet is way overkill.

The last idea is something I haven't tested fully, since my microcontroller (raspberry pi pico w) can't keep up with the "promiscuous mode" unofficially offered by its wifi chip. It's a neat idea, though: you're in an environment with wifi routers all around, and you want to guess the time elapsed since you last checked by listening, without credentials, to the chatter. With enough routers and some flash storage you can probably keep track of time, assuming the whole area doesn't get a power outage.

That's my very long way of saying that keeping time is a solved problem but all of the solutions have drawbacks and none works perfectly.

I started using them a long time ago to type Greek characters, but then I switched to vscode with a vim extension and it didn't support that keybinding so I lost the habit. Might work with the neovim extension now.

edit: Yep, but you have to add "k" to the list of "control characters handled by neovim" in the extension's settings.

Of course, life is about living and you only live once and yadda yadda. Saying AIs don't know something because they weren't really there smells close to androids aren't real because they weren't made by God. That's not to mention that they don't know anything in the vague sense of what we think knowing means.

I don't really have an opinion on the topic, but the framing in the article didn't speak to me. Makes me want to watch the movie again, though.

Here are some of the [more popular][1] ones, and then there are PCRE and Python.

It took me a while to learn that some of the older ones you see in e.g. grep are [specified by POSIX][2].

[1]: https://cppreference.com/cpp/regex#Regular_expression_gramma...

[2]: https://pubs.opengroup.org/onlinepubs/009696899/basedefs/xbd...

    /some/shell -l myjob.sh

    . ~/.profile && cd /some/where && ./job >>cron.log 2>&1

The Federalist Papers talk a lot about factionalism versus tyranny. On a larger scale, look at how long it took what are now European Union members to stop warring with each other.

Personally I prefer lisp 1 languages, like scheme. Even there, though, there was a split over r6rs, so we got a bunch of mostly-like-r5rs schemes and racket.

Maybe the problem is that lisps are no longer popular enough to have a winning implementation! If there is one, though, then it's Common Lisp on SBCL.

    > function foo({a, b, c}) {
    ... return {x: a, y: b, z: c};
    ... }
    undefined
    > foo({a: 1, b: 2, c: 3})
    { x: 1, y: 2, z: 3 }
    > const a = 'A', b = 'B', c = 'C';
    undefined
    > foo({a, b, c})
    { x: 'A', y: 'B', z: 'C' }
    >

Also, phosphorus is the more scarce fertilizer, I think. I remember reading a paper from a Chinese lab that was trying to figure out how to cheaply isolate phosphorus fertilizer from commercial pig farm feces. They decided it wouldn't be cost effective.