Is it evil of me to say that 7.2m a year (109000000/15) is not really doing that bad?
Honestly, I think a pretty good pyramid scheme a la the Mikkelson Twins would be to start up a wholly imaginary "MIL-SPEC SCAMMER SCHOOL" that tells you all about people like this lady, and offers a course on HOW TO NOT DO SUCH BAD THINGS, while winking with every muscle in your body.
Or, even better, advise you on how to be a big time MIL-SPEC guru who can lead SIGMA or whatever other nonsense the management of the day is huffing. This advise is your key to landing BIG WORK in the Defense Industry! Everyone knows it's all nonsense, but we can teach you how to turn that nonsense into passive income.
Of course such a fabulous class would cost beaucoup buxxx....
Ah, this sounds heartbreaking. I'll leave it to those salesmen with mental sickness.
I guess it makes a sort of sense. Eyes sense photons, touch detects physical force, tongue and nose give useful attributes of chemical properties, and neuron clusters adjudicate probability, the navigation of all the possible paths for the organism. "This happens when you go there, go here instead"
I mentioned it in a separate parent, but null purge is - for the stuff I work with - completely non-negotiable. Nulls seem to break virtually everything, just by existing. Furthermore, old-timey PDFs are chock full of the things, for God knows what reason, and a huge amount of data I work with are old-timey PDF.
It's hard to localize. Early Postscript - PDF software was the wild west, particularly when it comes to the text streams. Something I've noticed is that they're used a LOT in things like randlists (bullet lists), tab leaders, other "space that isn't a space".
I'm reminded of how you have to use `{empty}` character refs in lightweight markup like Asciidoc to "hold your place" in a list, in case you need the first element in the list to be an admonition or block. Like so:
. {empty}
+
WARNING: Don't catch yourself on fire!
+
Pour the gasoline.
And the equivalent XML which would be something like
<procedure>
<step>
<warning> Don't catch yourself on fire!</warning>
<para>Pour the gasoline.</para>
</step>
</procedure>
This is one of those rare cases where the XML is more elegant than the lightweight markup. That hack with `{empty}` bugs me.
Anyways, I'm spitballing that these old-timey nulls I'm seeing are being employed in an equivalent way, some sort of internal bespoke workaround to a format restriction.
Holy smokes. I'm no programmer, but I've built out bazillions of publishing/conversion/analysis systems, and null purge is pretty much the first thing that happens, every time. x00 breaks virtually everything just by existing - like, seriously, markup with one of these damn things will make the rest of the system choke and die as soon as it looks at it. Numpy? Pytorch? XSL? Doesn't matter. cough cough cough GACK
And my systems are all halfass, and I don't really know what I'm doing. I can't imagine actual real professionals letting that moulder its way downstream. Maybe their stuff is just way more complex and amazing than I can possibly imagine.
Binary files are full of null bytes it is one of the main criteria of binary file recognition. Also large swaths of null bytes are also common, common enough we have sparse files - files with holes in them. Those holes are all zeroes, but are not allocated in the file system. For an easy example think about a disk image.
Indeed, '\0' is the sentinel character for uncounted strings in C, and even if your own counted string implementation is “null-byte clean”, aspects of the underlying system may not be (Windows and Unix filesystems forbid embedded null characters, for example).
A company like Google (or Apple for that matter), with their own freewheeling project systems, would rather jump into an olympic pool filled with razor blades and used condoms before taking any amount of money from the hellish morass that is the defense procurement system. The instant you enter the MIC, kiss goodbye to any of your internal business systems - you will be re-writing the way you work every second of every day. And not for the better, I might add. I think Google looked at the costs of that, looked at the contract, and said, nah, thanks, I'm good. Then went back to feeding NSA/NRO for black money delivered by men in coats.
Of course, now, post-ZIRP, things are a wee bit different.
Yeah, that's via an OTA, which is basically - comparatively - free money. It's not a PoR (Program of Record). PoRs are where (many naive people think) all the money is. All those people are incorrect. It is, however, the PoR which will ruin your goddamn business when you sign it. Congratulations, that is now all you do.
Agreed on defense procurement revenue vs their current revenue streams. But they are given national-level amounts of resources (eg gigawatts for their data centers). In a wartime footing that would go away unless they re-oriented to serve common effort.
I thought Google purchased things like gigawatts for their data centers on the open market? Can you link to something that shows its bring give to them from the government for free?
GitLab on-prem is way, way, way more elegant than trying to get GitHub on-prem working. One of the things that makes me go, "Gah?" is that, well, Atlassian is more or less abandoning on-prem Bitbucket going forward. Perforce is, well, Perforce. Niche VCSs like SVN are rapidly getting impossible to keep running on modern platforms. All this really does seem to leave the field of "small to midsize companies who can't cloud" entirely to GitLab.
Which, I guess, says something about how expensive it is to run support for on-prem enterprise software. But that doesn't feel like an unsolvable problem, not with a customer field this rich. On-prem focused orgs tend to have wads of cash stuck up in them.
What a loss. Killer Elite was one of my favorite modern pieces of war reporting. Wright didn't let the hilariously dystopic "embedded" rules muzzle him or intimidate him - no, he went to play bullet dodger with Marine Recon. A lot of other press, the embedding worked like it was supposed to and kept them well to the rear.
His true crime is a similar round of WTFs, like when you learn about weird CIA crap for the first time, but over and over again.
Mental note to watch the TV series - that somehow passed me by.
Seat? I would have blown out a whole new access panel in the belly of that flivver with the sheer force of my terror.
The few times I've been in bush flights over terrain, it's always felt like the man upstairs is punching my dance card. When I'm feeling brave I'll sometimes ask pilots about it, and sometimes they're like, yep, feels that way flying too - that's why I love it!
> And most documentation systems are far easier adopted by people other than engineers.
Whew, gonna have to have a hard disagree with you there. DaC is several times - nay, orders of magnitude - less complicated than standing up a S1000D, a DITA, or even a DocBook publishing system. For anyone.
Count the layers of configuration.
S1000D, you have to worry about issue (which has zero compatibility, and the Technical Steering says they have zero intention of releasing any guide to matching the different issues up), you have to worry about BREX, then you have to worry about bespoke DMC schemes, and then you have all the many ways the PDF or IETM build can get built out to Custom Solution X, since the TS/SGs offer absolutely bupkiss for guidance in that department (it's a publication specification that doesn't specify the publication, what can I say?). The DITA side's not a lot better: you have multiple DITA schemas, DTD customization, specialization, and you have a very very very diverse batch of DITA-OT versions to pick from, then on top of that you have the wide wide world of XSL interpreters, again with very little interplay. DocBook is probably the sanest of the bunch, here, but we're still going to be wrestling with external entities, profiles, XSL, and whether we're doing 4.X or 5 or whatever is in DBNG.
Not to mention all of this stuff costs money. Sometimes a whole lot of it. Last time I shopped round, just the reviewer per seat licenses for the S1000D system were 13k per seat per year, the writer seats were over 50k per year.
DaC, on the other hand, I want to get re-use and conditionals, so I get Visual Studio Code. I get Asciidoc. I get some extensions. I get gitlab, set up whatever actions I want to use, set up the build machine if I want one, and if I'm feeling adventurous, Antora. I'm literally writing an hour later. I'll probably spend more time explaining to the reviewers what a Pull Request is.
As a pretty die-hard enthusiast for this approach - even for legacy, hard industries - let's take a close look at some of the limitations of this approach.
First, code is formal language, and docs are natural language. That's a lot of jargon; what does it mean? It means that the chunks inside of a piece of code are consistently significant; a method is a method, a function is a function. Chunks in a document are, woo boy, good luck with that one. XML doesn't even have line breaks normalized. Again, no matter what the XML priesthood natters about, it's natural language.
A consequence of this is that the units of change are much, much smaller in a repo of code vs a corpus of documents. This, well, is can be ok, but it also means that a PR in a docs as code arrangement can be frickin' terrifying. What this means, is that you have to have a pretty good handle on controlling the scope of change. Don't branch based on doc revisions, but rather on much more incremental change, like an engineering change order or a ticket number.
Your third problem is that the review format will never - can never - be completely equivalent to the deliverable. The build process will always stand in the way, because doing a full doc build for every read is too much overhead for basically any previewer or system on the planet. This is a hard stop for a lot of DaC adopters, as many crusty managers insist that the review format has to be IDENTICAL to the format as it's delivered. Of course, that means when you use things like CIRs (common information repositories) that you end up reviewing hundreds of thousands of books because an acronym changed....but I call 'em "crusty" for a reason. They're idiots.
It can be intimidating. And it probably isn't worth the investment for many projects. Especially not small ones. But https://www.amazon.com/gp/product/1541259335/ is a very compelling example of something in this vein.
Honestly, I think a pretty good pyramid scheme a la the Mikkelson Twins would be to start up a wholly imaginary "MIL-SPEC SCAMMER SCHOOL" that tells you all about people like this lady, and offers a course on HOW TO NOT DO SUCH BAD THINGS, while winking with every muscle in your body.
Or, even better, advise you on how to be a big time MIL-SPEC guru who can lead SIGMA or whatever other nonsense the management of the day is huffing. This advise is your key to landing BIG WORK in the Defense Industry! Everyone knows it's all nonsense, but we can teach you how to turn that nonsense into passive income.
Of course such a fabulous class would cost beaucoup buxxx....
Ah, this sounds heartbreaking. I'll leave it to those salesmen with mental sickness.