ornxka

Alternate take, the people who keep mucking up the perfectly fine UI[1] that I've been using for years should get on that bus, so the rest of us never have to worry about waking up and everything is in a different place for absolutely no reason.

[1] In general, I mean - I actually don't use AWS.

Oh, well I guess it's not just me then.

>I know the resurrection is a fact, and Watergate proved it to me. How? Because 12 men testified they had seen Jesus raised from the dead, then they proclaimed that truth for 40 years, never once denying it. Every one was beaten, tortured, stoned and put in prison. They would not have endured that if it weren't true. Watergate embroiled 12 of the most powerful men in the world-and they couldn't keep a lie for three weeks. You're telling me 12 apostles could keep a lie for 40 years? Absolutely impossible.

- Charles Colson, advisor to Richard Nixon during the Watergate scandal

Different resource usage patterns aside, why do people think that robots are somehow less "legitimate" consumers of data than their human operators? Do the authors of this article think that humans only use data for purposes sanctioned by its producers?

I think the world would be a much better place if we stopped treating programmatic access to interfaces differently than human access to it. Anybody can learn to code.

"Reality is that which doesn't cease to exist when you stop thinking about it", they say.

Or, to elaborate, these things have a cost whether people are aware of it (and care about it) or not. Maybe it's not so high now, but eventually it's likely to manifest itself, especially when the codebase needs to run in a new environment or be modified to follow a new paradigm. Those situations are where things tend to either "make the jump" and continue to be used or end up in the (already vast) graveyard of abandoned software because the cost of maintaining it became higher than the return it yielded.

Wait, Chrome is now requiring HSTS for localhost? This is absolute madness. Somebody needs to sit down with the people responsible for this and explain to them that this is not solving anybody's problems and is just making life more difficult for everyone.

Swap has always been so slow for me that I just disable it on all of my machines. I would rather the OOM reaper just SIGKILL whatever is using all my RAM than deal with slowness (which often persists after the OOM situation is gone).

>Bitcoin is a silly idea based on scarcity that doesn't exist.

If its scarcity isn't real, then why can't you conjure up an arbitrary number of bitcoins at will?

The point is that as long as telemetry is delivered over the internet, it is also tracking. There is absolutely no difference whatsoever unless your telemetry is delivered via Tor or some other mathematically proven means of nearly-anonymous transport.

>Which is a big problem.

Is it? What if the alternative is that people feel the wrong way about things?

Five's how many fingers I have.

That's a good point about the critical path - I was thinking it would be a bit bigger and slower since you'd have to decode it, but I hadn't realized what an impact that would probably have. No bit-perfect round trips is also absolutely horrifying and I would never have even thought that would be a thing.

>Compiler writers and tool authors are perfectly comfortable working with binary file formats. There's nothing more inherently future-compatible about JSON than a forward-compatible binary format like flatbuffers. Having to escape and then unescape naughty bytes is a huge downside for text-based formats that are hardly ever read by humans.

Well, the problem isn't binary or non-binary, the problem is that these formats like ELF are, apparently, really annoying to deal with, have weird limitations, and are difficult to extend. The reason I thought of JSON in particular is because it doesn't really need to be extended to encode anything (unless you include escaping or base64 encoding binary data you want to put inside of a JSON document as "extending" it). You can encode all of the fields in ELF (or any other format) inside of JSON, while it doesn't make sense to consider the converse because ELF has fixed fields with fixed meanings.

That's the problem with these bespoke binary formats like ELF - they're not designed to encode arbitrary schemas of data, they're designed for very specific tasks and then when they get used outside of their intended environment, we get problems like have been described in this thread. Nobody has ever had these problems with a JSON document - maybe with something that consumed one, but the file format itself simply does not have the same kind of limitations like ELF does. It has different limitations, but they're not of a fundamental and semantic nature like they are in a more rigid format.

You're right that it would be a problem to have to escape/unescape every section every time you wanted to run something because that's very slow, but I think that's basically the only problem that these bespoke binary formats solve. If that's the case, I wonder why something like Matroska wouldn't work for binaries? My understanding is that it's basically binary XML and allows for basically a completely arbitrary dictionary structure. It doesn't have nice tooling like JSON or XML do, but there's no weird restrictions on things like field length that I'm aware of. I guess it doesn't exactly have any "momentum", though, but maybe the NixOS people will get sick enough of ELF to consider such a drastic solution :P

I'm not really sure why it has to be that hard, like, why don't we just use base64-encoded JSON or something?

>Postfix is written in C, and none of us should be comfortable with that

