follower

With regard to "Un*x", the Wikipedia text is... imprecise[0].

The asterisk character in this context/usage is not used as a wildcard/glob but as a censoring device[3], in a manner similar to: "Don't censor f*ck on HN."

In the case of "Un*x" the motivation is not one of propriety but of proprietary--it was motivated by matters of legality (real or imagined) in relation to trademarks.

AIUI at the time UNIX(TM) was a trademark and it was thought by some that in order to avoid potential legal issues it was required to always include the TM superscript in order to avoid the wrath of the trademark owners for trademark infringement/generic-ism.

But as "Un*x" is not "UNIX"[4], the reasoning went, no trademark attribution was required.

Anyway, that's why when referring to "***/L*nux" I’ve (very) recently taken to calling it "***/L*nux", not wanting to infringe on Linus's trademark and all...

----

[0] The Wikipedia text doesn't really fully represent/match the text of the cited reference[1][2]:

"Used to refer to the Unix operating system [...] in writing, but avoiding the need for the ugly ™ typography [...] lawyers now say that the requirement for the trademark postfix has no legal force [...]"

[1] https://en.wikipedia.org/wiki/Unix-like#cite_note-jargonfile...

[2] http://catb.org/jargon/html/U/UN-asterisk-X.html

[3] https://en.wikipedia.org/wiki/Asterisk#Censorship

[4] Coincidentally, GNU is also Not Unix: https://en.wikipedia.org/wiki/GNU#Name

TL;DR: An Audio GIF stores audio inside a standards compliant GIF image: https://audiogif.rancidbacon.com/

----

From a brief test, at least some of the options on the page do support save-able single file--depending on the browser (e.g. desktop Firefox with right-click).

It is unfortunate that few, if any, of the commercial "GIF host" services or social media sites made any attempt to preserve the single file nature of the GIF with their "more efficient" replacements. Of course, in many cases this was intentional because they wanted to require people to use the company's web site as the "player".

Even more so, it has long bugged me that none of the attempted "replacements" have made any attempt to make use of the inherent extensibility of the GIF format itself to support transitioning to a more efficient format while also preserving the single file nature of the GIF and supporting "legacy" GIF-only clients.

The GIF format's extensibility was how GIFs gained the ability to loop, after all.

----

The GIF format could've been used to support transitioning to a more efficient format.

The key observations to make were:

(1) A GIF image sequence when converted to an efficient compressed video format occupied only small fraction of the original GIF.

(2) Thus a compressed video variant of the GIF could be appended to the original GIF file and the overall file size wouldn't be "significantly" larger than the original GIF.

(3) But even better thanks to GIF's extensibility via "Application Extension", rather than appending, the video data could "transparently" be embedded into the GIF (with a small size efficiency loss) and thus the file could be downloaded, transported & "legacy" visuals displayed by existing tools--without loss of the embedded compressed video variant's data.

(4) The last piece of the puzzle is that if we, say, also include a size value N in the second-to-last block of the GIF (with some fixed-byte-size per format version) then "NuGIF"-aware (or whatever :) ) client software (or, e.g. a JavaScript shim) could perform a HEAD request for total file size, followed by range-request of the second-to-last block, followed by range-request of last N-ish bytes to download just the bytes of the video encoded version. And "legacy" clients wouldn't be particularly "significantly" burdened by the additional video variant bytes contained with in the GIF.

But, ya know, nobody did. :)

(Obviously there's also the opportunity for a "more efficient" but "less ideal" variant of the concept such as simply embedding an alternative video URL in the GIF instead but that wouldn't be nearly as cool. :D )

