derhuerst

In case you are in (or IP-geolocated to) the EU: https://www.arte.tv/en/videos/115068-000-A/nuclear-putin-s-d...

to give a example: https://en.m.wikipedia.org/wiki/2019%E2%80%932021_Jammu_and_...

i'm not sure if in this case "only" the 4G network was shut off, but IMO it still serves as a good reminder of when such an event might happen again.

also: https://ooni.org/reports/

blog post with the background story why this was created: https://asahilinux.org/2025/03/progress-report-6-14/#is-this...

remotely related:

libinput (handles touchpad input in most Linux distributions) now supports three-finger dragging [0].

[0] https://who-t.blogspot.com/2025/02/libinput-and-3-finger-dra...

remotely related: When I used nearley.js [0], it had a very good learning curve. Tooling also looks quite nice.

[0] https://nearley.js.org/

This [0] seems to be the closest to your parent's statement:

> The common ground is that I have absolutely no interest in helping to spread a multi-language code base. I absolutely support using Rust in new codebase, but I do not at all in Linux.

[0] https://lwn.net/ml/all/20250204052916.GA28741@lst.de/

similar project: https://www.trainconnections.com/

for Node.js, consider retry: https://www.npmjs.com/package/retry

It looks like you have to manually add a 10G uplink to dedicated boxes: https://docs.hetzner.com/robot/dedicated-server/network/10g-...

I built a JavaScript library for my needs: https://github.com/derhuerst/parse-human-relative-time

I think it would be great to be able to embed the workflow in the URL, so that I can share pre-made workflows with people who can then apply it to their data.

A while ago I made this: https://derhuerst.github.io/berlin-subway-guide/

It is based on someone's enormous body of CC-licensed photos of cities in Europe, especially their public transportation systems. [1] – I re-use the photos by assigning them to the station IDs in Berlin's official transit dataset. [2]

[1] https://flickr.com/photos/ingolfbln/albums/ [2] https://github.com/derhuerst/vbb-station-photos

I do the same, but because it became tedious to insert the query & query plan manually, I wrote pev2-cli [1].

[1] https://github.com/derhuerst/pev2-cli

PRQL [1] is a compile-to-SQL relational querying language that puts FROM first.

[1] https://prql-lang.org

AFAIK mininet [0] can help you with this. It allows configuring latency and/or jitter dynamically using Python [1].

[0] https://mininet.org [1] https://mininet.org/api/classmininet_1_1link_1_1TCIntf.html#...

apparently the author is responding to questions in a sibling post: https://news.ycombinator.com/item?id=38666139

This has been discussed recently [1] in another post.

[1] https://news.ycombinator.com/item?id=36815705 (4 days ago, 202 points, 32 comments)

some past HN discussions: - https://news.ycombinator.com/item?id=20783006 - https://news.ycombinator.com/item?id=27525031 - https://news.ycombinator.com/item?id=33419944

see also https://news.ycombinator.com/item?id=34982889

I have used cscreen [1][2] for a while to switch resolutions beyond what macOS offers via its GUI. You can install it via `brew install cscreen`.

It seems like displayplacer is the spiritual and de facto successor to screen. [3]

[1] https://www.pyehouse.com/cscreen/#comments [2] https://apple.stackexchange.com/a/73696 [3] https://apple.stackexchange.com/a/173875

The extension could also use Wikidata [1] entries – which (AFAIK almost always) hold the data that is displayed in Wikipedia article's infobox – because then it wouldn't have to resort to parsing HTML.

Specifically, Wikidata has a "official website" property [2] that seems to be used. If there are multiple extensions, like in Sci-Hub's case [3], it could pick one based on user preferences.

[1] https://www.wikidata.org/ [2] https://www.wikidata.org/wiki/Property:P856 [3] https://www.wikidata.org/wiki/Q21980377

related: chisel [1] does TCP over HTTP

[1] https://github.com/jpillora/chisel

According to this tweet [1] by someone at a German climate NGO it is about 15 Mt CO2e, looking at the greenhouse effect of the Methane in the next 20 years.

[1] https://twitter.com/SaschaBay/status/1574664872293715968

> When I changed 'my-awesome-program' to 'ubahnchen' or something else when creating the hafas-client, it stopped getting valid responses.

