> One-Way-Door and Two-Way-Door Decisions
See also the "Linux kernel management style" document that's been in the kernel since forever: https://docs.kernel.org/6.1/process/management-style.html
Predicting the Future of Distributed Systems
11–20 of 51 posts
Re: Predicting the Future of Distributed Systems
#12[deleted]
Re: Predicting the Future of Distributed Systems
#13> One-Way-Door and Two-Way-Door Decisions See also the "Linux kernel management style" document that's been in the kernel since forever: https://docs.kernel.org/6.1/process/management-style.html
> Most people are idiots, and being a manager means you’ll have to deal with it, and perhaps more importantly, that they have to deal with you.
> It turns out that while it’s easy to undo technical mistakes, it’s not as easy to undo personality disorders. You just have to live with theirs - and yours.
this was definitely written by Linus XD
Re: Predicting the Future of Distributed Systems
#14I think the author has a point with one-way doors slowing down the adoption of distributed systems. The best way to build two way doors is to push for industry adoption of a particular API. In theory the backend of these APIs matter little to me, the developer, so long as they are fast and consistent. Some examples that come to mind is that Apache Beam is a "programming model" for Data pipelines, Akka is a "programmi…
OTel being a capture & ingest only specification is kind of messed up. There's no attempt from what I can tell for how to query or present stored data; it's just an over-the-wire specification, & that drastically limits usable scope. It means vendors each get to make their own services & backends & tools, but it's greviously limiting the effort as a whole, makes even an open spec like OTel a one-way door. Ideally OTe…
Otel works as a standard since there isn't any need to innovate at that level. Despite the over complications it has, all the implementations largely have the same requirements, and it's useful to instrument everything the same way.
Querying unfortunately has lots of room for innovation, and it's really hard to nail down in a spec especially when the vendors all want to compete.
Re: Predicting the Future of Distributed Systems
#15I think the author has a point with one-way doors slowing down the adoption of distributed systems. The best way to build two way doors is to push for industry adoption of a particular API. In theory the backend of these APIs matter little to me, the developer, so long as they are fast and consistent. Some examples that come to mind is that Apache Beam is a "programming model" for Data pipelines, Akka is a "programmi…
It boggles my mind that people accept architectures where the only dev story is a duplicate cloud instance of the required services.
Being able to bring the whole application up locally should be an absolute non-negotiable.
Re: Predicting the Future of Distributed Systems
#16Earlier quoted context omitted.
What does "distributed" mean? Looking through your link, what I see is a remote desktop app (e.g. client/server).
Puter hasn't anything to do with remote desktop. It's a desktop environment-like thing that runs in the browser, as a webpage. All its apps are HTML5 apps.
And none of it distributed. Ok.
Re: Predicting the Future of Distributed Systems
#17I think the author has a point with one-way doors slowing down the adoption of distributed systems. The best way to build two way doors is to push for industry adoption of a particular API. In theory the backend of these APIs matter little to me, the developer, so long as they are fast and consistent. Some examples that come to mind is that Apache Beam is a "programming model" for Data pipelines, Akka is a "programmi…
It boggles my mind that people accept architectures where the only dev story is a duplicate cloud instance of the required services. Being able to bring the whole application up locally should be an absolute non-negotiable.
> Being able to bring the whole application up locally should be an absolute non-negotiable.
This usually doesn't work that well for larger systems with services split between multiple teams. And it's not typically the RAM/CPU limitations that are the problem, but the amount of configuration that needs to be customized (and, in some cases, data).
Sooner or later, you just start testing with the other teams' production/staging environments rather than deal with local incompatibilities.
Re: Predicting the Future of Distributed Systems
#18I really enjoyed this article.
The one point I have issue with is that the dominance of object storage in today's distributed systems is very much due to economics, not technology. There's basically cheering every little step S3 takes towards a POSIX-like distributed file system like HDFS - "consistent listing of files, yeah!". Last week it was preconditions for writing files. There's still huge gymnastics needed in Iceberg/Delta to work with S3 given the lack of atomic rename.
Re: Predicting the Future of Distributed Systems
#19> One-Way-Door and Two-Way-Door Decisions See also the "Linux kernel management style" document that's been in the kernel since forever: https://docs.kernel.org/6.1/process/management-style.html
I really like the avoidance (elimination) of one-way-door decisions by turning them into several small(er) two-way-door decisions. I guess the software development interpretation of it is clearly defined boundaries of responsibility, and avoiding to leak implementation details beyond those?
Re: Predicting the Future of Distributed Systems
#20Earlier quoted context omitted.
Puter hasn't anything to do with remote desktop. It's a desktop environment-like thing that runs in the browser, as a webpage. All its apps are HTML5 apps.
And none of it distributed. Ok.
I guess by distributed they mean everything you do is stored in the cloud.