Of course, one obvious risk with a "dual content" format like this is that it would be possible for the GIF-encoded visual content to not match the video encoded visual content--as is already the case with e.g. embedded image thumbnails. (I've vaguely contemplated how the consistency might be verified with "untrusted sources" in some way based on--some portion of--actual visual content but... *shrug*)

Anyway all that has always just been a concept but...

...of course, we've just been ignoring the elephant trumpeting in the room...

...the reason I started digging into the GIF format in the first place...

...the thing that's always been missing from GIFs...

...sound!

----

Which is why about six years ago I created...

[Headphone warning.]

...the Audio GIF: https://audiogif.rancidbacon.com

[Spoiler alert: Just noticed, apparently, Web Audio API policy changed again at some point, so you may get `AudioContext` console message spam. :/ Guess that's web development for you--these days I normally let Godot handle it for me. :D The demo reel sequence used to only require a click on the first image...]

Complete with demo reel (no plugin needed!): https://audiogif.rancidbacon.com/start/

Yet, still just a.gif file: https://audiogif.rancidbacon.com/assets/samples/woah.a.gif

[Note: Just looked at the code & apparently past me never got around to making "Save Image As..." work when on a demo reel page but "Save Link As..." should work. :)]

[Also, No Spoilers but seriously what are the odds of me hearing this specific line being uttered "on air" during the time I was working on this project: https://audiogif.rancidbacon.com/three/ ?! :D ]

----

My Audio GIF project remains one I'm particularly proud of--in part just because I did actually release the thing; and, then, I guess I just really like lower-level hacks that serve no practical purpose but challenge "assumed wisdom"? :)

Oh, yeah, and part of the motivation for completing the project was the existence of a Reddit thread many years prior where I saw someone get almost totally mocked for having the audacity to ask whether it was possible for a GIF to have audio--to which the answer was a resounding (yet incorrect): No!

(Which I already knew at the time was entirely possible in theory.)

To their credit, I do recall there was one person who was brave enough to comment that it was a theoretical possibility.

So, for years after I assumed someone would surely create such project.

And, eventually, when someone didn't, I did. :)

----

One thing at the time that was cool was I discovered that some GIF hosting services that provided access to an actual GIF file also didn't strip unknown "Application Extension" blocks from the GIF file--so the audio in the GIF was preserved!

Unfortunately one thing at the time that was uncool was I discovered it was during a window of time when Range Requests required CORS--a restriction I think was eventually removed as unnecessary--but as a result I didn't upload a public demo that used an Audio GIF stored on one of the standard GIF hosts.

----

Obviously the Audio GIF format didn't exactly... set the world on fire at the time but that's okay because according to the linked article GIFs are "‘for boomers’ and ‘cringe’" anyway.

But... in twenty-five years time, when streaming isn't cool and vinyl isn't cool and camcorders aren't cool and when even audio cassettes are uncool again... well, the Audio GIF will be there waiting...

Waiting for someone to innocently ask: "Can GIFs have audio?"...

Waiting so a small voice can cut through the raucous laughter and say: "Well, ackchyually..."...

And, then, my work will be complete. :D

----

Too Long; Did Epilogue:

As a lesson for us all, perhaps the most amusing part of the whole project occurred when, having finally released everything, I posted one of the demo Audio GIFs to /r/gifs...

...only to have the mods reject the submission because... "it isn't a GIF" ...because... "GIFs don't have audio" ...despite literally being a GIF file! :D

Turns out, somewhere along the line, apparently "GIF" stopped being a specific file format and instead became a category referring to any short looping image sequence without sound--whatever the file format. :D *shrug*

skinner-out-of-touch.not.a.gif

----

Anyway, apparently this is my "How to GIF (2025 Edition)" article, so if you made it this far: thanks for reading. :)

TL;DR: Godot does support WASM project exports.

----

> The WASM distribution channel is a huge potential selling point for Bevy. You don't get that with Unreal, and AFAIK, with Godot either.

To clarify: if by "WASM distribution channel" you mean "exporting for the Web"--Godot has supported exporting & running projects in a web browser for around a decade[0].

(WASM has been supported since Godot 3.0[a] & is still supported in the current Godot 4.3[b][c]. Even prior to WASM, Godot 2.1 supported export for web via `asm.js`[d].)

Godot even has an editor[e]... :) which also runs in a browser via WASM[f].

That said, yes, you're correct that WASM support in both Bevy & Godot is a selling point--particularly because people often use Game Jams as an opportunity to try out new game engines and as "everybody knows" no-one[i] downloads executables from game jams so you'll get way more people trying your game[j] if they can play it in a web browser.

----

[0] The oldest `platform:web`-related issues tracked date back to 2015.

[a] https://docs.godotengine.org/en/3.0/getting_started/workflow...

[b] https://docs.godotengine.org/en/4.3/tutorials/export/exporti...

[c] The move to the new rendering architecture (OpenGL vs Vulkan vs WebGL) in Godot 4.0 has had an impact on which exact features are supported for web exports over time.

[d] https://docs.godotengine.org/en/2.1/learning/workflow/export...

[e] A light-hearted tongue-in-cheek jab played for cheap laughs with my only defense being that I've used both Godot[g] (since 2018) & Bevy[h] (since 2022) for 2D/3D game jam entries of varying degrees of incompleteness; participated in both communities; and am supportive of both endeavours. :)

[f] https://editor.godotengine.org/releases/4.3.stable/godot.edi...

[g] https://rancidbacon.itch.io/sheet-em-up

[h] https://rancidbacon.itch.io/darkrun

[i] (Rounding down.)

[j] My own most complete & played game jam entry was (unexpectedly) this Incremental/"Clicker Jam" entry inspired by a childhood spent dismantling electronics: https://rancidbacon.itch.io/screwing-around

> recommend this Spolsky classic on how to convince one to try a new VCS: https://hginit.github.io/

Based in part on the parallels of their respective titles, this post may be similar enough in style to potentially be informative about Jujutsu: https://v5.chriskrycho.com/essays/jj-init/#outline

I've linked directly to the Outline/TOC in order to provide a more immediate overview of the post's content but there's also a chunk of more "philosophical" introductory text before the Outline: https://v5.chriskrycho.com/essays/jj-init/