Please report this as an Issue in the hafas-client repo, so we can discuss this further.

> So I thought I should wait for VBB to give me an ID that works.

This is not how it works: - The official VBB API is an entirely different API, which they give you an auth token for when you ask. - hafas-client uses the "mobile" API, which has a static universal auth token. But it sends a (slightly randomised) User-Agent in order to communicate who/what is making requests. It might be that some User-Agents are blocked.

> v5.vbb.transport.rest's frames were missing something I needed, if I recall correctly. With a fork of hafas-client, I got something to work okay.

It would be great if you could create an Issue in hafas-client about this, so everyone can benefit from the changes.

> I realised I should use another user agent than 'my-awesome-program' which only VBB can provide, I think

If you're talking about hafas-client: No, you can use anything! It's merely about being transparent towards VBB who/what is using their API, but they don't have to approve it beforehand; They can't in fact, because the "mobile" HAFAS API just uses a static auth token.

There is a project called Peermaps that is building a full P2P stack for OSM-based maps:

They convert Planet OSM and Natural Earth OSM dumps into the storage format used by their geospatial DB [1] and then distribute them using P2P file storage tools like IPFS [3] or hyperdrive [4].

Because those storage tools make use of content addressing [5] and clever chunking [6], you can download only changes to the (converted) OSM dump.

Because those tools are inherently P2P-focused and come with pluggable transports, the data representing the changes in the (converted) OSM dump don't have to be sent via the internet. For example, Mapeo [7] allows syncing "local" changes to OSM via USB sticks [8].

[1] https://github.com/peermaps/eyros [2] https://github.com/peermaps/data [3] https://ipfs.io/#why [4] https://hypercore-protocol.org/guides/modules/hyperdrive/ [5] https://docs.ipfs.tech/concepts/how-ipfs-works/#content-addr... [6] https://blog.gopheracademy.com/advent-2018/split-data-with-c... [7] https://www.digital-democracy.org/mapeo/ [8] https://docs.mapeo.app/complete-reference-guide/mapeo-deskto...

Author of hafas-client here!

Do you know about v5.vbb.transport.rest's /radar API [1]? Because it wraps VBB's de-facto-open unofficial API [2][3], it doesn't require authentication or even signing a contract.

If you have problems using it, please get in touch with me!

[1] https://v5.vbb.transport.rest/api.html#get-radar [2] https://github.com/public-transport/hafas-client/tree/5.25.0... [3] https://github.com/public-transport/transport-apis/blob/8e05...

VBB has been publishing GTFS (Static/Schedule) data for almost 10 years now. [1][2]

But there is no (truly open) realtime data (e.g. GTFS Realtime or SIRI) available because their API [3] - requires signing a draconian contract (e.g. ridiculous liability clauses, no permission to pass the data on in any form), and - API works individual vehicles/trips, so you'd have to poll every single one out there to get the equivalent of a GTFS-RT dataset.

There is an unofficial API though [4][5] that is de-facto open, and I have built a tool that pools the data and creates a GTFS-RT feed. [6]

[1] https://daten.berlin.de/datensaetze/vbb-fahrplandaten-gtfs [2] https://www.golem.de/news/open-data-verkehrsverbund-berlin-b... [3] https://www.vbb.de/vbb-services/api-open-data/api/ [4] https://github.com/public-transport/hafas-client/tree/5.25.0... [5] https://github.com/public-transport/transport-apis/blob/8e05... [6] https://github.com/derhuerst/berlin-gtfs-rt-server

Note that this just interpolates the vehicles' positions based on their delay, which in turn is calculated based on periodic pings that the vehicle sends AFAIK. So the map does not show realtime positions in the same sense as e.g. HSL's trip planner does [1][2]. In fact, the location and speed of a vehicle can be very off.

Personally, I loathe this map, because it gives an impression of accurate data, even though it isn't that precise. VBB gets credit for providing supposedly reliable data, even though they could (and should, given amount of tax money spent) provide much better data!

[1] In the departures section on the left, tap on one of the upcoming departures to see the vehicle in realtime: https://reittiopas.hsl.fi/terminaalit/HSL%3A1000105?locale=e... [2] https://digitransit.fi/en/developers/apis/4-realtime-api/veh...