qmail is written in C, and it has never had a serious security hole that I am aware of. Not all C code is unsafe.

But most of those are terrible! Google has actually gotten worse over the years, literally all I've ever heard about fraud detection is the vast amount of both false positives and false negatives somehow, speech to text is utter garbage where you have to repeat yourself, consciously annunciate, and not use tricky grammatical constructs, and the thought of the same tech behind locking me out of my credit card every so often deciding if I'm being "toxic" or not is frankly terrifying.

AI might be producing value, but only in the sense of getting half of the quality for a quarter of the cost.

I'm pretty sure their "path to profitability" is actually intimately related to the fact that it is free to use.

Actually, you'd be really surprised about that: https://twitter.com/Foone/status/1229641258370355200

Thank you for posting this, I will now forever wonder who, if any, of the people I meet throughout my life will have been secret cardinals. The answer is almost certainly "none at all", but you're right, how would I know!

Am I the only one who thinks that no travel + tactile feedback actually sound like two highly desirable properties for a keyboard? Whenever I use someone else's butterfly keyboard I'm impressed and a bit jealous, but as I've never used one for long, I can't say whether it's really an improvement.

This post requires a Hacker News Gold account to view.

Well, it's definitely suspect now that RSA is broken.

Their behavior makes Firefox unlike literally every single other program with a text box, except the singular other browser people actually use. Neither browser should be different for the sake of it.

Nobody is addressing the elephant in the room, which is the reason why there are only two viable browsers in the first place - because the endless and ever-growing list of specifications and standards web browsers must comply with has grown to the point where it is apparently impossible to build a browser without the budget of a nation state. For example, https://drewdevault.com/2020/03/18/Reckless-limitless-scope.... has done some calculations, and has found that "the total word count of the W3C specification catalogue is 114 million words at the time of writing." Good luck implementing that, if you're not Google!

A lot of things could be done to simplify the amount of labor it takes to build a web browser. If you look at the architecture of the web, there is no reason for things to be this complicated - the web doesn't need a complicated high-level language runtime when it could have bytecode a la WASM, for example. But that's exactly the problem, because the reason why things have become so complicated is not because that's just how complicated the problem space is that a web browser attempts to solve, but because the people in charge of the web actually have a vested interest in things being as complicated as possible. When you already have the budget of a nation state, there is not only no benefit to your job requiring less labor to perform, it actually harms you because now competitors need that many fewer resources to compete with you. That's the real problem - they don't want it to be simple and easy, they want it to be complicated and hard, and the present problem of lack of browser diversity is just a consequence of that.

This is the real reason why things have gotten this bad in the browser space, and it's never going to get any better without first addressing this fact and then by breaking basically the entire web by decimating the volume of standards documents web browsers have to follow. There is no other option. Nobody is going to sift through 114 million words of specification documents to build another web browser for the web that exists today.

The web can't be saved. Its replacement will have to start from scratch.

>Checked C has low performance overhead (only 8.6% on selected benchmarks [25])

Isn't that actually kind of significant?

>its arcane and bizarre command-line syntax

I actually like dd's command-line syntax the most out of the Linux coreutils, and I wish more programs used a similar "key=value" argument system. It's pretty easy to remember too, since there's really only a few keys you need to remember to do 99% of what dd typically gets used for.

If people are going to make crappy half-baked software that doesn't work, they need to be upfront about it so people stop expecting it to do its job. If they're not going to do this, people are right to expect a basic level of quality and to complain when they don't get it.

Something similar happened to me once - I used faulty ram for about a year (it worked most of the time, and when it didn't, it typically became apparent within a few minutes of booting the system, so it was a minor annoyance at worst). One of the times it didn't work, I noticed all of my programs were being killed by the OOM reaper, even though I had just started the system. After running free in a spare terminal, I realized it was reporting that I had roughly INT_MAX memory in use, and so it was deciding to kill basically everything to try and get back to having a non-negative amount of free memory left. There must have been memory corruption in some kernel data structure somewhere that deals with memory allocation.

I rebooted and it never happened again, but it was pretty funny running free and seeing those ridiculous numbers pop up. I was kind of amazed the rest of the system was even working at all.

Not him, but the difference to me is that all of those systems are meant to be amenable to debugging - you can't run strace on an iPad.

>You had almost 15 years of warning from initial announcement to eol.

Why should I have to do labor to fix things that already work?

They're different to a human, why would it be any more difficult to understand that they're different for computers too? Trying to make things easier to understand by introducing complicated mechanisms just makes the whole thing harder to use.