The introductory text has parallels with the "Subversion Re-education" section of Spolsky's document--including the apparently mandatory (though stated in more reserved terms) reference to the effect the incumbent VCS has on one's brain: "just how weirdly Git has wired your brain". :D

As to the "why", to quote from the intro:

----

Jujutsu is two things:

(1) It is a new front-end to Git. This is by far the less interesting of the two things, but in practice it is a substantial part of the experience of using the tool today. [...]

(2) It is a new design for distributed version control. This is by far the more interesting part. In particular, [...] a few key concepts [...]:

(2.1) Changes are distinct from revisions: [...]

(2.2) Conflicts are first-class items: [...]

(2.3) The user interface is not only reasonable but actually really good: an idea borrowed from... literally every VCS other than Git.

----

As someone who reluctantly stopped using Mercurial primarily due to the friction around using hg-git to interoperate with GitHub, I think Jujutsu's approach of focusing initially on developing atop the "git backend" for interoperability is both wise & IMO pretty much a requirement for any project hoping to become the next industry standard VCS that everyone complains about. :D

Having said that, while I'm positive about the project's approach & potential, have read multiple Jujutsu articles, docs & even downloaded a binary, I'm yet to actually use it.

By now the main reason I've been less inclined to prioritize trying JuJutsu out is the project's mandatory CLA requirement for contributions: CLAs are anti-developer & an abuse of the power differential between individual developers and corporate entities.

I'm sure they'll realise the error of their ways eventually. :)

And, yes, perhaps I'm tilting at windmills--but that's probably also why I stuck with Mercurial for so long and why I'm even considering/hold out hope for a git replacement... :D

> it was Google Maps that made the experience of not needing to refresh the page popular

IMO that's a reasonable impression of the times unless I'm forgetting something (and the additional observation about sharing--"virality" as it was called, before you know--was insightful).

At the time the previous "state of the art" was something like MapQuest which IIRC had a UI that essentially displayed a single tile and then required you to click on one of four directional arrow images to move the visible portion of the map, triggering a page load in the process (maybe a frame load?).

Yahoo! also "participated" in the mapping space at the time.

In the event anyone's interested in further ancient history around the topic, this page is actually (to my surprise) still online (with many broken links presumably): https://libgmail.sourceforge.net/googlemaps.html

(It's what we did for fun in the Times Before Social Media. :D )

> [...] some of the announcements today have thrown us for a loop so plans are still being discussed.

Feel free not to answer, but: does this imply Rebbele were aware of an impending Pebble OS source release but not... the other thing?

If so, that seems... "unfortunate". :/

Also, btw, I really like the use of the phrase "user-respectful technology" in the Rebble post.

And, rather unsurprisingly given one of my other recent comments[0], I am supportive of the fact that the Foundation's missions includes these aspects in particular:

* "educating people about why these [little oasis of user-respectful technology] are important"

* "using them as a platform to teach embedded systems"

*insert additional supportive statement & well wishes here* :)

----

[0] https://news.ycombinator.com/item?id=42856930 [1]

[1] TooLong;Don'tRead. :)

Thank you for mentioning this detail again.

I generally remember that there's some problematic issue with Unihertz but often seem to manage to forget exactly which issue it is.

Non-compliance with the GPL is frustratingly common (over a huge range of company sizes too).

Not at helped by the fact that the community managed to (stupidly) burn bridges with the one person who seemed to be effecting actual change within Chinese companies with regard to GPL compliance.

Oh! Also: I'd be really interested for you to expand on "I think I’ve learned some valuable lessons[0]".

The 2022 updates gave an interesting insight into how your perspective had changed in regard to your initial thoughts and I'm interested to know if another three years has lead to further perspective changes.

I found Andrew Witte's remark of particular interest with regard to "...we allowed early success [...] to mask the fact that we never gained a good understanding of what our actual customers valued the most. We lucked into having made something people wanted (the original Pebble) and, IMO, never really were able to figure out exactly why it was successful. So it was hard to reproduce that success."

----

[0] https://ericmigi.com/blog/success-and-failure-at-pebble

TL;DR: Succinctness has never been my strong suit? :)

----

> But I'm not really sure that this fear is grounded - before we sold to Fitbit we 'unlocked' the Pebble mobile app [...].

If I'm reading OP's comment & your reply correctly, my impression is there's potentially a fear of either (a) "re-locking"; or, even just (b) "new thing not unlocked"--and, I think, you're saying that (a) isn't going to/can't happen?

On closer reading I think you might also be saying that (b) isn't going to happen because "new thing" is still going to use the previous unlocked app and/or maybe a new unlocked app? But, if that's the case, I only really saw that possible interpretation after a much closer re-read.

