Ndymium

Personally I'm specifically talking about Forgejo which is Go, but calls git for some operations. And the effect that was worse than pegging all the CPUs to 100% was filling of the disk with generated zip archives of all of the commits of all public repositories.

Sure, we can say that Forgejo should have had better defaults for this (the default was to clear archives after 24 hours). And that your site should be fast, run on an efficient server, and not have any even slightly expensive public endpoints. But in the end that is all victim blaming.

One of the nice parts of the web for me is that as long as I have a public IP address, I can use any dinky cheapo server I have and run my own infra on it. I don't need to rely on big players to do this for me. Sure, sometimes there's griefers/trolls out there, but generally they don't bother you. No one was ever interested in my little server, and search engines played fair (and to my knowledge still do) while still allowing my site to be discoverable.

Dealing with these bots is the first time my server has been consistently attacked. I can deal with them for now, but it is an additional thing to deal with and suddenly this idea of easy self hosting on low powered hardware is no longer so feasible. That makes me sad. I know what I should do about it, but I wish I didn't have to.

Search engine crawlers generally respected robots.txt and limited themselves to a trickle of requests, likely based on the relative popularity of the website. These bots do neither, they will crawl anything they can access and send enough requests per second to drown your server, especially if you're a self hoster running your own little site on a dinky server.

Search engines never took my site down, these bots did.

It's mentioned in their code forge[0] that they're working on getting the first release out. So there's not yet anything to download.

[0] https://codeberg.org/comaps/comaps

No, it was a test for a year and deemed a failure.

The Selectric is listed under 1961.

Just noting that the archives are written to disk on purpose, as they are cached for 24 hours (by default). But when you have a several thousand commit repository, and the bots tend to generate all the archive formats for every commit…

But Forgejo is not the only piece of software that can have CPU intensive endpoints. If I can't fence those off with robots.txt, should I just not be allowed to have them in the open? And if I forced people to have an account to view my packages, then surely I'd have close to 0 users for them.

They are a cache, but you can generate them for each branch, tag, and commit in at least three different formats... Now imagine you have a repo with several thousand commits.

They're deleted by default every 24 hours and that time is configurable. Not useful when you get 60 requests per second though.

I was also under attack recently [0]. The little Forgejo instance where I host my code (of several open source packages so it needs to be open) was run into the ground and the disk was filled with generated zip archives. I'm not the only one who has suffered the same fate. For me, the attacks subsided (for now) when I banned Alibaba Cloud's IP range.

If you are hosting a Forgejo instance, I strongly recommend setting DISABLE_DOWNLOAD_SOURCE_ARCHIVES to true. The crawlers will still peg your CPU but at least your disk won't be filled with zip files.

[0] https://blog.nytsoi.net/2025/03/01/obliterated-by-ai

I had this same issue recently. My Forgejo instance started to use 100 % of my home server's CPU as Claude and its AI friends from Meta and Google were hitting the basically infinite links at a high rate. I managed to curtail it with robots.txt and a user agent based blocklist in Caddy, but who knows how long that will work.

Whatever happened to courtesy in scraping?

Ah, thanks for explaining. :)

I presume they mean Han unification[0], which to an uneducated outsider sure sounds like a fuckup. I wonder if it's possible to fix it inside Unicode without throwing the rest of it away. Reserve new blocks for all the needed graphemes and deprecate the unified ones?

[0] https://en.wikipedia.org/wiki/Han_unification

Since it requires runtime checking anyway, that code has to live somewhere. The decoders are that code. I don't understand how changing the runtime representation would allow to not have those decoders. Unless you mean they should be implicitly generated by the compiler. Or maybe I'm just missing what you're saying.

How would this representation be converted back to known types without similar decoders? Right now Gleam compiles custom types to Erlang records (tuples) and JS classes.

I can appreciate the funny lyrics, but in real life I appreciate being able to write in my own language on a computer. Or even a mix of my language and another non-English language!

I'm a master of half finished projects, so here's one that's half finished and one that's actually published and has a half finished user's guide: a PWA client for the iBroadcast music service [0] and a static blog generator [1] that I use to generate my blog [2].

Since all of my free time programming nowadays is in Gleam, I hope to have better examples for you in the future. :)

[0] https://git.ahlcode.fi/nicd/elektrofoni

[1] https://hexdocs.pm/scriptorium/index.html

[2] https://blog.nytsoi.net

I use iBroadcast[0], it's a service dedicated exactly for this. Costs me a bit each year but I've felt it worth it. There's some differences to organising in iTunes like the handling of compilation albums that I'm not so fond of but you can see how it works on the free tier.

The browser client only does 128 kbps streaming but their mobile client can set the streaming quality (I have it at 256, max is 320) and I'm working on my own PWA client using their API that I've also set to 256, which would work on both mobile and desktop.

