jonenst

Joined 14 years ago

Karma

117

Submissions

Member since

Jul 6

[ my public key: https://keybase.io/jonenst; my proof: https://keybase.io/jonenst/sigs/2dOVlbcPWi0HNvYTX_sxKrmFDW5KC8Io95poar3CKrc ]

View on Hacker News

Recent submissions

Comment · 6 days ago

"It might make sense to learn now, before ..." Since 2023, everything learned in Year X was 99% useless in year X+1.

"we reached the stage, probably only in the last few weeks where ..." This has also been said every other month since 2023.

Comment · 11 days ago

I'm a simple (french) man. I hear the accent, I upvote. Cheers Béatrice

Comment · 12 days ago

Wake up, Hank. That game ain’t gonna play itself. Oh wait it does.

Comment · 18 days ago

Ok but what about basic features like metrics/observability, logging/alerting?

Maybe not all projects benefit from the full package but some things are now so commoditized that you should have them everywhere (and for heavier project add readiness/liveness probes, configuration management, live documentation, connection pooling, background task scheduling, dev tools like profiling and tracing)

Comment · 19 days ago

They're both ! Exception are definitely viewed as an alternate communication channel. And stack unwinding is one aspect of the communication. See https://nedbatchelder.com/text/exceptions-vs-status#h_valuab... (and many other)

Comment · 29 days ago

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.

Comment · 1 month ago

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.

Comment · 1 month ago

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

Comment · 3 months ago

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.

Comment · 6 months ago

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)

Comment · 1 year ago

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.

Comment · 1 year ago

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)

Comment · 1 year ago

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)

Comment · 1 year ago

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.

Comment · 1 year ago

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)