The upside will mostly be the schadenfreude we'll get when, coming in Q4 of this year, the managerial class is finally called on to show ROI for the $100,000+ (depending on company size) per employee they shunted to anthropic and openai.
Sure, the world will still burn, and the economy will collapse, and the managers will still blame the doers. But it's something.
I'd say having to turn off System Integrity Protection as a prerequisite to uninstalling a music player is crazy. Spoken as someone who likes MacOS and Apple Music.
The Apple Music thing bothers me and adds friction to my life every single day that I use MacOS.
We're on a tech forum where everyone here is aware (or at least can understand) how SIP is useful for the security model on MacOS. But for plenty of people with this problem, SIP is only the thing you learn can disable so you can immediately make your life a little better.
The crazy ones are Apple here, since this problem should not require disabling SIP to fix.
You can not do this on MacOS, at least on MacOS 26 on Apple Silicon without SIP disabled. I was:
- Unable to drag from the Applications drawer to Trash
- Unable to drag from the Spotlight search to Trash
- Unable to drag from Finder (in ~/Applications) to Trash
- Unable to delete (in Finder)
- Unable to delete (through rm in terminal).
This has been a bother for years across MacOS versions and I've tried variations of these, personally.
In the future, you might consider not denigrating others in this way. It is hard to save face when you are wrong. And it is hard for others to provide an avenue for you to save face while also pointing out that your statements are not true.
As a non power of Mac (only recently switched), I'll definitely try this.
My repeated attempts to remove from Dock and hide it all failed: half the time I remove my ear buds the Apple Music pops up in the middle of my screen and auto-enables itself in the Dock...
The Dock just contains a bunch of shortcuts. The app itself lives in the /Applications folder along with the rest of them that you can choose to add to your dock (by just dragging them down there and letting a spot open up for it).
You never need to write "fix", or "prevent" if you write a good message. Nobody says "fixed the car by changing the flat tire" or "Go prevent engine wear by getting an oil change today. You say "Change the flat tire", or "Change the oil".
You can do the same when you write commit messages. "Wrap user and account update in a transaction" - "Delete temp files after use".
I disagree. I think the commit description should be "stop the engine wear", not "change the oil". I much prefer commit messages describing why you did the changes, because the explanation of what you did is already there - the code diff itself.
Whatever describes the change better. Sometimes the issue is easier to describe "fix: car steers in slalom". Where the solution would have been subtle interaction between 3 different components that only occurs in 3rd gear.
None of this is as good as "free array memory before it goes out of scope". This is better than `fix: memory leak` - which is what most people would do. It's also better than `fix: free array memory...` because `fix:` is redundant when you have a good message. I get people want to build automation around this stuff, but just do that in a footer of a commit message where humans don't need to see it.
If I'm at the point of contributing a PR to a dependency, I've already identified the root cause in detail. There's no way a change log should be going into that level of detail, or else you're just duplicating the Git log for no reason.
Will the change log make mention of fixing the bug? Perhaps. But I'm going to want to read the technical details of the fix to make sure they've specifically addressed my issue, and not just a similar problem. What is the performance impact of the fix? Are there security implications they've explained in the commit message.
I'm a software engineer, not an end user, I want the technical details of my dependencies.
There's no benefit to any of this. Just write like human. It will be clear if it's a fix, or a refactor, or ?. Typically it isn't just one of those things.
Making an opinionated absolute statement about something that's widely used and argued about isn't even logical. If nobody got any benefit, it wouldn't be a thing.
The CC standard may not be for everyone, but having some convention is often helpful. git log --pretty=oneline of structured format gives you broad filtering that's useful. Just writing like a human doesn't give you that ability and you're forced to read every line.
I gave an example right there in my previous comment (log filtering). To expand: our eyes and brains are good at pattern matching. Looking at git log --pretty=oneline with a structure lets you discard any commits irrelevant to what you're looking for without much cognitive effort (e.g. if I'm interested in a code change, I can discard any commit that starts with "docs"). You don't have to read entire lines, only scan the first few characters, or have grep do it for you.
Another example is basic metrics stored right there in git. Did changing your testing strategy result in less follow up fixes after feature deployment? You can get that signal with a shell | pipe one-liner.
Honestly I'm not die-hard CC convention, but I think it's better than nothing, which is what the person I was responding to was suggesting. If you're using an issue tracker, having a convention to prefix or trailer the commit with the issue ID is the highest value IMHO. The point is having some convention to get teams on the same page and assist with git meta work.
The "Just Say No" engineer is a person who knows what existing tools can do, while more junior people don't know what their tools can do. So junior people are constantly proposing new types of yak shaving (new architecture, new storage backend, new framework, etc) that must be done before solving the problem at hand. This is all wasted resources and time, even if LLMs let you shave yaks faster. A good JSNE focuses your resources on solving problems straight away, not pouring them all into a bottomless pit of busy work.
Reading a well written programming book will put you ahead of 99% of other programmers using that language. Most programmers learn some subset of a language to get things working, and never learn more than that.
When a cop does millions of dollars of damage they only choice is for tax payers to pay, or for the victims to get nothing. Definitely the cops should also face consequences though.
Many (most? idk) governments that employ the cops (city, county, whatever) do have insurance for this, and grant police qualified immunity. There are some attempts to hold cops liable as well - https://leg.colorado.gov/bills/sb20-217. The City Council in my town immediately restored qualified immunity for their police. Don't underestimate the level of absolute blind support for cops that exists among the US population.
They did not say governments should have legal insurance. They said cops should have malpractice insurance. Insurers calculate individual rates and want profit.
Sure, the world will still burn, and the economy will collapse, and the managers will still blame the doers. But it's something.