> As I wrote, it does not work at all for concurrent access - I mentioned Google Docs & Co for this.
Indeed Google Docs is much better - we also used that - but it's still a WYSIWYG editor, which IMHO it translates to 'extremely hard to enforce style'.
> I never used Overleaf though (I guess that this is the product you refer to). I guess that having a concurrent system (such as etertab or something - or Overleaf if it supports truly concurrent editing) is the graal.
Yep, Overleaf was what we used. Its paid version was very much like Google Docs but on a plaintext editor wrt. to concurrent access. It could even do change tracking, comments, all the jazz, even Git synching (which we used for backups and CI)
> The drawback is that you need to know the language to cooperate. In a university setting this is not complicated, in a company - not so much.
I'm curious as to why. If the company is new and built on LaTeX from the very beginning why not? When I joined, I didn't know the language at all, but that wasn't a problem-one would learn on the job.
> Why? It has comments, tracking etc. Concurrent edition i impossible, though (even when MS says it is possible). For that Google Docs is great (or some self-hosted systems)
It doesn't scale. At all.
I used to work at a university lab group where all 30 of us would need to concurrently write, edit and review 150+-page, heavily technical reports with lots of diagrams and tables spanning pages. To be clear, most of the time all of us were working on the exact same huge document.
Word's version tracking stood no chance. Formatting was regularly off, tables were breaking apart, diagrams misplaced. Syncing was extremely bad, often with entire paragraphs in changes going missing, other times deleted portion were reappearing, all that jazz.
LaTeX on an online collaborative environment (well-known, not naming it -this post isnt an ad) on the other hand, despite its archaic way of working, never showed any of those problems. If a table was placed somewhere, we could be sure it would never get moved to random places, and changes/rewrites would be always synced correctly (as LaTeX source is plain text, merging algorithms/CRDTs have a much easier time).
> Also, the Steam client has to be one of the most stagnant applications I ever had the pleasure of using, not sure that makes Valve super efficient.
If said software is fit for purpose already, why the need to induce frivolous change for the sake of changes themselves? If permanent stagnancy is bad, perpetual change is equally bad IMHO.
I think parent refers to Codespaces and vscode.dev, not VSCode proper. These can indeed become gradually more locked down since they are completely online and out of the user's control, and as the UX difference between offline and cloud shrinks, people (especially new generations of developers) will slowly migrate there because of the convenience of not maintaining a toolchain themselves.
IC design for behemoths like Intel/AMD/Nvidia. AFAIK none of those is gonna let you anywhere near their multibillion-dollar design without being at the top of the field or having lots of experience (>5yrs) already
The same way Microsoft was forced to change to Chromium for Edge - Google forcing Chromium-specific features through the standardization process at a rate exhausting for Microsoft (or any other browser engine implementor) to follow in time without popular sites breaking.
Lead wrapping thick enough to sufficiently protect against radiation damage is very, very heavy. Beyond LEO, excessive weight is still ridiculously expensive.