Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
motorest
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
36 ms
·
751.
▲
by
motorest
1y ago
> Ironically, that looks a lot like when k8s is managed by a dedicated infra team / cloud provider. There are multiple concerns at play: - how to stitch together this cluster in a way that it can serve our purposes, - how to deploy
752.
▲
by
motorest
1y ago
> You just call some DNS that is provided by sysadmins/ops. You are the ops. There are no sysadmdins. Do you still live in the 90s? I mean, even Docker compose supports specifying multiple networks where to launch your local service
753.
▲
by
motorest
1y ago
> That’s only after you compile your Ubuntu kernel and all the software. No, that's simply wrong at so many levels.
754.
▲
by
motorest
1y ago
> But GP was saying that now with k8s developers don't need to know about the network. My rebuttal is that devs never had to do that. The only developers who never had to know about the network are those who do not work with network
755.
▲
by
motorest
1y ago
> All hardware is unreliable (...) The whole point is that none of the main cloud providers runs containers directly on bare metal servers, and even their own VPS are resilient to their own hardware failures. Then there's the whole
756.
▲
by
motorest
1y ago
> I currently need a container if I need to handle literally anything besides HTTP You don't. A container only handles concerns such as deployment and configuration. Containers don't speak HTTP either: they open ports and route
757.
▲
by
motorest
1y ago
> Did they need to know this before Kubernetes? Yes? How do you plan to configure an instance of an internal service to call another service? > I've been in the trade for over 20 years and the typical product developer never care
758.
▲
by
motorest
1y ago
> When Kubernetes was in its infancy, it was quite difficult to do the PKI and etcd setup required to run a cluster - and managed services didn't exist. I agree, but it's important to stress the fact that things like etcd are o
759.
▲
by
motorest
1y ago
> I'm not a Kubernetes expert, or even a novice, so I have no opinions on necessary and unnecessary bits and bobs in the system. But I have to think that container orchestration is a new enough domain that it must have some stuff th
760.
▲
by
motorest
1y ago
> You don't, but plenty of people don't care and ask for this shit. This is probably another way of saying "buzzword-driven" as people ask for "buzzwords". That's a fundamental problem with the approach
761.
▲
by
motorest
1y ago
> Yeah, as soon as you got your helm charts and node installers. I believe there's no need to go that path for most applications. A simple kustomize script already handles most of the non-esoteric needs. Sometimes things are simple
762.
▲
by
motorest
1y ago
> It’s also possible for things to just be too complex. I don't think so. The original problem that the likes of Kubernetes solves is still the same: setup a heterogeneous cluster of COTS hardware and random cloud VMs to run and aut
763.
▲
by
motorest
1y ago
> Rivet's taking a different approach of investing in different three primitives based on how most organizations deploy their applications today: I think your take only reflects buzzword-driven development, and makes no sense beyond
764.
▲
by
motorest
1y ago
> This is just so not true. You can literally launch talos and have an N node cluster in about 10 minutes 9 of which is waiting for downloads, configs, etc. 1 min of configuration. It’s just that easy. I agree, OP's points contrast
765.
▲
by
motorest
1y ago
> If you're using k8s as a service where you've outsourced all of the cluster maintenance (from any of the cloud vendors), which part due you see as super complex? This point bears repeating. OP's opinion and baseless asse
766.
▲
by
motorest
1y ago
> This sort of "they're just building on" talk is weird to me, and not really relevant. Not really. You're not talking about technology. You're debating the economics behind it. You're seeing naive fanboys p
767.
▲
by
motorest
1y ago
> Starship hasn't had a mission yet that I'm aware of. Then you will agree that comparing an unproven launcher which seems to be far far away from being able to fulfill a similar role is a very silly endeavour, let alone talk a
768.
▲
by
motorest
1y ago
> Launched reliably... 12 times. Was it required to launch more? How many moon missions did Starship fulfilled? It seems 50 years ago SaturnV launched 12 times more than Starship.
769.
▲
by
motorest
1y ago
> To be fair, they're also doing launches at a pace NASA could only have dreamed of back then. That's like comparing how many containers Maersk moves today with how much sea cargo was moved back in the age of discovery. Also, S
770.
▲
by
motorest
1y ago
> You are comparing "sending a small crew for a few days on the Moon ASAP for propaganda purposes" with "setting up a permanent outpost on the Moon". No, OP is comparing a launcher that worked reliably (it's in t
771.
▲
by
motorest
1y ago
> for up to 0.8% US GDP per year. Today that would be $200B/year, pure spent. Where is Space X today is making, ie. it has a revenue, $15B/year. The likes of SpaceX are reporting costs in the range of $15B/year because NAS
772.
▲
by
motorest
1y ago
> CRDTs are also crazy slow due to their architecture ; You must back up your extraordinary claim with some extraordinary evidence. There is nothing inherently slow in CRDTs. Also, applying changes is hardly on anyone's hot path. Th
773.
▲
by
motorest
1y ago
> Otherwise the best she can do is "not get in the way". Playing devil's advocate, policy can be set by inertia (i.e., no one is fired for buying IBM). So a government loyalist can have the motivation to implement a policy
774.
▲
by
motorest
1y ago
Related discussion: https://news.ycombinator.com/item?id=44301186
775.
▲
by
motorest
1y ago
Is this report trustworthy? I mean, it's strange that all of a sudden conventional power plants were the sole culprit.
776.
▲
by
motorest
1y ago
> As opposed to taking like 30 seconds to install cargo and rust? I think you're oblivious to the problem domain. C and C++ projects are tightly coupled with build systems. If you are not smack middle in the happy path, you will exp
777.
▲
by
motorest
1y ago
> Unfortunately, this is not surprising. The profession has been trending sharply down since modern LLM AI has come onto the scene. I think LLMs have absolutely nothing to do with this. For years, with the inception of the cloud and chan
778.
▲
by
motorest
1y ago
> How did people live without this for c projects is beyond my imagination. They didn't. Things like Conan and vcpkg exist for almost a decade by now. Also, on any OS under the sun except Windows, the system's package manager i
779.
▲
by
motorest
1y ago
> I dunno a lot of migrations to X technology are pitched as valuable on one quality dimension. We improved performance by Y%! I'd add that more often than not these performance impacts are not due to changes in programming language
780.
▲
by
motorest
1y ago
Quantifying software complexity is still largely an open problem. There are approaches that focus on quantifying but are arguably of limited use due to their disconnect with mental models, and there are approaches that focus on evaluating m
More ›