nithril

If it is on-prem, calling it "cloud" computer is imho misleading / marketing term.

They do not primarily maintain free softwares, they primarily maintain softwares to better control their business models.

And it is "free" because it does not impact their business models, on the contrary

Is range really an issue if you can easily find charging spot and recharge in less than 15min?

Not yet, it is still using GPT 3.5. The access to GitHub Copilot X (GPT-4) is in closed beta [1].

[1] https://github.com/features/preview/copilot-x

There is as well that blog post introducing GraalOS [1]

But still only providing marketing information.

It sounds like they are interleaving GraalOS feature with the Oracle cloud feature, eg. for the "Run On Demand" and "Applications, not Containers".

[1] https://blogs.oracle.com/java/post/introducing-graalos

It is actually simpler to conceptualize the difference, one is stateless, the other one is stateful.

Actually structured logging exists since years like in Java https://github.com/logfellow/logstash-logback-encoder

From my experience, the challenge of a good review lies less on the how to convey but more on the capacity to set the cursor between a suggestion and an important remarks.

Same finding.

That's why that sentence in the article "but almost every technology company uses it." should be rephrased to "but almost every technology company do not need it"

From a read perspective I would agree but from a write perspective if the partition is not available? (genuinely asking)

> Why replicate data at the VM/disk level when those disks are already provided as a fully redundant system?

Azure disk replications are for the durability of the data, not the avalability of the data from a kafka perspective.

It is an improvement to better understand the glyphosate effects. Rational decision cannot be taken by only considering the glyphosate effects. Decisions have to be taken with an holistic view on the agricultural systems.

Eg. glyphosate might an option to regain control over weeds versus a systematic plow of the soil that has for consequences to damage its structure and its organisms.

Still not comparable. Session cookie requires a session datastore server side. It then requires to enable sticky session, to replicate the session between the server or to have a distributed datastore. if user information are cached it will require either a local cache or a distributed cache.

JWT token does not require that.

Both solutions requires invalidation.

Still waiting for OVH or Scaleway to be really multi AZ (>2) with a network that cannot be cut by anyone...

Might not be so obvious when summing all the cost (apex, opex). Not mentioning the difficulty to find experienced people to maintain it. Unless you are really big of course

As long as the operator is really well designed but it is rarely the case. I switched from helm to bare k8s manifest for the same reason, helm/operator can be helpful, but not when the maintainer introduces breaking change (that does not relate to the service by itself) that needs a delete/deploy of the k8s resources

On the contrary I wouldn't be surprised if the Russian defense industry is more effective (ratio result/spending) than the US one

The benefit from an app running in a container and already listening to an HTTP port with on top an horizontal autoscaler looks small. I might miss something in the approach but as watchdog requires an "HTTP-level multiplexing for requests" (so the app should listen for http), the app is already running in a container with watchdog: everything is in place to not need watchdog.

From the FAQ:

> Why do I need watchdog anyway?

> Whilst we don’t recommend it, if you’re using a HTTP microservice that conforms to the Workloads spec, then technically you may be able to get away without using it.

They do: less inputs mean that the farmer has to spend less time on the fields. Fertilizer isn't put in one shot. It is done multiple time over the year. Less means it will be done less times.

The automatization is far from being the norm (if you mean autonomous tractor). Then automatization applies to both type of agriculture. But there how do I figure? Not sure to properly understand your question, because less works mean less labors. Automatized or not.

It requires far more knowledge: an in depth understanding of the agriculture relating sciences. But less pesticides, less fertilizers, no-till certainly reduces the labor.

This article sounds like a truism.

Not true since g1gc

which problem? There is no problem, especially since the latest gc. Only tradeof

> MongoDB has identified a real pain point: many developers don't like to use SQL to interface with a transactional database.

The pain point relates less to SQL but more to the RDBMS and the rigid schema. SQL is spreading and may become a ubiquitous query language.

And the infosphere will become reality

Remenber, your primary statement was : "Virtually all Groovy work involved Grails. There's no other reason to adopt Groovy."

There are plenty other reasons to adopt Groovy, other than Grails

Your other statement are opinion, not fact.

Your statement is reductive. You can replace xtend by all the new jvm language. In fact these languages haven't proove anything. On the contrary of groovy.

On my own experience I use groovy not only for grails :

- virtually all java classes can be replaced by groovy classes. Groovy is far more concise. eg. I use groovy for spring/backed bean.

- SwingBuilder

- gpars

This is a great news. Groovy becomes more and more mature and efficient.

As for scala.