(Alternatively, maybe I just didn't weight sufficiently strongly the FAQ: "Will it be exactly like Pebble?" "Yes. In almost every way.")

More broadly (outside the positive example of your specific track record with regard to OGPebble & the app unlocking), given the landscape of the past 1.5+ decades littered with even just recent examples such as Spotify's Car Thing, Google's Stadia controller, Bambu Labs, and pretty much every phone ever[0][0a], I think it would be a stretch to consider the fear to be entirely ungrounded.

Particularly if some portion of the device firmware etc and/or server software is still going to be closed source.

In terms of strength of confidence in the potential of achieving a "desired open outcome/ongoing experience", I imagine the ordering from least to greatest trust required by product purchasers is something like: "completely open & unlocked from the beginning", "legally binding commitment/escrow for open & unlocked on 'exit'", "word/reputation for open & unlocked on 'exit'", through to "amorphous hope for largesse/noblesse-oblige/benevolence/other-fancy-latin-phrase for positive outcome at some unspecified future time".

And, um, trust in general might be slightly lacking these days, for some reason. :)

Anyway, IMO FWIW.

----

On a slightly different note, while reading comments in the various PebbleOS/RePebble threads I've been contemplating what has changed with regard to the consumer electronics hardware market compared to, say, fifteen plus years ago.

Certainly the "hope" of Android bringing the Power & Freedom of "Linux on Desktop" to "Linux on the Phonetop"[1] from the early 2000s seems to have been completely abandoned[2] but on the other hand Framework[3] exists and the Steam Deck[4] exists.

Perhaps the two most surprising things related to this "control over personal devices" topic from recent history:

(1) the discovery 1-2 years ago that it wasn't just irascible curmudgeons like me wanting to have control over the devices in their lives[5] but a much younger generation was also looking to "dumb phones" in a conscious effort to exert some control over the impact of such devices on their lives.

(1.1) aside: the attraction of similar demographic(s) to audio cassette tapes on the other hand, I totally don't "get" but by now I'm starting to suspect this state may now be primarily driven by the desire to not accidentally make cassettes uncool by "getting" it. :D

(2) noting over the past year or so the significant increase in the number (or even the mere presence) of YouTube comments from gamers remarking that they have just, or, want to, move from Windows to Linux. Gamers. GAMERS! The same demographic who previously would ruthlessly mock anyone who dare suggest such a move might be possible[6] let alone desirable...

This might all just be the biased perspective of a jaded idealistic optimist[7] but it's not nothing. Unless it is.

Approaching consumer electronics hardware with this trend as a guiding force may also not be the way to run a financially sustainable hardware business but on the other hand, what if?

----

BTW I noticed in one place on the page (https://repebble.com/) the text states:

* "(which purchased Fitbit, which had bought Pebble)"

and in another it states:

* "before the company's IP was sold to Fitbit in 2016".

I mention this because the difference is a nuance that has seemed to be significant in other times/places, so thought it might have unintentionally slipped through proof-reading--even if of no real consequence now. :)

----

Also: Hello! (Again. :) ) This was unexpected news, for sure.

Left another "short" note for you here (in case you've not encountered it organically): https://news.ycombinator.com/item?id=42856930

----

[0] Yes, yes, Fairphone exists.

[0a] Televisions!

[1] Irony? Satire? Sarcasm? *shrug*

[2] Speaking of small phones, this still remains of interest: https://smallandroidphone.com/

[3] I so want to know what category Framework's "Next Thing" is in--primarily because what's seemingly the "most obvious" category for them to move into also seems the most "unlikely" by any reasonable measure. So to find out would be to either be surprised by a category I hadn't considered or surprised by the audaciousness of their next goal.

[4] Hand-waving away for now any problematic aspects of its current context.

[5] See also: https://news.ycombinator.com/item?id=42848761 & https://news.ycombinator.com/item?id=42845574 (non-pejorative :) )

[6] Yes, yes, every PlayStation fan-persoin runs BSD.

[7] I do like the phrase "user-respectful technology" as used here: https://rebble.io/2025/01/27/the-future-of-rebble.html

Still "daily driving" my burgundy[0] Pebble... hoodie/fleece!

(It's impressive quality company swag.)

@erohead, when you're at the stage of needing a kick-ass RePebble SDK developed & supported again[1], you know where to find me. :)

lol @ the FAQ: "Aren’t you the guy who screwed this up last time?"

Also, while looking through the repo, I'd totally forgotten the alphabetically ordered fast-food themed release code names which included the "Kiwiburger" (a global chain's local product that contains neither the bird nor the fruit) that I now wonder how many people it confused. :)

The "Kiwiburger" code name release also happened to coincide with the inclusion of "Simplicity" (a watch face I designed & implemented) as one of the standard faces shipped with each Pebble watch by default.

I was particularly proud of the inclusion of "Simplicity"--especially when Engadget subsequently said it was "...sure to make minimalists happy" which was what I was aiming for. (I seem to recall it also gave me the opportunity to say "Hey, I designed that watch face!" when I saw a Pebble watch on display at an airport duty free store once. :D )

