latk

Yes you can implement it yourself – given how bad available cookie consent tools are, you're more likely to be compliant that way.

However, consent under the GDPR must be specific. That means the user should be able to consent to or withhold consent for individual processing purposes. Analytics would be one purpose, personalized ads another.

Note that under EU cookie laws you don't need consent for cookies that are strictly necessary for the service requested by the user. E.g. using a cookie for dark mode preference, for a shopping cart, or for the consent status itself is perfectly fine without consent.

> Even the simplest organizational schemes require a great deal of _discipline_ to be successful with

Which I think means: all that's needed is discipline. Which organizational scheme you use (if any) is almost irrelevant.

The useful question is then: which methods help building discipline?

Yup, Perl7 + Carton looks like a good combo for stable programs that don't have to be distributed publicly. I just wish cpanm and Carton were Core :D

Interesting, I've been moving away from Perl and Python and towards Rust precisely because I'm afraid of bitrot. Perl the language is stable as fuck and takes back-compat extremely seriously. The problem for me was the library ecosystem: Cpan makes it tedious to pin/vendor dependencies, and installs dependencies globally by default.

They sell the same devices, but often have subtle differences regarding the exact available configuration, e.g. which SSD models are available or what the default warranty terms are. An apples to apples comparison is usually within 20€, but here it's 785€ (Schenker) vs 860€ (Tuxedo).

Hmm. It's weird that they allow for such large arbitrage opportunities given that they're part of the same tronic5 company group.

> I feel like I read somewhere that telling the user to adjust their cookie settings in the browser was speficically discussed, and not allowed, but I could be wrong.

Consent must be informed and specific, so simply asking users to set their browser to accept or reject all cookies (regardless of purpose) is not compliant.

On the other hand, if browsers get their act together and standardize a consent API with the necessary features, then browser-based consent management would surely be compliant. GDPR and ePrivacy don't address this explicitly, though GDPR Recital 32 considers consent by “choosing technical settings for information society services”.

Centralising consent in browsers is a key consideration in the proposal for an updated ePrivacy Regulation, but the EU is not going to mandate specific technologies. Everyone is well aware of the mess that is the Do-Not-Track header.

ESR was not banned for having the wrong opinion – many others expressed similar opinions both before and after his messages. But ESR, over the course of a few days where he returned to the mailing list, was increasingly unable to express those opinions in a professional manner.

While the moderators never stated their rationale, an unfortunate combination of off-list and on-list replies leaked one of ESR's blocked emails[1] although there were possibly others. Given the context of the discussion, ESR is not only deeply unprofessional here, but also making personal attacks against Coraline Ada Ehmke. Disagreement is OK, attacks are not.

And as Gil notes in that email, how ESR is promoting his cause is actually hurting and undermining open source, not rescuing it. I'd add that such attacks are even more unacceptable when they come from an ex-President or Cofounder.

If I had been the moderator to make that call, I'd even have considered banning ESR without any particular evidence. That guy isn't new to the scene but has a long history of troublesome behavior. Even his first message upon return did not provide anything new to the discussion, so there was no reason to believe that keeping him around would provide any value to anyone. When his messages were largely brushed off (because they contributed no novel points aside from BeInG wRiTtEn By ThE cOfOuNdEr) that only seemed to encourage him to get more extreme, thus running straight into a ban. If not after that message, surely after the next.

[1]: http://lists.opensource.org/pipermail/license-discuss_lists....

One of them does rather dishonest marketing, the other is upfront about capabilities and defaults.

Telegram: we do E2E!* That makes us MORE SECURE than other messengers!

Matrix: you can enable E2E if you want.

* just not by default†

† unless you count "E2E" security between your client and our servers,‡ which we'll confusingly highlight in our security documentation as if it were special††

‡ you don't really need E2E anyway because we store your data in shell companies across the world

†† I guess it is "special" because Telegram invented its own crypto algorithms?

