What is Hackers' Pub?

Hackers' Pub is a place for software engineers to share their knowledge and experience with each other. It's also an ActivityPub-enabled social network, so you can follow your favorite hackers in the fediverse and get their latest posts in your feed.

1
0
0
0
0
0
26
0
0
13
0
0
0
0
0
0
1
0
1
0
0
0
0
1
0

RE: mastodon.social/@arstechnica/1

...in which Amazon tell us that outages were caused by unreviewed AI code...

oh yeah somebody said something about there being no doubt about productivity gains because 'they see them everyday'?

Well ok I'll accept your still anecdotal evidence but I would like to debit hours from those x1 engineers productivity gains and raise a credit for hours lost by every person affected by these outages.

0
0
1
0
0
0
2
0
0
2
1
1
0

I have finished the temperature blanket panel for 2025! This is a decade-long project. Each stripe represents the local daily high temperature in farenheit: red is 90s, orange is 80s, yellow is 70s, and so on.

To capture the entire winter and summer seasons, the first bottom row actually starts on November 1st of the previous year, and the numbers are placed on January 1st of the labeled year, and it continues up from there.

A large crochet blanket that looks like a bar graph in stripes of rainbow colors, with 6 long vertical panels labeled with the years 2020 through 2025. Each panel shows the seasonal shifts in the daily high temperature. Notable highlights are the extremely hot summer of 2020, the very cold polar vortex of 2022, a strange week of warm days in the spring of 2023, and the extremely mild winter of 2024. The most recent panel shows evidence of our very short, wet summer this past year, with many fewer orange and red days.
0
21
0
1
0
0
6
0
0
0
0
0
0
0
0
0

ARTE.tv featured our project in a recent documentary on European digital dependencies:

openwebsearch.eu/wo-bleibt-das

🥳 A big shoutout goes to @djoerd from our team at @Radboud_uniRadboud University whom you can see in the interview!

University Passau, @Radboud_uniRadboud University, CERN, German Aerospace Center, Leipzig University, Technische Universität Graz, IT4Innovations National Supercomputing Center, CSC-IT Center for Science, A1 Slovenija d.d., Bauhaus-Universität Weimar, @osfOpen Search Foundation, @LRZ_DELeibniz Supercomputing Centre , SUMA-EV, @nlnet

Our project was featured on arte.tv (German version)
0
0
0
0
0

I've spent my whole career working with neurodivergent people in tech.

Here's to the people who thrive with interrupts, who work best when juggling four different things, are pretty great incident responders, and can code while talking on slack.

Here's to the people who need four uninterupted hours to get anything done, but what they get done is fantastic, and they have the in depth knowledge to explain nuances you didn't even know were there, making them the folk who find the long term remediations after incidents.

Here's to the people who take great joy in picking the lint out of a codebase because it's fun, who refactor for the challenge, who see bad process and ache to get changes in to reduce the friction.

Here's to the people who seem to know everyone, who reach across teams to tap experts who don't get the recognition others do, and work best when working WITH.

Y'all are amazing

0
9
0

Today @kopperkopper :colon_three: shared a post on the fediverse titled how to not regret c2s, and I found it genuinely interesting to read, even if I'm not sure its proposed architecture actually solves what it sets out to solve.

The author's frustration with naïve implementations is well-founded. Slapping an facade onto an existing Mastodon-like server and calling it C2S doesn't buy you much—you end up with the rigidity of a bespoke API without any of the interoperability C2S is supposed to offer. The “JSON-LD flavored Mastodon API” framing is apt.

The proposed solution is to split responsibility more aggressively: the C2S server should be nearly stateless and dumb, storing ActivityPub objects without interpreting them, while a separate “client” layer handles indexing, timelines, moderation, and exposes its own API to the frontend running on the user's device. It's a clean separation of concerns on paper.

But here's what bothers me. When you map this architecture onto familiar terms, it looks roughly like this:

  • C2S server ≈ a database (PostgreSQL, say)
  • “Client” ≈ an application server (Mastodon, Misskey)
  • “Frontend” ≈ the actual client app on your phone

That's not a new architecture. That's just the current architecture with the labels shifted. The interesting question is which interface gets standardized, and the author's answer is the one between the C2S server and the “client” layer—the bottom boundary.

The problem is that what people actually want from C2S is to connect any frontend to any server. The portability they're after lives at the top boundary, between the frontend and whatever is behind it. But the author explicitly argues against standardizing that layer: “we don't really need a standardized api,” they write, leaving each client free to expose whatever API it likes.

Which means frontends remain locked to specific clients, just as Mastodon apps are locked to the Mastodon API today. The interoperability promise of C2S—log in to any server with any app—isn't actually delivered. It's been pushed one layer down, out of reach of the end user.

There's real value in the post's thinking about data hosting vs. interpretation, and about the security implications of servers that understand too much. But as an answer to the question C2S is supposed to answer, I'm not convinced.

2
0
0
0