Actually I think that corporate sovereignty is inevitable, hence countries should have never allowed companies to get that large. But for this discussion, yes Microsoft just needs to split and/or go to the Cayman Islands.
I don't think corporate sovereignty is needed for that; just blowing up Microsoft into a bunch of independently-operating entities, one per relevant jurisdiction.
As someone that started with 300/300 and went via 1200/75 to 9600 etc - I don't believe conflating signalling changes with bps is an indication of physical or temporal proximity.
Oh, I got the implication, but I think it was such a common mistake back then, that I don't think it's age-related now - it's a bit of a trope, to assume baud and bps mean the same thing, and people tend to prefer to use a more technical term even when it's not fully understood. Hence we are where we are with terms like decimate, myriad, nubile, detox etc, forcefully redefined by common (mis)usage. I need a cup of tea, clearly.
Anyway, I didn't think my throw-away comment would engender such a large response. I guess we're not the only olds around here!
No, just that confusing the two was ubiquitous at the time 14.4k, 28k, and 56k modems were the standard.
Like it was more common than confusing Kbps and KBps.
I mean, the 3.5" floppy disk could store 1.44 MB... and by that people meant the capacity was 1,474,560 bytes = 1.44 * 1024 * 1000. Accuracy and consistency in terminology has never been particularly important to marketing and advertising, except marketing and advertising is exactly where most laypersons first learn technical terms.
I started out with a 2400 baud US Robotics modem with my "ISP" being my local university to surf gopher and BBS. When both baud rates and bits per second were being marketed side by side I kinda lost the thread tbh. Using different bases for storage vs transmission rates didn't help.
I'm not sure why you'd expect partial updates of a single statement in the first place. I mean, if I run `UPDATE Account SET Status = 'Closed' WHERE LastAccess < NOW() - INTERVAL '90 days';`, I'm not going to be happy if there's 50 records that match, the DB updates 30 successfully, and then error on 20. Atomic isn't just about rows. Do all the work or none of it.
If you're experiencing things that smell like TOCTOU, first you need to be sure you don't have oddball many-to-one issues going on (i.e., a cardinality violation error), and then you're going to have to increase your transaction isolation level to eliminate non-repeatable reads and phantom reads.
Like, the alternative to a MERGE is writing a few UPDATE statements followed by an INSERT and wrapping the entire batch in a transaction. And you should likely still wrap the whole thing in a transaction. If it breaks, you just replay the whole thing. Re-run the whole job.
I don't want partial updates, I want full, conflict-free upserts.
At read committed (default) isolation level, INSERT ... ON CONFLICT handles concurrent, conflicting inserts just fine, while MERGE ... WHEN NOT MATCHED (e.g.) does not. This is surprising behavior from the syntax alone, one would assume the two statements, when written with the same intent, would have the same behavior. Of course, this difference is documented, see the last paragraph of the Notes section on MERGE: https://www.postgresql.org/docs/18/sql-merge.html#id-1.9.3.1...
I don't know this for sure, but I believe that the effect of raising the transaction isolation level will just be to turn the constraint violation into a serialization error. That's not any easier to handle gracefully.
I'm sorry, this is just an elaborate argument of obscurity-as-security. You're clinging to privacy as though it were security, in stark avoidance of Kerckhoffs's principle.
You can use Shannon's maxim instead if you're going to be deliberately obtuse. The point is true for any system intended to be secure, and a network is such a system, as is the security software such as the claimed NAT software.
Or do you really want to argue that Linux Netfilter/nftables or BSD pf being open source is a security problem?
No, the reality is that every modern network device running NAT for a user device network is also already a fully stateful firewall, because the software required to do one is virtually identical to the other.
You can't buy a home router with NAT and no firewall, and no home routers ship that don't also have a default deny rule on that firewall. The same is true for SOHO routers and effectively every consumer network gateway device you might buy.
You literally have to go well out of your way to find a network device capable of NAT that can't function as a stateful firewall, and when you find it, it's likely to be carrier-grade. In other words, not intended to be capable of any security at all. The amount of NAT processing it's intended to handle will challenge the hardware enough as it is.
A view only makes sense if your RDBMS supports indexed views or the query engine is otherwise smart enough to pierce the view definition. Not all of them can do those things.
The reason to soft delete is to preserve the deleted data for later use. If you need to not query that data for a significant amount of the system use that 75% soft deletes is a performance problem, then you either need to move the soft deleted data out of the way inside the table (partition) or to another table entirely.
The correct thing to do if your retention policy is causing a performance problem is to sit down and actually decide what the data is truly needed for, and if you can make some transformations/projections to combine only the actual data you really use to a different location so you can discard the rest. That's just data warehousing.
Data warehouse doesn't only mean "cube tables". It also just means "a different location for data we rarely need, stored in a way that is only convenient for the old data needs". It doesn't need to be a different RDBMS or even a different database.
reply