I'd like Telegram a lot more if they would stop with their bullshit claims, because it's actually a good service for some usecases. While reading the article I was hoping it was just written by a clueless Telegram fanboy, but reality is disappointing…

1. Many indie developers will not actually be subject to the GDPR. The GDPR effectively only applies to non-EU controllers if they are actively targeting and expecting EU users, or if they are monitoring/tracking users in the EU.

The canonical reference to when that's the case is the EDPB Guideline 3/2018 on the territorial scope of the GDPR [1]. These guidelines are more narrow than widely perceived, e.g. that regional US news websites started blocking EU visitors is totally silly and unnecessary. Mere accessibility of a service, without offering the service to persons in the EU, does not trigger the GDPR.

2. If the developer does expect to be subject to the GDPR, they can hire a representative. There are many lawyers offering this service. It's not a terribly involved job, but it affects which member state's data protection agency is responsible. E.g. if you think Austrian GDPR interpretations are nuts, go look for someone in Ireland instead.

[1]: https://edpb.europa.eu/our-work-tools/our-documents/guidelin...

I think the situation is the other way around:

* Singular “they” can be the correct pronoun for some people, especially enbies.

* Monica does not want to use singular they for grammatical/stylistic reasons – when talking about persons of unspecified gender, alternative constructions are available.

* SE's CoC clarification supposedly says you must use the correct pronoun if it is known, including singular they. Constructions that intentionally avoid pronouns would then be ruled out.

* This is not a ban on the use of singular they.

Of course, SE's new CoC or new interpretation is still not public, so its actual contents are unknown.

Singular they is great when pronouns are unspecified, and also makes for a great specific pronoun :)

But the issue at hand is precisely that Monica doesn't want to use singular they, even when someone has specified that pronoun – not out of bigotry, but because it supposedly makes for ambiguous, inelegant writing. Instead she prefers alternative constructions. I think this standpoint is more stupid than actually harmful; Stack Exchange of course disagrees.

I understand your scepticism, and was thinking hard about this before I published the linked post.

Anti-trans and anti-CoC sentiment are certainly part of the issue at hand, but likely not by Monica. Some of the resignations may be partially motivated by hate, many of the responses definitely are. However, there are many other aspects of the firing that are problematic by themselves, regardless of the reason for the firing.

It doesn't matter what Monica believes, only how she acts and speaks. It is my understanding (based on hearsay) that at no point in this incident did she make statements that would be considered transphobic by a reasonable person. While she was uncomfortable with upcoming CoC changes, she was also asking for clarification and guidance in good faith. Definitely not in that “I'm just asking a question!” trolling style. Asking sincere questions would be the sign of a potential ally, it is illogical to shut those down. However, some of the relevant correspondence is in personal emails, so we'll never know the truth.

I'm confident that she didn't say or do anything that would violate the current or upcoming SE CoC, but that the director firing her felt that Monica's questions were evidence that she would not uphold the upcoming CoC. This is silly: if a mod feels they are unable to fulfil their position they can just resign, no need to boot them in advance. I dislike the “thoughtcrime” meme, but here it might actually fit.

There's also an aspect that I find more troubling, which is the legitimacy of CoCs. They only protect the community when violations are investigated fairly. Normally the problem is that the CoC is not enforced enough. Here, a CoC was enforced without there being a violation, and that gives ammunition to the idiots who think the sole purpose of a CoC is to silence insufficiently progressive speech.

Edit 1: the first resignation is in that explicitly lists the CoC as reason for resignation [1]. The CoC will apparently require that correct pronouns are used.

Edit 2: the new CoC will allegedly require pronouns, i.e. will not allow the avoidance of pronouns. As a person who prefers non-standard pronouns, such a requirement is counterproductive because it requires some people to act against their conscience, whereas avoiding pronouns still avoids misgendering and lets everyone save face.

[1]: https://christianity.meta.stackexchange.com/questions/6718/b...

