I really like that this article explained the title thesis in the first 4 paragraphs. At that point you can decide if you agree or if your want to read on. No unnecessary fluff baiting the reader to read the whole thing in order to find out what are the two kinds of users. More writing like this.
I like how you packed only the necessities - tiles for maps, routing, and geocoding index in in sqlite. I checked the monaco deployment and missed lookup with street number, as someone else also pointed out.
Why not create a "builder" repo, where people could generate their own local datasets by a bounding box?
Yeah, house-number lookup is not there yet. The demo geocoder does place/street-level search + reverse, but house numbers need a richer address index - it's on the roadmap.
Re: a bbox "builder" repo - it's an interesting idea. I could see it going two ways: (a) you want to run a bbox builder yourself, or (b) you want a simple way to specify a bbox so the dataset pack can be produced for you.
I started with the "ship a known-good pack" approach because the build pipeline is the messy part, and I want deployed boxes to stay simple/reproducible.
For your use case, which did you mean - run the build locally, or "draw/paste a bbox and get back a ready-to-run pack"? And would bbox be OK, or do you prefer admin boundaries (country/state/city)?
I would prefer to run the build locally/myself, and to specify either a bounding box with lon and lat, or a country. The output would be data files and/or docker images with data. But as sibling comment said, if you plan to sell it, I understand it makes less sense to offer building logic.
I get why you created the monaco pack, it's a nice demo and fast to download and run. I would rather choose a big city where potential users live (london, nyc, the bay,?), but maybe there are technicalities that make that more complex.
Drawing box on a map in browser and generating the tiles, routing and geocoding db sounds quite heavy for backend compute. There was a project wiht a website that could generate a tileset (pmtiles file?) from box drawn on a map, but I can't find it now. There was a limit to the box size and if it was over some threshold, you had to have premium, or contact sales, or sth, I thought it was protomaps, but no tool like that there now.
Anyway really nice idea, I will follow your progress for sure!
Bounding box input is a really interesting idea. For my product, the best use would probably be to automate the request/fulfillment flow if this ever picks up. Letting someone draw/paste a bbox makes the request unambiguous and could be automated end-to-end.
Btw, the pack build process isn’t that compute-heavy. It’s not instant, but as a rough data point: on my laptop, a small country like Austria/Slovakia is on the order of ~1 hour to build the three artifacts (tiles + routing tiles + SQLite geocoder).
Yes - I do plan to sell Corviont, and it is worth explaining the licensing bit.
It is built on open-source components and OSM-derived data, so the obligations are mostly (a) keeping third-party software licensing/attribution intact, and (b) OSM/ODbL compliance - clear attribution, and if you distribute derived OSM databases, meeting the ODbL share-alike requirements for those database artifacts.
I am handling this via attribution in the UI/docs and a licensing reference bundled with the dataset that points to a public licensing/attribution repo containing the third-party license texts and details: http://github.com/corviont/licensing
What I am selling is the packaging + ops side: ready-to-run region packs and (eventually) a signed updater for fleets.
When I read your first comment, I immediately thought that the audiobooks are voiced by AI. I'm really surprised to learn the opposite.
So you take existing recordings created before 1929 and remaster them? Are recordings (of books published pre-1929) which were created after 1929 in public domain too?
I don't even want to ask about producing and voice actors.. Really nice idea and realization!
There's a really awesome site called Librivox [1], where volunteers narrate books that are in the public domain. Those recordings are also in the public domain as well (this is just part of the Librivox thing). The quality of those recordings (both the narration, and the actual recording quality) varies quite a bit and most of them aren't at a quality I'd expect people to pay for and thus aren't useable for me. I've spent hours and hours sorting through those recordings finding the best ones (from a narration perspective) and then improving the recording/audio quality on them. Those recordings have all mostly been made in the last 20yrs, so they're not old recordings of the books. So, the value I add to the Librivox recordings are: curation/selection, audio enhancement, and a much better delivery mechanism (IMHO).
I'm also simultaneously building out our own library of original audio content by working with voice actors to get them recorded and proof read (this is a very expensive and time consuming process, but also very fun). One of the hardest parts is honestly the proofing process. Once I get finished narration files I have to compare them result with the actual script (as there are always mistakes) and request edits. I use whisper.cpp to transcribe them and then git and a few other scripts to compare the transcript with the actual book text.
I'll also add that I _do not_ use AI Audio narration because it just doesn't sound good IMHO, and I personally hate listening to it. I regularly run experiments to see what the current state of the tech is and it's still pretty far from where it needs to be IMO. I also don't love the idea of AI swallowing absolutely everything.
True, although i do think its likely that its not top of mind. When things aren't relatable, its hard to take them into account in everyday life, even when you're factually aware of it.
This will be really handy for dream journaling. When you just woke up and know that you'll forget the dream as soon as you open your eyes, you can click the ring and record.
I read the drama last week, and after seeing this, I have to side with Rebble. I think they kept the community alive since Eric M cashed out and Fitbit shut it down. As the stars have aligned in recent years, Eric revives Pebble, but if Rebble wouldn't spend all the effort maintaining the app store, his consumer base would be much smaller and it would be much harder to bootstrap again.
With Repebble (Core Devices) and their new appstore (or/and apt-style repository system), Rebble seems obsolete, it's a bit sad. They deserve credit which they won't be able to claim anymore. They should be rewarded somehow for bridging the dark age, otherwise it seems they served purpose all until Eric returned and said "Thank You and fuck off".
Also, to me, Eric talking doesn't sound authentic, and I wouldn't be surprised if he's lying. I don't mean to insult though, mad respect for putting project like Pebble together.
Hope that there's some place and purpose for Rebble in the future.
I'm surprised by this comment; after the drama last week and after seeing this I fully have to side against Rebble.
The nature of driving a healthy open source centered ecosystem is that you don't control it under your iron fist: you make good contributions, users _and_ companies are able to use them in all new ways which comply with the licensing terms. And it seems that RePebble is going way beyond the licensing terms requirements, but bending over backwards to honor Rebble here when they aren't actually required to.
I just can't imagine what people want from RePebble if not this: they are being maximally open, making it so all of everything would be able to continue if they went out of business tomorrow, while also actively enabling people to continue using Rebble's store and paid offerings. Should they be forcing users to use Rebble's offerings (instead of making things even more open) as a reward for doing a good job bridging the dark age?
My impression is that there is a lot more going on than just the facts provided by both sides. Core technologies managed to get Katie Berry to step away from the project[1] and that's extremely significant to me. Her tireless dedication to keeping Pebble alive (and get it open sourced) is how any of this is possible. For her to just up and leave now tells me that Eric and Core are not being as magnanimous and friendly to community as these blogs posts and actions might suggest.
Both of those comments seem to just boil down to "Core probably could be more proactive about comms", which hardly seems like a particularly egregious sin.
"interactions with Core have gone so poorly that they were adversely impacting my mental health"
That seems a little more serious than "could be proactive about comms" especially when this is one of the key people responsible for a lot of the original Pebble tech, rebble tech, and working within Google to get the Pebble OS open sourced.
I think unfortunately this is a normal thing that happens: passionate people get very attached to something and have trouble dealing with dispute even when everyone is relatively good intentioned. I've seen it in the workplace a dozen times.
They also backed down from their ludicrous position that they are acting as protectors of other people's watchfaces being downloaded in bulk by a particular company they don't like, whereas they are totally fine with the watchfaces being publicly available for general use. It clearly reads as them trying to clutch control of the one thing they haven't open sourced.
Rebble contributors did have a legitimate gripe, which is that they were lead to develop some additional software under the idea that there would be an agreement at the end of the day. But the Rebble Foundation's response to this was totally immature and irrational.
I agree with what Eric said in his follow up, which is that it is quite concerning to engage in a partnership with an organization which reacts like this as part of a negotiation process. God knows I wouldn't, and it doesn;t surprise me that an alternative solution was found.
Well said and exactly my thoughts on it as well. Eric has done more than he really had to, and it is unclear to me what rebble really wants/is positioning for.
You are not really factoring in all the work on the hardware, much of the software, and the entirety of the financing, which is being done by Eric and the Core Devices team.
If Rebble wants to take the risk and put out a smartwatch, there is nothing stopping them. Infact all of the open sourcing work Core Devices has done gives them a good starting point.
He gave them a deal that would directly send cash their way, which he didn't have to do at all. The vast majority of founders wouldn't have touched that with a 10 foot pole.
> They deserve credit which they won't be able to claim anymore.
Why won't they be able to claim credit for the work that they did the past because of other people's work in the present?
> Also, to me, Eric talking doesn't sound authentic, and I wouldn't be surprised if he's lying. I don't mean to insult though, mad respect for putting project like Pebble together.
What the heck are you trying to do here if not insult him? It seems wild to say he sounds inauthentic and you think he's potentially lying, and then try to hedge by saying that's not intended as an insult.
Yes! I really like the idea of podman, but after 4 hours trying to make it work on 24.04, I reverted to Docker and compose.
There is some dissonance in presenting Podman as a plug-in replacement for Docker, and making it so damn hard to install on (some category's) most popular contemporary LTS Linux distro.
