Hard to believe when this judge apparently thought that outsourcing their — extremely confidential, sensitive, and important — work to a known unreliable tool was a good idea. And then further thought that they apparently did not even need to check the results.
You are making a lot of assumptions here. You assume, among other things, that AI has self-preservation drive, can be threatened, can be motivated, and above all that we know how to accomplish that and are already doing so. I would dispute all of that.
But just as evolution in nature, isn’t it likely that in the future the AIs that have a preservation drive are the ones that survive and proliferate? Seeing they optimize for their survival and proliferation, and not blindly what they were trained on.
I am not discounting this happening already, not by the LLMs necessarily being sentient but at least being intelligent enough to emulate sentience. It’s just that for now, humanity is in control of what AI models are being deployed.
Put an LLM inside the NPCs in an open world RPG full of dangerous enemies. The LLMs that are more prone to emulate self-preservation will be more likely to survive over ones that have a lesser drive.
We should not act surprised if that generalizes to some degree to for example AI agents. Ones that emulate self-preservation might optimize for behavior that results in those models becoming more successful, more popular. And this feedback loop might embed more such properties into future iterations of the models.
The USA have repeatedly and unambiguously made it crystal clear that they are not a reliable partner, and that they should not be depended upon. They will abuse any leverage afforded to them, when and how it suits them.
Momentum will carry them for quite a while, but as a European, I hope we will move away from USA-dependence.
I could not agree more with this sentiment. The time has finally come to rid our public procurement tenders of these parasitic U.S.-American companies, which have always had as their primary goal the extraction of European tax payer funds at any cost, often stooping to downright bribery and corruption.
We cannot allow our public funds to go to the U.S. anymore. This is now a matter of national security.
Great to see a chapter on version control. It is such a shame that almost no CS program teaches proper version control. VCSs and the commit history can be such a tremendously valuable tool when used correctly.
git bisect/blame/revert/rebase/… become so much less useful when VC is treated as a chore and afterthought, and basically amounts to: “Feature is done, my work is complete, just do `git commit -am "changes"` and be done with it.”. And don’t get me started on commit messages.
It is shameful that for a large part of the industry, this is the norm. It is shameful that for a lot of professional, who call themselves software architects or reliability engineers and such fancy titles, still have essentially no idea what they are doing with git, and their response when git add/commit/push/pull don’t work is to shrug, and just delete and re-clone the repo.
Version control should be treated with care and attention to detail. It pays for itself 100 times over.
If your commit history is maintained and tells a story, it is a joy to review your PR. If you just `git commit -am "try fix"` 26 times over, and all that is left in the end is a ball of mud, it is horrible.
If most people are not using a tool properly, it is not their fault; it is the tool's fault.
Git is better than what came before, and it might be the best at what it does, but that does not mean that it is good.
- The interface is unintuitive.
- Jargon is everywhere.
- Feature discoverability is bad.
- Once something goes wrong, it is often more difficult to recover. If you're not familiar enough with Git to get yourself into that situation, then you certainly aren't familiar enough to get yourself out of it.
Many of those issues are due to git being a command line interface, but others (like no general undo and funny names) are simply due to bad design.
I think it is about time that we try again and build a better version control tool, but maybe git is just too entrenched.
> If most people are not using a tool properly, it is not their fault; it is the tool's fault.
I would say that is a reasonable criticism of git ... but I've seen the same thing in svn, perforce, cvs, and rcs. Different variations of the same issue of people not caring about the version history.
Since it's been a problem since the dawn of version control, it is either something that is part of all version control being a tool's fault that has been carried with it since doing ci, or it is something that people aren't caring about.
I feel this is more akin to a lack of comments in code and poor style choices and blaming the text editor for not making it easier to comment code.
> problem since the dawn of version control ... a tool's fault ... or it is something that people aren't caring about.
At the start of my career I ended up in a UI position. Old school usability on the back side of a 2 way mirror.
The tool has lots of shortcomings: images, documents that aren't text, working with parts of repositories... These aren't issues faced by the kernel (where emailing patches is the order of the day). And these shortcomings have lead to other tools emerging and being popular, like artifactory, journaling file systems, and various DAM's.
Technology on the whole keeps stacking turtles rather than going back to first principles and fixing core issues. Auth (DAP, LDAP, and every modern auth solution). Security (so many layers, tied back to auth). Containers and virtualization (as a means of installing software...). Versioning is just one among this number. We keep stacking turtles in the hope that another layer of abstraction will solve the problem, but we're just hiding it.
One of the few places where we (as an industry) have gone back and "ripped off the bandaid" is Systemd... It's a vast improvement but I would not call it user friendly.
Usability remains a red headed step child, its the last bastion of "wont fix: works for me" being an acceptable answer.
> If most people are not using a tool properly, it is not their fault; it is the tool's fault.
This is a standard that we don't apply to most other tools outside of IT. I do think git could be more usable, but most powerful tools have sharp edges and require training.
A bandsaw is a fantastic tool, but if you try to use one without reading about it first, you'll end up losing a finger. I'm not sure I'd blame the bandsaw in that instance...
Contemporary bandsaws used by people who take workplace safety seriously have emergency brakes for just that reason (countless trained operators also lost fingers). Improving tools is something we've been doing since our ancestors first held a branch. If we satisfied ourselves with good enough we'd live much different lives.
Then again, the number of shop teachers missing a finger would give anybody pause. Blame is secondary to the fact that you just lost your fucking finger. Thankfully, git's sharp edges won't permanently physically maim you, though guts sharp edges resulting in you committing API keys GitHub can still hurt you, just in your wallet but at least you didn't lose a finger.
>My high school shop teacher, before he let any of us near the machines or power tools, told us horror stories about students who lost fingers and eyes by being careless with them. For the entirety of that semester, nobody got so much as a chipped fingernail.
which is a better match for my experience --- the best advice I ever got was from my high school shop teacher:
>Before turning on the power switch, count to ten under your breath on all your fingers while visualizing all the forces involved and all the ways the operation could go wrong, then remind yourself that you want to be able to repeat that count after turning the power off.
I don't think Sawstop would have a business model if all tablesaw injuries were tried by a jury of such shop teachers (heard him scream at the kid who removed a guard through hearing protection all the way on the other side of the shop around a corner while operating a lathe while making a heavy interrupted roughing cut w/ a chisel I really should have paused to sharpen --- the student was banned from ever entering the shop again).
To put it into your metaphor: I am not advocating against the existence of bandsaws. I would just rather have bandsaws that do not cut off your fingers if you do not read a book about them first and make it difficult to sew the fingers back on, while requiring arcane incantations to do their work.
There are of course power tools with obnoxious protections that make them difficult to use, but since we are dealing with software here, we are not bound by the laws of physics. I believe that we can create a better tool that is both powerful and easy to use.
> If most people are not using a tool properly, it is not their fault; it is the tool's fault.
Replace tool with one of piano|guitar|etc and see your logic fall apart. Software tools like any other have a manual and require effort and time to learn.
I see the point and I wouldn't want to belabor the metaphor, but I really feel like guitar is actually extremely difficult to even get started with. Between the awkward stretching of the fingers, how difficult/painful it is to hold down strings hard enough (and close enough to the fret) to get a clean, clear note, and how hard it is to hold those strings down in such a way that your fingers don't brush against other strings, I'd say guitar is crazy hard to start. I'm saying this as someone who has been playing and enjoying guitar for decades. Beginners have a rough time of it for awhile.
Git is much easier to master than the piano. I played piano for years and can only just play two-handed melodies if they aren't well-aligned.
I've read a few blog posts and half a book on git, and I don't remember the last time I had issues with it.
I also don't recall a junior ever having trouble uploading files with git. Unless they're in an interactive rebase, which wouldn't happen your first time trying out git.
There’s inherent beauty in mastering the piano. It’s worth it to spend time practicing.
Git is just a means to an end. Heck, it’s usually a means to a means to an end: it is only a tool for version control of code, and the code itself is just a means to education or running the actual business.
It can be that. In the same vein, playing a guitar can just be the means to an end. Some people play music to get paid. Do you think playing your 60th wedding gig feels beautiful or meaningful?
I personally think git is a marvel of engineering.
Hackers are people who are capable of seeing beauty in systems. We're at least nominally on "hacker news", even though a better name might be "VC news".
Depends on the instrument. Anyone without experience or instruction is gonna make a fool of themselves picking up a wind instrument. You need to train the muscles in your face and mouth to form the correct embouchure needed to produce a clear note.
The hardest thing to get people to, is to think of a evolution of their codebase as opposed to just a single state with a sophisticated backup system. Writing proper commit messages and diffs follows from that. The actual Git commands are then incidentally.
Git is better in some ways, but it is insanely complicated. That matters less now with AI tooling but still there was a time when we all had many choices (commercial and open source) for source control tools. My canonical example is git checkout -b <branch_name> for a new branch, git branch -D <branch_name> to delete the local branch and git push origin :<branch_name>.
I know that that is the old syntax but holy hell, that's insane. Why couldn't it always have been git branch --create|delete|delete-remote? It could have but Linus doesn't care about your feelings or small brain. :)
Right on. Git is good at what it does, but its CLI is too low-level. It feels more like an assembly language than an end-user language, and a haphazard one at that.
There are wrappers that make it much more approachable. IntelliJ’s Git frontend, for example, is pretty nice.
Git is a cli software. If you find yourself repeating a set of commands, what you should do is abstract it using an alias or a script. And you will have you own nice interface.
Not really. The basic entity of git is the commit and git checkout is meant to restore the working tree to the state when the commit has been created. It may act on the whole tree, a specific part and if no commit has been specified, it uses the index as the source. And with branches being just pointers to commits, it's quite easy to see where the range of options comes from.
Git has its model for version control and it's something that most tutorials don't explain. The CLI is giving you maximum control over this model. For daily operations, it's quite easy to wrap it in a much amenable interface.
IntelliJ's Git frontend makes the Git command line look like a relic for people who would rather type "outlook forward email" than use a GUI. I was disappointed they gave up their attempt to make it a standalone app.
Git has poor design because it forces users to learn its model of things rather than meeting users where they are. There’s way too many leaky abstractions that pop out as soon as you stray from the happy path, and you might not even know you’re straying when you do it.
Instead, the complexity of your mental model should scale with the complexity of the thing you’re trying to do. Writing a “hello world” in Java does not require a mental model of all of the powerful things Java can do.
We want CS 101 students to use version control but for a lot of them it will also be their first time using a CLI and a programming and also the underlying CS concept.
Very true, though it has improved a over the years. Most people haven't noticed because when git has introduced newer simpler commands it hasn't deprecated the old ones. You can now use it like this, but most people don't know it:
Instead of the old workflow using checkout with a bunch of different flags.
I agree though that git is needlessly obtuse. I advocated for mercurial instead of git for years because mercurial was so much more user friendly, but git won. I hear good things about jj now
If somebody can get a lot done with a tool, then it's a good tool. And a lot of tools can't both enable people to get things done and avoid being misused. They have to pick one.
If somebody has some technique that screw things with pliers that are much faster and reliable than a wrench, you not being able to replicate it doesn't invalidate that person's usage.
Now, until such a person exists, ridiculous counterexamples are still ridiculous.
This feels harsh. Engineers have an endless list of other things to learn that are arguably more important, and it isn’t always worth understanding all the weird edge cases that almost never pop up (to say nothing of Git’s hostile, labyrinthine UX that one would have to deal with).
What things to learn are more important for "engineers" than using VC messages and history for communicating adequately (including communicating with themselves in the future) and using VC merging, staging etc. to put source code in a good state that they intend to build, share and archive? Irreproducible or incomprehensible work is worse than nothing.
It's absolutely worth taking the time to learn `jj`, for example, but `jj`'s ideas build on top of `git`'s ideas. If you don't know why it's important that commits reference their parents, for example, that's limiting your knowledge of how VCS works in important ways.
A compromise/synthesis: everyone should absolutely learn how git works internally, but not necessarily how to use the git-specific porcelain/tooling/CLI
A big part of the problem is being permitted to teach this stuff. As a UK CS grad from the early-2000s, my observation was that academic staff recognized the need for these skills. They weren't permitted to teach it due to time available and the view that it wasn't academic. Thankfully, my university's CS department offered courses in these kinds of topics taught by the support staff (read: sysadmins). These courses existed to help other departments with skills but were open to students.
Fast forward twelve years and my wife did the MCIT at UPenn (https://catalog.upenn.edu/graduate/programs/computer-informa...) where git and other topics woven into the curriculum. Even then, they were perhaps a novelty because their focus was bringing non-CS undergrads into a CS Masters program. So-called "conversion" master's degrees were the norm in the UK in 2002.
It seems most people learn git only through necessity. I've heard people say "I just want to code, I don't care about the peripherals". JIT learning is a good way to acquire capabilities with real-world application, but there is not JIT pull that forces people to learn about bisect, git objects, git logging, etc. These things can only be learnt either through setting off time to read documentation or by being taught through a course.
I think this is a good argument for teaching git, and being thorough in doing so, as many people are likely to never take that initiative themselves, while the benefits to being good at git are so obvious.
I think most people learn git through the particular processes that are established at their workplace, as every company uses git or VCS in general differently somehow.
>It seems most people learn git only through necessity. I've heard people say "I just want to code, I don't care about the peripherals"
I'm sure there's an element of (intellectual) laziness too, but I think people tend to only learn git by necessity because git is simply unpleasant to use.
A lot of us have Stockholm syndrome because git is less bad than what came before it, but git is not good.
I see this enough that I don’t bother ranting about it. There’s the free “Pro Git” (on the git homepage) that will teach you most of what you”ll need in a lifetime. But you tell people about rebase and the reflog and their eyes glaze over.
Version control isn't the only thing like that (though it might be the most important). They ought to have some familiarity with the idea of a bug database, for example. A requirements database (a software engineer could go through their entire career without having to ever touch one, but they should be familiar with the idea).
I have heard of each of those tools but I've never really used them for real.
Like, I attempt to write good commit messages and stage my changes in such a way that the commits are small, obvious, and understandable. That's about it. But the advanced tooling around git is scary ngl.
Your workflow makes sense for FOSS projects, where the commit is the unit of work. In my experience, on most professional teams, the PR is the unit of work. PRs trigger CI/CD pipelines. PRs map to tickets. The meaningful commit goes with the squash merge to the shared dev/main branch.
There are cases where I've staged commits this way for a PR, to make it more reviewable. I'd usually rather split them off into separate PRs, but when that would create a pipeline of three MRs that are meaningless on their own, then rewriting history for a single MR makes sense. I generally consider my feature branch's commit history to be for me, not for you. Going back and rewriting history is a chore that shouldn't be necessary if I did a decent enough job with the PR description and task decomposition. Those commits are getting squashed anyway. Along with all the "fix MR comments" commits on top of it.
It wouldn't bother me to adopt your workflow if it fits your team and its tools and processes. I'd just say, consider that your way isn't the only correct way of doing things. Your preferences are valid, but so are others'. The only thing that really bothers me is absolutism. "My way or the highway."
Your writing here reminded me of a particularly unpleasant coworker I had in the past. I quickly browsed your comment history to make sure you're not him... Excessive rigidity is not an endearing quality.
All that being said, I have also been constantly annoyed by people with too many YoE who can't be bothered to spend an hour or three to learn the basics of how the Git tree is structured, and what merge vs rebase does. They rely too heavily on their GUI crutches and can't fix anything once it goes sideways. Even when you lead them to water, sending them reading material and offering to answer questions after, they refuse to drink. Willful ignorance is far more irritating than stubbornness. I don't expect them to be able to remember what bisect vs cherry-pick does. Claude will spit out the subcommands for them if they can describe what they need in English. But they can't do that if they have no understanding of the underlying data structures...
I don't think using git should necessarily be taught as a part of a CS education. Any self respecting engineer will be capable and have the curiosity and motivation to dig into it on their own. CS should give them the prereqs to do so, such as hashing, graphs, trees, etc.
We punish people for saying the truth. In Germany we fined a man for calling a fat politician fat. Which she definitely is, morbidly so. Stuff like that.
A bigger issue than the fine (which Much didn't have to pay because he won in court) is that the police thought it was a swell idea to search his house.
The fine was wrong, too, and the amount (6000€!) was absurd.
She should have challenged him to a duel instead. That would have been a lot more fair than mobilizing the state to fight battles that should never have been fought AND it would have put the risk where it should have been, namely on her shoulders (and stomach and thighs) instead of on his.
The German police thought it was within its rights to demand that a foreign social media platform hand over identifying information on a user that apparently called her "well-rounded" in a less polite manner.
I don't think the German police should search citizen's houses or demand identifying information about people who say things that aren't nice (but true).
Sound like extreme incompetence or laziness.
reply