Anyway, I should probably get this memoir off to the publishers[3]. :)

----

[0] Oh, sorry, apparently it's cranberry. :)

[1] I helped develop & support the very well-received initial SDK that enabled "Hacker Backers" and others to create their first Pebble watch faces & watch apps.

It was quite an experience to be working on the SDK remotely from New Zealand[1a] and then have the initial public SDK release immediately covered by the likes of TechCrunch[1b], The Verge[1c] and Engadget. (An SDK! :D )

There was a lot of pent-up interest/demand for the SDK so it was really great to see how excited people were when they successfully implemented their first watch face or (later) watch app. In many/most cases this was the person's first experience of anything approaching "embedded" programming--there was a lot of effort put into removing as many barriers from the development experience as possible, so it was really rewarding to see people succeed.

(Initially the process still required a locally installed embedded development environment, so even with all the effort invested to reduce barriers it still wasn't a simple process but turns out people were really motivated. :) It also turned out that I was really motivated to script/automate & simplify the process simply to avoid having to write documentation covering a more manual process. :D )

It was also super cool to see people then develop other (particularly web-based) tools to enable people with even less technical experience/skill to still create e.g. a custom watch face with their favourite sports team logo or the family dog featured on it.

I mention all this in part to reminisce and in part to convey some of what the mood around Pebble was at the time for those who may not have been around *cough* nearly fifteen years ago and were wondering what (part of) the "big deal" was...

An early version of the SDK documentation is archived here: https://web.archive.org/web/20130415083512/http://developer....

[1a] via this HN Jobs post IIRC: https://news.ycombinator.com/item?id=4132957

[1b] https://techcrunch.com/2013/04/12/pebble-watchface-sdk-now-a...

[1c] https://www.theverge.com/2013/4/15/4228700/pebble-tetris-clo...

[2] https://github.com/google/pebble/blob/3b927684809fba173ee540...

[3] Okay, one last note: interesting to observe it was suddenly a lot more difficult to find Pebble/SDK related links from ~2012/2013 due to the amount of coverage the PebbleOS/RePebble announcements seem to have received. Read into that what you wish. :)

For visibility (via comment by 1337shadow @ https://news.ycombinator.com/item?id=42848245):

----

> Instead, we took a more direct route - I asked friends at Google (which bought Fitbit, which had bought Pebble’s IP) if they could open source PebbleOS. They said yes! Over the last year, a team inside Google (including some amazing ex-Pebblers turned Googlers) has been working on this. And today is the day - the source code for PebbleOS is now available at github.com/google/pebble (see their blog post).

https://ericmigi.com/blog/why-were-bringing-pebble-back

----

> So much for “open source”

In the given context "Proprietary source code" seems to potentially primarily mean third-party proprietary source code which Google doesn't have the rights to re-license.

There's further discussion about what was removed & potentially why here: https://news.ycombinator.com/item?id=42845102

TL;DR: Hardware support library source/blobs from CPU/MCU hardware vendor(s) with restrictive license/distribution constraints.

(Some of which may no longer apply to more recent versions of the vendor code in question.)

> Ps so Eric Migikovsky works for Google now? I thought he was working on beeper.

AIUI the connection to Google here is that Google acquired the rights to Pebble OS (when Google acquired FitBit (after FitBit had previously purchased the rights to Pebble OS from Pebble Technology before it closed)).

As Google has now released the code under an Open Source license, Eric (with no connection to Google) is now seemingly planning to build something utilizing the newly opened source.

(Further context is that some other people who formerly worked for Pebble do now work for Google and were involved in the process of getting Google to release the Pebble OS source under an Open Source license.)

Eric commented re: Beeper here: https://news.ycombinator.com/item?id=42845776

> Is he planning on self-financing presumably out of some personal wealth?

This may be relevant context for your question: https://www.nytimes.com/2024/04/09/technology/beeper-messagi...

Unfortunately, as mentioned in another comment, the Bluetooth stack is apparently one of the items that is not included in the source release[0]:

    Some parts of the firmware have been removed for licensing reasons,

including:

    [...]

     - The Bluetooth stack, except for a stub that will function in an emulator

    [...]

Which suggests that the Bluetooth stack wasn't entirely of their own making, so perhaps any of Pebble's own additions were too intertwined (e.g. gave away too much Bluetooth stack vendor proprietary API info) to be easily separated?

[0] https://github.com/google/pebble/blob/3b927684809fba173ee540...

TL;DR: No. Maybe? Depends.

It's probably reasonable to make a distinction between "Real Time" desktop/server OS (on CPUs) vs "Real Time" embedded hardware OS (on MCUs).

(Even aside from any hard-/soft- real time distinction.)

On the embedded side, in addition to FreeRTOS (upon which Pebble OS is built), I'm aware of others with reasonably high profile such as:

* Zephyr (Linux Foundation, C): https://en.wikipedia.org/wiki/Zephyr_(operating_system)

* NuttX (Apache Software Foundation, C & C++): https://en.wikipedia.org/wiki/NuttX

In addition, there's also some "up & coming" Rust language projects which fall somewhere along the "framework" to "OS" spectrum (in part, via https://arewertosyet.com):

* Tock: https://github.com/tock/tock

* Embassy: https://github.com/embassy-rs/embassy

* Hubris: https://hubris.oxide.computer

On the desktop side, I seem to recall in the past, OS such as BeOS & QNX have been presented as a possible future for real time desktop OS that hasn't arrived.

As someone else already mentioned, PREEMPT_RT being merged for Linux is a recent development somewhat in this space which could have impact on both desktop & "embedded" situations but suitability varies dependent on, say, whether you're wanting to use it for audio production versus controlling some 10 tonne robot operating next to humans.

Hope this at least goes some way to answering your question. :)

