Nah, hackthebox and many other red team simulation type sites have strict rules of engagement. You’re there to solve a puzzle as defined by hackthebox, not get around the puzzle by hacking hackthebox.

The amount of people who say they do agile/kanban/scrum but have never talked to a customer/end user, let alone released something, is frightening

You don’t necessarily need types for that kind of thing though, a strict linter that flags that code works just as well

We used to do this with thumb drives. You can get a 128G usb3 thumb drive these days for like 20 bucks in the checkout line of most electronics stores. Cool things about a thumb* drive is I don’t need to pay a subscription fee for it, it doesn’t need an Internet connection, and it isn’t liable to be rifled through by Microsoft unless Bill Gates comes to your house and steals it from you.

With other AIs

Just like any software design principle, it’s understood at a surface level by tons of bad developers who then try and solve every problem with that one principle. Then slightly better developers come along and say “ugh this is gross, OOP is bad!” And then they avoid the principle at all costs and tell everyone how bad it is at every opportunity.

anything we can do to push gaming into Linux would help it to become a better everyday OS

I feel like the SteamDeck and SteamOS have already done more for Linux gaming than ChromeOS ever had the potential for.

Sounds like he doesn’t want to spend his time tinkering, but playing.

Ehhh, I feel like this person is a tinkerer, it’s just the things they wanna tinker with don’t play nice with Linux.

Installing a modded version of Minecraft indicates a desire to tinker. Roblox is a game based around the concept of tinkering. EA games (especially ones from 7 years ago) require some level of tinkering even in Windows.

I get so many cloudflare captchas browsing on Firefox. They mostly go away when I change my user agent string to Chrome. Making the Internet more hostile for a particular group of users is pretty shitty behavior in my book.

Compiling to bash seems awesome

See, i disagree because

I don’t think anyone other than the person who wrote it in amber will run a bash file that looks like machine-generated gibberish on their machine.

Lol I barely want to run (or read) human generated bash, machine generated bash sounds like a new fresh hell that I don’t wanna touch with a ten foot pole.

He used to have some charisma lol. Also the early Linus Tech Tips content, like back when they were running it out of someone’s house, was usually pretty entertaining. Back then the content was much more silly and creative though, and much less corporatized.

Don’t put words in my mouth.

a more sensible default would be -A

No it wouldn’t. You’d have git beginners committing IDE configs and secrets left and right if -A was the default behavior.

vim, less a text editor and more a cruel joke of figuring out how to exit it.

Esc, :, q. Sure it’s a funny internet meme to say vim is impossible to quit out of, but any self-respecting software developer should know how, and if you don’t, you have google. If you think this is hard, no wonder you struggle with git.

it chose defaults that made sense to the person programming it, not to the developer using it and interacting with it.

Just because you don’t like the defaults doesn’t mean they don’t make sense. It just means you don’t understand the (very good) reasons those defaults were chosen.

Git has a steep learning curve not because it’s necessary but because it chose defaults that made sense to the person programming it, not to the developer using it and interacting with it.

Git’s authors were the first users. The team that started the linux kernel project created it and used it because no other version control tool in existence at that time suited their needs. The subtle implication that you, as a user of git, know better than the authors, who were the original users, is laughable.

git add with no arguments outputs a message telling you to specify a path.

git commit with no arguments drops you into a text editor with instructions on how to write a commit message.

git push with no arguments will literally print the git push --set-upstream command you need to run if your branch has no upstream.

Again, I recognize that git has a steep learning curve, but you chose just about the worst possible examples to try and prove that point lol.

I am not doing anything complex with it

So basic, well documented, easily understandable commands like git add, git commit, git push, git branch, and git checkout should have you covered.

the CLI surface area that’s exposed to me is by and large nonsense and does not meet me where I’m at

What an interesting way to say “git has steep learning curve”. Which is true, git takes time to learn and even more to master. You can get there solely by reading the man pages and online docs though, which isn’t something a lot of other complex tools can say (looking at you kubernetes).

Also I don’t know if a package manager really compares in complexity to git, which is not just a version control tool, it’s also a thin interface for manipulating a directed acyclic graph.

There are tons of wrappers for git, but they all kinda suck. They either don’t let you do something the cli does, so you have to resort to the arcane magicks every now and then anyways. Or they just obfuscate things to the point where you have no idea what it’s doing, making it impossible to know how to fix things if (when) it fucks things up.

The best part is they don’t understand the cost of that retraining. The non-engineer marketing types in my field suggest AI as a potential solution to any technical problem they possibly can. One of the product owners who’s more technically inclined finally had enough during a recent meeting and straight up to told those guys “AI is the least efficient way to solve any technical problem, and should only be considered if everything else has failed”. I wanted to shake his hand right then and there.

Listing those requirements up front would make things way easier for brute force attackers

Seriously, ask yourself, how often did the need arise to look into old commits

Literally every single day. I have a git alias that prints out the commit graph for my repositories, and by looking at that I can instantly see what tasks my coworkers are working on, what their progress is, and what their work is based on. It’s way more useful than any stand-up meeting I’ve ever attended.

I’ve been in the industry for a few years now and I can literally count on one hand how often I had to actually look at commit history for more than maybe 10 commits back.

I’ve been in the industry for nearly 15 years, but I can say that the last 3 years have been my most productive, and I attribute a lot of that to the fact that I’m on a team that cares about git history, knows how to use it, and keeps it readable. Like other people have been saying, this is a self fulfilling prophecy - most people don’t care to keep their git history readable, so they’ve only ever seen unreadable git histories, and so they think git history is useless.

I honestly don’t see a use case that would justify the overhead.

What overhead? The learning curve on rebasing isn’t that much steeper than that of merging or just using git itself. Take an hour to read the git docs, watch a tutorial or two, and you’re good to go. Understand that people actually read your commit messages and take 15 extra seconds to make them actually useful. Take an extra minute before opening an MR to rebase your personal branches interactively and squash down the “fixed a typo” and “ran isort” commits into something that’s actually useful. In the long run this saves time by making your code more easily reviewable, and giving reviewers useful context around your changes.

It’s always just “but what if X, then you’d save hours!” But X never happens or X is caused by a fucked up process somewhere else and git is just the hammer to nail down every problem.

No, having a clean, readable git history literally saves my team hours. I haven’t had to manually write or edit a changelog in three years because we generate it automatically from our commit messages. I haven’t had to think about a version number in three years because they’re automatically calculated from our commit messages. Those are the types of things teams sink weeks into, time absolutely wasted spent arguing over whether this thing or that is a patch bump or a minor bump, and no one can say for sure without looking at diffs or spinning up multiple versions of the code and poking it manually, because the git log is a tangled mess of spaghetti with meatballs made of messages like “finally fixed the thing” and “please just work dammit”. My team can tell you those things instantly just by looking at the git log. Because we care about history, and we keep it clean and useable.

To keep your analogy, most people’s git histories, when using a merge-based workflow, is the equivalent of never cleaning the kitchen, ever.