Similar (but more mature) client : https://sr.ht/~delthas/senpai/
Readit Newsemersion commented on ZUSE: IRC terminal client github.com/babycommando/z... · Posted by u/babycommando
My # 1 issue with wayland is it is Linux Specific, not protable.
I am hoping the *BSDs get together and keep Xorg maintained instead of having to port Linux crazyness into their systems.
The Wayland library has upstream support for FreeBSD and OpenBSD. Some compositors also have upstream support for these.
emersion commented on I failed moving my Google calendar to Proton shilin.ca/i-tried-moving-... · Posted by u/true_pk
Another option would be to try this hydroxide patch (that i need to find time to review...):
emersion commented on Git-absorb: Git commit –fixup, but automatic github.com/tummychow/git-... · Posted by u/striking
FWIW, I've been using this alias for the past couple years for fixup commits, and I've been happy with it:
> gfx='git commit --fixup $(git log $(git merge-base main HEAD)..HEAD --oneline| fzf| cut -d" " -f1)'
It shows you the commits on the current branch and lets you select one via fzf. It then creates the fixup commit based on the commit you selected.
With a shell such as fish, one can "git commit --fixup <tab>" and a list of commits will be displayed.
Deleted Comment
> Note that the system uses a client-server architecture but isn't really distributed.
Yeah, I kind of agree. The thing is, it's orchestrating multiple containers to do the job. I can't figure out why you couldn't just have one container.
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.)
I know I don't understand the domain at all, but I'm surprised that in this day and age you'd want a distributed system to do railway design. What aspect of the problem makes it unsuitable for running in a single process?
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.
Very cool!
How hard is it to use though for someone without a real technical skill set ?
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 ProRes bitstream spec was given to SMPTE [1], but I never managed to find any information on ProRes RAW, so it's exciting to see software and compute implementations here. Has this been reverse-engineered by the FFMPEG wizards? At first glance of the code, it does look fairly similar to the regular ProRes.
[1] https://pub.smpte.org/doc/rdd36/20220909-pub/rdd36-2022.pdf