nightpool

Surely there's some middle ground between only hosting your own data and being reliant on another site to keep track of your following / followers and hosting a duplicate copy of the entire network?

But why is it required? Do you really need a copy of everyone's data locally? If the only way to self-host bluesky is to have an entire copy of the entire database, that seems like it's really bad from a scaling perspective.

The print stylesheets are also kind of broken. With my printer's default margins, the page becomes an overlapping mess: https://i.imgur.com/lTlFz4l.png

And even with margins turned off, stories are split "across" pages in a way that makes them useless for printing: https://i.imgur.com/SvmTGa8.png Need to pay more attention to your "break-inside" properties: https://developer.mozilla.org/en-US/docs/Web/CSS/break-insid... (and switch from using JS-generated absolute styles to using a CSS column layout or masonry grid)

Very cool! Looks like it has an XSS vector though :P

https://i.imgur.com/5bbKiFc.png

Resourcing issues are changes to philosophy at some level or another

WordPress.com was a predominant WordPress host for a long time, and now they no longer are. That's exactly the point I'm making.

> Literally all they have to do is avoid a scenario where no one wants to use them. ... That is a lot easier than trying to be a high-growth company.

I don't really think it's as easy as you make it out to be. Easier? sure. Easy enough to sustain the company once Ghost gains more alternative hosts? I dunno.

Growth, no, but they need a consistent revenue stream and if they don't shift focus away from their open source aspects to their paying customers, then their market share will be stolen by the companies that do and they'll lose their revenue stream

Fair! In this case though I meant small in terms of adoption—it looks like there are some alternative Ghost hosting providers, but none of them really have name-brand recognition in the same way Ghost does, and even Ghost is one small player in the "non-Wordpress subscription blog / mailing list" space. But a lot of my comment comes from watching the Redis / AWS Valkey split as well—even if Redis stayed as a smaller team instead of trying to compete with the hyperscalers, they'd still be stuck in the same catch-22—watching their revenue dwindle to zero while AWS and GCP competed on proprietary platform features.

Sure, I don't see where in my comment I imply this is a problem for all open source communities, just that it's a problem for the type of open source community John seems to want Ghost to be (no intellectual property, making revenue via providing services).

For #1, that is the kind of logic that works fine for the early adopters, but frustrates and turns away the people who just want e.g. a Substack that won't squeeze them for login walls or a Wordpress that is easier to use. I've seen a lot of non-technical people in that bucket turned away recently by Ghost (Pro)'s opaque and confusing member-based hosting costs. It makes it completely impractical to run a free email newsletter, and plenty of other Ghost providers seem to have this worked out. So all it takes is one of those competitors breaking through to achieve name recognition and get a lucky roll of the marketing dice to overtake Ghost in revenue. And then they can fund their own fork and the Ghost community is forced to agree to their development wishes or become outpaced by their proprietary features. It's a pretty bad place to be in.

I can't really comment too much on historical Wordpress politics—given Matt's recent public meltdown I'm completely willing to believe that he's continued to shoot Wordpress in the foot in more obscure ways in the past—but the posturing here vs. Wordpress really strikes me as someone who has gotten lucky and has attributed that luck to skill instead.

What happens when Ghost gets popular enough to get their own "G Engine" competing with with Ghost (Pro)? As Wordpress.com shows, there's no serious moat for open source hosting. Either Ghost devotes resources away from their open core and towards their hosting platform, or they lose the competition for marketshare to a company that does devote those resources and then they have no funding stream, aside from what G Engine deigns to give them out of the grace of their own heart. And all of the platitudes about voting or board seats and everything else don't really make one lick of difference if you don't have any funding to make that happen, and you have to rely on pay-to-play funding from the people who are actually making money in the space, and let them set your agenda.

So, Matt's behavior aside, I do think these issues are pretty endemic to the idea of "open core" funding as a company (or market) grows beyond a certain size. Unified non-profit or dual-corporation structure (Mozilla Corporation vs Mozilla Foundation) doesn't change the fundamental logic of "where does the money come from?". I don't think Ghost is providing any new solutions here—they've just gotten lucky / been small enough to not be out-competed in their hosting niche yet.

I have the same problem with this that I do with "federated forums" or "federated forges"—what does it even mean for an encyclopedia to be federated? In fact, they already are—if I want to go look up information about Minecraft, I can use the federated internet to go to minecraft.wiki.

So what are these new "federation" features actually giving us? Is it just OpenID login reinvented?

TFA: "But doctors never definitively diagnosed Johnson with celiac disease. His doctors wanted to do a biopsy to get a definite answer, but that would require eating gluten again, something Johnson wasn’t willing to chance"

