It is bad terminology, yes. But also - a pretense that you know the overarching influence of a commit ahead of time, which you don't - but once you have conventional commits everyone on the team and the LLMs have to spend time/tokens inventing that stupid nomenclature.
Which is not hard to do (it is a modulo over a mersenne twister or something similar), but in my recent gigs just Flipper with optional "state of the flags table as of now" endpoint was more than enough. That modulo+random combo required tools like LaunchDarkly to ship SDKs in several languages, and the ones I had to work with were just plain horrible fit for their language of choice. But because the evaluation was relegated to the edge, the whole system got way more complex than desirable. In actuality, I think a refetch of the current flags table "for this customer" every so often is just fine, and way less of a nuisance.
So glad Flipper exists and I don't have to deal with this stuff anymore.
This is the next evolution of the "My film does not use CGI" sneering. Sure, doing proper pre-rendered VFX with photo-realism is great and also people doing it love it. But can it be done on the budgets/fixed bids/turnarounds when the producer comes with "...and all of that will be a full virtual set and it should be streaming next Monday morning", for peanuts?..
If it's Gore saying it - maybe he should talk to his producers then, and ask them whether they actually have budgeted the "proper" VFX talent/timelines for the show. He has creative control - the people doing the work do not.
Mine is 2560x1440 which is a pretty nice "sweet spot" size. A comparable 5k to 6k display still commands a substantial price, and - given that I work at two locations - would need me to have two of them. The screen I use as my current (a 3x2 BenQ) also has some amount of subsampling going on, because running it at 2x ("Retina native HiDPI") all the UI controls are too damn big, and space is not enough. Running it at 1x (everything teeeny-tiny) is just not very good for my eyesight and not very workable - and, again, with Zed bumps into the same broken antialiasing rasterizer they have.
And it is not an OS thing. The OS renders subpixel antialiased fonts just fine. But Zed uses its own font rasterizer, and it completely falters when faced with a "standard passable resolution" screen - the letters become mushy, as if they have been blurred - and rather sloppily at that.
Interesting article, but it mixes up two concerns, I would say. One is retrieving trees from the DB and storing them - which can be annoying but has nothing to do with permissions. Another one is "hiding" unpermitted nodes/branches from the viewer (if that is what applying permissions is about - it can also handle read-only things, for instance). If these two concepts get separated and it is not a big deal to "overfetch" for the current user before doing the filtering - things become way easier. When the tree is reconstructed, you can do breadth-first traversal and compute permissions for every item in there - or retrieve the permissions for items at that level, if you are doing ACL stuff. From there - if there is no permission for the current viewer on that node - you exclude it from further scans and you do not add its' children to further traversals as you go down. Max. number of scans = tree depth. With some PG prowess you could even fold this into sophisticated SQL stuff.
It depends on whether the ELAC is an LRU (line-replaceable unit, i.e. a box with ports that can be swapped at an airport) and whether a software update can be uploaded into a unit that is installed (not all aircraft have a "firmware update via cable or floppy", so to speak)
This ELAC version is 100-something, and the A320 first flew around 1988. Why the updates - for example, there are updates to flight control law transitions, like after 1991 where the aircraft would limit flight control inputs during landing, thinking it would be preventing a stall - because it would not go into the flare law appropriately. See https://en.wikipedia.org/wiki/Iberia_Flight_1456
The cause could have also been an extra check introduced in one of the routines - which backfired in this particular failure scenario.
True. I would say, however, that every "concept" of airliner flight deck has its own gimmicks that can kill. The Airbus "dual input" is such a gimmick. Even though there was, for example, an AF accident with a 777 where there was hardware linkage between yokes and the two pilots were fighting... each other. Physically.
The animations were there, but they were frame-based with the number of frames carefully calculated to show UI state changes that were relevant. For example, when you would open a folder, there would be an animation showing a window rect animating from the folder icon into the window shape, but it would be very subtle - I remember it being 1 or 2 intermediate frames at most. It was enough to show how you get from "there" to "here" but not dizziingly egregious the way it became in Aqua.
Truth be told, I do have a suspicion that some folks (possibly - some folks close to Avie or other former NeXT seniors post-acquisition) have noticed that with dynamic loading, hard drive speed, and ubiquitous dynamic dispatch of ObjC OSX would just be extremely, extremely slow. So they probably conjured a scheme to show fancy animations to people and wooing everyone with visual effects to conceal that a bit. Looney town theory, I know, but I do wonder. Rhapsody was also perceptually very slow, and probably not for animations.
There were also quite a few tricks used all the way from the dithering/blitting optimizations on the early Macs. For example, if you can blit a dotted rect for a window being dragged instead of buffering the entire window, everything underneath, the shadow mask - and then doing the shadow compositing and the window compositing on every redraw - you can save a ton of cycles.
You could very well have do-wait-do-wait loops when custom text compositing or layout was involved and not thoroughly optimized - like in early versions of InDesign, for instance - but it was the exception rather than the rule.
I'd rather say the zenith was 8.1 which was not very widely used. 8.5 did add some nice gimmicks like the app switcher palette but for some reason it felt way slower than 8.1.
That is an interesting difference. Also, from what I know, the German signaling is configured in such a way that there always be sufficient braking distance between signals - including speed reductions, whereas if you look at how tightly the UK speed signs are placed it seems that they do not give any "warning", they state the fact - and you better be prepared.
Most European railways require a driver to have done some route familiarization for most routes, which tends to work fairly well. What does not work very well is that the UK has very patchy and antiquated train safety systems (AWS / TPWS are somewhat rudimentary and deployed - by far - not everywhere) and signaling. Even speed restrictions in the UK are placed very, very tightly and you better know them by heart because they didn't get placed with the idea that the driver must have sufficient time to reduce speed / react between where they get a warning signal and where the restriction comes into effect.
I suspect the move from public to private ownership did adversely affect the upgrades of those, as well as electrification on several key routes.
If I remember correctly they do not even have something as basic as an electronic coursebook - which became mandatory in Germany in the 90s already. And at least in NL if you have a set of routes in a certain direction / route set - drivers would get route familiarization both for the main routes and for the bypasses.