These approaches should be completely flipped, the default should be your upgrade engineers get remote access to the customer's database (vpn, etc) and run the standardized and ad-hoc upgrade scripts on their system. Shipping the customer's data back and forth for every upgrade is absurd and a privacy nightmare.
ERPNext has a very peculiar home-grown deployment system that is required to host it yourself. I didn't much like it when I looked into it a while back.
I've been looking into switching our manufacturing business over to Odoo, replacing Dynamics GP + another mfg software. My impression is that it's very customizable, but may require some specialized expertise to implement correctly for one's environment. Enterprise would probably net save us money on just support contracts compared to our current setup.
"Open-Source" is a bit of a misnomer. The majority of the important modules are enterprise only. That said even enterprise is source-available for paying customers which is a breath of fresh air compared to the competition.
Having enterprise as open source gives additional freedom and cost savings in terms of technology roadmap. When you need something now, you can build in-house quickly or via external help. No fees to be just able to contribute to the roadmap and wait for 1-2 update cycles (typically 6-12 months) for other ERP systems.
I agree we all ought to use available punctuation marks correctly. That said, I am compelled to lodge a formal complaint against quoted text arbitrarily assimilating punctuation from its surrounding context.
Quoted text is a sacred verbatim reproduction of its original source. Good authors are very careful to insert [brackets] around words inserted to clarify or add context, and they never miss an oppurtunity (sic) to preserve the source's spelling or grammatical mistakes. And yet quoted text can just suck in a period, comma, or question mark from its quoted context, simply handing the quoting author the key to completely overturn the meaning of a sentence?! Nonsense! Whatever is between the quotes had better be an exact reproduction, save aforementioned exceptions and their explicit annotations. And dash that pathetic “bUt mUH aEstHeTIcS!” argument on the rocks!
“But it's ugly!”, says you.
“Your shallow subjective opinion of the visual appearance of so-called ugly punctuation sequences is irrelevant in the face of the immense opportunity for misbehavior this piffling preference provides perfidious publications.”, says I.
I completely agree, this is perhaps the least sensible part of common English syntax.
"Hello," he said.
"Hello", he said.
Only one of these makes actual sense as a hierarchical grammar, and it's not the commonly accepted one! If enough of us do it correctly perhaps we can change it.
I’ve always wondered about this. I guess typographically they should just occupy the same horizontal space, or at least be kerned closer in such a way as to prevent the ugly holes without cramming.
It’s true, though, that the hierarchically wrong option looks better, IMHO. The whitespace before the comma is intolerable.
This is an interesting case where I am of two autistic hearts, the logical one slowly losing vehemence as I get older and become more accepting of traditions.
The basic thesis is that the relational model and SQL has been the prevailing choice for database management systems for decades and that won't change soon.
For WireGuard in general, you provide it an AllowedIPs config which is a list of CIDR ranges that should be routed across the link. That could be `0.0.0.0/0` (aka everything), a single subnet, a union of several, or even individual IPs. This config is technically symmetric between the endpoints, though a prototypical implementation of "individual clients enable the VPN to access the internal network" may limit the "client" AllowedIPs to an individual address.
Maybe don't drop the warranty disclaimer just yet.
> The MMWA requires conspicuous disclosure of warranty terms (e.g., designations like "Full" or "Limited" as prominent titles).
> The common practice of ALL-CAPS WARRANTY DISCLAIMERS (e.g., "AS IS, NO WARRANTY") stems primarily from state adoptions of UCC § 2-316, which requires disclaimers of implied warranties to be "conspicuous" (and suggests all-caps as one way, especially in plain text).
Unicode wants to be able to preserve round-trip re-encoding from this other standard which has separate letter-K and degree-K characters. Making these small sacrifices for compatibility is how Unicode became the defacto world standard.
Automatic version detection, revalidation, prewarming... caching seems so complicated these days. Forgive me for starting a sentence with "why don't we just"... but why don't we just use the hash of the object as the cache key and be done with it? You get integrity validation as a bonus to boot.
Sure, but where's the fun in that? Then you wouldn't be able to write "we architected a caching layer"! To their credit, at least this isn't the actual title of the article, but it still left me wondering if an actual architect (you know, the kind of architect that designs buildings) would say "I architected this"?
You don't need to invalidate anything if the cache is keyed on the hash of the served objects. To put it another way, a hash-keyed cache results in perfectly precise, instant, distributed cache invalidation. Read the code in my comment again.
