and like 4 of them aren’t birds but venomous spiders trying to disguise themselves and murder you

I feel like being able to run things locally is really valuable as well. This has been one of my biggest issues with stuff like aws where it’s very difficult to have an offline local environment. You have things like localstack, but it’s not perfect.

I think you’re on to something. Given how software is generally built to the lowest standard possible, there are more and more exploits piling on as a result. The details of any modern tech stack is far beyond human comprehension. It’s just not possible to meaningfully audit all the code and all the different interactions within it. The whole thing is just a giant house of cards.

This is the curse of working in tech. As long as things are working smoothly from customer perspective then the pleas to spend the time to deal with the tech debt are ignored. Yet, when enough debt piles up and things start breaking then it’s the people who’ve been warning about the problems the whole time who get blamed.

There are plenty of greenfield projects out there.

yup, that thing’s a nightmare alright

When a project is developed for a while, a lot of initial design decisions can become invalidated as business needs evolve. New features have to be added, and in many cases they go against original assumptions about how the project would be used. At that point you have to start making hacks and kludging new features in. This creates a lot of special cases and surprising behaviors making overall project brittle and hard to maintain. That’s what’s known as tech debt.

In an ideal world you would have time to do proper redesign to accommodate new features, clean up problems as you go, and so on. However, in reality there’s usually just not enough time to do any of that so people just pile on features at the cost of overall development becoming harder and more error prone. This is a great discussion on the subject incidentally https://medium.com/@wm/the-generation-ship-model-of-software-development-5ef89a74854b

I got Asahi working on M1, and everything works fine aside from the camera and hibernation. The second is a bit of a bummer cause the battery keeps draining fairly quickly even when you put it to sleep.

I find this tends to be more of a case in bigger companies where middle management becomes dominant.

O7

although it looks like it’s not as bad as originally seems https://grapheneos.social/@GrapheneOS/112967309987371034

I’m not the one sealioning into your threads to harass you 🤡

Seems like my home is actually living rent free in that head of yours. 😂

take a look at Apache Ignite https://ignite.apache.org/docs/latest/tools/sqlline

there’s also datafusion that lets you run SQL commands via CIL on CSV and JSON https://datafusion.apache.org/user-guide/cli/usage.html

ouch

I’ve been running my own nextcloud for around a decade now. I use it for my calendar, contacts, and file storage. It’s basically replaced all the google services for me, and has been effectively zero maintenance. It just works.

I’m sure somebody will do a proper write up in a few days.

sorry, I haven’t looked if there’s a more detailed analysis yet

here’s a good overview of what happened https://www.thestack.technology/crowstrike-null-pointer-blamed-rca/

I find small services work fine for well defined and context free tasks. For example, say you have common tasks like handling user authorization, PDF generation, etc. Having a common service to handle that is a good idea. This sort of a service bus can be leveraged by different apps that can focus on their business logic, and leverage common functionality.

However, anything that’s part of a common workflow and has shared state is much better handled within a single application. Splitting things out into services creates a ton of overhead, and doesn’t actually address any problems since you have to be able to reason about the entirety of the workflow anyways. You end up having a much more difficult development process where you need a bunch of services running. Doing API calls means having to add endpoints, do authentication, etc. where within a single app you just do a function call. Debugging and tracing becomes a lot more difficult, and so on.