jonenst

My personal quiet grumbling is that everyone got on the TUI bandwagon without any rational reason. I find it borderline psychotic. Or maybe humans are much more like sheep than we care to admit: we just follow the flock into the (UI) ravine. So your GUI is a nice escape.

I wish there was a canonical write up on the governance of "java" and its history, it has changed a lot over the years (not just once I guess) and has a lot of fine prints. I find it hard to understand the hidden reasons and behind-the-scenes conflicts/compromises. There could probably be a whole book about this I guess.

Because AFAIK the filesystem is at the same time a huge API and designed for a different use case. I can think of the following examples:

- very flat structures: storing hundred of thousands of files in a single directory will fail

- designed for local disks and NFS is a leaky abstraction:

  - running a system using on locks will fail

  - cache behaviors work fine for the "humans browsing files" usecase but not so much for other cases

probably many more reasons

I find it very surprising that they went for unchecked exceptions. For JsonValueException the following rationale is given "This exception is unchecked, so that scripts and small programs are easier to read and write." But for JsonParseException there is no rationale. This is surprising especially given the pushback from openjdk members against jackson3 moving to unchecked exception.

I wonder how the legal battle will develop : the trademark https://data.inpi.fr/marques/FR5133202 is France only I think ? So a Paris resident infringed upon by a NYC resident, with content on github and also a website registered with godaddy (according to whois) and using cloudflare dns servers. Good luck sorting everything out. Although maybe the relative fame of the project will act as a lubricant/privilege in this case ? (IANAL but if this case is as obvious as it looks, speed would be good. And ideally it would be fast for any such case, not just the famous ones)

Since they had the reconciliation system because they decided the main use case was declarative, it makes sense that they used it to implement kubectl run. But they could have done it differently.

Imagine if pods couldn't reach other and you had to specify all networks and networking rules.

Or imagine that once you created a container you had to manually schedule it on a node. And when the node or pod crashes you have to manually schedule it somewhere else.

To me the core of k8s is pod scheduling on nodes, networking ingress (e.g. nodeport service), networking between pods (everything addressable directly), and colocated containers inside pods.

Declarative reconciliation is (very) nice but not irreplaceable (and actually not mandatory, e.g. kubectl run xyz)

What about kustomize and kpt ? I'm using them (instead of helm) but but:

* kpt is still not 1.0

* both kustomize and kpt require complex setups to programatically generate configs (even for simple things like replicas = replicasx2)

I'm surprised the author doesn't mention environment secrets, which I think currently are the only way to avoid that anyone with push access to any repo also gets full access to all secrets (by pushing a new workflow file and triggering it). This makes org and repo secrets practically useless for any team where only admins or maintainers should have access to secrets.

Neither Branch Protection nor the newer Rulesets allow to protect secrets from someone with push acces to the repo. From what I understand, only environment secrets provide this feature (and have the drawback that you can't share them among multiple repos in the same org without copying them everywhere, although you can script the copying with the github api)

Duplicate of

https://news.ycombinator.com/item?id=41902873

https://news.ycombinator.com/item?id=41902808

The factory must grow, to infinity and beyond !

I would have had more sympathy for the author if they explained why they care so much about github stars. It's just internet points after all. At the very end, they say "What started as a side project has recently become a company" so if it's all about business, maybe they could have made that more prominent. EDIT: sorry, not meant to be harsh. Hopefully you get what you want and thank you for writing open source software

Where are all these batteries and solar panels made ? How much GHG was emitted to build them, and how much GHG is expected to be saved by choosing this kind of electrical grid instead of alternatives ?

This website is overloaded with adds. It almost feels like a scam. Based on the fact that almost all other comments are not talking about it, I guess at least one of the following hypotheses is true (if not all of them): - most people here use an efficient addblocker - The website changed since its first appearance on the first page (maximize revenue?) - some comments are sponsored - on mobile it feels overwhelming but on desktops it's more bearable

We use socat to buffer logs sent from containers (docker-compose) during the short window at startup where logstash and elasticsearch are not ready yet. Works great!

Using java8 in 2019 is pretty normal. It's "only" 6 years old (released at the beginning of 2014), nothing like the cobol horror stories. The 6 years old java is not very different from what software you get from debian stable. The next lts java11 was released at the end of 2018 and does break some things so you need time to update. It was supported by oracle until Jan 2019, while other vendors have pledged support until 2023 and more.

And most importantly java8 is still a decent experience.

I've been doing the AoC in factor since the beginning and this year I'm trying rust. Looks like i'm following the opposite path as you are :)

I had fun participating in the google codejam using factor, and in 2012 I wasn't the only one ! https://www.go-hero.net/jam/12/languages/Factor

Too bad that google codejam limited the available languages starting from 2018..

Factor is a very impressive engineering accomplishment, the standard library has so many useful algorithms and data structures implemented, and almost all of it with very clean APIs and documentation.

They should

- remove the memoized versions (obviously it's faster)

- show the executed instructions for each language of the main loop (which would be a nice exercise with all the vms and dynamic languages)

Couldn't you use plot "./out.csv" using 1:2 with lines to have the same line graph with gnuplot ?

It's a nice visualization, but cpu usage shoots through the roof ! Deleting the animated arrows between the countries helps a bit, but then it still uses around 50% cpu (and that's on a fast desktop computer. Can't imagine my laptop trying to display this page). Using Ubuntu + firefox (it's a little better with chromium).

Is it a problem with this page ? With my setup ? Or is it just impossible to do something of this quality on the web without monster cpus ?

Wow, this article is bad. And the comments are so positive, one has to wonder how many come from the writer's friends...

This has to be a troll. Both snippets of code given in page 2 are pretty readable and self-documented. The author didn't provide an implementation of the same algorithm in an imperative language. I'd be ready to bet that the comparision wouldn't be to the advantage of the imperative language.