Yes, but I think maybe people in this thread are painting it unfairly? Another way to frame it is that they used industry best practices and their intuition to develop the game, then revisited their decisions to see if they still made sense. When they didn't, they updated the game. It's normal for any product to be imperfect on initial release. It's part of actually getting to market.
To be clear, I don't think it's a huge sin. It's the kind of mistake all of us make from time to time. And it got corrected, so all's well that ends well.
I’m a Zig outsider. I gathered the context from reading the conversation around it, most of it posted to HN. Which is why I also pointed out I may have incomplete information.
If one looks past the immediate surface, which is a prerequisite to form an informed opinion, Zigbook is the one who clearly looks bad. The website is no longer up, even, now showing a DMCA notice.
The way these sorts of things look to outsiders depends on the set of facts that are presented to those outsiders.
Choosing to focus on the existence of drama and bullying without delving into the underlying reason why there was such a negative reaction in the first place is kind of part and parcel to that.
At best it's the removal of context necessary to understand the dynamics at play, at worst it's a lie of omission.
The primary challenge I see is that at least in the US, government positions are often elected and termed, meaning there is no guarantee your cash flow from your government job will continue long-term. This is why you must continue to operate as a private citizen, with a government job.
The second potential issue is one of pay - the best of society can make far more in a commercial setting than in a government setting - barring corruption, of course.
For your second potential issue, I’m saying that’s the point. Nobody becomes a priest for money.
These people who become priests do so for other reasons and they largely want to exit the commercial economy. That’s the type of people government should be made of. Under this system pretty much 100 percent of politicians wouldn’t have even become a politician.
Since we are talking about political leadership at the highest levels (not pastoral local municipalities), a good comparison with priesthood would be the Vatican. Even in priesthood, when there is concentrated power over vulnerable populations, we can find: wealth hoarding, money laundering, collaboration with organized crime, and protection of rampant sexual abuse. For hundreds of years. This suggests to me that the issue is hierarchy more than it is quality of those who reign over us.
Here's my hot take: politicians should be paid a lot of money, and in return they should be subject to limits on how they can invest, if they can invest at all. Remove the incentives that cause corruption and attract talent. I think it's a bit naive to say that public servants need to be earning a meager salary. Underpaid people don't stay in their roles very long.
The first point is true of most employment, unless you're one of the ~10% of US employees with a union contract. Your paycheck is always subject to the whims of your employer.
I don't have a great solution for the 2nd issue you pose though. Raising the pay of elected officials is often politically unpopular, but you're certainly right that one makes more in the private sector than as a junior congressperson.
Yes and no - if you lose your job at Apple, you can go down the street to Microsoft. If you lose your elected government job, you can't run again for years. Meaning, you have to switch from being a government employee back to being a commercial employee.
A lot of them actually. Ceph personally I've used. But there's a ton, some open source, some paid. Backblaze has a product Buckets or something. Dell powerscale. Cloudian has one. Nutanix has one.
Ceph is awesome for software defined storage where you have multiple storage nodes and multiple storage devices on each. It's way too heavy and resource intensive for a single machine with loopback devices.
Ceph has multiple daemons that would need to be running: monitor, manager, OSD (1 per storage device), and RADOS Gateway (RGW). If you only had a single storage device it would still be 4 daemons.
systemd has been the de facto standard for over a decade now and is very stable. I have found that even most people who complained about the initial transition are very welcoming of its benefits now.
Depends a bit on how you define systemd. Just found out that the systemd developers don't understand DNS (or IPv6). Interesting problems result from that.
> Just found out that the systemd developers don't understand DNS (or IPv6).
Just according to Github, systemd has over 2,300 contributors. Which ones are you referring to?
And more to the point, what is this supposed to mean? Did you encounter a bug or something? DNS on Linux is sort of famously a tire fire, see for example https://tailscale.com/blog/sisyphean-dns-client-linux ... IPv6 networking is also famously difficult on Linux, with many users still refusing to even leave it enabled, frustratingly for those of us who care about IPv6.
Systemd-resolved invents DNS records (not really something you would like to see, makes debugging DNS issues a nightmare). But worse, it populates those DNS records with IPv6 link local addresses, which really have no place in DNS.
Then, when after a nice debugging session why your application behaves so strangely, all the data in DNS is correct, why doesn't it work, you find that this issue has been reported before and was rejected as won't fix, works as intended.
Hm, but systemd-resolved mainly doesn't provide DNS services, it provides _name resolution_. Names can be resolved using more sources than just DNS, some of which do support link-locals properly, so it's normal for getaddrinfo() or the other standard name resolution functions to return addresses that aren't in DNS.
i.e. it's not inventing DNS records, because the things returned by getaddrinfo() aren't (exclusively) DNS records.
The debug tool for this is `getent ahosts`. `dig` is certainly useful, but it makes direct DNS queries rather than going via the system's name resolution setup, so it can't tell you what your programs are seeing.
systemd-resolved responds on port 53. It inserts itself in /etc/resolv.conf as the DNS resolver that is to be used by DNS stub resolvers.
It can do whatever it likes as longs as it follows DNS RFCs when replying to DNS requests.
Redefining recursive DNS resolution as general 'name resolution' is indeed exactly the kind of horror I expect from the systemd project. If systemd-resolved wants to do general name resolution, then just take a different transport protocol (dbus for example) and leave DNS alone.
It's not from systemd though. glibc's NSS stuff has been around since... 1996?, and it had support for lookups over NIS in the same year, so getaddrinfo() (or rather gethostbyname(), since this predates getaddrinfo()!) have never just been DNS.
systemd-resolved normally does use a separate protocol, specifically an NSS plugin (see /etc/nsswitch.conf). The DNS server part is mostly only there as a fallback/compatibility hack for software that tries to implement its own name resolution by reading /etc/hosts and /etc/resolv.conf and doing DNS queries.
I suppose "the DNS compatibility hack should follow DNS RFCs" is a reasonable argument... but applications normally go via the NSS plugin anyway, not via that fallback, so it probably wouldn't have helped you much.
I'm not sure what you are talking about. Our software has a stub resolver that is not the one in glibc. It directly issues DNS requests without going through /etc/nsswitch.conf.
It would have been fine if it was getaddrinfo (and it was done properly) because getaddrinfo gives back a socket and that can add the scope ID to the IPv6 link local address. In DNS there is no scope ID, so it will never work in Linux (it would work on Windows, but that's a different story).
If you don't like those additional name resolution methods, then turn them off. Resolved gives you full control over that, usually on a per-interface basis.
If you don't like that systemd is broken, then you can turn it off. Yes, that's why people are avoiding systemd. Not so much that the software has bugs, but the attitude of the community.
It's not broken - it's a tradeoff. systemd-resolved is an optional component of systemd. It's not a part of the core. If you don't like the choices it took, you can use another resolver - there are plenty.
I don't think many people are avoiding systemd now - but those who do tend to do it because it non-optionally replaces so much of the system. OP is pointing out that's not the case of systemd-resolved.
It's not a trade-off. Use of /etc/resolv.conf and port 53 is defined by historical use and by a large number of IETF RFC.
When you violate those, it is broken.
That's why systemd has such a bad reputation. Systemd almost always breaks existing use in unexpected ways. And in the case of DNS, it is a clearly defined protocol, which systemd-resolved breaks. Which you claim is a 'tradeoff'.
When a project ships an optional component that is broken, it is still a broken component.
The sad thing about systemd (including systemd-resolved) is that it is default on Linux distributions. So if you write software then you are forced to deal with it, because quite a few users will have it without being aware of the issues.
Yes, violating historical precedent is part of the tradeoff - I see no contradiction. Are you able to identify the positive benefits offered by this approach? If not, we're not really "engineering" so to speak. Just picking favorites.
> The sad thing about systemd (including systemd-resolved) is that it is default on Linux distributions. So if you write software then you are forced to deal with it, because quite a few users will have it without being aware of the issues.
I'm well aware - my day job is writing networking software.
That's the main problem with systemd: replacing services that don't need replacing and doing a bad job of it. Its DNS resolver is particularly infamous for its problems.
Um, if they are asking for an avenue to do so, probably yes?
I personally spend hundreds a month on charitable donations - to political advocacy groups, social outreach organizations, and to open-source software that provides me immense value. I think this is one of the most direct ways I can influence the world around me.
It is well known in fund raising most people who say they would donate will not donate. And anyone can give Mozilla Corporation money now by subscribing to their services.
I'm not sure this is exclusive to fundraising - the same is said in business about people who will actually purchase a product, versus those that say they will. Regardless, the comment felt unnecessary in context.
And for what it's worth - subscribing to services is not really the same. For one thing, it puts a cap on how much I can (reasonably) provide.
My rear view mirror does this, I wish my side mirrors did too. Although recently I've noticed some cars headlights can even pierce my rear view mirror's polarized dimming. It never used to be a problem in the past. I've seen the difference when drivers turn their high beams on and off. It always did a great job against driver's brights including large trucks. But occasionally there's now a vehicle with the light of a thousand suns that is too bright for the auto-dimming.
The subscription fee was what enabled them to host these services. From their blog post, they mention spending hundreds of thousands of dollars on infrastructure and software. I expect that the connections and skills involved in running the Rebble web services don't directly translate to creating a hardware product.
That said, I think you are right that Rebble is feeling left out - and that it is hard to figure out exactly how they can fit into Core's vision. But I think there are a couple of primary and immediate issues:
1. Core wants Rebble's data - so clearly there is value here, but Core is framing this debacle like Rebble is irrelevant. Also, I don't know that Google would've ever released PebbleOS if Rebble didn't exist
2. Rebble wants to see the future of Pebble remain open-source or at least compatible with their services, so that if Pebble goes bust again, the community can continue on
Core doesn't want Rebble's data. They want the data from the original Pebble store, which is not owned by Rebble. It's the work of thousands of independent developers and it should be shared freely, not kept in a walled garden with "no scraping" terms added on. It's actually offensive that Rebble is using other developers' data (that they originally scraped from Pebble) as a bargaining chip in their contract negotiation that they made into a public squabble.
I don't think that's quite right - Rebble has updated a number of these apps to keep them supported. As sibling commenter posted, the original apps are available publicly.
I think that’s the crux of the issue is rebble isn’t under any obligation distribute them open source, unless say the original app had a “copyleft” policy?
AFAIK the original apps were individually licensed by the creators... so Rebble would need to have permission before claiming anything for their own except in the case of explicit permissive licenses (like MIT). In some cases (copyleft licenses) Rebble would be required to make their maintenance also open source.
Seems cheap to me. Host anything and you're gonna need developers. Developers are expensive. A hundred thousand dollars is pretty much what you'd pay for a single developer in a year. 5 Devs is still a small team and that's half a million dollars per year.
This thread is very confusing to me - they charged a subscription for these features. They weren't losing money - they were spending it. Money in, money out.
Their original statement was "we’ve spent hundreds of thousands of dollars on storing and hosting the data" that was scraped from the Pebble app store. So, explicitly not on the other services. I have to agree with other commenters that $200,000+ seems like an extravagant bill for hosting this data for 8 years with a web frontend and maybe 20,000 users.
I think this is a bit of a disingenuous reading of the article when the surrounding text states:
> Since then, we built a replacement app store API that was compatible with the old app store front end. We built a storage backend for it, and then we spent enormous effort to import the data that we salvaged. We’ve built a totally new dev portal, where y’all submitted brand new apps that never existed while Pebble was around. [...] And the App Store that we’ve built together is much more than it was when Pebble stopped existing. We’ve patched hundreds of apps with Timeline and weather endpoint updates. We’ve curated removal requests from people who wanted to unpublish their apps. And it has new versions of old apps, and brand new apps from the two hackathons we’ve run!
None of that is included in their statement that "we’ve spent hundreds of thousands of dollars on storing and hosting the data". If they meant that they spent hundreds of thousands of dollars on building a dev portal, patching apps, and the other stuff you mention, they should have said that instead of "storing and hosting the data".
You are choosing a very literal interpretation, which is fine, if you think it is useful. To me, it looks disingenuous and irrelevant. The hosting and storage of that data would have been pointless without this additional development. And arguably, the app store development _is_ part of hosting it.
Cool, it is imperative those services are not operated at a loss. If you choose to do charity, you best make peace with the fact that you will never get either the time nor the money back.
I don't think they were operating as a charity - they were charging for the features that cost them money to provide... that's how they spent the aforementioned money.
They funded some software development, they paid hosting bills, and they paid third party services for weather data, etc.
So they cashflowed the services they provided. And they’re not hunderds of thousands of dollars out of pocket on this, right? So what are they complaining about? Are they worried about losing their revenue stream or what?
This thread started with OP calling Pebble rentseeking and used the subscription services as an example. I replied to point out that the subscription fees were used to fund services and development - they weren't profit. Then the thread went off the rails with some claiming that spending money is proof that Rebble is incompetent and others claiming that they shouldn't be whining about spending money (which they weren't) and I'm no longer clear what point you are trying to make.
Stated elsewhere in thread, I believe the primary concern is that Rebble will import the data into a separate, closed app store owned by Pebble, which Pebble will lock Rebble out of (i.e. block scraping and refuse to release this data), and then if Pebble goes bust again, Rebble is left with less than they started with.
> Stated elsewhere in thread, I believe the primary concern is that Rebble will import the data into a separate, closed app store owned by Pebble, which Pebble will lock Rebble out of
This is what Rebble is doing right now.
The proposal as per the article by Pebble is for Rebble to keep hosting, and for Pebble to pay them to do that. Why would Pebble move things into a closed store when their openness last time is what allowed Rebble to scrape all the apps in the first place? Only Rebble has behaved like this.
> It’s clear he cares deeply about this product and its potential, far and above what the community could hope for. I think the default trust should be with him, or at least it is for me.
The default trust should be with him instead of _the community_ that built and maintained Rebble for a decade?
It's not clear why the community refuses to make the app store archive public. It's an archive of other developers' work. Doesn't make any sense to say "you can only get these from the Rebble website". Just do requester-pays on the S3 bucket.
The concern is that it will be imported into a separate app store owned by Pebble, which Pebble will lock Rebble out of (i.e. block scraping and refuse to release this data), and then if Pebble goes bust again, Rebble is left with less than they started with.
As I understand it, they almost came to an agreement on this:
> We want to give Core’s users access to the Rebble App Store. (We thought we agreed on that last month.) We’re happy to commit to maintaining the Web Services. We’d be happy to let them contribute and build new features. And what we want in return is simple: if we give Core access to our data, we want to make sure they’re not just going to build a walled garden app store around our hard work.
To be clear, the Rebble app store includes more than just things uploaded to Pebble - many apps have been created and uploaded since Pebble OG shutdown.
Not affiliated with Rebble, but IMO another worry is that Core Devices takes the store and turns around and says "the app/watchface store is for official Pebble hardware only via the official Pebble phone app." It's not only about Rebble being locked out, but any hypothetical future hardware from someone other than Core Devices.
Part of the excitement of the Pebble OS being open sourced is that someone else could cook up their own watch, either for a different physical style, weird niche features, a successor to Pebble Time Round that Core Devices so far hasn't shown interest in making, etc. Will that happen? Who knows. But I like that it could!
If Core Devices vacuums up the Rebble store, puts Rebble out of business, and says any 3rd party Pebble OS devices aren't allowed to download apps from the main source, that's not good for the open community. I have no idea if Core Devices intends to do that, but it would be nice if they agreed that the store will stay open for everyone with compatible devices.
Whether Rebble has any legal leverage to do that since the data they archived from the original Pebble store isn't legally theirs to begin with, I have no idea. But given that the store's contents only survived because of their efforts, it feels like the right thing to do.
I think you're 100% right WRT the open-source code Rebble developed publicly. The big open question right now seems to be about the private app store data Rebble archived (and further developed) - which looks legally murky to me.
‘We’re happy to let them build whatever they want as long as it doesn’t hurt Rebble’
Eric mentions that they want to release free weather APIs so apps that show weather don't need to require the user to add an API key. As well as voice-to-text transcriptions. Rebble offers both of those services as a paid subscription. That would hurt Rebble's bottom line.
At the end of the day, Rebble built a business on top of scraped Pebble App Store data & open source code. They continued to keep their code open source. Eric paid fees to gain the rights to any code that wasn't open source.
The Pebble App Store data was never theirs. The underlying Pebble code was never theirs. The common library isn't theirs, Eric bought it from the maintainers.
It really does suck that the Rebble developers could lose a decent source of income. But that's what happens when you build your business on open source technology that you don't own.
But also, they must have some big balls to claim that all of the data they scraped from the Pebble App Store is THEIR data. I'd like to see the agreements from the pre-Rebble devs attesting to that.
That's certainly the sticking point for Core. Also, Rebble is a non-profit, not a business.
> But also, they must have some big balls to claim that all of the data they scraped from the Pebble App Store is THEIR data. I'd like to see the agreements from the pre-Rebble devs attesting to that.
Agreed with this, but if it's not theirs, they also probably are not legally permitted to release it to Pebble (or host their app store, of course.) I am curious what the original terms were when they uploaded their apps to the OG Pebble app store.
reply