A significant part of my job, unfortunately, is helping people fix their workspaces when Perforce (p4) goes bad, or creating guardrails and wrappers to stop Perforce doing bad things.
In fairness, p4 predates most of the VCSes we consider "modern", so I empathize with a lot of the underlying architecture decisions. However, it has and continues to utterly fail at improving at a reasonable pace.
For example:
- p4 tracks file metadata of client workspaces on the server (sync'ed locally, opened for edit, file revision, etc) and uses this as the basis to avoid doing unneeded work. If this becomes desync'ed, a reconcile or force sync must be used. A reconcile can take hours, potentially days; it tries do detect file moves by default, so likely at least O(c^n) for some c>1. I have never personally seen a default reconcile operation _complete_ over any modestly large game code base, and in practice, people accumulate a litany of workarounds and scripts to fix this for themselves.
- Scripting p4 is a nightmare. Documentation is poor, schemas do not exist, and all the language-specific libraries are just thin wrappers over its C++ API.
- By default, p4 "helps" you with text files by "correcting" line endings on sync or even converting between encodings. This works until you have a mixed-OS environment, and discover a part of the pipechain that _must_ have a certain style. There are various levers to pull to make this better, but I've yet to find something fool proof.
- By default, p4 keeps flies read-only, only unlocking them when explicitly marked as being edited. This means, to avoid having to do this manually, every tool you use needs to be p4-aware. Or, you can turn this off, and choose to contend reconcile instead. (See above)
- Branching a modest game project, with, say, Unreal source code, can take hours. And this is the quick version where you ask the server to simply create new metadata, with no file transfer to a client.
- p4 is licensed by the user-account. Every user entity in p4 not intended exclusively for performing backups and maintenance operations counts toward this, including users required to integrate with other services. Plus, often times, these integration users must have admin access to be useful. The security posture is horrific.
This is why I wish more command line tools were split into a library that does most of the work and a cli module for purely user interaction. Parsing stdout seems so unnecessary and could be avoided if a program could simply import a library.
> p4 tracks file metadata of client workspaces on the server
Honestly, using P4 necessitates a plugin for $EDITOR of choice. The jetbrains IDEs do full on integration, but I managed a decade with an addon that just ran "p4 add/edit" on any save.
> Scripting p4 is a nightmare
Agreed, but so is git, or plastic. My experience has been using the CLI with -Ztag is the way.
> By default, p4 "helps" you with text files by "correcting" line endings on sync or even converting between encodings
This is a nightmare, and definitely one of P4's worst traits. Everywhere I've worked we have a presubmit trigger, to catch this.
> By default, p4 keeps flies read-only, only unlocking them when explicitly marked as being edited.
See point 1, but honestly you go very very far with just p4 edit a whole folder.
> Branching a modest game project, with, say, Unreal source code, can take hours. And this is the quick version where you ask the server to simply create new metadata, with no file transfer to a client.
A new stream including submission at my current job is about 20 minutes. Even at $BIG_CORP with 800 people working on a project, a branch didn't take hours. (Assumning by branch you mean streams. If it's a branch I have no idea, we don't use them)
> p4 is licensed by the user-account
P4's licensing is predatory. It's very much "talk to us", but you'll find out that "talk to us" pricing is exactly the same for absolutely everyone. If you're really lucky, and get someone who is feeling generous, they might give you 1-2 extra automation seats. Given P4's security model is so old, I don't hate shared credentials for this. A bit like IAM roles, nobody should really have access to the credentials even if they were scoped appropriately.
I've been using p4 daily for about 21 years at various game studios (with a small break of around 5 years in the middle, where I used it only sporadically) and I think I can count the number of times I've used "reconcile offline work" on one hand. I think the only time my workspace has gotten into some kind of corrupted state was because of a crash that left it half-synced. If that ever happens I usually just blow it away and force sync the entire repo again rather than use reconcile (because it's so slow).
Reconciling is my least favourite part. It always feels like everyone’s checkout is a unique blend of local files and permissions you have to fix up now and then. It can be hard to keep track of how much one’s deviated.
I can understand how git isn’t always appropriate for less technical workflows and large file sizes, but p4 pain is its own character.
That's not quite what I meant by unusably bad, though that does have its own set of challenges for sure. I was just in Toronto for the first time and appreciated the designers of the Ojibwe Latin alphabet for pulling it off without diacritics.
What's happening with your example is just that the symbols chosen for the phonemic transcription are non-Latin so they're unfamiliar to read aloud and harder to type for non-speakers. What I meant was if we all wrote with all of our individual idiosyncrasies of speech without converging on a prescribed standard (a writing system separate from speech transcription).
"Amnu ge sum'm frum upsterz, gimmi u sek" but even more so, with IPA characters for all the 40-odd individual sounds of my dialect of English - then you write your response in the same level of phonetic detail. Exactly what a writing system shouldn't do.
I'm not the person you're responding to, but I think what he meant when he said that a "strict phonetic transcription" would be bad is phonetic vs. phonemic. Most writing systems (apart from things like Chinese) represent (some of) the phonemes of the language, not the phones (not phonetic). For example, in English we have two kinds of p-sounds: one is found in words like 'pill', the other in words like 'spill'. We write them both the same, because which sound the letter should take is determined by the environment: after an /s/, it's pronounced without a puff of air, elsewhere (or mostly elsewhere) it's pronounced followed by a puff of air. It's actually hard for most native speakers of English to tell the difference, although speakers of languages like Thai, where the two sounds can appear in the same environment and can be used to distinguish different words, can hear the difference just fine.
Bottom line: writing systems that are easy for native speakers to use, usually represent the phonemes of the language, not each phone.
Back in my youth, after the Internet became common but before Wikipedia, I tried to discover the answer to this and came away disappointed again and again. Every article I could find simply stated "because light scattering", and barely much more.
How does scattering work? Why does light scatter? _What does scattering even mean in the context of light?_
The light "beam" we perceive is the result of infinite circular waves. The points were the light is not are points where they cancel each other out. We had that as part of the school curriculum, do you not have that, or did you forget?
Between CD/DVD drives, writers, Zip Drives, and extra hard drives, it wasn't unusual for a workstation to naturally end up with G: or H:, before mapped network storage became common.
> Ansible is a complete mess. You're better off managing things with Puppet or Salt, as that gives you an actual declarative mechanism
We thought this, too, when choosing Salt over Ansible, but that was a complete disaster.
Ansible is definitely designed to operate at a lower abstraction level, but modules that behave like desired state declarations actually work very well. And creating your own modules turned out to be at least an order of magnitude easier than in Salt.
We do use Ansible to manage containers via podman-systemd, but slightly hampered by Ubuntu not shipping with podman 5. It's... fine?
Our mixed Windows, Linux VM and Linux bare metal deployment scenario is likely fairly niche, but Ansible is really the only tenable solution.
It was "fun" discovering this the hard way a number of years ago when active US Android user count for a game we were supporting dropped 15% essentially overnight. The TCP stack in the client only did IPv4.
The challenge, ironically, was convincing management that adding IPv6 was the thing worth trying. After almost a week of getting nowhere (and almost 2 weeks of outage), I forced the issue by saying "Look, I'm doing this. I need one engineer for 2 days. If it doesn't work, then it doesn't work."
He got the change implemented in 2 hours. QA OKed it the next day. The topic never came up again.
I once attempted to use XSLT to transform SOAP requests generated by our system so the providers' implementation would accept them. This included having to sufficiently grok XSD, WSDL el at to figure out what part of the chain is broken.
At the end of the (very long) process, I just hard-coded the reference request XML given by the particularly problematic endpoints, put some regex replacements behind it, and called it a day.
Or, at least, not giving a fair take on its particular approach to open source.
We both self-host and pay for the service. There is ample engagement from the development team with the larger community. There are also a myriad of open source projects without the same licence restrictions that Sentry-the-company publishes or maintains which make up key functionalities in Sentry-the-product.
There was a period in World Rally Championship history when the top drivers would manipulate the starting order for the following day's stages by intentionally slowing down before the end of the stage. It was bizarre to watch teams intentionally give up 10+ second margins when stage wins can come down to half-second gaps.
In the BTCC, there was a similar situation for a while: in one of the races, the best-perfoming half of the pack would start at the back of the grid, and the worst-performing half at the front of the grid - but in-order within the two groups. However, since 2006 there has been some randomness added to the grid positioning, which makes attempting to manipulate it a risky business.
In fairness, p4 predates most of the VCSes we consider "modern", so I empathize with a lot of the underlying architecture decisions. However, it has and continues to utterly fail at improving at a reasonable pace.
For example: