GitLab is also getting worse and worse. They're going full-in on AI and each new release is more cluttered with useless features and requires more and more resources to run smoothly. After six years self-hosting a GitLab instance for a few hundred users (among which a few dozens are quite active), I abandoned this summer and I'm currently migrating the instance to Forgejo.
It's a shame because I like GitLabs UX and runners much more than other forges. I've been considering forking gitlab and removing complexity. GitLab uses multiple GB of memory idle with no users. It's sad.
I agree. GitLab UI was great and the simplicity of its CI/CD is unequaled on other forges. It's sad that Forgejo went with the actions model from GitHub which introduce a lot of useless complexity. But it seems that Woodpecker CI [1] could be a good candidate to replace GitLab CI, as it uses very similar concepts and workflow description files.
I teach a free software development course to my undergrad students. It's really exciting to stumble upon one of the work they did for my class in the wild (it's the first listed bug fix — which is the last of the three pull requests this student got merged in Immich during my course). I feel so proud! :)
This is too oddly written to read in its entirety and I don't get the point. I mostly still do things like it says it worked in 2008. The difference with the "modern" workflow with 1400 packages and a build system is that web pages I put online just work, unlike most modern website which are horribly bug ridden and take ages to load and render.
I really don't understand that some people are still trying to sell blockchain-based electronic voting. But anyway, I just wanted to tell a fun anecdote about the impossibility of making an obfuscater that works for any arbitrary program, or rather, since this is trivial for Quines [1], that it is possible to protect any program from obfuscation by making a simili-Quine of it. Given a program P, it is possible to construct a program Q(P) that takes an additional optional boolean input that defaults to false and which, when this additional input is false (i.e., by default), behaves exactly like the program P, but when called with the additional input set to true, acts as a Quine instead of executing P, thus outputs the source code for Q(P) (which is constructed to includes P's source code). This is guaranteed to work basically because an obfuscater cannot change the behavior of a program without breaking indistinguishability. I remember having a lot of fun working on that as an undergrad a long time ago [2].
I think the analogy presented here is broken. RSS doesn't depend on Google Reader at all. Even at its prime, RSS depended less on Google Reader than email depends on Gmail now. In ATProto, AppViews heavily depends on Relays to be useful, and Relays are quite expensive to run. Also, the yellow circles which represent blogs in the RSS illustration are really not of the same nature as the same circles which represent posts on Facebook. Blogs are self-sufficient, for example.
I'm not saying ATProto is bad at all, but I feel like this blog post adds more confusion than it clarifies anything.
Relays are actually quite cheap now! They used to be a bit more expensive when they archived all the traffic, but in sync 1.1 that was dropped and they can be run on $20/mo VMs pretty trivially now
Someone has to archive the data, right? Perhaps the complexity has been pushed to the AppViews?
If I read a post from a month ago, how will my client know how many likes it has or what the replies were? Without reverse links, someone has to look up in a database of all AT actions for likes/replies pointing to that post.
Contrast with the inbox/outbox forward/reverse linking model of activity pub.
AppViews already had to archive whatever data from the network they cared about. The change just means that an AppView won't be able to infinitely backfill from any relay, you either need to find a relay that archives all the data you want and backfill from that relay, or you'll need to backfill by querying pds's directly. Or you could just not backfill at all, your AppView can do whatever it wants to really. Clients always talk to an AppView to get information about the network, the AppView manages the building of reverse links, the relay doesn't care about the hydrated state of the network, its just a stream of events which occur on the atproto network.
While relays are among the more intensive parts of AT Protocol infrastructure, their cost of operation is still something most people can afford: approximately $30/mo now. What is truly expensive and difficult is something that will be immutably so regardless of how centralized or decentralized you are: moderation.
If $30 a month is too much for you, then you probably should be doing something other than trying to run a relay. It is just not a significant amount of money.
$30 a month is a pretty massive costs for such a program. Why does it require such a beefy VPS, is it just the initial bootstrapping that requires such resources?
Because if you want to relay every single public event for every single user on the entire atproto network in real-time to many consuming apps and services… that's gonna cost something. Not that it costs a lot, but to expect what a relay does to be infinitely cheap is to not understand what it's doing or why it's doing it.
"Most people" cannot afford $30 /month. And of those who can, most of those cannot afford the time and effort required to run a relay.
And I honestly think this is one of the fundamental problems with the push back towards protocols and decentralization. We're overestimating the bandwidth and capabilities of the average user and we haven't fixed the problems that pushed everyone towards centralization in the first place.
Take me, for instance. I am not only capable of running my own Mastodon or Atproto data server+relay -- I'm technically capable of writing my own ActivityPub or Atproto app.
But I'm currently sitting with accounts on bsky.app and mastodon.social -- the biggest most centralized "instances" (yes, I know, but it reasonably describes the problem). This is because I do not have the time or mental bandwidth to even pick an "instance" that would be better suited to me and migrate, let alone run my own.
And this is doubly and triply true for the average person who doesn't have the technical abilities I have.
As a result, both Mastodon and Bluesky are still practically centralized to a large degree. An overwhelming majority (more than 90% last I found data) of Bluesky users are hosted by bsky.app. Similarly on Mastodon, a large plurality of users (~20%) are on Mastodon.social. Mastodon's obviously doing better than Bluesky in this regard, but it also has about a quarter of the overall traction, and I'd honestly put that down to Bluesky's apparent centralization which makes it a lot easier for people to join and wrap their heads around it.
This isn't about "average user". Relays have nothing to do with using atproto as a user. They're about developers making new apps.
By "most people" it's implied we're talking about most people who want to run a web app in their spare time. Do you mean a different definition? If you want to run a web app (which is the only reason you'd want a relay) and you're able to pool with ten other developers who want to do the same, you can make the cost to $3/mo. Is that feasible? What do you normally pay for web app hosting?
And again, if you're a hobbyist developer, you'd just use a community relay that already exists and is free. I assume that, if you want to run your own, you have a specific reason to do so.
You're getting hung up on the relay distinction (which is fair). But I'm not talking about relay's here.
And to be clear, I'm talking about the push back towards protocols and decentralization as the solution to enshittification and lock in. I fully believe decentralized protocols and the ability for us to run federated instances for our communities is valuable in and of itself. What I'm arguing against here is the degree to which the pro-social tech community has coalesced around this push as the one and only solution to the problems of enshittification.
And in that context, the average user is everything. And the push fundamentally misunderstands both how enshittification works (email is fully decentralized but still enshittified to a large degree) and the capabilities of the average user (not just their technical capabilities but their cognitive load capacity).
If you want, s/relay/pds/ and my point may become clearer. Or, even, s/relay+pds/app/. The point is pds+relay+app functions as instance for the average user. And the average user doesn't have the time, energy, or cognitive capacity to pick an instance that would be the right fit for them. Which means these decentralized networks are still heavily centralized. And if they remain heavily centralized, those central players still exercise an enormous amount of power over the network.
Including the power to enshittify it.
We can't solve enshittification if we're not cognizant of what the average user is capable of. And that capability extends to more than just "technical understanding". So far, I don't think the protocols push, in so far as it is being pushed as the solution to enshittification, is grappling with that adequately.
I view Bluesky as being decentralized-optional. It's cool because you actually can join first and wrap your head around it later. You can continue using your account you created on the fully 1st-party stack, and you still have the option to switch to self-hosting the parts you care about, without losing your posts or followers.
- If you just want to use your domain name as a username, you set a DNS record.
- If what you care about is the client, you can build your own website or native app. You don't really even need to host a server other than for your own static assets, since the app can request Bluesky network data directly via the logged-in user's PDS (they even have CORS headers!)
- If what you care about is data sovereignty, you can self host your PDS (personal data server) on a low-end VPS. It's cheap because it pretty much just holds your data, passes events to Relays, and proxies data requests to your preferred AppView.
- If what you care about is not needing to trust Bluesky to reliably gather and collate events from each PDS, then you'd need to host a Relay ($30/month) and an AppView (even more expensive) so you'd be best off pooling resources with other people you trust. But that's kind of the nuclear option.
- With a narrower scope though: if you noticed that Bluesky was censoring a handful of legitimate accounts and you still wanted to follow them, I think you could probably have a personal Relay+AppView that only listens to the censored accounts' PDS's, and proxies other requests to the 1st party AppView. (I'm not 100% sure if that would be allowed.)
>"Most people" cannot afford $30 /month. And of those who can, most of those cannot afford the time and effort required to run a relay.
I don't think that was a recommendation for people to do, but to demonstrate that it doesn't require much in the way of resources. That VM could probably host hundreds of people, since relays scale and de-dupe shared content.
If someone said that email or a personal website was inexpensive and could be hosted on a cheap VM, I don't think you'd make a comment like the above dismissing it as impractical: the idea is that if it's that cheap, then there are people that can host cheap/free (maybe ad supported) relays, similar to how cheap/free webmail exists today.
> "Most people" cannot afford $30 /month. And of those who can, most of those cannot afford the time and effort required to run a relay.
??? that's not the point. the goal isn't that some non-technical 40 year old will run their own relay. the goal is that relays will be cheap enough to run that there can be hundreds of relays for developers of apps to choose from.
relays are DEVELOPER facing only, meaning the developer of the app chooses which to use, and can even use none at all and build the functionality of the relay into their app itself.
no matter where your account is hosted, it will be crawled by every relay (unless it's banned from some of them) so users or people who "don't have the bandwidth to think about this" don't have to worry about relays at all. anyone who will ACTUALLY BENEFIT from an independently hosted relay (app dev) will perceive them as an incredibly marginal cost.
> This is because I do not have the time or mental bandwidth to even pick an "instance" that would be better suited to me and migrate, let alone run my own.
Idk what to say to that. So I'll just say that you can run `npm create pds` and have a single-user PDS hosted for free on Cloudflare in minutes.
But I think what you meant to say (stop me if I'm wrong) isn't that you don't have the "mental bandwidth", it's more that you (and the average user) don't actually _want_ to migrate because there's no tangible benefit.
To this I would say: migration is not the path to spreading users out across instances at a large scale. Migration to me is more of an insurance against a service going down or turning evil. The real way to get people to spread out across different PDSes is to make it so there are more "entry points" to the atmosphere, so more people are onboarded to the atmosphere in more places other than Bluesky, where they can sign up and automatically be on another instance. If more independent atproto apps are created with their own PDSes for onboarding, that's what will solve the problem imo, not encouraging users to migrate (although that can also be done at smaller scales, as Blacksky and Eurosky have proven)
>To this I would say: migration is not the path to spreading users out across instances at a large scale. Migration to me is more of an insurance against a service going down or turning evil.
I think people aren't paying enough attention this part right here: I think the architecture of atproto creates a different set of incentives. People running communities are more likely to face community pressure to ban users, or de-federate with other communities they don't like, and your open/decentralized network fractures apart, creating little silos.
People running infrastructure connecting them to a global network/resource are less likely to feel those pressures. No one asks an email provider to ban another webmail host. The architecture colors the perception.
The biggest problem Bluesky has had is that by virtue of being the only effective relay at launch, people viewed it more like the former and less like the latter. But I think if we start to see more places like Blacksky and Eurosky get mindshare, we can shift it back.
An average user does not need to run their own node for decentralization to work. It just needs to be cheap and easy enough for enough of technical users to run
Oooh! I fondly remember my N95! Pictures and movies it took were great, at least for the time, and it had apps and a lot of stuffs like a browser that were presented as new on the phone space when the first iPhone was released, while I had my N95 for almost a year at this time. Symbian was a really nice system.
I liked Symbian a lot, but I agree that Maemo was superior! Two after what I told above, in 2010, a few friends of mine had N900 and they seemed great. I was still in my study at the time and I interviewed for a summer internship at Nokia to work on Maemo and it was going great, but at some point during the recruitment process, that part of Nokia was sold (to Intel I think? the MeeGo project was announced a bit later) so they stopped all hiring even of interns and I had to find another internship.
This is a good introduction to Dune, but frankly, Dune kinda sucks. I mean, it is very powerful, and works very well, but it's too much of a hassle, especially for beginners. I don't want a language specific build system to require two different files to actually be usable, even on very simple projects… I still use it because it is the de facto standard, but I really preferred ocamlbuild [1], which was actually a tool that just worked without any configuration necessary for simple projects that uses standard tools. Where you would need to write a Makefile and call make, you could just write nothing and call ocamlbuild and it would just work. Dune lost that ability entirely.
Thanks for putting it this way. I have to admit I was really astonished by the question as I feel like HN is very much pro-AI at least in the sense that there is more AI promotion on HN than there is AI acceptance among people in the real world. It's been months if not years since most of the posts are about genAI, and in a largely favorable way. It's actually quite fascinating that for some people it feels like the opposite.
I hang around a few developer-centric communities, and my gut feeling is that HN is by far the most pro-AI. It's somewhat rare to find people all-in on "developers just got replaced by AI, pick a different career field guys" anywhere but here. Maybe there are just more developer-adjacent types on HN.
I do find it somewhat amusing to read the commentary here and ponder why some of these people are wildly enthusiastic about making software development a dead field but simultaneously don't think it's also going to put them out of work. Programmers may be a lucrative target, but LLMs are "good enough" at many other knowledge disciplines too.
I think generally, extremist views tend to echo further than nuanced ones. This goes for any major topic really: whether it's politics, religion, arts, etc.
The AI discussion on HN is exhilarated by the fact that it can have a tangible impact on people's lives on this forum. You add to this the possibility of a minority extracting an unfathomable amount of wealth from the hype train and we lose all hope for a moderate discussion.
My own views on this are rather boring. After having tried various models, I've reached the conclusion that it adds minor benefits to my workflows, but I don't have to lose sleep from Claude reaching singularity anytime soon..
I'm using Claude Code at this moment to do some work for me. It's doing a pretty great job, if I'm being honest. It's going faster than I would, overall, but it's not some kind of 10x magic. It does things faster and in some cases better on the first shot, but it misunderstands and needs guidance on plenty of things, tweaks, etc. Even if I don't necessarily tweak the actual code and just ask Claude to go clean up it's shit, that still takes time.
I think the folks who say 20-40% faster is typical are definitely in the right ballpark. And that's best case. There are plenty of times where my biggest blockers are not anything Claude will ever be able to fix.
Maybe the result of this whole experience will be grudging appreciation from management that software developers aren't just coders. Maybe. I'm an optimist, though. And my manager already knew that.
For me, one of the big improvements is the ability to legitimately work via text message. That probably sounds dystopian in a bunch of ways to some people. But there are times that I want to work, but couldn't, previously.
Now I can work from wherever, whenever, by speaking into my headphones, and have it persist. Sure, I want to be in front of a screen to do final syntax review, but I don't mind planning out architecture and guiding an LLM towards a cohesive result while going for a walk or jog. That's just not a workflow that would have been viable 3 years ago.
I find it somewhat encouraging to hear that the devoted AI shills have not managed to generate the artificial consensus / synthetic consent that they seem to have been intending to.
I feel like introducing lambda calculus (using JS syntax) would be less cumbersome and convoluted than referring to "the challenge" without really justifying it and deferring to respect the rules for so long. But maybe some people entirely unfamiliar with these concepts find this approach easier?
It sets a challenge as a rhetorical tool, but then completely fails to honour the challenge through the bulk of the explanation.
- don’t use recursion: spends multiple paragraphs implying that a function calling itself isn’t recursion
- don’t use declaration: ignoring that defining arguments to a function is declaration
I’m not saying the article is “wrong”. But I thunk I’d have preferred a plain intro to lambda calculus.
(Writing this as someone who has struggled to learn “real” functional programming the few times I’ve tried over the past 20+ years, but who very much likes using RxJS and the functional flavour of lodash and wishes I could see deeper into that black hole.)
I’ll re-read it, because clearly I don’t get it. And I’d like to.
My first two attempts made it seem like it was building on a function calling itself, with itself as an argument (so that it can call itself). I’m not sure how that isn’t recursion, and I didn’t read it as throwing away those approaches. But, as I say, I’ll re-read it…
author here. the idea is to see how the Y and Z combinators come out relatively naturally given an extremely constrained context with no loops, no recursion, no bindings. the article is intentionally structured as a sequence of failed attempts that progressively reveal which phenomenon is still responsible for the recursive behaviour.
in the article, i define recursion narrowly as "... call the function `fact` from inside the definition of the function `fact`".
you're right that `factgen` is also not recursive but it is also rejected, but for a different reason: self-reference. declarations are banned precisely because they give a function a "name" that can be referenced later.
please note that the solution which uses Z combinator (given at the end) grows from `(x => x(x))(x => x(x))`, which is NOT self-referential. it achieves self-replication by literally rewriting the content of the function twice, which is different from self-referential recursion of `factgen`.
I think I missed the significance of your narrowed definition of recursion, and didn't apply it the way you intended when I read the article. I admit to my bad reading.
I went on to discuss your article with an LLM and used the experiences I've had _using_ some functional approaches in JS to help it give me a tutorial on the combinators, to try to better understand your article and the underlying principles. I "mostly get it" now, but I will have to go over it a couple more times.
You shared a thought-provoking article, even if I didn't immediately get your intended lesson out of it.
So it's as confusing as I thought to do it that way. I wasn't sure if I thought so because I'm already familiar with all these concepts or because this introduction is indeed convoluted. Thanks for taking the time to reply!
First, thanks for sharing this link, it was an interesting read! A few remarks below.
I had a hard time reading the wc code in the article. First I had to go to the GitHub to understand that "da" stands for dynamic array, and then understand that what the author calls wc is not at all the wc linux commands, which by default gives you the number of lines, words, and characters in a file, not the count of occurrences of each word in the file, which is what the proposed code does.
Also, since I had to read the GitHub README, another remark: it says that sp_io uses pthreads rather than fork and exec. Both of those approach (but especially pthreads) are contradictory to the explicit goals of programming against lowest level interfaces. I believe the lowest level syscall is clone3 [1], which gives you more fine grained control on what is shared between the parent and child processes, allowing to implement fork or threads.
By the time you know enough to reasonably use clone3, you have also learned that doing so is an exceptionally bad idea save for very rare circumstances.
To be portable it's probably best to use the pthreads API for everything, make no additional assumptions, and rely on the user to provide the implementation. Consider what happens when someone is working with OpenMP, CUDA, or similar and attempts to make use of a dependency that in turn makes use of your library. The easier it is to understand the assumptions made by your library the better.
I agree with that. I'm just stating that it's contradictory with the project's own principles.
> Program directly against syscalls
It's the very first one of the listed principles. In the paragraph after this title it even says it "must" be the case in italic to insist on it, and there's a footnote to define what they mean, which is very clear in that pthreads should be out according to this principle.
reply