31,676 karma · joined July 26, 2012
Importantly, I think there's only so much advancement you can get out of people by investing in economies of scale and iterating on process (and people, as icky as that idea is), while there's a huge amount of advancement to get out of machinery, including moving to whole new categories of machinery (which depending on how far you want to take the "slaved are machines" metaphor is waht a shift away from slaves was in the first place). In that respect maybe what you're noting is just that the shift from slaves to machines was the first in an iterative process which is speeding up over time.
> If we'd abolished slavery in Roman times we might have terraformed Mars by now.
I think maybe the right was to look at it is if we were able to abolish slavery and keep the same output (which might have required an economic or social system that incentivized farm consolidation for economies of scale that plantations were able to more easily achieve), then yes, we would have terraformed mars by now, but probably just because we happened to be along the tech tree earlier in the timeline.
Perhaps most importantly, it not being an immediate change allows the entrenched interests time to shift their strategies and portfolios over time to take advantage of the more economically advantageous option. Many people aren't happy with the time frames that generally requires, but they also seem to be very happy with reliable energy and and economy that doesn't collapse overnight and having invested a year or two ago in a car which would become worthless tomorrow.
I wonder how much of that was because of economies of scale (Even if it's forced scale). Plantations are large and have many workers, and can scale without having to worry (to a degree) about retaining workers, since workers are for most intents just machines you invest in and pay to keep up in that system, which allows for easier scaling.
We've seen increasing consolidation of farms into large entities over the centuries, so perhaps this was just a system that made that much, much easier to do.
Groups of people can and do have bias, but I also think it's much harder to control the outcome (for better or worse) when inputs are more diverse.
I ask you what to use instead, and how to deal with datastore versioning.
You say you're talking about how we don't have type safety that extends to the remote systems we're interacting with.
I ask how that helps versioning problems with these systems where you need to deal with applying changes across distributes systems, which specifically is not solved by having types in lockstep definition between systems, because in application of change there are problems to work thought.
You note we did all this deliberately and we didn't have to. I keep asking you what the other option is, because you keep acting like there is one, but refusing to give an example of what that would be, because a monorepo is no solution for the problems being discussed here in the article, which to be clear, are not limited to code.
You've made it very clear you think we should have done "something" else, but refuse to articulate what that is. If it's not known, or not explored, then I posit we didn't "choose" this path, it's the path that was open to us.
> You’re discussing how to live in the house after the foundation cracked.
You keep saying we should have used something else for the foundation that wouldn't crack, but refuse to explain what this mythical material is.
What is your proposed alternative, or are you just waxing theoretical?
I came away with some additional understanding of the problem, and thinking there are various nascent techniques to address this problem, none of them entirely sufficient, but that it's being worked on from multiple directions. I'm not sure the article was aiming for more than that.
And that helps when you are dealing with schema changes that need to be rolled out at AWS, your local DB, a Kafka cluster, how? The whole point of this article was how to approach the problem when there are different components in the system which make a monorepo and what it provides for this infeasible or impossible.
> I know it's not "practical" but that's not my point. My point is that there's a huge portion of problems with "systems" that are literally obviously solvable and with obvious solutions it's just I'm too lazy to write a production grade database from scratch, sorry guys.
The article talks about database solutions that help with this problem.
I'm uncertain how to interpret your responses in light of the article, when they seem to be ignoring most of what the article is about, which is solving exactly these problems you are talking about. Is your position that we shouldn't look for solutions to the harder problems because some people aren't even using the solutions to the easy problems?
> I felt as though this article was, through its headers and overuse of specific rhetorical devices, constantly trying to grab my attention in that same shallow manner.
I think perhaps you're quick to assess a certain type of writing, which many see as done quite well and in a way that's approachable and is good at retaining interest, as AI. Perhaps you just don't like this type of writing that many do, and AI tries to emulate it, and you're keying on specific aspects of both the original and the emulation and because you don't appreciate either it's hard for you to discern between them? Or maybe there is no difference between the AI and non-AI articles that utilize these, and it's just your dislike of them which colors your view?
I, for one, found the article fairly approachable and easy to read given the somewhat niche content and that it was half survey of the current state of our ability to handle change in systems like these. Then again, I barely pay any attention to section titles. I couldn't even remember reading the ones you presented. Perhaps I've trained myself to see them just as section separators.
In any case, nothing in this stuck out as AI generated to me, and if it was, it was well enough done that I don't feel I wasted any time reading it.
Even if you were to reduce the database to a simple API, the question then remains how do you make sure to version it along with the other portions of the system that utilize it to prevent problems. The point of the article seems to be to point out that while this is a much harder problem (which I think you are categorizing as "things that can't really be easily solved"), there are actually solutions being developed in different areas that can be utilized, and it surveys many of them.
That isn't very useful by itself. What's your suggested alternative that aligns with your advice of "don't"? How does it deal with destructive changes to data (e.g. a table drop)?
This method of test passing wasn't okay when Volkswagen did it, and it's not appropriate for employees at a company that asks them to take the test, for the exact same reason.
Is it needless? It's useful specifically because he is someone influential, and someone might say "Lua was antirez's choice when making redis, and I trust and respect his engineering, so I'm going to keep Lua as a top contender for use in my project because of that" and him being clear on his choices and reasoning is useful in that respect. In any case where you think he has a responsibility to be careful what he says because of that influence, that can also be used in this case as a reason he should definitely explain his thoughts on it then and now.
My mind immediately jumped to the idea that this is a play on words for the ancient Maya civilizations, and Maya Angelou. Apparently I wasn't the only one.[1]
1: https://gamefaqs.gamespot.com/boards/197483-grandia/53620555
It probably markets and explains itself perfectly find for someone in that space and/or looking for this solution, so I'm not sure that's actually a problem, but if you also want to stick in the mind of someone that sees this and doesn't have any current interest, but may stumble into needing a solution like this in the future, a few extra words in your initial description might help it be understood more quickly and be something remembered even if they don't dive into it. Or maybe it's fine and I'm just a bit slow today.
While I don't disbelieve this out of hand, I can think of different things that might easily make this untrue. On what evidence is this assertion based? Is it just "our brains are essentially similar and much of it is not hard wired therefore they should perform the same" or is there deeper science and/or testing behind this?
We're using a combination of Zabbix (alerting) and local Grafana/Prometheus/Loki (observability) at this point, but I've been worried about when Grafana will rug-pull for a while now. Hopefully enough people using their cloud offering sates their appetite and they leave the people running locally alone.
I imagine FreeBSD could do something similar if they aren't already. IIRC FreeBSD has a Linux emulation layer (but I don't know how much attention it still gets), and it's had containerization primitives longer than linux, so some amount of filling in the gaps in containerization features and syscall tables (if needed) could possibly yield an OCI compatibility later (for all I know all this already exists).
The problem, and the reason if this doesn't exist why people probably weren't as interested in doing the work, is it would always be "mostly" compatible and working and there would be no guarantee that the underlying software wouldn't exhibit bugs or weird behavior from small behavior differences in the platform when emulating something else. Why open yourself up to the headache when you can just run Linux with containers or build what you want on FreeBSD with jails and their own native containerization primitives.