emersion

This works as long as you're the only copyright holder. If other developers contribute, weakening the license requires their approval.

Do you have plans to publish the source code under an open-source license?

Some time ago I've written an article about a particular aspect of shells, job control: https://emersion.fr/blog/2019/job-control/

Library maintainer here. Why not send a PR?

My go-to small event loop library is https://github.com/any1/aml

No, it just felt a tad cleaner to have the comment slashes separate from the path leading slash.

The following would probably be more portable:

    ///usr/bin/env go run "$0" "$@"; exit

Note, the exit code isn't passed through due to: https://github.com/golang/go/issues/13440

AFAIU not yet because the underlying GUI framework doesn't support this, but the developer mentioned they'd definitely be interested in adding it.

"you lost compile-time type checking" makes it sound like you haven't been using code generation? Varlink has an interface definition language which makes everything type-safe.

The main use-case is different: gRPC and Cap'n'Proto are designed for networked servers, while D-Bus and Varlink are designed for local IPC. Varlink is a lot simpler than other alternatives.

There are open-source projects trying to replace older closed-source software used to produce these timetables:

- Netzgrafik-Editor: https://github.com/OpenRailAssociation/netzgrafik-editor-fro...

- OSRD: https://osrd.fr/en/

(Disclaimer: I'm working on OSRD.)

Pretty much reverse engineered: https://mk.pars.ee/notes/a9ihgynpvdo6003w

Similar (but more mature) client : https://sr.ht/~delthas/senpai/

The Wayland library has upstream support for FreeBSD and OpenBSD. Some compositors also have upstream support for these.

Another option would be to try this hydroxide patch (that i need to find time to review...):

https://github.com/emersion/hydroxide/pull/282

With a shell such as fish, one can "git commit --fixup <tab>" and a list of commits will be displayed.

Part of the answer is that some of these services need to be scaled horizontally to be able to handle a significant number of users (e.g. tile servers, the core server), another part of the answer is architectural constraints (e.g. the core server needs to keep quite a bit of per-infrastructure data in RAM).

(Of course, it's completely possible to build a single container which runs all of the services in parallel, but then monitoring/scaling/availability/etc are more difficult to handle.)

The database needs to be shared between multiple actors: several teams of multiple people working in different companies. For instance, a team may be working on a single project such as a new railway or a large timetable change. Another example would be multiple freight companies requesting new routes.

Additionally, the UI contains complicated elements such as custom maps with the railway network and custom graphs to visualize trains. There is a large ecosystem to implement this kind of stuff via Web technologies. A webapp also removes the need to distribute an installable binary on many different platforms (some may be quite restricted due to company policies) and many different machines (there are many users, see above).

Note that the system uses a client-server architecture but isn't really distributed.

Shouldn't be too hard, the tool is designed to be intuitive. That said, it may not be obvious how to use the planning part of the tool if you're not familiar with trains.

The README contains instructions to start OSRD with docker-compose, if you want to try it out. Would be nice to have a public demo instance for sure!

The userspace components (GL/Vulkan driver, NVENC, etc) and the firmware remain closed source.

The Steam Deck dock supports this, for instance.

A possible workaround for users is to use an active HDMI adapter, e.g. a USB-C dock or DisplayPort → HDMI converter.

FWIW Flutter is now moving sway from Skia, they are migrating to a dedicated custom GPU renderer (Impeller).

Yes. I'd argue the problem is not on the project's side, it's on the Google side (they have ridiculously high requirements for registering OAuth clients for IMAP/SMTP use, especially for a small open-source project).

Unfortunately this requires users to setup their own OAuth client, which is a pretty manual/cumbersome process.

Note that Google has a very complicated process to migrate an IMAP/SMTP app to OAuth. There is a long list of requirements to register an OAuth client for these protocols: https://developers.google.com/terms/api-services-user-data-p...

AMS ≠ AWS :P