Note that carto.tchoo does not provide real position in real-time: it only has access to departures, stops, delays and suppressions and interpolate position based on this.
This means that if your train is running at half-speed or stopped but does not result in an official delay, the position will not match reality.
The statement that current AI are "juniors" that need to be checked and managed still holds true. It is a tool based on probabilities.
If you are fine with giving every keys and write accesses to your junior because you think they will probability do the correct thing and make no mistake, then it's on you.
Like with juniors, you can vent on online forums, but ultimately you removed all the fool's guard you got and what they did has been done.
So, it's been one year since I use Zed daily, and I didn't encounter this issue, or any other issue for instance, everything is smooth and I never encountered a failure or a crash.
I work on large (everything is relative, though) monorepos, that would probably qualify for this limit, and I remember already did the kind of "workaround" discussed in this issue years ago on this device. I think it's hard to blame the software when the default file limit is so low depending on the languages you work with.
Anyway, if you would encounter this problem, you would have already encountered it with other tools, or else this is fine.
The logical conclusion from statistics is hybrid work. I am full remote because of the distance, bust most of my company is hybrid, and my experience is exactly as described by the results of the Microsoft studies.
I go on site 3-5 days per month, and I always connect more (more than 0) with people outside my team and happens, even on work related topics which enable new interesting findings and what not.
It helps that the company where I work has a culture that make people want to go to the offices even if they are not required to do so. There are pics days when the office is full because people want to see each others, then they are free to remote work any time it is wanted/needed.
I think that works out if you are alone, if you are with other people, the waiter will probably interrupt the socialization you are doing with the people you are with, causing stress even for the waiter.
Also we should recognize that the waiter is often looked down at, it is not a very nice job, and as a human being, having a poor experience with some customers will probably pass on to other customers, etc...
I'd go as far as having a job with "wait" in the name, and having to wait, calmy and happily or else you don't get your tip, is not so far from slavery.
> Most Git GUIs map fairly closely to the underlying git model.
Maybe, but most Git GUIs don't provide clear error messages. This is the case of VSCode, which my teamates keep using. When you use Git CLI you can just have the original error message and know what's wrong.
I was also burned by sourcetree some years ago where it lost part of my code while doing a merge I didn't even understand.
I am not a Git expert. But I can remember the 5 commands needed to do my job every day: `commit`, `push`, `pull`, `rebase`, `checkout`. (you can also add `add` and `status` to the list if you want)
They're straighforward, except for `checkout` which is adressed by `switch` for the main usage.
If you use it wrong, Git CLI will tell you in most of the cases, and even tell you how to do what you intented to do. Git GUIs will probably tell you something wrong happened and left you at that or try to be more intelligent than you are and do something wrong.
> Isn't that just being incredibly lazy.
-> this is what I'd answer to do those Git GUIs.
> Isn't that just being incredibly lazy.
-> this is what I'd say to people who won't write these 5 commands on a sticky note or something and keep it for a month before realizing it wasn't hard to remember once you _commit_ to it and that Git is not hard, minus exceptional problems but Git GUIs absolutely won't help you with these exceptional problems.
In short: X.org is a decade old display server that became the standard to display graphical window on the majority of Linux distribution. GNOME, KDE, XFCE and others are/were client to this display server.
Wayland is a new protocol where the window manager (ie GNOME, KDE,...) is responsible of directly managing the display. Each window manager must reimplement this protocol (or use a library already doing this work) which enable them to have more control over the windows.
Applications must also directly support Wayland like they did for X.org before (which was the default commonly used, so no problem) or the user just have XWayland installed on their computer to show X.org windows inside a Wayland WM but then the application may not display correctly (blur, artifcats,...)
Android Beam is built-in since 8 years, but like many Android features, there's little to no discoverability when using the OS past the initial marketing on release.
I don't even understand why someone who has a hosting would want to write on medium when they can host their own blog, especially when in the case of liberapay and mastodon they say they are fighting for freedom but choose to wirte their posts in a closed, centralized service which also has user-hostile behavior.