Some systems or admins may not trust unprivileged namespacing (thus disabling and its use requiring root), while Landlock may be enabled (and is specifically designed to be used by unprivileged processes).
> have a theory that every major technology shift happened when one part of the stack collapsed with another.
If that was true, we would ultimately end up with a single layer. Instead I would say that major shifts happen when we move the boundaries between layers.
The author here proposes to replace servers by synced client-side data stores.
That is certainly a good idea for some applications, but it also comes with drawbacks. For example, it would be easier to avoid stale data, but it would be harder to enforce permissions.
I feel like this is the "serverless" discussion all over again.
There was still a server, its just not YOUR server. In this case, there will still be servers, just maybe not something that you need to manage state on.
This misnaming creates endless conflict when trying to communicate this with hyper excited management who want to get on the latest trend.
Cant wait to be on the meeting and hearing: "We dont need servers when we migrate to client side data stores".
I think the management isn't hyper excited about naming - in fact, they couldn't care less for what the name means (it's just a buzzword). What they're excited about is what the thing does - which is, turn more capex into opex. With "cloud", we can subscribe to servers instead of owning them. With "serverless", we can subscribe directly to what servers do, without managing servers themselves. Etc.
Recently, something quite rare happened. I needed to Xerox some paper documents. Well, such actions are rare today, but years ago, it was quite common to Xerox things.
Over time, the meaning of the word 'Xerox' changed. More specifically, it gained a new meaning. For a long time, Xerox only referred to a company named in 1961. Some time in the late 60s, it started to be used as a verb, and as I was growing up in the 70s and 80s, the word 'Xerox' was overwhelmingly used in its verb form.
Our society decided as a whole that it was ok for the noun Xerox to be used a verb. That's a normal and natural part of language development.
As others have noted, management doesn't care whether the serverless thing you want to use is running on servers or not. They care that they don't have to maintain servers themselves. CapEx vs OpEx and all that.
I agree that there could be some small hazard with the idea that, if I run my important thing in a 'serverless' fashion, then I don't have to associate all of the problems/challenges/concerns I have with 'servers' to my important thing.
It's an abstraction, and all abstractions are leaky.
If we're lucky, this abstraction will, on average, leak very little.
> Over time, the meaning of the word 'Xerox' changed. More specifically, it gained a new meaning. For a long time, Xerox only referred to a company named in 1961. Some time in the late 60s, it started to be used as a verb, and as I was growing up in the 70s and 80s, the word 'Xerox' was overwhelmingly used in its verb form.
https://www.youtube.com/watch?v=PZbqAMEwtOE#t=5m58s I don't think this dramatization (of a court proceedings from 2010) is related to Xerox's plight with losing their trademark, but said dramatization is brilliant nonetheless
I agree, but at least it is consistent. This is also how `for`, `list`, `aria-labelledby`, `aria-describedby`, and probably many other attributes work.
This is a nicely written description of some of the things that flatpak does under the hood for people who know docker. Of course, flatpak does a lot more (e.g. filtered dbus access).
I personally think that flatpak is not the end of history and we should continue to experiment with different approaches.
The one thing I thought was IMHO missing from this article was JavaScript.
In HTML, it is pretty natural to add white space (i.e. text nodes containing white space) between all elements. You basically only have to worry if you want to avoid that.
In JavaScript, the opposite is true. If you want to create a text node, you have to do so explicitly. If you just create elements and append them to the same parent, they will be added without whitespace.
I am not sure how JSX behaves in this regard. Last time I checked it was more like JavaScript than HTML, which was of curse very confusing for people.
Concerning text-to-speech and the missing separation of HTML and CSS: There are several open issues about this in the spec that defines how accessible names and descriptions are computed from HTML elements: https://github.com/w3c/accname/issues?q=state%3Aopen%20label...
I expected an uninformed rant and actually got a really well informed, balanced rant. I don't agree that this is a major issue, but every time I thought of a counter argument it was immediately addressed in the article. Well done!
Yep. I don't agree with the premise, and I'm never reaching for the pre tag as they seem to do, but the content is informative and goes into a lot of details. The topic is very well researched.
I think HTML whitespace handling is a good compromise. It has drawbacks but they are workable. I wouldn't want the quoting solution (suddenly you'd need an additional escaping mechanism, which complexifies things, and I do believe it would make authoring HTML harder). And I'm not sure how could HTML do better without such a quoting solution.
I'm particularly not convinced by the CMS argument:
- A CMS can let users write stuff in HTML with a wysiwyg editor
- A CMS can trim printed strings, and replace new lines with br elements. If you need people to be able to break lines while writing, you can use something like markdown or whatever HN does.
As for prettifying HTML with automated tools in the editor, I never bothered. That scares me exactly because I'm afraid they will break my careful handling of whitespaces or do ugly stuff, I just prefer doing it by hand.
XML and SGML ought to have a deintent syntax that would allow indenting the code without indenting the content in the pre tag, though.
It seems well-intentioned, but not particularly well informed...
* It mixes concerns of HTML and CSS - e.g. <pre> eating newlines is a result of the HTML parser, but whitespace collapsing is specified in CSS.
* It suggests turning HTML from a markup language into... whatever incompatible thing the author came up with. Arguably it's not much worse than XHTML, but I don't expect better adoption.
* The final suggestion is to add a character reference to CSS - the sole issue being that CSS does not see character references, those are turned by HTML into Unicode codepoints. Also, the set of character references is closed, for good reasons.[0]
* (Nit, but "block formatting context" does not mean what the author thinks it means. Flex items behave like blocks because they become blockified - BFCs solve a separate, similarly hairy issue (floats & margin collapsing.))
I prefer using language agnostic tools where possible because that is both simpler and allows me to use the same tools with every language. For example, git, grep, or vim all work on any text file. vim has a few language specific settings though (e.g. syntax highlighting).
reply