To fix this, let's add another third-party security service and give it all the sensitive information. I am sure it won't get hacked!

As for AI specifically.. life is too short to read all the interesting pages already, and AI just makes is so much worse.

- AI is verbose in general, so you are spending a lot of time reading and not getting much new facts out of that.

- Heavy AI use often means that author has little idea about the topic themselves, and thus cannot engage in comments. Since discussion with authors are often most interesting part of HN, that makes submission less interesting.

And yes, it is possible to use AI assistance to create nice and concise report on the topics you can happily talk about, but then this would not be labeled as "AI".

Why are AI people so dramatic? Ok, there is yet another JS sandbox escape - not the first one, not the last one. It will be patched, and the bar will be raised for a bit... at least until the next exploit is found.

If anything, AI will make _weaponized_ exploits less likely. Before, one had to find a talented person, and get pretty lucky too. If this AI is as good as promised, you can have dependabot-style exploit finder running 24/7 for the 1/10th cost of a single FTE. If it's really that good, I'd expect that all browser authors adopt those into their development process.

> It is why I paid for your app...

this is about closed-source, paid software - no PRs possible there.

One solution is to double-down on prop 13 ideas, and also add limits on how much house sale can be taxed. Another is to slowly start dialing-down prop 13 and allow higher tax rate increases. Both of those have problems.

> the machine could be calibrated to an accuracy of 2%.

I always wondered how precise those "physical computers" were - this one apparently had error of 1/50, or about 6 bits of precision.

But what's definitely missing is "ADC" and "DSP" parts - you are not getting any usable bits out of that chip, the best you can is raw analog I and Q signals. You still need a whole bunch of complex rad-hard logic to get usable data.

[0] https://www.researchgate.net/figure/Block-diagram-of-a-typic...

"That's an answer I don't have .. I'd defer the decision to teachers" - you are really sounding right now like someone who comes to a town's discussion of whether to get more solar panels, and starts saying how nice it would be if the fusion were solved, and we all had an near-infinite source of cheap and clean energy. Yes, it would be nice, but unless you have a good idea on how to achieve this, please don't distract people from the real problems they have.

The AI-in-education is the same way: there is a crisis right now, and it seems that the only way is to lean heavily onto proctored exams - which students hate, and are more expensive for schools too. Saying "There should be a better way, I have no idea about what this better way is, but meanwhile what you are doing is bad" really does not help much.

Most filesystems just get a few files/directories damaged though. ZFS is famous for handling totally crazy things like broken hardware which damages data in-transit. ext4 has no checksum, but at least fsck will drop things into lost+found directory.

The "making all data inaccessible" part is pretty unique to btrfs, and lets not pretend nothing can be done about this.

Unfortunately at the high school level, the materials are not that complex, and there are a lot of ways to cheat. Answer keys for textbooks, graphical calculators (or CAS systems), reports copied wholesale from some websites. AI just made all of this significantly worse.

https://news.ycombinator.com/item?id=45027072

"Delve – Fake Compliance as a Service" https://news.ycombinator.com/item?id=47444319

All I saw were 386's and 486's, and I am pretty sure every piece of software I ever used was either C or Turbo Pascal or direct assembly. In the mid-90s, Java appeared and I remember how horribly slow those Java apps were compared to C/Pascal code.

So _today_ I write parsers in a very different way as well, copying strings is very cheap (today) and not worth it extra complexity.

But remember we are talking about the past, when those conventions are being established. And back in the 90's, zero copy and zero allocations were real advantage. Not in the theoretical CS sense, but in very practical - remember there was _no_ "dynamically resizing vector" in C's (or Pascal's) stdlib, it's just raw malloc() and realloc(), and it is up to you to assemble vector from it as needed. And free()/malloc() overhead was non-trivial, you had to re-use and grow the buffer as needed. And you want to store the parsed data, storing separate length would double your index size! So a parse-in-place + null-terminated strings approach would give you both smaller code and smaller runtime, at the expense of a few sharp corners. But we were all running with scissors back then.

And yes, today it would be easier to make a copy of the data... but remember we are talking about 90's, where RAM is measured in megabytes and your L1 cache may be only 8KB or so.

Plus, C-style strings allow a lot of optimizations - if you have a mutable buffer with data, you can make a string out of them with zero copy and zero allocations. strtok(3) is an example of such approach, but I've implemented plenty of similar parsers back in the day. INI, CSV, JSON, XML - query file size, allocate buffer once, read it into the buffer, drop some NULL's into strategic positions, maybe shuffle some bytes around for that rare escape case, and you have a whole bunch of C strings, ready to use, and with no length limits.

Compared to this, Pascal strings would be incredibly painful to use... So you query file size, allocate, read it, and then what? 1-byte length is too short, and for 2+ byte length, you need a secondary buffer to copy string to. And how big should this buffer be? Are you going to be dynamically resizing it or wasting some space?

And sure, _today_ I no longer write code like that, I don't mind dropping std::string into my code, it'd just a meg or so of libraries and 3x overhead for short strings - but that's nothing those days. But back when those conventions were established, it was really really important.

I suspect that the main reason people are using of "parallel" is because it was the first to grab this very nice, very obvious package name. "rush" and "gargs" and "pexec" simply does not have the same obviousness to it.

If you think asking for citations is too much (and I do), I recommend using something else. Yes, "parallel" does have some nice features, and something you might need to use an extra command or two, but it is worth it for the peace of mind, plus it respects author's wishes too.