TL;DR: Tintin in the Land of the Public Domain.

I had forgotten Pebble used Tintin-themed code names (which I assume was the inspiration for the Snowy assistant app's name?)...

Tangentially & coincidentally related: the Tintin & Snowy[0] characters entered the/a Public Domain[1] at the beginning of this year!

Which means your lawyer might advise that you might now actually be able to use an actual original Snowy illustration[2] for the app logo...

I mention this primarily because I am currently (in theory) developing a Tintin-themed game for an annual Public Domain game jam[3]. In reality, I've spent more time trying to locate scans of Tintin-related documents/illustrations[4] that actually fall under the constraints necessary for even US Public Domain[5].

----

[0] Milou.

[1] Well, actually[1a], maybe only in the US for 2025? And 2034 in Berne-associated countries? And 2054 in Belgium? Or any year if you're an AI, seemingly? Okay, perhaps it's better to not use an original illustration. Such are the joys of actually trying to interact with the Public Domain in good faith[1b].

[1a] https://en.wikipedia.org/wiki/Tintin_in_the_Land_of_the_Sovi...

[1b] It just now occurs to me to wonder whether or not Milou can actually be referred to as "Snowy" given Tintin wasn't translated into English until the 1950s (late 1950s for the use of the name "Snowy" rather "Milou") (and as late as 1989 for the first title "Tintin in the Land of the Soviets"), given translations are AIUI new works?

[2] First appearance: https://en.wikipedia.org/wiki/File:Tintin_and_Snowy_from_Tin...

[3] https://itch.io/jam/gaming-like-its-1929

[4] Pretty interesting finding different variants on archive.org, e.g. [4a][4b][4c]. (After all, "entering the Public Domain" is not of much value if the related material isn't accessible or the status is unclear. (Which is why recent trends in FLOSS project copyright year ranges statements bug me...))

[4a] Original French language album: https://archive.org/details/tintinnb/Francais/Tome%2001%20-%...

[4b] Second French language newspaper serialization: https://archive.org/details/cv-1930-50-pb/page/n3/mode/2up

[4c] Original physical illustration: https://archive.org/details/tome-01-herge-chronologie-dune-o...

[5] Okay, yeah, this kinda turned into a Public Domain rant, sorry? :)

(To bring it back to the topic at hand: "Hey, can't wait until this Pebble OS code enters the Public Domain in the year `2024 + YYY`." :) )

> There was a great little site that let you use a visual UI to build the file

Was the site you used "Watchface Generator" (.de -- domain was poached at some point) : https://developer.rebble.io/developer.pebble.com/community/t...

I seem to recall there were a couple of graphic + watch-face only generator sites but think the .de hosted one was most common?

Of particular note in the current context:

There was also the ground-breaking "CloudPebble IDE" by Katharine Berry (subsequently employed by Pebble), who "coincidentally" :) happens to be one of the three authors of the Google blog post about the Pebble OS release: https://opensource.googleblog.com/2025/01/see-code-that-powe...

(And who is apparently also part of the Rebble team.)

For anyone interested here's a couple of related links I encountered while trying to recall what CloudPebble was called :) :

* Write-up of a person's experience of using CloudPebble to write their first Pebble watch face (with no previous C or Linux experience): https://thomasstoeckert.us/project/pebble-sse-classic

* Write-up about Rebble project by iFixIt in 2019: https://www.ifixit.com/News/33398/rebble-with-a-cause-how-pe...

* Source code for CloudPebble: https://github.com/pebble/cloudpebble

The Allen Key (a.k.a Hex Key) stored within the device itself is (marketing) genius--that to my surprise doesn't seem to feature very prominently in their marketing... :D