There is a perpetual tension between those who want SE to be helping everyone, and those who want to curate a helpful resource. People involved with community moderation aspects tend to fall into the latter group.

For the last half decade or so SE has progressively abandoned this latter group, leading to a lot of pent-up frustration. Some changes SE has made are sensible (e.g. striving to be more welcoming and more inclusive), but the volunteer work of curators has only become more difficult. SE refuses to implement new tools to aid moderation, so that e.g. spam fighting is mostly done by volunteer projects.

That only sets the general scene. Since the last year or so SE has stopped engaging the community on Meta, mostly just announcing changes top-down. Tweets by third parties have larger impact on SE policy than long-standing complaints by the community. This has led to a further deterioration of the relationship. The illegal changes to the content license a month ago are a perfect example of this top-down, uncooperative approach.

Now the actual drama starts: in a closed moderator chat, there was some kind of discussion or disagreement. I'm not privy to the details. Not all of this is nice, e.g. it seems that SE is unwilling to protect trans moderators from vitriol by other mods. But to everyone's confusion, Monica Cellio was suddenly removed as a volunteer moderator. She is known as being extremely reasonable, experienced, and sincere. While she might have tried to discuss sincere questions, it is beyond belief that she would attack another moderator.

So moderators and other engaged users are deeply frustrated, see a company that no longer engages with the community, does stupid decisions, and has now fired one of the best volunteer moderators in a despicable manner. For a lot of people, this is the straw that broke the camel's back. E.g. one mod I know decided to resign because they now see themselves completely unable to achieve any positive change on the site. And if Monica isn't a good-enough mod, how can they hope to be remotely adequate?

Disclosure: I wrote the linked Meta.SE question. It is my belief that SE the company and SE the community need to cooperate for both to be successful. Yes, the community can sometimes be toxic. But the company seems to have given up completely on engaging with the community, and that does not bode well.

The author is interested in PL design, and thinks that while C++ style object implementations are great at offering compatibility with certain systems or interfaces, other approaches allow for far nicer semantics in a greenfield programming language.

For example, fat pointers make it possible to implement interfaces for existing types. I have experienced that as game-changing in Haskell, Go, Rust.

I also disagree that any memory usage can be handwaved as “no longer relevant today”. Electron, or garbage collection: perhaps. But object size affects cache pressure, and cache utilization is critical to performance. C++ is typically good at keeping objects small, except when it comes to multiple inheritance.

(Author) I am aware of the problem. For me it works on desktop but not on mobile browsers – apparently the Unicode box drawing characters are not really fixed-width on all systems?

One day I'll write a Pandoc filter that pipes these diagrams through a Shaky or Ditaa type tool first…

CLR routes any interface calls through an indirect cell or pad that can be quickly rewritten to point to a different dispatch stub. Some stubs perform caching whereas the generic resolver behaves as explained by the pseudocode in my article.

The “book of the runtime” has a graph visualizing these possibilities: https://github.com/dotnet/coreclr/blob/master/Documentation/...

So this is a self-modifying code approach.

Author here. Both the JVM and CLR do some pretty aggressive optimizations even for normal interface calls. In the Java section I also show inline caching, a standard optimization approach. The CLR calls its approach to caching “virtual stub dispatch”. Speculative optimizations and inlining would be more advanced optimizations that I did not cover.

But what about the worst case – the method lookup when the method is not in the cache? There, the CLR introduces an additional level of indirection for calls through interface types, which has benefits for memory usage and possibly dispatch time. But since this is the worst case, the complexity doesn't matter that much as long as the important cases (which can be cached) work well.

OSI generally requires that the license steward/author submits the license for review if they want it to be approved.

