You are not misunderstanding anything, I use Go and Rust/TypeScript in my daily work and you are correct - it is the OP that does not understand why people use lockfiles in CI (to prevent minor updates and changes in upstream through verifying a hash signature).
They may be an expert in Go, but from their writing they appear to be misunderstanding (or at least misrepresenting) how things work in other languages. See the previous discussion here: https://lobste.rs/s/exv2eq/go_sum_is_not_lockfile
> They may be an expert in Go, but from their writing they appear to be misunderstanding (or at least misrepresenting) how things work in other languages
Thanks for that link.
Based on reading through that whole discussion there just now and my understanding of the different ecosystems, my conclusion is that certainly people there are telling Filippo Valsorda that he is misunderstanding how things work in other languages, but then AFAICT Filippo or others chime in to explain how he is in fact not misunderstanding.
This subthread to me was a seemingly prototypical exchange there:
Someone in that subthread tells Filippo (FiloSottile) that he is misunderstanding cargo behavior, but Filippo then reiterates which behavior he is talking about (add vs. install), Filippo does a simple test to illustrate his point, and some others seem to agree that he is correct in what he originally said.
That said, YMMV, and that overall discussion does certainly seem to have some confusion and people seemingly talking past each other (e.g., some people mixing up "dependents" vs. "dependencies", etc.).
> but then AFAICT Filippo or others chime in to explain how he is in fact not misunderstanding.
I don't get this impression. Rather, as you say, I get the impression that people are talking past each other, a property which also extends to the author, and the overall failure to reach a mutual understanding of terms only contributes to muddying the waters all around. Here's a direct example that's still in the OP:
"The lockfile (e.g. uv.lock, package-lock.json, Cargo.lock) is a relatively recent innovation in some ecosystems, and it lists the actual versions used in the most recent build. It is not really human-readable, and is ignored by dependents, allowing the rapid spread of supply-chain attacks."
At the end there, what the author is talking about has nothing to do with lockfiles specifically, let alone when they are applied or ignored, but rather to do with the difference between minimum-version selection (which Go uses) and max-compatible-version selection.
Here's another one:
"In other ecosystems, package resolution time going down below 1s is celebrated"
This is repeating the mistaken claims that Russ Cox made years ago when he designed Go's current packaging system. Package resolution in e.g. Cargo is almost too fast to measure, even on large dependency trees.
Addy's users have been developers and Google has been very responsive in the past. I was usually able to get a hold of someone from teams I needed from Chrome DevTools and they've assisted open source projects like Node.js where Google doesn't have a stake. He also has a blog, books and often attended conferences to speak to users directly when it aligned with his role. I agree about the general Google criticism but I believe it's unjustified in this particular (admittedly rare) case.
This is really nice though looking at the code - a lot of the postgres types are missing as well a lot of the newer parquet logical types - but this is a great start and a nice use of FDW.
Postgres has like 300+ types but mostly stuff like decimals should work the same way it does with Postgres (with the edge cases like NaN existing in Postgres but not parquets accordingly)
If it wasn't for the fact that they totally only targeted Bible apps and ignored things like reddit when doing this I would say its just an honest mistake, but they only seemingly marked Bible related apps. In one instance the developers app isn't even an app that contains the Bible, its a Bible reading tracker so you can keep track of which verses you have read thus far, still marked NSFW. There was not enough thought put into this ban and it only seems to target one demographic of apps.
> We don't flag general apps, e.g., ebook readers and browsers. But bible readers are not general apps. They are designed to read bible and there are NSFW contents in bible.
Honestly I think their argument is pretty weak, especially since like you said in this case it was a bible reading tracker.
It seems like the point of this comment is to concoct an example for which anyone agreeing with the parent comment would supposedly hold an inconsistent opinion. I'll insert my own consistency: neither should be flagged NSFW.
> If it wasn't for the fact that they totally only targeted Bible apps. ［...］ it only seems to target one demographic of apps.
Not true. Quran just as targeted as Bible.
> and ignored things like reddit
What do you mean with "ignored reddit"? There is no official reddit app on f-droid and community clients are flagged with the "depends on or promotes non-free network service" anti-feature.
An offline reading-tracking app being flagged sounds like one false positive that should be corrected, though. Have you tried submitting a PR for it?
It seems someone at F-Droid may have a political axe to grind with the current US presidency and the majority of the population of America who elected (1.)them.
Don't get me wrong, I hold the "eligible but didn't vote" group equally accountable for the current regime, but it was not the majority of the population that voted for him.
"If "Did Not Vote" had been a presidential candidate, they would have beaten Donald Trump by 9.1 million votes, and they would have won 21 states, earning 265 electoral college votes to Trump's 175 and Harris's 98."
Hacker News is explicitly not only for those two things.
"Anything that good hackers would find interesting. That includes more than hacking and startups."
I don't find anything political about mass murder, and you should consider your position if you do. This is about criminal proceedings, not political ones.
Personally, I find the fact that people still say a genocide, which has been broadcast for years on our tech platforms raw, is still being denied by anyone, quite disturbing, and definitely titillating to the mind
Sure, Palo Alto can acquire Cyberark and then use its sales organization to up-sell its customers on CyberArk's offering.
I've seen this at Microsoft where acquiring startups that provide capabilities and then incorporating them into Azure or Defender led to the usage of those capabilities skyrocketing and those particular acquisitions (not going to specifics because NDA) ended up being profitable.
Even moreso when you take into account that CyberArk is not exactly a beloved product because it involves a lot of hassle. At 5-6B it may have been reasonable or simply a portfolio add that's cheap because of shared ownership/refinance but for 25B they could have bought Okta, which would have added much more value to their portfolio...
And this is the continued path to "enshittification" we're on through the continued growth forever. Companies aren't buying products, they're buying customers.
I worked for PAN back in the days where the sentiment, directly from Nir Zuk (founder), was: innovators dilemma. There's a relatively recent article [0] on the early days that does a nice job of laying out how that was a core tenant of how PAN operated. At the time I was there Mark McLaughlin was leading the charge as CEO and was the right person to drive PAN to $100M ARR.
But as you see the company shift after Mark you really start to see less of an engineering mindset of bringing new and disruptive technology to the landscape. Nikesh doesn't know how to do that. He's an ex-Googler and a finance background to boot. PAN is no longer disruptive in the technical sense. They're now disruptive to fresh ideas and good technology, which is bad for everyone.
I work now in a segment that competes with PAN in a small niche of their product set and I've displaced their points solution dozens of times in the last year. The product we're displacing is a product that PAN acquired in early 2019. The customers on that platform constantly complain about how the product has not evolved in years and support at PAN is horrendous. The last point, support, used to be a shining light for PAN. They had exceptional support - but, as with all things, scaling high quality is hard. It's why you won't find an In-N-Out too far off the Pacific coast. It's because of quality and their commitment to it. PAN is chasing stock prices and revenue, they aren't committed to their customers as they once were.
In-N-Out has a huge footprint in DFW btw. I agree with you on their commitment to quality but as I understand it their growth is slow because they don't take outside investment or loans and they need enough capital to open a regional footprint of stores because they do their own distribution.
The problem is that you come to a prestigious place like Microsoft and end up using horrible outdated software.
Credit where credit is due at my time at Excel we did improve things a lot (migration from Script# to TypeScript, migration from SourceDepot to git, shorter dev loop and better tooling etc) and a large chunk of development time was spent on developer tooling/happiness.
But it does suck to have to go to one of the old places and use sourcedepot and `osubmit` the "make a change" tool and then go over 16 popups in the "happy path" to submit your patch for review (also done in a weird windows gui review tool)
I am not sure the wheel can be rediscovered many more times but definitely check out Kris's work from around 2010-2012 around q-connection and streaming/rpc of chunks of data. Promises themselves have roots in this and there are better formats for this.
Check our mark miller's E stuff and thesis - this stuff goes all the way back to the 80s.
reply