(Perhaps because the audience to which such a thing seems to be marketing genius isn't their current desired target? :) )

From my perspective the interior Allen Key: immediately acts as a point of uniqueness; communicates something very specific about the product; and, potentially, serves to calibrate potential customer expectations.

(Exactly what the "very specific" thing communicated is, is obviously open to interpretation: it could be "the enclosed Allen Key means this device requires tinkering"; or, alternatively, "the enclosed Allen Key means I don't have to tinker with this device but that is an option available to me".)

The Comet is the most interesting thing I've seen come out of CES this week.

I'd heard of neither the product nor the company before I watched these videos (in this order):

* "Mecha Comet Linux Handheld (CES 2025)" (~5 min): https://www.youtube-nocookie.com/embed/89pAwl55HJw

* "Mecha Comet Modular Linux Handheld at #ces2025, NXP i.MX8, NVMe, Debian, Open Source Extensions, GPU" (~12 min): https://www.youtube-nocookie.com/embed/DB-0H8Q4d1U

* "Mecha Comet Teaser" (~1 min): https://www.youtube-nocookie.com/embed/AGHmvOFkUKw

In the first two videos the company founder does a really good job of demonstrating/explaining device features, describing some of the context for the product; and, the motivation behind particular implementation details (e.g. using an NXP processor due to an absence of NDA requirements & their reputation for upstreaming Linux kernel patches).

On the software side, they are using Rust for development of various elements of the device OS/GUI (a detail that might be of interest to some people) including a toolkit for Wayland clients (a detail that might be of interest to some other people :) ). (And they appear to be doing a significant amount of software development "in the open", based on a brief look at the level of activity in various repos/branches.)

However, particularly while watching the first video there was a nagging feeling of "Hmmm, does this all sound a bit too good to be true?" (partly for specific reasons e.g. an impending Kickstarter campaign launch; and, partly just from a general sense of "there's always some reason why we can't have nice things" :) ).

The founder did specify that (as I understand it) they aren't dependent on the Kickstarter for funding of manufacturing; and, that part of the reason the KS campaign wouldn't launch for couple of months was that they wanted to minimise the time between people's support & receipt of their campaign "reward" device.

(Obviously have to take the founder's word on that; and, also, plans don't always go according to... plan.)

Perhaps, amusingly, after spending some time exploring the Mecha web site & source repos, discovering development had been underway for around three years, and, getting a bit more insight into what the company's overall plan seemed to be, I started to wonder "Is this starting to seem too slick? How has this been funded so far & what is the monetization plan going forward?". :D

On the positive side--from a company financial sustainability point of view--it seems The Comet isn't a one-off "pie in the sky tinkering toy for Linux nerds" (nonpejorative :) ) but more of a combination proving-ground/audience-attractor/development-kit for a series of more industrial/enterprise-focused boards & services that serve as a platform for people/companies building custom sensor-orientated device solutions.

On the potentially negative side--from a "is some big company going to acquire Mecha and take away our toy" point of view--well, the same information is also true. :)

However, assuming that Mecha delivers on its stated intent around Open Source (which seems like it might be off to a reasonable start based on a brief look at its current repos), before any such acquisition might happen then such an eventuality would be "unfortunate" but not an immediate death knell for existing units in people's hands.

Having said all that:

The Comet definitely seems like an intriguing device with interesting potential but--given the many sagas of the many devices from the many companies that have come before it--I think it would be beneficial for the company to share more about the business context and overall roadmap to help potential supporters be more informed.

And, of course, it would be wise for potential supporters to exercise a degree of caution consummate to their ability to absorb the impact of their cash or device being "flushed down the toilet", as it were. :)

(Disclosure: While I am very much interested in embedded Linux devices like this I am not likely to purchase The Comet any time soon due to a lack of disposable income.)

I wonder how this page might look if people could only comment in support of policies that wouldn't lead to a direct personal financial benefit.

