I asked a question about 15 years ago. Lots of responses/engagement and a good answer. I just got an email a month or so back telling me that question got closed as a dupe. I checked...it was not even close to a dupe. Exhausting.
Anyone who's used SO has had a similar experience. It's like saying you posted a comment on Reddit and got banned from three unrelated subreddits. It's just what happens there.
I was a SO user from 2011 or so and have not experienced it. I'm with GP and GGP where whenever someone does post an example, it almost always shows them having misunderstood the site or misrepresented the situation, and should have been closed even in the good early days.
For example, one of the uses for closing a question is to give the asker time to improve it based on feedback before people start piling on irrelevant answers (such as including more detail showing why it's not a duplicate of another question). IIRC doing so automatically makes it eligible for reopening, without even having to ask.
Another is that duplicates are meant to point at the best version of the question/answer. Usually this is caught when the new question is posted and it's closed as a duplicate of the older one before answers are posted, so you don't see GGGP's situation, but if it's not caught by someone who knows about the older question the new one can become better and then, by design, the old one is closed and pointed at the better new question.
> one of the uses for closing a question is to give the asker time to improve it based on feedback
Pretty much, yeah.
There are multiple reasons to close a question, but fundamentally three categories: duplicates (which don't need to be changed unless you were misunderstood and a change would make it clear that you meant a different question); questions that can be fixed but require OP's private information to do so (e.g. expecting OP to focus on one question, or provide a proper example, or phrase things more clearly); and questions that fundamentally cannot be fixed (e.g. they're simply off topic).
Whenever a question can be fixed, it's expected that the asker tries to improve it.
But fundamentally the purpose of closing a question is to prevent answers to a question that doesn't meet the site standards. Where a question is fixable, this is only intended to last until it actually does get fixed.
> IIRC doing so automatically makes it eligible for reopening, without even having to ask.
It is immediately eligible for reopening from the moment it's closed. Sometimes people make mistakes.
But whenever anyone edits the question (including OP) there is a checkbox that can be used to assert that the edit resolves the problem, which puts it in a specific queue for consideration (otherwise, someone would have to stumble on it randomly).
> but if it's not caught by someone who knows about the older question the new one can become better
On rare occasions, there has been a deliberate organized effort to do a new question, because the old one was deemed simply insufficient (usually not a matter of becoming outdated, but simply failing to present and address the subject matter in a way that would be accessible to the target audience).
I get that's how it feels but I've also seen more SO questions closed off that seemed perfectly reasonable/not duplicates except in the most vaguest sense than I can count.
"Unlimited" for a consumer will probably take a form like limited parallel agents at max intelligence for X amount of tokens, followed by either single threaded agents or nerfed intelligence or both.
This is the same mechanism used in unlimited mobile internet for example.
I've never understood the security argument people are making when they complain about `curl foo | bash`. I get that these scripts sometimes mess up your bashrc or whatever, but from a security perspective I see no issue. You are already installing software from the same domain. If they were going to do something nasty, they could do it with any of the software you are using from them. It doesn't have to be the setup script.
To compare it to just one other option: when you run `npx foo`, you know* that you’re getting the same public artifact that anyone else running it at the same time would get. (If you have a `min-release-age` configured, you also benefit from that.) If I wanted to distribute software like this, I’d include npm-shrinkwrap.json; then, with `npx foo@1.2.3`, you could be similarly confident in getting the same app every time.
(I picked this option for ease of comparison, getting a couple of major security wins with very low effort; I don’t recommend `npx`ing stuff in an otherwise unprotected environment either.)
maybe then we'll pin hashes instead of filenames, and oops now anybody can fork my/domain and hand out a link that looks official with whatever contents they wish
While I don't think piping curl into bash is the most secure, npm installing has proven time and time again to open yourself up to supply chain attacks. At least with curl you know that you're getting the supply chain put together by the software author. With npm, every single library is a vector for attack every time you update.
You’d be getting the supply chain put together by the software author in either case. It’s common to do both badly, but if you care about doing it well, that’s easier with npm (e.g. shrinkwrap, as mentioned) and can be taken farther (the non-varying artifact thing).
Npm dependencies resolve at install time though, so some of the pinned versions may have changed ownership or otherwise been modified since the author pinned them. With the curl | bash solution you're getting a singular supply chain packaged by the author at release time.
Package versions released on npm are immutable, so no, they can’t. If you have unpinned transitive dependencies: that’s why I mentioned npm-shrinkwrap.json a couple of times.
And again, npm is also an example of “a singular supply chain [selected] by the author” in this way. On top of what cpuguy83 mentioned, curl | sh is vulnerable to compromise anywhere on the stack serving the script (domain name, host, maybe CDN, GitHub account if it’s just a redirect to GitHub as they regularly are), and coming back to what I originally said, even the real author might decide to serve you a special version of the script that nobody else is getting. You’d never know.
With curl|bash you are literally getting anything that happens to be in that script. These are frequently poorly constructed, so not check hashes or pin dependencies they install.
Even security companies (see trivy supply chain attack) get these badly wrong.
I'm not replying here to say one is better than than the other (npm has obviously had its share of problems) but rather to combat claims that curl|bash is somehow safer, it absolutely is not, in fact it's all the bad stuff about npm without the pretense of being potentially safe.
You can detect the use of curl|bash server side, hence it's an essentially undetectable attack vector. People have shown poc attacks of that kind all the way back in the 2010s
I push binaries from untrusted sources through VirusTotal before running them. Piping a Bash script from curl bypasses that. Furthermore, such Bash scripts, when they aren’t self-contained, make security checks more difficult than a self-contained archive, installer, or binary, even when downloading the script without immediate execution.
I don’t believe an agent can do that effectively without a sandbox to run the script in, if the script isn’t self-contained.
And everyone running a research agent on every download can’t be the solution. It’s much more effective to crowdsource a security database based on hashes. But for that, the downloads need to be self-contained.
The intended workflow is to download the install scripts, download the source code, read them both, and then start running things. That’s how Open Source is secured. Piping from bash to curl is just the most obvious warning flag.
There is no argument. It's just people's reflex reactions.
The technical excuses they come up with (e.g. that the server can detect it and send different content) are just post-hoc justifications for their instinct.
It's `curl foo | sudo bash` that's the bigger objection. Running software usually shouldn't require root, and then the equivalence argument you make doesn't hold.
Installing from distribution package is much safer than curl+bash because it doesn't require you to extend trust to anybody else. You could argue that malicious code could still pass through the distribution mechanism, but at least it's fully auditable and you're guaranteed to be in the same boat as everyone else.
a script isn't getting hashed to see whether or not it's the one the website intended to serve you, for one.
what use is hashing every piece of software that goes thru the distros package manager just to throw caution to the wind at the layer above it?
w.r.t. "it's already from the same domain" , well most bash/z install scripts either invoke a package manager or they download and untar a package that has nothing to do with the host domain, anyway.
In the before times, and sometimes now even, the way I always coded was by thinking/discussing the work, then hacking up various interesting bits, then throwing it away and doing it the "right" way. Plan mode makes it harder to go back and forth between "hacking" and "thinking" phases.
To answer the original question, most people who care about their filesystem at all care about its stability. Not just "does it work now" but also "will it work and improve over time". Infighting puts the future at risk.
But you might want to check out the bus factor on btrfs too; when a maintainer says "but we've saved Facebook billions and billions of dollars!", calls for the other filesystem maintainer to be ejected from the community, then quits to join Anthropic a month later - that's not a vote of confidence.
I'd be very happy if people could just stop bringing up drama and us factors. We put it behind us a year ago, but it seems not everyone got the memo.
Other things: since no companies sponsoring its development had any interest in raid 5/6, which is mostly a home enthusiast thing.
Western Digital picked up this work last year and is slowly getting through the new design without the write hole, I think we'll see working raid 5/6 in the next year or two.
> Other things: since no companies sponsoring its development had any interest in raid 5/6, which is mostly a home enthusiast thing.
I've used RAID-Z1/2/3 at a couple of jobs: yes IOps is suck-y, but if it's for backups of other systems, or the central logging server, or network monitoring (Suricata, Snort), sometimes your priority is cheap/bulk.
I'm currently in the HPC space, and Lustre is a thing here, and it has tiered storage via policies: you can (e.g.) put your recent/hot data on NVMe, but older/colder bits on spinning rust on ZFS.
Might end in a new bcachefs fork beeing included back into mainline. If companies sponsor a few fulltime devs working on the new fork, we finally might have a stable enterprise ready CoW filesystem.
Thought about a real fork going in its own direction. I would love to use bcachefs in all our products. But the current state does not qualify for usage within enterprise environments. Any ideas how to get that fixed? How many core developers are present? Any fallback plans, ...? How to help to get there?
If you ignore the ethical issues, and you shouldn't (!!!), there is an appeal to mined diamonds, and it is exactly what you say above. The idea that some dinosaur or tree or whatever got mushed down is really interesting too.
> In the first case, TFA refutes by claiming 'wrong' repeatedly, which does not convince me of anything. If anything, Zitron is probably right in this regard, since the majority of progress in recent LLM tech has been setting up of guardrails to cajole the models using 'agents'.
You don't have to like them, use them, or consider them "good enough", but the idea that models haven't gotten better in the last two years is ridiculous.
I wouldn't trust it with a credit card, or really any sort of non-reversable decision making. Most of what I do outside of work either requires physical interaction, or is something I do for fun. For now, I assume that is what people use this stuff for. Fun.
Edit: oh neat! Its self editing.