Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google open-sources the Pebble OS

opensource.googleblog.com

Post reply on HN
Print view View original

191–200 of 216 posts

Re: Google open-sources the Pebble OS

#191

Post by JohnKemeny »

JumpCrisscross wrote: post #173
JohnKemeny wrote: post #168

Earlier quoted context omitted.

This is not exactly what is meant by Commoditise your complements. "Commoditise your complements" in this setting would mean making watch OSs free for everyone in order to make demand for watches go up.

> This is not exactly what is meant by Commoditise your complements 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?

You have predatory pricing, which is illegal.

According to Wikipedia:

> Predatory pricing is a commercial pricing strategy which involves the use of large scale undercutting to eliminate competition.

Re: Google open-sources the Pebble OS

#192

Post by raxxor »

elevatedastalt wrote: post #84

People passing cynical comments at Google need to understand that at a big co like Google, something like this doesn't 'just happen'. It probably happened because some passionate L6/L7 engineer wanted to do it and pushed through the bureaucracy to get approvals for it, probably largely on their own time (by which I mean that this was at best a side-project for them and at worst a distraction that was losing them favo…

Which is ironic because Google needs to improve their reputation about sunsetting early. This is one of the main arguments for why many businesses for why they do not employ their alternatives

Re: Google open-sources the Pebble OS

#193

Post by aryonoco »

v9v wrote: post #179
jsheard wrote: post #6

They've open sourced what they can, but these third party bits had to be stripped out: - 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

I remember reading that the Bluetooth stack was one of the main differentiators for Pebble at the time due to its reliability, shame it's not included here.

In 2014, that certainly was true. Every open source Bluetooth stack (i.e., Android, Linux and FreeBSD) was buggy and unreliable. Since then they rewrote the Bluetooth stack in Android twice, and finally what's in AOSP is quite comprehensive and reliable. It's now been merged into ChromeOS as well.

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.

Re: Google open-sources the Pebble OS

#194

Post by drzaiusx11 »

adastra22 wrote: post #147
xeromal wrote: post #138

Earlier quoted context omitted.

Being cynical is almost a default of the internet and I think it squanders a lot of hope. It's better not to be cynical

It is better to be less cynical than your average redditor or HN denizen, but not entirely uncynical.

I'm going to call the above rule, "Goldilocks Cynicism." Words to live by.

Re: Google open-sources the Pebble OS

#197

Post by follower »

will0 wrote: post #105
whalesalad wrote: post #16

Are there any applications that are also open sourced? They mention snowy but it is giving a 404: https://github.com/pebble-dev/snowy

Try that URL again :)

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`." :) )

Re: Google open-sources the Pebble OS

#198

Post by [deleted] »

elevatedastalt wrote: post #84

People passing cynical comments at Google need to understand that at a big co like Google, something like this doesn't 'just happen'. It probably happened because some passionate L6/L7 engineer wanted to do it and pushed through the bureaucracy to get approvals for it, probably largely on their own time (by which I mean that this was at best a side-project for them and at worst a distraction that was losing them favo…

[deleted]

Re: Google open-sources the Pebble OS

#200

Post by follower »

pyuser583 wrote: post #90

How much work is being done in the RTOS space? I would think a lot, but then I hear programmers complain it’s not worth it. Are RTOSs still the future?

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. :)

Post reply on HN