I _could_ also just write API endpoints and handle client-side interaction however I want. If your preferences are incompatible with mine, that's a tradeoff I'm choosing to make. I am doing the work, you see, and I can choose how I want to do it.

You ostensibly run some flavor of Linux. Do you also complain that macOS apps don't run on your machine? It seems to me like a similar argument: somebody has developed an application in some particular way, but your choices have resulted in that application not running on your machine. Your choices are not necessarily _wrong_, but they are of very little consequence to somebody who has developed an application with a particular environment/runtime in mind. Why should they have to make significant architectural changes to their application to support your non-standard choices?

> It's not like a team wanted to rewrite it in PHP, which we can all at least agree would be madness.

That seems like the same argument that TFA is making, but in reverse. I think it's just as invalid. PHP is a perfectly fine language for many things. There is plenty of greenfield development being done in PHP these days + a substantial amount of PHP in production all over the place. Unilaterally writing it off as "madness" seems pretty disingenuous to me.

Congratulations for getting the point of the article. :)

> In the hopes that this work may in some way contribute to their exploration of space, this is dedicated to the crew members of this country' s present and future manned space programs. If only I could join them in their exciting endeavors.

Imagine writing this 6 years before you were literally standing on the moon.

"JSON Query" is kind of a long name. You should find a way to shorten it. Maybe "jQuery" or something along those lines :P

Do you actually care if the requests were made on some specific calendar day? Or do you just want to make sure that heavy users are paying more and/or people aren't abusing your system?

Instead of tying your quotas to calendar days in some specific time zone, tie them to a rolling 24 hour usage period. Even better: use a rolling hour.

You might consider some of the pre made stuff at https://www.csunplugged.org/en/

I genuinely can't tell if this is satire.

I thought it would have been obvious by the "Program Files" at the end :).

Anyway, Linux community as a whole has an antiquated development process, and needs to modernize and follow the best practices of an industry-leading trend-setter, like MS Teams.

Surely Linux should be developed Google style, with a Web Scale perspective. uucp, tar, yacc, roff removed (with a 30 day notice, of course!), all the uses of "creat" amended to add the final "e", etc.

And systemd already follows Microsoft best practices, such as "Fire and Motion" https://www.joelonsoftware.com/2002/01/06/fire-and-motion/

The X11 people are trying this hard. I'm really curious how Wayland will evolve but, the history of GTK and QT does not give me much hope.

Wait you were kidding? I've already spun up a kubes cluster so we can feed FHS in a globally load-balanced CI/CD pipeline, I have an agentic LLM doing constant improvements so we can sprint to you never knowing where your files are!

It's like ASLR for files but no maps because maps aren't for trailblazers, they make the maps! It's very cutting edge and a value-add!

(Obligatory /s)

Ok, so it's only half satire, or is this reply also a satire? I mean, MS Teams, really?

(Yes, the reply was also satire)

IRC -> Slack was basically a less capable electron based GUI on top of what IRC offered.

Imagine a less capable electron based GUI on top of what emacs offers and I bet you'd get reasonably close to vscode.

The product that OP is building is a todo list. Rails or Laravel would have both worked just fine. Elixir/Phoenix are neat technologies, but I get the sense that this decision was primarily "because I want to" rather than any particular selection methodology (which is fine - you do you, OP).

It’s not just a simple todo list. The product includes advanced features like goal tracking, minimal project management, a streak system, daily task resets with a 3-task limit, and AI-powered task creation that can break tasks into subtasks. Users also get individual profiles to share streak progress and build habits. On top of that, we’re working on additional features like adding team members to projects and real-time collaboration. While it’s certainly possible to build these in Laravel, implementing them is not as seamless or straightforward as it is in Phoenix.

> I kept waiting for the description of what it would be used for, but there was only a passing reference to learning how to run AI workloads.

Future posts will address some of this. :)