You can also set the browser client to stream the original file directly but browsers don't play most of my formats like ALAC so it just doesn't play anything then.

[0] https://ibroadcast.com/

I agree, "timestamp with time zone" is a terribly misleading name and personally I don't use that type very much.

Here's the PostgreSQL documentation about timestamptz:

> For timestamp with time zone, the internally stored value is always in UTC (Universal Coordinated Time, traditionally known as Greenwich Mean Time, GMT). An input value that has an explicit time zone specified is converted to UTC using the appropriate offset for that time zone. If no time zone is stated in the input string, then it is assumed to be in the time zone indicated by the system's TimeZone parameter, and is converted to UTC using the offset for the timezone zone.

> When a timestamp with time zone value is output, it is always converted from UTC to the current timezone zone, and displayed as local time in that zone. To see the time in another time zone, either change timezone or use the AT TIME ZONE construct (see Section 9.9.4).

To me it seems to state quite clearly that timestamptz is converted on write from the input offset to UTC and on read from UTC to whatever the connection timezone is. Can you elaborate on which part of this is wrong? Or maybe we're talking past each other?

I actually had the same deal with firewalls and prefixes, since I want to direct traffic to my server and its address obviously depends on the prefix. Turns out OpenWrt has a feature for this too [0], meaning you can use a destination address like "::1234/-56" in your firewall rules.

[0] https://openwrt.org/docs/guide-user/firewall/fw3_configurati...

Related, I just recently got IPv6 in my home connection and tried to set it up with my EdgeRouter X. It was impossible even though I followed all the online instructions to the letter. I then installed OpenWrt on it and it worked like a charm, with IPv6 out of the box (I did customise my configuration later). I wrote a post about the process for anyone interested [0].

[0] https://blog.nytsoi.net/2024/09/19/edgerouter-x-openwrt

It can also cause trouble if you store past events but do not store the user's local offset or timezone at the time of the event. If you aggregate these events later into a dataset of "events by hour", they may be grouped wrong (from a user's perspective) if you convert them all to the user's _current_ timezone.

But, you need a runtime. If Gleam had its own runtime, that would be another layer in a similar vein. Here Gleam is using Erlang (or a JS runtime) which is bound to be more supported and have a longer lifetime than something they cooked up themselves.

Besides, Gleam's original aim was basically "Erlang but static types", so the choice of Erlang as runtime was always there.

I wouldn't call myself a person with a mathematical background, but there are those people who believe it's just fine. [0] I don't have enough knowledge to debate that, but it would seem to disprove "basically nobody". Zero is a convention, like NaN or Inf are conventions.

A problem that Gleam has here is that the Erlang runtime does not have NaN or Inf in its float type (or integer type for that matter). It could be represented with an atom, but that would require an atom and a float having the same type in Gleam, which is not something the type system can do (by design). The operator could, in theory, return a Result(Float, DivisionByZeroError), but that would make using it very inconvenient. Thus zero was chosen, and there is an equivalent function in the stdlib that returns a result instead, if you wish to check for division by zero.

[0] https://www.hillelwayne.com/post/divide-by-zero/

Which part do you feel like would be an issue? When you run `gleam compile`, it will automatically call the Erlang compiler to finish the job.

I find it very handy that the intermediate Erlang (or JS) files are available in the build directory. It lets you easily see what form your code will take when compiled.

It's a reference to Jon Postel who wrote the following in RFC 761[0]:

    TCP implementations should follow a general principle of robustness:
    be conservative in what you do, be liberal in what you accept from
    others.

Postel's Law is also known as the Robustness principle. [1]

[0] https://datatracker.ietf.org/doc/html/rfc761#section-2.10

[1] https://en.wikipedia.org/wiki/Robustness_principle

You may have strong opinions on anti-cheat software and they may be correct, but it is required for playing certain online multi-player games, and people want to play those games on Linux too (especially the Steam Deck, I would presume). Ergo, people want anti-cheat software on Linux.

Speaking from a purely customer perspective (I'm not a business person or startup founder), the big things that are missing from the landing page and/or signup flow are:

- Pricing. I don't know what this is going to cost me. It does not say if I'm entering a trial period or if it's free.

- Privacy policy. Who are you and what will you do with my data?

Also, I suppose this is a target market thing, but I've never heard of LINE so having it mentioned does not make me more interested. I guess it will work where that app is popular, though.

What was the mobile Authy fiasco?

It's the same stuff. I'm not sure how much of it leaks, but you have to either flare it or use it for something or it leaks anyway. Using it for cars and trucks is basically flaring it but using that energy for propulsion.

The taxes are not based on that, though. They're strictly interested in tailpipe emissions (not even lifecycle emissions), and don't recognise biogas at all.

I'm planning on switching to a BEV eventually, but right now it's not financially possible. Most of the time I commute on my bicycle anyway.