141–150 of 307 posts
Earlier quoted context omitted.
Actually it was more like "new team got in charge" actually. There is a FOSDEM 2019 talk about it.
Thanks! The talk: "The clusterfuck hidden in the Kubernetes code base" https://fosdem.org/2019/schedule/event/kubernetesclusterfuck...
> We look at what it would take to begin undoing the spaghetti code that is the various Kubernetes binaries
Well at least the developers are being frank about it I guess.
Earlier quoted context omitted.
How it isn't? You just explained it quite well. Not to mention that the Web is now full of discussions around this, with official posts from Oracle, Red-Hat, Amazon, IBM, Azul, Microsoft explaining how to go forward.
Figure out what you would pay if you used it in an elastic ECS setup. Using only Oracle documentation as a guide :)
But assuming that Oracle support is actually desired, here is what you are asking for.
https://www.oracle.com/technetwork/java/java-se-support-road...
https://www.oracle.com/java/java-se-subscription.html
https://shop.oracle.com/apex/f?p=DSTORE:2:::NO:RIR,RP,2:PROD...
Old Java dog here.
But lets just forget about the efforts from AdoptaJDK, Red-Hat, Amazon, Azul and bash Oracle, it is more fun.
Earlier quoted context omitted.
I'm not a fan of relying on distro package managers for installation of runtime dependencies on servers. Too many opportunites for variables to creep in if the version isn't locked, and then having to make sure all the package manager dependencies and config themselves. Even if you automate you're still at the mercy of the repo to have the version you need etc. and often times you need to customize the install for a…
What's the alternative? Not installing the dependencies so the app doesn't work?
> Java was excluded from consideration because of the requirement of deploying the JVM and associated libraries along with any program to their production servers. This was an amount of operational complexity and resource overhead that was as undesirable as the unsafety of C or C++. Just so everyone here is aware, this is by now an outdated complaint against Java. https://vertx.io/blog/eclipse-vert-x-goes-native/ I'm…
Earlier quoted context omitted.
Rust's package managment (cargo) is the best thing I have ever seen of it's kind. The very basic thing you can do is: cargo new funkyproject Which creates a new barebones rust project called "funkyproject". Every dependency specified in it's Cargo.toml will be automatically downloaded at build (if there is a new version). When a build is sucessful the versions of said dependency will be saved into a Cargo.lock file.…
> Every dependency specified in it's Cargo.toml will be automatically downloaded at build (if there is a new version). Why do people want this? The builds are no longer reproducible, security and edge case issues can come out of nowhere, api changes from an irresponsible maintainer can break things, network and resource failure can break the build, it's just a terrible idea. The proper use of a semvar system is entir…
Earlier quoted context omitted.
Well, speaking from experience with a JBoss application layer in a recent software project I worked on: New java versions do break existing libraries or apps, and need to be tested thoroughly. When the company hasn't budgeted for that expense, it becomes difficult to update. Often an architect or software team will insist on using the Oracle JVM rather than the included openjvm. That adds extra steps to download, sto…
> New java versions do break existing libraries or apps Have you used the Rust compiler? My experience tells me that any Github Rust project not updated in the last two years doesn't work with my Rust compiler. Whereas Java apps written a decade ago still compile and run on OpenJDK/Oracle often with zero or near zero changes. > Often an architect or software team will insist on using the Oracle JVM rather than the in…
Please file bugs against the Rust compiler then, because that would be a serious violation of the compatibility rules!
Earlier quoted context omitted.
Actually it was more like "new team got in charge" actually. There is a FOSDEM 2019 talk about it.
Thanks! The talk: "The clusterfuck hidden in the Kubernetes code base" https://fosdem.org/2019/schedule/event/kubernetesclusterfuck...
> The audience walks away feeling empathetic that they aren’t alone in their journey to writing idiomatic Go and is now equipped with strong refactoring techniques developed by some of the world’s top engineers for the Kuberentes project.
As an occasional user of kubernetes, minikube etc. it's not something I would have guessed to have been developed by the word's top engineers.
I mean kubernetes tries to, and probably manages to provide an useful abstraction, but at a few million LOC and a few man-month of full time senior engineering effort to run anything in production it's not exactly a epitome of elegant and efficient engineering.
Earlier quoted context omitted.
Figure out what you would pay if you used it in an elastic ECS setup. Using only Oracle documentation as a guide :)
Why should I? There is OpenJDK for that. But assuming that Oracle support is actually desired, here is what you are asking for. https://www.oracle.com/technetwork/java/java-se-support-road... https://www.oracle.com/java/java-se-subscription.html https://shop.oracle.com/apex/f?p=DSTORE:2:::NO:RIR,RP,2:PROD... Old Java dog here. But lets just forget about the efforts from AdoptaJDK, Red-Hat, Amazon, Azul and bash Oracl…
None of that helps you with what the charge is when you're elastic, or using multiples of hyperthreads that don't add up to a integer number of cores. I agree that OpenJDK is a better idea.
Earlier quoted context omitted.
> Every dependency specified in it's Cargo.toml will be automatically downloaded at build (if there is a new version). Why do people want this? The builds are no longer reproducible, security and edge case issues can come out of nowhere, api changes from an irresponsible maintainer can break things, network and resource failure can break the build, it's just a terrible idea. The proper use of a semvar system is entir…
Reproducibility was a core concern for cargo. Your parent is incorrect. A lock file means that your dependencies are never updated unless you explicitly ask for an update.
Rust is no worse here than say Haskell with cabal or stack or Swift with whatever they were using I forgot or go for that matter.
Earlier quoted context omitted.
The paper makes it clear they were evaluating languages based upon efficiency. The rust implementation was more efficient than the JS one. A CPU bound service of course is bottlenecked at the CPU, and this benefits from efficiency. At scale, it makes sense to replace this with Rust. Javascript did the job, but did not provide the same efficiency as Rust.
I'm not clear on why this is particularly CPU heavy, though: "the authorization service that determines whether a user is allowed to, say, publish a particular package"