You're welcome to compile your own Firefox or Chromium build if you disagree with the trust decisions the default ones make.

Well, GP proposed removing the idea of trailing newlines from standard *nix tools entirely, so I think it's fair to ask what shop is going to update their RHEL deployment to upgrade to a version of `cat` or `sed` that doesn't have trailing newlines but can't spend 5 minutes to handle a newline properly in their CSV parser? That doesn't make a lot of sense.

And it was pretty clear from the context of norir's comment that they were not talking about legacy software, they were talking about writing new projects/file formats that used newlines as a separator. Just because you want to shoehorn your legacy projects into this discussion doesn't mean that they fit.

I have never had any issues with this using a standards compliant CSV parser.

Right, but I would be really shocked if Zendesk's internal email handler was doing any SPF/DKIM/DMARC validation at all. So even if a domain has DMARC set up, Zendesk is probably ignoring it. Which is probably pretty reasonable given how rare DMARC reject/quarantine has been historically

In this case, that probably means that H1 had a Zoom or Slack convo with the team and is relaying their decision into text instead of making them write it down themselves.

Yes? and as GP said, he stepped down because (as explained in the first line of his email) "Now that PEP 572 is done, I don't ever want to have to fight so hard for a PEP and find that so many people despise my decisions."

They're saying that the client software (the servers that speak the IPFS protocols) has to load the files to be served into their own local storage database, it can't just keep a "metadata file" and read the existing files off disk. Presumably somebody could write a client that spoke the IPFS protocol and did this, or fork the main Go or JS one, but until someone does that they're stuck with the software that's already been written

As someone who doesn't follow the language, which recent events are you referring to?

> I haven't used Kamal yet but how does it deal with your action cable process and background worker becoming healthy with v2 of your app while the web app is still serving v1 of your code or vice versa?

Isn't this the same problem you'd have deploying your updated code to any number of servers larger than one? There's no way to shift over all the traffic at the exact same time, so all database changes have to be forwards compatible e.g. you can add columns before using them, all code changes have to be cross compatible (e.g. if there are unknown job names or arguments, they get automatically retried)

Or they won't discover, because they'll be 5 years gone onto the next company, and the product will slowly decay under the cost of upkeep of its technical debt and the business fail.

The free market is not, in fact, perfectly frictionless. Executive decisions still matter and can make the difference between having, say, a photo sharing site that people like to use, and having one that's shut down because they can't pay to fix the legacy code.

Exactly. Execs see the monthly spend, people actually doing the work see the long-term externalities and hidden costs. Many, many people I know would and do buy more expensive (often Made in USA but not always) products when doing so means that the products will last longer and need less maintenance. Treating labor as commodities implies that the labor is interchangeable. Everyone who's actually done the work knows that it's not. There's no shortcut to paying for good talent.

It's not just Rust—rewriting a C network service into Java or Python or Go is also an example of transitioning to memory safe languages. The point is that you're not exposed to memory safety bugs in your own code. Arguably it's much better to choose a language without Rust-like manual memory management when you don't absolutely need it.

Really? What is the justification for allowing Nintendo titles to use it but not third parties? Security concerns?

I hear https://github.com/google/web-serial-polyfill gets used a fair amount on Android devices, so that might be one road you could go down. Additionally, I can't imagine it would be that hard would it be to build a mobile app that could provide a WebSerial interface to a friendly webview of your choosing. You'd need the user to download an app, but then you could use the same code for both web and app versions.

I think that's the pretax salary number? (they said "pay", and it was CoL adjusted from their starting $80k target salary in ~2021). They estimated their fully loaded cost in the same update as around $108k per employee (gave total payroll expenses as $36k monthly for four full-time employees). They said in a different update they were using a QSEHRA, which seems to have a cap of $11k per employee, so presumably that covers most of the difference? But maybe I'm just interpreting that completely wrong. I remember they posted about their healthcare coverage woes at one point but I don't remember the details.

That all being said, I don't think this is a huge indictment of Cohost—they had a solid 4 years, and in all likelihood they'd have had to close up sooner if their personal financial situations were more precarious. But a situation where making less than $94k is "precarious" is a very tough one to be trying to starta new social media company in.

(Roughly $94k annually per employee as detailed in the 2023 financial update—low for Silicon Valley but high for co-ops / small community sites / "small tech")

Angel investors generally make equity investments, not loans. Cohost in the past has been very specific about the fact that their funding was the latter.

Expenses also includes salary and accounting fees, AIUI