This is done by a lot of customer support and helpdesk systems that one would almost consider “legacy” that are certainly not related to AI in any way.
So I would assume that the uptick is caused by you moving somewhat up in you career so you deal with such BS systems more often.
On the other hand, the approach with explicit markers in the email is reliable. Alternative is some bunch of ad-hoc rules that will extract the actual reply from the reply, which has a lot of edge cases (which for some systems even extend to edge cases that involve the MIME envelope, not the message text itself).
From the PQ protocol PoV the way how this works is pretty much irrelevant, but the actual implementation of PostgreSQL contains ridiculous amount of places that depend on the “backward” MVCC implementation of the tuple heaps.
pg_repack is an hack-ish solution to do what VACUUM FULL does without completely locking the relation in question. But well, when you care about either of these things, your workload has significant issues, with the typical case being using pgsql as a backend for something that was originally a thick client designed for some kind of RDBMS based on shared files (InterBase mentioned in TFA, MS Jet whatever…)
> Oracle and MySQL do not have this problem in their MVCC implementation because their secondary indexes do not store the physical addresses of new versions. Instead, they store a logical identifier (e.g., tuple id, primary key) that the DBMS then uses to look up the current version’s physical address. Now this may make secondary index reads slower since the DBMS has to resolve a logical identifier, but these DBMS have other advantages in their MVCC implementation to reduce overhead.
Interesting behavior of MySQL that I have observed (~500GB database, with a schema that is more of an document oriented than relational) is that when you update single row doing SELECT id WHERE something; UPDATE what WHERE id=id is orders of magnitudes faster than UPDATE what WHERE something. I somehow suspect that this is the reason for this behavior. But well, the normal workload will not do that and this only slows down ad-hoc DML when you fix some inconsistency.
Law enforcement/EMS often have their own phonetic alphabets and it is not that uncommon to use two at once: one for call signs and second for the actual alphanumeric data (in theory, in practice it gets mixed up, but everybody still understands the meaning)
Also there is a way to pronounce all of the NATO alphabet words that is not exactly a normal english pronounciation in order to make the first letter obvious and to reduce the possibility of mistranscription (the most obvious example is “nineR”). Sadly this does not really work in Czech, as laypeople will very often interpret “keˈbɛk” as K. (So the takeaway there is to not use NATO phonetic alphabet when you are dictating the pickup code to the package pickup point clerk)
And it includes an explanation of what is wrong with ESR's version. But well, lets reiterate that: ESR is this weird kind of quasi-libertarian ego-maniac who occasionally produces something marginally useful and then oversells how that thing is part of the critical internet infrastructure or something like that.
The same design decision is in most languages that implement Common Lisp/Scheme-style numeric tower (eg. have rationals as core type). You do basic arithmetic on rationals or integers, you get rational or integer. You do transcendental function on pretty much anything, you get float. Also usually you also get stuff like complex rationals, which makes the rules somewhat convoluted, but that is no that relevant for this discussion.
There is this one somewhat widely deployed niche system that uses sqlite databases as RPC serialization format. The original idea behind that was limited virtual address space of the CE-based embedded devices, but the design got stuck.
ASN.1 BER/DER is more or less the same thing as CBOR. The perceived complexity of ASN.1 comes from the schema language and specifications written in the convoluted telco/ITU-T style (and well, the 80's type system that has ~8 times two different types for “human readable string”).
There is a lot of good things to be said about Alpha and it is probably the most RISC of all 90's RISC ISAs, but the actual hardware is full of weirdness and all the real CPUs were deeply pipelined OoO designs (think Intel NetBurst) that prioritized high clock rates and huge straight-line throughput above all else (which is also why that ran really hot and could not be really scaled down for embedded use). Taking good ideas from that while discarding the “speed-demon” design is a part of why AMD become relevant again in 00's with amd64 cementing that position (but well, AMD K7 is very much Alpha-related design, to the extent that the chipsets are interchangeable between K7 and EV6. The interesting part of that is that these CPUs do not have FSB in the “bus” sense, but there is a point-to-point link between CPU and chipset).
BWX does not help with unaligned accesses, but solves the fact that original Alpha did not even have instructions for memory accesses smaller than word. Which kind of becomes an issue when you start building the systems on PC-like hardware (another related “feature” is that EV5 does not have equivalent to MTRRs, but dealing with the weirdness of VGA framebuffer accesses is part of the architecture specification by means of hardcoded uncached memory region).
The displays aren't that much special. Probably the main two things that are special about them are color rendition and contrast and the rest is just about the certification process. And extrapolating from automotive experience, the color rendition and contrast is about some team of engineers being solely dedicated to simulating various lightning conditions and verifying that the screen remains legible, does not interfere with night vision and does not cause reflections on other instruments that would make them hard to read. In automotive this kind of simulations use multiple terabytes of reflectivity data for various mostly “dull” materials (gigabytes upon gigabytes of data on what the driver might wear…), so extrapolate from that to “most advanced fighter aircraft”.
This instrument is only an display that shows data coming from another device that does the actual measurements. One of the reasons why the threewire synchro interface is used is that it is surprisingly accurate as long as you don't care about the fact that it is “slow” by modern standards. The same interface was used to direct artillery and similar things that require significant accuracy to be effective.
There is not that much complexity (circuit-wise) in the DRAM array itself apart from the fact that the sense amplifier is essentially an SRAM cell and not really an “amplifier”. Another layer of ridiculous complexity is how to interface that to the outside world without spending the precious die area of DRAM optimized process for complex interface logic or PHYs, so you get the only high-speed single ended parallel bus with weird voltage levels interface that is used in modern computers.
One thing to note about authentication in DH-like systems is that you can derive symmetric key without authenticating the parties, establish secure (but unauthenticated) channel with the resulting symmetric key(s) and the do authentication inside that channel in a way that will only succeed if the symmetric key used by both parties is the same (this is called channel binding). For example SSH2 and many Active Directory related protocols do this.
IIRC for WAP the only way to use form elements was JavaScript as there was no equivalent of HTML <form> that would just submit the request automatically.
One thing that I do not understand is how an app can determine whether secure boot is enabled in any kind of secure way. The TPM and Secure boot system is not designed for that.
That might be case for small non-modular PLCs that replace what would otherwise be half a cabinet worth of relay rat's nest. That is a valid use for PLCs and the ladder diagram is also somewhat natural for that.
But in many cases you have large-ish systems that have various lookup tables in PLC memory, do non-cyclical communication (ie. communicate with something external over some “normal” protocol, not over fieldbus) or even just contain many instances of the same logic (there are PLC families that cannot do indirect accesses to the process image memory, so if you want the PLC to do 12 instances of the same trivial logic, there is no way to do that in a loop and you have to copy-paste that 12 times…). In my opinion for many of these situations just programming the thing in “real” programming language (even while preserving the cyclic process image model) would be very beneficial.
The only reason why you want to use PLC is that the fact that the hardware is generally robust and has industrial IO interfaces offsets the totally horrible developer experience of IEC 61131-3.
As for the Intel ME and AMD PSP: these things have a huge role in getting the CPU to state that looks like x86 PC so that the host firmware can actually run. The complexity of the initialization got so high, that doing that in SW on a separate embedded core that is “well-behaved” and can be programmed in C makes more sense than trying to write all that logic in weirdly limited assembly that is inherent in traditional early stage BIOS startup code.
I believe that at least on some HPE ProLiants some part of this low-level initialization is in fact done by iLo, which at that boot stage also directly controls the framebuffer (on G10 you can even briefly see a flash of message like “handing over the console to host”, after which the display reinitializes and starts showing the function key legends). I assume that Dell does something similar, but in the early stages you simply get “Please wait” and giant throbber (and not any kind of progress indication).
I would consider that mostly a feature. The situation where that is useful (you somehow lost the credentials for BMC, but have root access to the host) is in my experience significantly more common (I see that multiple times in a year) than attacker implanting stuff into the BMC firmware (never seen that).
Obviously if you rent out whole physical machines and automate the provisioning by IPMI, then the last thing you want is the customer having admin access to the BMC.
Dell iDRAC has an interesting feature that allows you to make all of the BMC configuration read-only which can only be disabled by factory resetting the iDRAC by means of physical (and IIRC not exactly documented) switch on the BMC board. (Well, it is still _i_DRAC as in “integrated”, but on current higher-end PowerEdges the iDRAC is separate OCP-like card, but well, the system does not work without it)
The idea behind defragmentation is to make the files themselves consecutive, which is not done in any way in this game, which makes it somehow confusing. The fact that DOS/Windows defrag also moves the used space to the beginning of the block device is mostly an implementation detail (and the experience with unix filesystems seems to indicate that it is actually better strategy to intentionally fragment the files by allocating the space almost randomly as long as the fragments are "large").
The main issue there is that the mantra something you know, something you own, something you are is completely wrong in the authentication context. The issue there is that the biometric “something you are” cannot be revoked and also depends on the relying system having some kind of secure path to whatever sensor measured it. So in the end as an authentication it is only useful as convenience feature (eg. how TouchID/FaceID works on Apple platforms). Identification is another thing and obviously biometrics are useful there, but well, there are not that many ethical uses for system that does identification without authentication.