MilStdJunkie

no profile record

comments

2 ปีที่แล้วdiscuss

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.

2 ปีที่แล้วdiscuss

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"

2 ปีที่แล้วdiscuss

Ah, I'm a dummy. Of course these would be binaries getting chucked around.

2 ปีที่แล้วdiscuss

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.

2 ปีที่แล้วdiscuss

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.

2 ปีที่แล้วdiscuss

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.

2 ปีที่แล้วdiscuss

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.

2 ปีที่แล้วdiscuss

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.

2 ปีที่แล้วdiscuss

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.

2 ปีที่แล้วdiscuss

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.

2 ปีที่แล้วdiscuss

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!

2 ปีที่แล้วdiscuss

> 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.

2 ปีที่แล้วdiscuss

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.

2 ปีที่แล้วdiscuss

Also a market for putting a more doc-focused UI on git, integrating that too[1]. Pull Requests are basically gold for doc review, but the process of getting to the PR is something that always seems to need a bit of training. Nothing like the training that's needed to grok the basic graph-based change model, and how it's going to work for natural language (ish) documents, but that's a whole other kettle of fish.

[1] GitLens comes pretty close to this, however.

2 ปีที่แล้วdiscuss

Lots of DaC shops use feature flags for their conditional content. "Conditional Content" is a huge hobbyhorse in component content, because you need conditionals to re-use chunks. How else could the chunk be made applicable to multiple people? In doculandia, it's more common to run into conditional handling that's inline with the document markup - ifdef/ifeval/ifndef in Asciidoc, some stuff in Jekyll, S1000D applic, DocBook profiles, DITA class/ditaval - but I'm not one hundred percent sold that's a solid practice. Moving conditionals into the document layer might have been a mistake. I dunno! I'd love to kick off a conversation.

2 ปีที่แล้วdiscuss

The DaC debates grow increasingly grim as the overall employment situation worsens across industries. It's pretty hard to get people to react authentically, rather than see the discussion as an attack on how they do their jobs[0].

I'm going to head all this off at the pass, and say instead that DaC[1] is a technological tool for a limited number of business use cases. It's not a panacea, no more than XML publishing in a CCMS (component content management system) was seen as the Alpha and the Omega (and indeed still is by a whoooooole lot of people). I say this as a heartfelt believer in the DaC approach vs a big heavy XML approach.

Your first question - really, this should always be your first question - is, "how do people do their jobs today?". If you work in a broom factory, and the CAD guy reads word documents, the pubs guys use Framemaker, the reviews are in PDF, and the final delivery is a handful of PDF documents....well, using DaC is going to be a jump.

Now, is that jump worth it? Well, it might be. Your CAD guy might know his way around gitlens, your pubs folks probably have some experience with more complex publishing build systems, and, most important of all, you might have a change tempo that really recommends the faster-moving flows of DaC. If you're going the Asciidoc route, you could even try out some re-use via the `include` and `conditional` directives. But it also could be a disaster, with no one using VCS, no one planning out re-use properly[2], people passing reviews around in whatever format, and PDF builds hand-tooled each time. It's not something you dive into because it's what the cool kids are doing. Some places, maybe even most places legacy industry wise, it's just not going to work. Your task - if your job is consulting about such things - is to be able to read the room real fast, and recognize where it's a good fit, and where you might need to back off and point to a heavier solution.

[0] Big traditional XML publishing systems are also in the crosshairs, as they're quite frankly usuriously expensive, also writer teams have started noticing the annoying tendency of vendors to sell a big CCMS and then - once the content's migrated - completely disappearing, knowing that the costs of migration will keep you paying the bill basically forever.

[1] DaC defined as : lightweight markup (adoc, md, rst, etc), written/reviewed with a general-purpose text editor, where change/review/publish is handled on generic version control (git, hg, svn, etc), and the consumable "documents" are produced as part of a build system.

[2] Which crashes ANY CCMS, regardless of how expensive or how DaC-y it is.

2 ปีที่แล้วdiscuss

Has everyone suddenly forgotten the ability of VC to make money just . . evaporate? The list is long and the dollar number is heartbreaking.

Well, if they have, I suppose they'll be reminded forcefully by today's substantially different rate environment.

I'm not saying "AI" isn't a big deal. It is. It's got all sorts of uses. Is the state of play worth dumping this quantity of brains and dollars? Jury's out on that. But saying it's worth lots of money because people are throwing lots of money is not a winning argument.

2 ปีที่แล้วdiscuss

The city laments of the ancient near east might fall near this, but definitely many Roman writers, like Vegetius, saw very clearly that their civilization was headed for oblivion, and they wrote about it, sometimes quite heartbreakingly. There's a whole genre of literature from the late 19th century that does this same thing with the British Empire - honestly, it's a strong tradition today.

Thing is, what you see in retrospect, is that nothing really dies all the way. Bits and pieces - sometimes very large pieces, in the case of Rome - can be digested and live on for hundreds or thousands of years. The current climate crisis will be a problem, no doubt, but it will be overshadowed rapidly by the conflicts that it sparks. Thirsty people don't worry about radiation.

2 ปีที่แล้วdiscuss

Yeah, but it's very much worth hitting the seven-or-eight figure crypto holders too - those guys don't have the liquidity to support 24/7 security staff. Sure, they could buy some tech, but security tech . . I'm trying to be nice, and it's just not working . . it's not going to keep out a determined and informed attacker. Their best defense gimmick is (would have been) anonymity, but staying anonymous on the chain requires extra steps, and not everyone is gonna do those.

2 ปีที่แล้วdiscuss

"Easy" and "hard" are a lot less important than "risk", I think. Sure, as entrepreneur, I might make 200% gains one out of four times versus 10% gains four out of four times as FTE, but if I'm not already sitting on sustainment money then it doesn't matter what the gains are - I need that four out of four.

It's why you see mostly kids with eff-off money in the game, a few kids from upper middle class, and the tiniest trickle of the actually poor. If you ever wanted a non-commie reason for UBI, that's one of them - you expand the entrepreneur pool by a metric buttload.