strictfp

"some customers may experience a slight elevation in error rates" --> everything is on fire, absolutely nothing works

"some customers may experience a slight elevation in error rates" --> everything is on fire

Pretty much every linux tool pulls these shenanigans. I hate it when there's no flag to control output.

Generally I agree. Humans are much better at recognizing patterns than machines.

But as a counterpoint I was once working in a project where our monitoring dashboard showed an anomaly in incoming traffic. It turned out that it was an ISP problem and that we were the first ones to notice according to them.

So maybe part of the answer as to why customers are faster is that different monitoring systems are monitoring each other :)

Balkanization in the licensing models is the biggest problem for people outside of the US. There is a lot of media that I cannot buy digitally. Some of those I can buy in physical formats, and some I just straight up cannot buy. Period.

My biggest gripe with continuations, futures and callbacks is the propensity for stalls; if the programmer makes a mistake it's quite likely that the program will just stall, with very little insight available as to why that happened.

With threads, green or not, you have a much clearer failure model and is easier to debug.

I probably supressed my memories of connection issues :D I love DVCSes, hated not being able to work offline I agree with the time lapse view and p4merge. Maybe one should hack together a time lapse tool for git? :thonk:

If you read my post again, you'll see that I already mentioned rerere :)

Welcome to Docker, I love you

IMO conflict resolution is almost always harder than redoing the change by hand, especially while looking at the old diff and redoing it towards the new branch. Kind of ironic given how hard diff editors try to help.

I really liked Perforce changelists, so in theory I should like the staging area, but I kind of don't :)

I use it nowadays, but I think it's too limited to provide value like Perforce changelists does.

I'd like to have one changelist for random local dev changes, like setting debug flags or turning off optimizations. Stuff I have no plan on checking in.

Then I'd like to group my edits into maybe one to three possible future commits.

The staging area doesn't allow this, I need to keep doing "git add -p" and carefully sidestep all the debugging stuff, plus that I can only work on one commit at a time.

So could have been useful, but not so useful in it's current state IMO.

git-remove-ref-format vigilantly removes non-annotated remote ref formats using non-configured upstream branches, while applying applicable parents to transfer the given ref formats.

https://git-man-page-generator.lokaltog.net

Yeah, but they denied the problem for the longest time, so they deserve some flak for it :)

I don't know, git doesn't have very good memory when doing rebases. You need to redo the same conflict resolution several times. You need rerere to get around that. Plus that it's quite hard to rewrite dates, names, or split commits into several.

Intersting. I always found git needlessly obtuse, with for instance the status reporting diffs to local remote-tracking branches instead of the actual remote branches, the staging area having an unclear purpose to me at the start, that it mixes up "local" "remote" and "base" depending on how an operation is implemented, commands doing double duty providing wildly different functionality etc..

Agreed. Perforce has much better UX and tooling than git though.

I love git because it's fast, but the UX is trash

"How should I change to a different branch?" asked the programmer.

"Use git checkout."

"And how should I create a branch?"

"Use git checkout."

"And how should I update the contents of a single file in my working directory, without involving branches at all?"

"Use git checkout."

https://stevelosh.com/blog/2013/04/git-koans/

Did you ever use any other VCS?

I think the mental model is "I can use this tool, since it's hard it will make me look smart"

BuT It MaKEs SeNsE If YoU KnOW HoW ItS ImPleMEnTeD

In change management they argue that companies tend to purposely slow down change over time to become more predictable and lock in on the "successful route". That certainly mirrors my experience. The only thing I don't understand is why you hire so many people when you let a few handful people gate everything. You might just as well fire 80% of the workforce.

Oracle is a hot mess but it also has some really powerful features, like table sharding , that actually works if you manage to set it up correctly.

Not true. People are trying to use the mental model of a huge stateful desktop app and apply it to the web. That's not to say it's a good idea to use that model, far from it.

The web was designed to avoid it for multiple very good reasons. In fact, the success of the web has partially been attributed to those very design decisions, so it might make sense to pay attention to them.

There's nothing intrinsically wrong with say ZK, it's very powerful, but my point is that you should avoid these systems if you can. Distributed concensus is not an easy problem, it's very error prone, and if you do this more than you absolutely have to you're doing it wrong.

Having built many distributed applications I would hesitate to use ZK/consul directly, mostly since your cloud provider is already providing most type of primitives directly or indirectly in the services they provide.

My stance is: why even have any of those? Are you running in a local datacenter?

Press x to doubt

I disagree. The idea with REST is to push state to the backend, and add links to substates, so that the protocol doesn't have to be stateful, and logic is pushed to the edges of the network.

SPAs breaks this principle by making webpages into fully fledged apps who do their own state tracking and navigation. This was never the intention of REST. The idea was to make the webpages themselves linkable RESTful substates of the application, and having the browser do the rest.

From the SPA angle, RPC might look like a good solution. But RPC in itself doesn't solve any problems except literal remoting.

A RESTful API makes states linkable and removes ordering dependences from the API.

Look at web frameworks which tried to make web sessions stateful. They are dealing with all the pains that REST solves.

I wouldn't say so. The problem is the cyber warfare market created by nation states. If it wasn't for those large spenders, we wouldn't be where we are right now.

IMO nation states had a very negative influence on the internet, bringing secrecy, warfare, balkanized markets, mandatory identification and other closed concepts to a place that worked on open principles.

If states would invest more in security advancement and open research than in warfare, we might have been in a better position.