Upon being asked about this by OSI President Simon Phipps, Kyle Mitchell responded that Blue Oak has no plans to seek approval (https://twitter.com/kemitchell/status/1104579340732264448). I would have found anything else surprising, given that last month Mitchell had this to say about the OSI (in the context of SSPL review):

> I've lost confidence in this body's ability to make rigorous decisions, or even facilitate focused debate, […]. So I've otherwise stopped responding, and focused my efforts where collective time and talent have hope of yielding practical results.

Source: http://lists.opensource.org/pipermail/license-review_lists.o... Context: https://opensource.org/LicenseReview022019

That Perens quote refers specifically to Sunil Deshpande's article about the SSPL and Open Source, not to the SSPL itself. But it's not far off either way…

The reaction on the OSI's license-review list is more varied. Lawrence Rosen and Ken Mitchell argue that the license should be approved. Everyone else is criticizing that it clearly violates the spirit of Open Source software (no discrimination against fields of endeavour!), and that the license is too broad and too vague in the critical section (Rosen agrees with the latter part). Carlo Piana points out that the goal of the license seems to be to create so much legal uncertainty that any serious user would be forced to buy a proprietary license from MongoDB.

Python's variables spring into existence at the moment of first assignment and are function-scoped (or module-scoped). The scope can also be terminated with the "del" statement. This has three problems:

1. The lifetime of a variable depends on control flow, and is not statically determined (in the general case). The exact scope is dynamic.

2. Many variables are not used throughout a function, but only within a small region of a function, e.g. an "else" block. Python's variables have a too large scope. To add confusion, a few Python constructs like "except" clauses or list comprehensions are block-scoped.

3. Working with nested functions is extra complicated. While you can read variables from outer scopes, you cannot assign them, unless you declare them as "nonlocal" or "global" in the nested function.

As a special case of 3, consider closures that are declared within a loop:

    adders = []
    for x in range(10):
      adders.append(lambda y: x + y)

All these lambdas close over the same "x" variable which is reassigned. After the loop terminates, "x = 9" for all lambdas.

Python's common workaround is to use an immediately invoked function that binds the value to a scoped argument. In lambda calculus terms, we have to desugar the "let" abstraction to function application:

    ...
      adders.append((lambda x_: lambda y: x_ + y)(x))

(Another alternative is to capture by value by using default arguments, as the defaults are executed at function definition time: "lambda y, x=x: x + y".)

A similar language that shares Python's problems is PHP, where a nested function has to explicitly "use" outer variables it wants to capture.

Perl (like most languages since Algol, Scheme, and C) requires explicit variable declaration (unless "use strict" is not enabled). In Perl, "my" declares a local/block-scoped variable. Consequences:

1. The lifetime of a variable is easy to determine statically: from the declaration to the end of the current scope (in Perl: to the next "}" that marks the end of the current block). This is called "lexical" scope.

2. I can restrict a variable to the smallest scope where it is needed, thus simplifying my code.

3. Nested functions are much easier. If I assign a variable, it uses existing (outer) bindings, unless I explicitly shadow the variable with a local declaration.

If we return to the closures in loops problem, Perl creates a new variable for each loop iteration, thus avoiding Python's problems:

    my @adders;
    for my $x (0..9) {
      push @adders, sub ($y) { $x + $y };
    }

Because the "a.b" is not a key, but a table "a" that contains an entry with key "b". If you write "a.b = 1" then that integer is not a table, and can't have an entry called "c".

Because it avoids these problems, your "name.alternative.first" example seems perfectly sensible to me. Alternatively, the name might be an array:

    [[name]]
    first = "Bob"
    last = "Smith

    [[name]]
    first = "Robert"

It's probably best to think of TOML as convenient syntax for creating a JSON-like structure. What kind of JSON would you expect as the result of your config examples?

You are completely correct that simply blocking access does not make them compliant while they are still storing that data.

But compliance isn't binary. I'm sure the data protection authorities understand the difference between “LOL I'm already noncompliant so I'll just continue business as usual” versus “Working hard to fix this – in the meanwhile, let's prevent covered Subjects from sending us more data until we are prepared to handle it compliantly.”

GDPR applies if (1) the Controller or a Processor is “established” in the EU, or if (2) the Subject is in the EU. Citizenship doesn't matter, and geoblocking is the legally correct solution. As an example: U.S. tourists on a trip to Paris are protected by the GDPR, but a Polish expat in California is not. (See Art. 3 GDPR https://gdpr-info.eu/art-3-gdpr/)

It doesn't. But if you notice you might be doing something illegal, it's a great first step towards compliance to stop doing _more_ of it.

Here, Instapaper is likely not misusing user data, but has to catch up on compliance documentation and small details (e.g. signing data processing agreements with services they use, raising the age limit from 13 to 16, …)

But would another company even have standing to sue? The GDPR is about personal data of natural persons. Such data subjects can sue under Art. 79 if their rights are violated. The most another company could do would be to “incentivize” a natural person to get their rights violated by you and then sue.

Perl5 has a lot of historical baggage that makes certain things difficult to do efficiently. For example, how objects work. There is an insane amount of indirection involved for a simple method call, and this indirection can't generally be removed if we want Perl5 to stay highly backwards-compatible. Numerics aren't particularly efficient either. Perl5's opcodes are very high-level. That makes each individual opcode pretty fast, but makes it difficult to inline stuff. Variables can have “magic” attached that can change their semantics substantially. While this is very flexible and allows to do some amazing things, this also requires this magic to be checked on each access. So Perl5 has a lot of features that rank high on “clever”, but low on “can be optimized”. Perl5 never got JIT support, and only has a couple of very experimental Perl-to-C transpilers.

What is fast is string handling and log mangling. Perl was created for that; everything else is bolted on.

Disregarding generalized parsing because you can't prove unambiguity is like eschewing Turing-complete languages because you can't solve the halting problem: it's short-sighted.

In the context of programming language design, an unambiguous syntax is important. However, parsing technology is not exclusively applied to programming languages. Marpa's support for ambiguity and abstract syntax forests can e.g. be used for natural language processing. 10 in 10 joke tellers concur: Ambiguity in the English language is a feature, not a bug.

Well, when I use Marpa, I don't actually use abstract syntax forests. But the ability to generate and compare multiple parses, plus especially the ability to inspect the parsing state at an arbitrary point during the parse, are great debugging tools to understand why a given grammar is ambiguous.

HTML headers can include a `<link rel="canonical" …>` that points to the up-to-date URL of this item. Furthermore, outdated or invalid titles could be redirected with a "301 moved permanently" to the current title.

That's not an issue if only the ID is used to identify the submission, whereas the title slug is only human-readable fluff. E.g

    /item/1234/original-submission
    /item/1234/edited-title
    /item/1234/arbitrary-string
    /item/1234/

This could also be done with the current query string approach, e.g.

    /item?id=1234&title=original-submission
    /item?id=1234&title=edited-title
    /item?id=1234&title=arbitrary-string
    /item?id=1234

OP's suggestion of having the title be part of the ID would be quite inelegant, but possible if the real ID is only the digits up to the first hyphen.

Ideally, the title would be completely ignored, but other titles would redirect to an URL with the current title.

For a format to be used, it has to be attractive in some form. Markdown is attractive because it's extremely easy to read and write. HTML is attractive because it can be displayed by all web browsers. LaTeX is attractive because it is extremely powerful, has the best math typesetting, and allows for user-defined abstractions. Your format is not easy to read. There is no implementation that displays it. It lacks many advanced features that make it useful, and those features that it does have are rather weird.

To evaluate the format, let's consider a couple of texts that could be written, with their unique requirements:

- A fantasy novel. The novel may rely on custom fonts, or multi-colored text. Your UBook cannot handle this (but to be fair, neither can Markdown).

- A collection of poems. Modern poems can have rather challenging layout requirements, which UBook does not offer (but to be fair, neither does Markdown).

- A highschool-level math textbook. This requires good support for math typesetting, figures, and tables. UBook has no clear vision to support math typesetting, e.g. through something like MathJax (to be fair, HTML relies on JavaScript or MathML for this, but some Markdown dialects are math-aware).

- A programming book. This requires a form of verbatim input and syntax highlighting. Neither is possible with UBook (to be fair this is a pain in HTML, and only some Markdown dialects are highlighting-aware).

- An academic paper. This has domain-specific requirements (e.g. math typesetting, special typesetting for linguistics) and also requires excellent handling of references (HTML: yes, Markdown: no) and footnotes (HTML: no, Markdown: in some dialects). The footnote handling in UBook is not sufficient (for example, it's not possible to reference the same footnote from multiple locations).

Of course that are rather demanding examples, and there are plenty of texts that don't need many of these features. What use cases remain? Any text without advanced layout or formatting requirements, and without a need for much structure: wide swaths of literature, and non-demanding technical writing. Is your UBook the best choice for those use cases? Wouldn't it be easier to write it as Markdown, and compile it via HTML to a MOBI or EPUB before deploying?

Now that I've looked at the scope of the language, let's look at the finer design decisions of UBook itself.

- For example, the whole book has to be in a single file. This makes it unwieldy to write. Adding an "include" feature could help.

- All commands except the table commands are terribly short, which makes them hard to remember. This makes sense for often-used commands, but seldom-used commands can be longer. for example, "$A" is not as memorable as "$AUTHOR".

- UBook considers a line break to be a paragraph separator. This is bad for two reasons: (1) Advanced users with version control might want to split paragraphs onto multiple lines for better "diff"s. (2) Line breaks and paragraphs are semantically different, and HTML, Markdown, and LaTeX include ways to output a line break without starting a new paragraph.

- The "$E" command (empty line) makes no sense whatsoever. No other format I know supports such a feature (although it can be faked with line breaks).

- Inventing a new link syntax is highly unnecessary. The one used by Markdown is pretty good, and allows us to refer to a link target via a shorthand:

    Some Text [inline](link) or [keyword] link which can be used with [other text][keyword] as well

    [keyword]: some link

- For the given use cases, the index functionality is unnecessary: A text complex enough to require a glossary will likely have more requirements that are not met by UBook, e.g. a way to link to a glossary entry in the text.

- Using the same character to introduce a block-level command and a headline is very confusing. It might be better to use explicit headline commands like "$SUBSECTION" and "$CHAPTER" (compare LaTeX).

- The format appears to lack composability. E.g. it's not obvious whether a block-level image can be included in a quote. It does not seem like a table cell could contain another table. It doesn't seem like a list item could contain multiple paragraphs (and if it does, where does the item end and normal text start?). Of course, this makes it very easy to parse (which is unnecessary, given today's state of parsing technology).

- The fact that the three-character sequence "$Q " has to be included before each quoted line is a WTF in itself (and a misfeature shared similarly by Markdown). This is undue burden on the author as he has to type it, and undue burden on the parser as this makes the language non-context free. Using a quotation-start and quotation-end marker would be much better for all involved.

- I fail to see the difference between horizontal lines and "$S" section separators.

- The "$END" is a horrible anachronism and should die. The end of file is good enough to denote the end. Requiring such a token means that all your examples on the page won't work, and that many authors would be surprised when their magnus opus doesn't display.

Your UBook in its current state is not a viable markup language. It has a few interesting concepts (indices, footnotes, book-orientation, table-cell merging), but isn't really attractive when we have so many other possible languages. Before redesigning the language, take a look at AsciiDoc, MultiMarkdown, and older markup languages like LaTeX, Perl's POD, and troff. Learn from their mistakes instead of repeating them! Remember that many restrictions of these formats do not apply to you!

UBook as a distribution format is unlikely to ever become a viable option even though it has some nice features like excerpts (I would like to see the ebook format market to be disrupted, but UBook won't manage that). It would be better to de-emphasize this part of UBook, and focus on it as an authoring tool that can compile to various ebook formats.