(Disclosure: In such a situation I would be unable to post this comment--as, in our just world, this comment's insightfulness would undoubtedly lead to me being the beneficiary of significant financial remuneration.)

> Is it even feasible to provide gnu binaries?

It depends on one's definition of "feasible", I guess.

Building against the "most recent glibc pushed by GitHub" doesn't make it feasible but building against an older glibc (which you can still do on a container which is otherwise using a recent glibc) is at least somewhat feasible.

The primary benefit from building against musl is that it "coincidentally" means that even the people who don't care at all about supporting older systems end up doing so "accidentally" due to their desire to use musl (for, presumably, some other reason).

Indeed, maybe musl will finally be the long-term compatible Linux native binary format to one day replace win64+wine.

glibc compatibility breakage is the bane of my existence.

The situation is made worse by GitHub pushing people to build against the default extremely recent glibc in "ubuntu-latest" for binary artifact builds rather than what should be done: building against the oldest glibc possible (you can still do that within a "ubuntu-latest" container).

glibc breaks "version compatibility" at times for the most IMO ridiculous reasons but also has support for running binaries linked against older glibc versions on newer glibc that just gets completely ignored.

Based on my understanding/recollection of `expect`, the concept is that you're scripting a command/process (or command sequence) via a "terminal connection" (or basic stdin/stdout), based on the (either complete or partial) "expected" dialogue response.

e.g.

1. make initial connect over ssh (e.g. spawn ssh cli process) 2. expect "login: " response 3. send "admin" 4. expect "password: " response 5. send "password" 6. expect "$ " 7. send "whoami\n" 8. etc etc

I guess that might in theory be possible to script a TUI with but I suspect it'd get pretty convoluted over an extended period of time.

(BTW I mentioned this in a comment elsewhere in this thread but check out https://crates.io/crates/termwiz to avoid re-inventing the wheel for a bunch of terminal-related functionality.)

FWIW WezTerm does seem to split much of its "generic terminal" functionality into separate published re-usable crates:

* https://lib.rs/gh/wez/wezterm/wezterm / https://crates.io/crates/termwiz

(Projects that build on this crate includes "ratatui" among others...)

In particular, I note at least these specific feature areas:

* "support functions for applications interested in either displaying data to a terminal or in building a terminal emulator": https://lib.rs/crates/termwiz

* "to help with parsing input received from a terminal": https://docs.rs/termwiz/latest/termwiz/input/index.html

* "Model a cell in the terminal display": https://docs.rs/termwiz/latest/termwiz/cell/index.html

* "parse escape sequences and attach semantic meaning": https://docs.rs/termwiz/latest/termwiz/escape/index.html

* "abstraction over a terminal device": https://docs.rs/termwiz/latest/termwiz/terminal/index.html

* https://docs.rs/termwiz/latest/termwiz/color/index.html

* "cross platform API for working with the psuedo terminal (pty) interfaces": https://lib.rs/crates/portable-pty

* "Low level escape sequence parser": https://lib.rs/crates/vtparse

So, seems like quite a lot there to help avoid re-inventing the wheel for terminal-related functionality (for andyk/ku1ik & others).

> column mode in MacOS's finder

FWIW these are known as "Miller columns" if anyone wants to research the topic further: https://en.wikipedia.org/wiki/Miller_columns

> You get down to where you're working at the syllable level - noticing, for instance, that moving on this word, rather than that one changes the whole dynamic of the scene.

That's an interesting perspective on performance for me as it parallels one of the aspects I enjoyed about performing stand-up comedy regularly for a time (primarily at open mics): getting to observe/analyse/theorize what contributed to whether a particular "bit" "worked" or not--both for myself and others.

For my own performances, I could choose a different word, phrasing, tempo etc and see how/if that affected audience response.

Equally, learning from observing the impact of when other performers did the same, refining their set over multiple weeks.

And, then, also seeing how other factors we had less control over (you know, such as the audience :) ) had an impact: sometimes same line, same delivery, might kill one week but got crickets the next.

Granted, my approach to comedy might lean a little more... analytical than some. :D

> but Christians largely believe that God will supernaturally preserve the Bible no matter what

You know, until you put it in this context, it hadn't occurred to me how--from some perspectives--"convenient" that is. :)

Fortunately memorization isn't a requirement for stand-up or my stint performing it might've ended up even shorter than it already was. :D

Like general public-speaking, approaches used by individuals to prepare/perform stand-up do seem to vary based on personal preference/comfort/style.

(In a similar way I wasn't a fan of/good at "rote memorization" in my academic life either.)

Well, that seems intriguingly topical in the current era of LLMs & occurrences of their verbatim reproduction of training data... :)

Perhaps it's not mindless reproduction of the training data, rather, entirely mindful reproduction... :D

The Wikipedia page notes:

"Pierre Menard is often used to raise questions and discussion about the nature of authorship, appropriation, and interpretation."

The following remark in the article reminded me of one of the points raised in a video[0] on the "Answer in Progress" YouTube channel:

"Deep understanding involves focusing your attention on the underlying meaning of an item or event, and each of us can use this strategy to enhance everyday retention."

The AIP video is motivated by Sabrina's (video creator/presenter) frustration around having a memory that "sucks":

"I can't remember a lot of the things I have done. I can't remember a lot of the things I'm supposed to do..."

One of the points raised in the video was:

"The most important thing for memory when an event is happening is to pay attention to it."

Which seems to be consistent with the view expressed in the article.

If memory is a topic of interest to you, you might find the AIP video a worthwhile watch:

After investigating memory related research and conversations with people who have memorization related experience (both theoretical and practical) an attempt to memorise & recite 3,141 digits of pi in front of a theatre audience is made...

(And, even if it's not a topic of interest, Sabrina's approach to both research[1] and presentation generally makes the result both informative and entertaining.)

---- footnotes ----

[0] "i memorized 3,141 digits of pi to prove a point": https://www.youtube.com/embed/KAjkicwrD4I

[1] As a university graduate with a focus in math, economics, & statistics, who often develops software tools during video creation process.