shiomiru

Yeah it's so sparse on actual details of Sumerian or cuneiform that after reading the article I remain unconvinced the "author" either cares for or knows anything about the topic.

(To be clear I know nothing about it either, but as a human with some similarly "pointless" hobbies, I can't imagine posting a writeup with so much motivational bullshit but so little about the actual thing I'm interested in.)

I can usually read JS generated by TS, but calling the C Nim outputs "human-readable" is very generous considering it flattens most structured control flow to goto. (It's hard to do it otherwise, Nim has to deal with exceptions and destructors but C has neither.)

Classifying Nim as a transpiler also results in weird cases like NLVM[1] which most would consider a compiler even though it is a back-end on the same "level" as Nim's C generator.

[1]: https://github.com/arnetheduck/nlvm

I should've worded differently. By the narrative of this website, Google is "paying" Mozilla & Apple to remove XSLT, thus they are "controlled" by Google.

I personally don't quite believe it's all that black and white, just wanted to point out that the "open web" argument is questionable even if you accept this premise.

Ironically, that text is all you get if you load the site from a text browser (Lynx etc.) It doesn't feel too different from <noscript>This website requires JavaScript</noscript>...

I now wonder if XSLT is implemented by any browser that isn't controlled by Google (or derived from one that is).

To clarify, I think it's fair to say "I use GitHub because I don't think MS is that bad" (I disagree, but it's at least a consistent view.)

I only take an issue with "I think MS is morally reprehensible but everybody uses it so I'll keep using it too" because it's a self-fulfilling prophecy. Most people looking for code hosting will use whatever they first run into, so when you choose a host for your project you are also directly channeling users towards said host. It's your responsibility to pick a host for your projects that isn't evil by your standards, whatever those may be.

If it's not a magical achievement, then surely competitors could replicate it too.

Of course you can't put a million users today in a service used by a thousand yesterday, but I don't buy the "non-profits don't scale" argument. If that were true, we wouldn't have Wikipedia either.

I switched because btop provides vi-like keybindings. For htop I think you have to use a fork to get that.

But your confidence in GitHub's continued existence comes from its network effects, no? And competing services can only gain such network effects if more people use them. So to me this feels like a defeatist argument.

Sixel came earlier, and already fulfilled the basic requirement of "put pixels on screen in a single well-defined format" (something not even iTerm2's protocol does.)

Kitty is a lot more complex: it accepts five different encodings, has three different ways to load the data, supports animations, etc. So it's no wonder only a few terminal developers had time to implement it.

See also: https://github.com/veltza/st-sx/issues/1#issuecomment-190272... 5000 lines (Kitty) vs 1000 lines (Sixel) even though the Kitty patch is just a "subset".

It's deep in the uncanny valley. Even ignoring the writing style, the entire post is about the incredible insight of "you can build TCP on top of UDP" using a forced analogy. No further analysis, no real world example, just UDP and the convertible and the convertible and UDP...

It says

> the encodings defined in Encoding, including, but not limited to

where "Encoding" refers to https://encoding.spec.whatwg.org (probably that should be a link.) So it just means "the other spec defines at least these, but maybe others too." (e.g. EUC-JP is included in Encoding but not listed in HTML.)

> It would greatly simplify browser code and HTML spec.

I doubt it would make a dent - e.g. in the "skipping <head>" case, you'd be replacing the error recovery mechanism of "jump to the next insertion mode" with "display an error", but a) you'd still need the code path to handle it, b) now you're in the business of producing good error messages which is notoriously difficult.

Something that would actually make the parser a lot simpler is removing document.write, which has been obsolete ever since the introduction of the DOM and whose main remaining real world use-case seems to be ad delivery. (If it's not clear why this would help, consider that document.write can write scripts that call document.write, etc.)

I've done something like that in my TUI browser:

https://codeberg.org/bptato/chawan/src/commit/3f2fffd882ff47...

It just spins up a background process when a canvas context is created and sends drawing commands through IPC. As a result, you can rm the 970k canvas binary (most of it is just Unifont) and with some luck you will only break canvas rendering.

Of course this only works for things that are relatively self-contained. So you can add/remove image decoders or protocol handlers without recompiling (the main binary has zero networking code), but the JS API is still baked in.

(I imagine you could also implement some less performance-sensitive APIs in JS and load the bytecode on demand, but I haven't tried.)

> The point is they are not even compliment to their "own" spec. They are part of whatwg.

I think web devs have too much faith in the "standard"; the WHATWG specifies anything supported by two implementations, and with Google controlling Mozilla that already feels somewhat unfair...

> Write a page on chrome, works 90% on Firefox. But will likely works 10% on safari.

Disregarding the issue that you're writing pages that only 90% work on anything but Chrome... do you have any examples of Safari misbehaving?

The whole post is obviously LLM spam. e.g.

> It is the conductor [emoji] that directs the symphony of independent Spaces.

this pattern is a meme by now.

Also, SMTP straight up leaks your IP address when sending e-mails (the "Received" header.)

The Unlicense isn't "just" public domain though, it also has a fallback clause that explicitly lists things you are allowed to do ("copy, modify, publish, use, compile, sell, or distribute"). So I think the intent is, even if PD isn't recognized and line 1 is invalid, you're still granting a license to the same effect.

SQLite on the other hand just says

    The author disclaims copyright to this source code.  In place of a legal
    notice, here is a blessing:

      May you do good and not evil.
      May you find forgiveness for yourself and forgive others.
      May you share freely, never taking more than you give.

which seems less useful once you strike sentence 1.

I had to work around this recently - it involved reimplementing my poll wrapper on top of select(), with the proprietary macOS extension that makes it support unlimited fds. (Of course -D_DARWIN_UNLIMITED_SELECT is completely unportable, so I still need poll too.)

Meanwhile poll() just works on Linux and the BSDs, certified or not.

> It looks well-intended

The recent PuTTY domain squatting debacle has made me suspicious, and indeed... if you look closer, you'll notice that the owner of ublockorigin.com is also advertising his completely unrelated products in a "my other tools" section.

It already exists for Sixel: https://github.com/saitoha/xserver-sixel

...but at that point X forwarding or VNC seems more useful.

But that's also completely unremarkable, given that word for word translation in any two languages is expected to be a lossy conversion.

> The problem is they abandoned rails for react.

Which, it seems, was a result of the M$ acquisition: https://muan.co/posts/javascript

> Telling people to ignore code points

Nobody is saying that, the point is that if you're parsing Unicode by counting codepoints you're doing it wrong. The way you actually parse Unicode text (in 99% of cases) is by iterating through the codepoints, and then the actual count is fairly irrelevant, it's just a stream.

Other uses of codepoint length are also questionable: for measurement it's useless, for bounds checking (random access) it's inefficient. It may be useful in some edge cases, but TFA's point is that a general purpose language's default string type shouldn't optimize for edge cases.

> I think the real reason most are so obsessed with blocking crawlers is they want “their cut”…

I find that an unfair view of the situation. Sure, there are examples such as StackOverflow (which is ridiculous enough as they didn't make the content) but the typical use case I've seen on the small scale is "I want to self-host my git repos because M$ has ruined GitHub, but some VC-funded assholes are drowning the server in requests".

They could just clone the git repo, and then pull every n hours, but it requires specialized code so they won't. Why would they? There's no money in maintaining that. And that's true for any positive measure you may imagine until these companies are fined for destroying the commons.

Right. If anything, it's the opposite: removing XSLT reduces the complexity of existing browsers, allowing new ones to catch up faster.

To me it seems that some people just really like using XSLT, and don't want it gone. Which is fair, but it also has nothing to do with the web's openness - yes, Google has far too much power, but XSLT isn't helping.

Neither is it required in Nim.

A Nim object is a stack-allocated value type, without refcounting. You can put that in a heap-allocated seq (pass-by-value with move semantics), ref (refcounting), a custom container (you decide), or ptr (unsafe, like C).

ARC's ref is similar to C++'s shared_ptr, or Rust's Rc - with that alone it might still count as "GC'ed". But ARC also has ownership semantics, and hooks for custom containers: https://nim-lang.org/docs/destructors.html so I think it's fair to put it in the "system language" category.

And if you don't want to install Java, there's also a C++ implementation: https://i2pd.website/

> As if oligopolization of the browser space wasn't a deliberate objective of the WHATWG.

So why is it that when once in a blue moon the WHATWG tries to do something that also happens to help new implementations, web devs come in to cry bloody murder? Maybe there are co-conspirators to the scheme? :)

> No, adding complex new interfaces and then demanding that every browser implement them quickly is what does that.

New interfaces forced into the spec without concern for complexity have led to the demise of existing browser engines.

But the lack of new implementations is also a result of the insistence on keeping all obsolete interfaces, no matter how complex or how little their remaining usefulness, at all cost. (Looking at you, document.write...)

> > a) freeze the standard

> Yes, or rather new features should become rarer over time.

This is far more unrealistic than dropping XSLT support.