Google open-sources the Pebble OS(opensource.googleblog.com) |
Google open-sources the Pebble OS(opensource.googleblog.com) |
But what can you do with this?
They did it because they felt it was the right thing to do. Good things happen through the actions of individuals like this. We should acknowledge and celebrate it when they do, anti-big-tech cynicism can wait.
Something like this would be bizarrely easy if you had the ear of the right person. (i.e. someone who would tell legal etc. "you gotta do it" when asked)
Reason why is, it's a feel-good thing that aligns well with Old Google values, and Google's not yet old enough for "Why bother doing anything at all?" to be an acceptable vocalized response.
It has standard, if not worse, dysfunction with internal conflict at this point. But there just isn't room to come up with a good reason to not open-source the decade-old OS.
Commoditise your complements.
Injecting competition into the watch market reduces the chances one of the majors, e.g. Apple or Altman, runs away with the wearables sector if it takes off again in respect of AI.
For all the sins that Google commits, they're generally decent about the whole open source community. There's things they rely on they should be providing funding for, certainly. But they're good about letting their people contribute, and often good about opening things up to the outside world.
Of course this project is bigger and more complicated, and clearly had tendrils into a lot of other things, so...
----
> 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
----
May be the whole design and development process from the start should be everything they do could one day be open sourced. So be aware what you do and what you comment.
Pebble, on the other hand, was built fully outside Google and only ended up there via a circuitous route (the Fitbit acquisition), so this is not a concern.
(That said, I offer my gratitude for the perseverance it took to get this done)
What do we do with this POS?
"Commoditise your complements" in this setting would mean making watch OSs free for everyone in order to make demand for watches go up.
You're right. The strict interpretation would be the more people who wear smartwatches, the wider Google's surveillance net.
Is there a commercial strategic term for denying your adversaries oxygen?
There's Microsoft's Embrace, extend, and extinguish https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...
According to Wikipedia:
> Predatory pricing is a commercial pricing strategy which involves the use of large scale undercutting to eliminate competition.
Source code like this doesn’t just have no value for Google. It has negative value. It’s a massive liability.
That’s why big cos simply bury source code instead of releasing it in the open.
Converting a zero-value IP into low impact positive PR has business value. Making MS-DOS sources public falls in the same bucket.
“PebbleOS took dozens of engineers working over 4 years to build, alongside our fantastic product and QA teams. Reproducing that for new hardware would take a long time.” [0]
The lackluster value and sales of Google hardware is no master plan, it's a simple incompetency.
You do not need revenue to be liable though.
The plaintiff would have to show actual financial loss due to the infringement. In the case of the pebble assets, that seems exceedingly unlikely.
Generously assume for the sake of argument that the entire codebase is a straight up copy of Samsung and Apple’s IP. What damages have been caused by that IP sitting dormant on Google’s hard drives for the past six years?
... nope. Not even in the US, where "3 years" as you claim is from the possible discovery date, not the infrigment date (https://www.michaelbest.com/Newsroom/340003/US-Supreme-Court...), and this would probably only accrue when the source code is released (as it can be argued that it would be difficult to see a more subtle copyright infrigment on object code).
Also statutory damages exists, so even for no revenue there is a reasonable possibility that they will be sued for that alone (similar to how game and music piracy lawsuits work).
> and 6 years for patents
Other jurisdictions like Germany (no limits) exists.
I wrote a blog post about our plans to bring Pebble back, sustainably. https://ericmigi.com/blog/why-were-bringing-pebble-back
We got our original start on HN (https://news.ycombinator.com/item?id=3827868), it's a pleasure to be back.
If you're interested in getting a new Pebble, check out https://rePebble.com
We're bringing Pebble back - https://news.ycombinator.com/item?id=42845091 - Jan 2025 (1 comment)
The future of Rebble - https://news.ycombinator.com/item?id=42845017 - Jan 2025 (3 comments)
I actually held off from buying a Pebble back in the day because the software wasn't open source and I was worried about getting dependent on a product I had no control over. (Yes, I see the vicious Tragedy of the Commons wrapped up there, but still gotta make the optimal choice for me). I'm beyond stoked to see this movement! And it being open source, I have no such qualms. If they are affordable enough, I'll probably be gifting these out on the regular so expect to sell at least a dozen or two :-D
I still have my time round in a drawer somewhere. I moved to a galaxy watch, which is great for being able to play Spotify offline, GPS etc, but like all modern smart watches is terrible for bloat and a screen that's responsible for like 70% of the power draw.
It's really disheartening that the average consumer only sees the shiny oled and slick animations and doesn't think at all about the inconvenience of charging at least once a day...
But. Isn’t most of the value of a codebase like this not the code itself, but all the knowledge of the people who worked on it day to day? Where are they?
It’s really intriguing. People who have a lot of goodwill towards Pebble BELIEVE the source code is valuable. That doesn’t mean that it is.
Credit where it's due
- All of the system fonts
- The Bluetooth stack, except for a stub that will function in an emulator
- The STM peripheral library
- The voice codec
- ARM CMSIS
- For the Pebble 2 HR, the heart rate monitor driver
This really does help mitigate the damage done by "Killed by Google" and people are genuinely grateful (personally in my case).
But even better would be to fix the dysfunctional internal dynamics that cause this syndrome in what appears to be disproportionally more frequently compared to other corporations.
And who knows, maybe we could even see new smartwatches running a derivative of the Pebble OS at some point? The old hardware's great but since they're not being made anymore it's only a matter of time before they break down.
Props to Google on this.
Google states: "" This is for information only.""
""This is the latest version of the internal repository from Pebble Technology providing the software to run on Pebble watches. Proprietary source code has been removed from this repository and it will not compile as-is""
I love my transflective MIP Garmin Fenix watch, but it's not nearly as high-contrast as my wife's Kindle, which uses a reflective MIP e-paper display.
I would be an ideal candidate for a rePebble if I were not as happy as I am with my Garmin - though with their recent changes to inReach plans, crazy prices and lackluster features on the Fenix 8, and trend towards AMOLED displays (away from their roots, chasing the Apple watch market) they're not looking as amazing as they once did.
Some commenters mentioned that the e-ink screen (and the accompanying battery life) was one reason why the Pebble is so beloved, which reminded me of the Basis Peak, which was primarily a health tracker watch with some (very limited) smart functionality (mostly just some notifications, if I recall), that also had an e-ink screen and a nearly 1 week battery life and had a sort of similar trajectory:
Bought by Intel, then killed two years later after a battery related recall issue.
It was, in my opinion, by far the best fitness tracker watch ever, and remains so to this day. Not so much because of it's actual features (which were relatively standard), but the software paradigm of simple yet effective exercise gamification that helped encourage exercise habit formation. 8 years later and I still miss it.
From what I googled, this is just for stack allocation in gcc. Does that mean Pebble only has stack allocation?
I'm also seeing references to rtos as the true underlying os though.
https://github.com/google/pebble/blob/main/src/fw/kernel/pbl...
Which calls heap malloc:
https://github.com/google/pebble/blob/main/src/libutil/heap....
It's a delightful bit of kit that was sadly abandoned by owner and it's nice that they are open-sourcing a dead product instead of just leaving it to rot like so many other electronics are.
One motivated person at a decently high enough level can get it pushed through, as long as whoever the person making the decision asks about it says, 'eh, ok.'
I'm back to a "classic" analog watch as I realized I don't really want notifications. But I might buy a smart watch (probably Apple watch at this point since I have a bunch of iOS hardware) for the health features (HR, EKG, etc.)
"" Proprietary source code has been removed from this repository and it will not compile as-is. This is for information only. ""
Well done.
Are RTOSs still the future?
1) PREEMPT_RT recently brought realtime capability to mainline Linux[0].
2) Amazon open sourced the safety-certified ThreadX[1].
I guess you can freeze some compiler options to give you consistent results.
I've once optimized a function to be faster, and in a unit test asserted that the old slower version gives exactly the same floating point answer as the new optimized version. It's doable in some cases.
All of the system fonts
Presumably the source included the TTF files from which the rasterized bitmap resources were automatically generated. Including the pre-rasterized bitmaps extracted from a previous release should not be a problem as typefaces and bitmap fonts are not subject to copyright in the US, vs vector font files which are eligible for copyright as computer programs. The Bluetooth stack, except for a stub that will function in an emulator
This seems unfortunate, and looks to be one of the most critical gaps in the source release. The STM peripheral library
You can get this from ST no problem, although it is only licensed for use on STM devices. The voice codec
It should be feasible enough to replace this. ARM CMSIS
The old versions with non-free licenses are still available from ARM or ST, and the recent versions are Apache licensed (but some porting of code might be required to use to newer versions). For the Pebble 2 HR, the heart rate monitor driver
This was probably based on sample code from the vendor which could be replaced.It's worth noting that CMSIS itself is open source but some of the drivers for this hardware probably were not.
I feel like it's the same about many of the items mentioned above, the free/libre offering in that space are a lot more polished than was the case 9-10 years ago. Back then the audio codec was still a patent encumbered minefield, now you can just use opus. The quality and diversity of free fonts is ordered of magnitudes above what it was 10 years ago.
In short, it should be much easier for Eric to fill those gaps with free/open offerings than it was 10 years ago.
The solution is simple - don't hop on Google's new products (there's a risk with the older ones as well, albeit smaller). It's just not worth it to invest your money and time with such a significant risk of it getting killed (and its general half-assedness). There are usually alternatives.
The rules of reality are written the moment you click "agree" on the EULA. Like the other comment says; the only way to win is to refuse buying things you don't own. Otherwise you're just a sucker who has a hard time living down their mistakes.
RIP Google Wave... I had such high hopes when it was first released... :'(
Everyone kills software products. The problem is our attitude of entitlement towards things we sign an EULA to use. You "own" TikTok on the App Store? Pssh, please. You don't even own the software runtime you use TikTok with.
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`." :) )
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. :)
Then had an Asus ZenWatch 3. WatchOS was frustrating at the time over the ability to customise what notifications would actually get to the watch, and the battery life of the device was terrible, getting worse over the space of a couple of years. Even had some reliability issues with the messages actually reaching the watch at all.
Wanting to go back to e-ink displays and longer battery life, I've got a Amazfit Blip, who's software was just awful. Even "simple" things like sleep tracking wouldn't work properly, dying out or flat out not being accessible from "Sleep for Android", heart rate monitoring wouldn't sync reliably to anything, notifications would just randomly stop working. It also had no ability to disable certain apps from sending notifications to the watch, even if the notifications are set to silent on the phone.
There was an open source app that I used to have to use alongside their own app that was necessary to actually fix everything wrong with the original software and make the device work with anything approaching reliability.
The recent overhaul of their own app (seems like a ground up rewrite to me) has actually fixed most of the issues that I've had with it. It still occasionally just craps out and requires me to turn the whole bluetooth stack off and on again.
- Always on. Garmin has option to do that as well but it reduce the battery life to like 3 days. In outdoor my Pebble Time is very bright with zero backlight.
- 5 days battery. I went on a trip to Japan without its proprietary charger, by the time I board my flight back it was on power save mode and it died the moment the plane landed. Garmin could do this if you set it to power saving mode, but the Pebble is in standard mode. One could argue that the Garmin do have more stuff like health monitoring that Pebble didn't.
- Cheap and no frills. I want a second screen for my phone, not a health tracker. Originally my Pebble Time shipped with zero fitness features, and it later added a step counter once it's clear that the market direction go that way.
- Garmin is quite thick, Pebble Time is thinner
- The UI is simple - press up for past event, down for future event (calendar). Press the middle button for menu. Hold are configurable. Garmin has 4 main menus which are very confusing (fitness menu, shortcut menu, apps menu, system menu).
- Lots of free apps and watch faces which I actually used (like a music app that show album art). I don't see any apps I would want to use on the Garmin, and they're mostly paid. The "hide in a hole while ceiling crush the map" game on Pebble was really well done. Now my Garmin use the simple time in Verdana watch face because I cba to find a decent one.
- Even with low framerates, Pebble managed to deliver cute little animations. Replying to message show a flying paper plane, screen transitions have suitable animations (not generic ones like Android), and the best one is muting an apps show a Ostrich putting its head under the ground. The animation also hides how slow the hardware actually is, with later OS versions stalling over a second or two after a second long animation.
- I think the phone app UI is not as good as say, Apple Watch, but it focus on apps and the store without the fitness features. Garmin's app is entirely about fitness and they hide smartwatch stuff in a menu plus another separate Connect IQ app.
Overall the PebbleOS feel like a really solid and polished product than any smartwatch today. It do fewer things than most smartwatches, but that's all I care about and everything it does is very polished.
[0] https://www.kickstarter.com/projects/getpebble/pebble-e-pape...
Unfortunately mine got stolen and broken, which is a shame. I wonder how hard they are to buy today, and how difficult battery replacements for them are…
Memory in pixel means that each pixel remembers its current state, saving on a lot of power budget because the bus/LCD controller is completely shut down, it essentially only uses power to update the display. Versus a traditional LCD or oled where you need to send it data at x refresh rate continously, meaning the high power draw bus and controller are constantly slurping power.
Even though eink has gotten better I still wouldn't use it for something like this, the refresh rate is still a tad too slow, the controllers are always proprietary weirdness with crazy voltage waveform magic to clear the display properly, resulting in that ugly multiple flashing that most eink/epaper displays do.
I got a Xperia XZ2 compact in 2018, and used it daily util a month ago. It made it through a day of regular use until the very end, when I had to retire it because of issues with software updates.
Modern-ish Li-Ion batteries can take thousands of full cycles.