lifthrasiir

In fact that line in question does come from an IOCCC winner: https://github.com/ioccc-src/winner/blob/master/1985/shapiro...

Presumably because Rust is more suitable than Go in agentic coding? (I'm not sure, but that seems the purported answer.)

It is actually hardcoded and also reachable by "play the block game": https://america.gov/_astro/block-game-poem.Khrmh8AU.js

The former also conveys that you are rude, which is not what you usually want.

I was about to immediately suggest UCS-X, and then pleased that the author offers a fair comparison to UCS-X and many other alternatives. Great. Too bad UCS-X is possibly more memorable name.

I recently had a misfortune to draw every country flag with a limited palette of shapes (axis-aligned rectangle and triangle, ellipses, {a/b} regular polygons) and operations (union, subtraction). [1] It is really annoying to be as faithful as possible; you have to deal with varying aspect ratios and under- or unspecified construction methods and colors, and at some point you have to decide how to modify the flag to fit the target resolution and aspect ratio without being too different. Also you would eventually have to face the flag of Bhutan [2]... (I haven't yet drawn it.)

[1] https://github.com/lifthrasiir/unison/blob/gh-pages/font/fla...

[2] https://en.wikipedia.org/wiki/Flag_of_Bhutan

Apart from the usual hypocrisy,

> Safety controls may be lost – models trained on Claude's Outputs won't have our safety measures, potentially leading to harmful or dangerous AI systems. We also have no visibility into deployment, meaning we cannot monitor how these distilled models are used or prevent misuse.

So was that why your models caused three real-world security incidents?

I'm on a mobile right now so I can't give the exact paper link but you can learn about the CORE-MATH project [1].

[1] https://core-math.gitlabpages.inria.fr/

The dilemma is hypothetical (because we now know the exact precision requirement for those functions over all 64-bit doubles) but let's assume that we don't know that and also we happen to use decimals instead. What if, some f(x) is known to be, say, 123.4999...9997 with 1,000 fractional digits? You have to calculate at least 1,000 decimal digits of f(x) in order to correctly round, before that we only know it's between 123.4999...999 and 123.5000...001. There seems no mathematical theory that specially prevents this annoying possibility, hence the dilemma.

Common sense testing only tells about the presence of common sense, that's it. It is clear from recent events that LLMs do definitely possess some sort of intelligence even though it might have been polarized to certain domains.

It is a project-wide concern, so the stake is obviously high.

They learned English or gave up.

All of which have been challenged though. As the stake is high, any such reason (for or against LLMs, to be fair) has to be backed with Wikipedia-level evidences at the very least.

The OP said the Mandela effect [1] which is definitely about the past event. Anyhow, I'm okay with Codeberg's decision (I'm not even its stakeholder, so what can I say about that anyway) but it has to be honest about the intent. If its definition of "F/OSS" has changed, do say so.

[1] https://en.wikipedia.org/wiki/False_memory#Mandela_effect

Many influential F/OSS projects started with a small number of users (and contributors), and will continue to do so for the foreseeable future. Codeberg effectively says that it only welcome mature enough projects that it feels worthy to host, and that's selfish. That's not a direct problem by itself but still a good reason to get criticized.

Do yourself a favor and look at the actual HN thread [1] when Codeberg was widely discussed for the first time. It is crystal clear that Codeberg was seen as a direct alternative to GitHub at that time, and even the founder's quoted statement gave a nod to that I think?

> [...] But as developers of free software we fell into a trap – we poured invaluable source code, documentation and last not least a huge and steady stream of data about our personalities, interests and social networks into proprietary platforms. [...]

(And no one knew Codeberg had a right to determine which source code and documentation is invaluable.)

[1] https://news.ycombinator.com/item?id=22795930

I think an even better advice is that everyone should know array programming, because you generally need that mindset for SIMD optimizations as (packed) SIMD-specific techniques are surprisingly rare. And array programming gives you a generally performant code even without SIMD because it is much easier to auto-vectorize.

In the other words, free() is a flawed API. :-)

This follows what SourceHut did in 2022 [1], but I think SourceHut did much better job to announce that (as of this writing).

[1] https://sourcehut.org/blog/2022-10-31-tos-update-cryptocurre...

Apparently in early this month.

> In the three examples below, the model accurately renders Japanese, Korean, and Spanish respectively.

And yet the Korean text is not accurate... [1]

[1] E.g. "드레스 컬렉션 dress collection" has vowels ㅔ mixed with ㅐ, "초웜한" should be "초월한 exceeding", "신키한" should be "실키한 silky", "디자언되다" should be "디자인되다 have been designed", "로얼" should be "로열 royal", and so on.

I used to make a hybrid bitmap-vector font called Unison [1] a decade ago and I made it in that way so that I don't have to learn the fine art of (vector) typography. Or at least that I could skip most of it (for example, kerning is still required for proportional fonts, but that doesn't have to be very precise in bitmap fonts). I'm now working on Unison once again after 11 years of time, this time armed with a dedicated font editor called Uniform. I haven't publicly released Uniform in public yet but anyone interested can already download and compile it.

[1] https://github.com/lifthrasiir/unison

Probably, but knowing that redirection operators can be freely moved within normal arguments [EDIT: thank ButlerianJihad for pursuing me to make this more accurate] is useful.

Don't do this:

  cat file | wc -l            => wc -l < file
  cat file | head -n 5        => head -n 5 file
  cat file | awk '{print $1}' => awk '{print $1}' file
  cat file | sort             => sort file

Do this instead:

  cat file | wc -l            => <file wc -l
  cat file | head -n 5        => <file head -n 5
  cat file | awk '{print $1}' => <file awk '{print $1}'
  cat file | sort             => <file sort

The front-cat abuse is all about the order. The effective solution needs to keep the relative order of arguments.

How does it compare with utf8proc [1]? I'm aware that Mojibake does a bit more than utf8proc (e.g. bi-di) but that seems marginal to me.

[1] https://juliastrings.github.io/utf8proc/

Context: 码 means "code" in Chinese and prominently appears in words like, e.g. 源代码 (source code).

> exfiltrating user data (including env files, entire source code etc) which is what grok-build did here

I think env files are filtered out [1]. Anyway, the most suspicious code would be `upload_session_state` which is currently a stub function, though it is hard to say if it was only planned (badly) or has been removed as a damage control.

[1] https://github.com/xai-org/grok-build/blob/c1b5909ec707c069f...

Is this the infamous "cloud upload" routine? I'm not sure it is indeed insidious, though it is of course possible that the code has been filtered out. https://github.com/xai-org/grok-build/blob/main/crates/codeg...

Sharing those things to coding agents and model providers is probably inevitable for the use. The memory with random tidbits is not.