Yes it does. They don’t have to pay $200k/yr + $50k immediately, and don’t have to spend the time, effort, and money on self-hosting and migrating away.
It solves it for this one client. It doesn’t provide any transparency on exactly how this occurred (like you would for say, a data breach) and provides no guarantees (only words) that this won’t happen again, or any guarantee that this isn’t happening to any other client right at this moment!
This entire article is a strawman. It fails to even understand the basic important problem lock files try to address.
Sure, I can deterministically resolve the same X.Y.Z versions of packages according to whatever algorithm I like.
But literally everything is mutable (read: can be compromised). Package managers, bytes flying over the network, build servers - all mutable. A published version of a package can be overwritten. Some package managers allow authors to overwrite existing versions.
That means no guarantee of reproducibility. I build again the next day, and I may not download the same code for the same X.Y.Z version of a package. Or my local cached packages may have changed.
So I need checksums on packages. Then I can prove I have the exact same code in those packages. And if I have checksums on packages, I have a lock file.
> lockfiles are an absolutely unnecessary concept that complicates things without a good reason
What is even the complication? The lock file is autogenerated on a successful build and I commit it. It's trivial to use. It's literally all benefit and no downside.
> Gradle suffers the same exact issue by default, because it inherits it from Maven
It's not the exact same issue because Gradle and Maven have different conflict resolution:
Maven dependency conflict resolution works with a shortest path, which is impacted by declaration ordering. Gradle does full conflict resolution, selecting the highest version of a dependency found in the graph.
Reflection is slow and bug prone. Struct tags are widely considered in the Go community to be a nasty hack yet a necessary evil. They should be used at little as possible because if you mess them up you don't get a compile error, you get a runtime error.
Beware of microbenchmarks, but in my tests the above package only added around 0.001 ms over the standard library flag package. Even if real world usage increases that by several orders of magnitude, it isn't going to matter. No human will ever notice.
I'm on Sonoma (14.5). In System Settings > Siri & Spotlight,
1. I can deselect some pre-defined categories that Spotlight searches
2. I can click the "Spotlight Privacy..." button (at the very bottom right). Then I can add folders for it to ignore.
(My preference is for Spotlight to ignore almost everything, so that it isn't indexing stuff and eating CPU on this old Macbook Air. I only have it scan Applications, Calculator, and System Settings. I have it specifically ignore my entire home directory which is where all my git repos are.)
Are you saying that if I limit the Spotlight search space then Alfred will follow? Makes sense, if it's relying on Spotlight's index. I'll give it a try.
As if there was no bullying in any other age? Is Apple's walled garden really the source of this bullying? Teenagers can bully each other about anything.
With how long it's been on the front page, how controversial it is, and the fact that it was posted earlier and that post _was_ flagged... I would be willing to bet a moderator has somehow disabled the ability for this post specifically to be actually flagged and is simply ignoring those that click the flag button.
I'm sure that seems conspiratorial but the guy writing the post effectively "cuts the checks" for the moderation staff here.
That's not the point - the point is there is a clear conflict of interest between users and moderation when it comes to unflagging a post from the forum's creator.
Even if you are somehow totally impartial (and it's hard to imagine from my point of view, due to information asymmetry and very mild cynicism) it would still be wise to "recuse yourself" - similar to the guidelines about how moderation happens less when it comes to topics directly discussing ycombinator.
This seems obvious to me. I'm not even particularly fond of the user flagging system. It's so clearly ripe for misuse by people trying to effectively censor topics they personally don't like. But if that system is in place, and another system is used to occasionally remove it- the latter system should be used with more care than has been done here. Not because you're definitely corrupt- but because the optics on it are not in your favor at all and it would be challenging if not impossible to alleviate those concerns.
Agreed. I finally tried Github Copilot for a bit at work. It felt like babysitting a bad developer. I have no confidence in the correctness of the code it produces, so everything requires careful review. Sometimes it spits out very broken code on non trivial tasks.
I’m still figuring out if/how it can make me more productive.
First impression is it’s more a drain on productivity than not.
I have found it does a ok job of writing simple bash utility scripts.
Stuff like "I need a bash script that saves my current git branch into a temp file, then another script to create a new git branch based off the value in the file"
