The problem is that such a browser wouldn't be any use to users in the short-term, because most of the web simply wouldn't "work" in it.
So, I don't think it's developers that are the problem. As a web dev myself, I'd much rather have less, mostly unnecessary, complexity to deal with, but I can't see a rational path towards that.
The counter argument would be that git is the poster-child of poor UX, which could be blamed on the fact that it exposes too much of its internal data structure and general inner-workings to the user.
I.e. too much focus has been put on data structures and not enough on the rest of the tool.
A less efficient data structure, but more focus on UX could have saved millions of man hours by this point.
It's difficult, because git's exposition of it's data structures enables you to use it in ways that would not otherwise be possible.
I think git is more of a power-tool than people sometimes want it to be. It's more like vi than it is like MS Word, but it's ubiquity makes people wish it had an MS-word mode.
So, I think that it's hard to fault git's developers for where it is today. It's a faithful implementation of it's mission.
FWIW, I have never used a tool with better documentation than git in 2020 (it hasn't always had good --help documentation, but it absolutely does today).
Or perhaps learning Git just requires a different approach: you understand the model first, not the interface. Once you understand the model (which is quite simple), the interface is easy.
People keep repeating this, but it's not true. The interface has so many "this flag in this case" but "this other flag in that case" and "that command doesn't support this flag like that" etc. There's no composability or orthoganality or suggestiveness. It's nonsensical and capricious and unmemorable, even though I understand the "simple" underlying model and have for years.
> The counter argument would be that git is the poster-child of poor UX, which could be blamed on the fact that it exposes too much of its internal data structure and general inner-workings to the user.
I agree with you that the UI is inconsistent, however I don't agree that it's the result of git exposing too much of the internal data structure.
Yes, I think so. There are many git clients which offer superior UX already, but they only provide a subset of the functionality available with the data structure. I'd personally love to experiment with showing and editing the data structure more 'directly', instead of relying on a battery of CLI commands and options.
> Parent is simply referring to the front-end skill of building an app with rich client-side state that isn't persisted to a backend DB.
Frequently some or all of the state is persisted to a datastore, whether client-side or backend (which of those isn't really a substantive difference in the skill involved, except that backend stores make planning around communication failures more important), and even when it's not, “my internal data structures don't also get loaded from and saved to an external store” doesn’t add any additional required skill, it strictly reduces the set of skills that need to be applied.
> large React applications tend to be just as heavyweight and hard to understand as Angular ones once you need a router, state manager, and 20 or 30 other "compact" libraries to do what you're trying to do.
I largely disagree with the comment you're replying to in its oversimplification of things, however, this simply isn't true. 'Create React App' plus 'React-Router' is literally all you need for the vast majority of applications.
And you don't need "20 or 30 other compact libraries", unless what you're doing is specialised and requires them.
The idea you need "a state manager" is an unfortunate fallacy, due to React/Facebook's history by accidentally implying a Flux-like solution should be added to augment React, when in fact so much more could be achieved by simply following React's component model, and React's built-in mechanisms for managing state.
Exactly - the innerHTML approach doesn't work for component composition and it completely fails for things like forms, where you will blow away form input focus/cursor state etc.
This was a stumbling-block of the fairly simplistic predecessors to the React/Angular generation - like in Backbone.js if you chose to implement 'render()' in such a naive way.
qmail last had an official release in the late 90's.
everything else is third-party forks / patches. Back in the day, I upgraded many systems from sendmail to qmail. However, that was a very long time ago... It's been over 15 years since I've done something like that.
Nowadays, the author should be telling people to install postfix.
The app is vulnerable if it runs in an unsafe environment that allows qmail to access more than 4GB (an absurdly large value when qmail was published in 1997 -- it would cost $5000 plus a rare, expensive machine to hold it).
djb's view is that the environment is the responsibility of the admin, not the program's responsibility to enforce sane defaults. This is of course debatable.
If the admin uses a recommended environment (low memory limit), there is no exploitability.
I meant: my parent comment (@allover) was missing a reference to how ES is insecure by default, this community gives them heck (rightly so) and that this comparison (qmail v. ES) could have been added (ie: was missing) from his post.
For a result of: this is a qmail bug that could/should be fixed AND ES should fix theirs too.
I'm for sure (I thought obviously) not excusing either qmail or ES from being insecure by default or for their "fix" to be: "you're doing it wrong".
I don't think my karma will ever recover from this (Tiger King joke)
