Royal Marines Gucci Rebrand

Caecilius

LE
Kit Reviewer
Book Reviewer
Oh well, I’m clearly not as smart as you, we might have to agree to disagree. :)
Perhaps if you had been following what I’ve been following the ‘200 seconds’ would have made immediate sense to you, and you would know what it referred to, and how long the previous estimate was. :)
The 200 seconds refers to a questionable quantum computing paper published by Google that's been heavily disputed. As I said, you've confused quad and quantum. It also wasn't an encryption crack - it was a mathematical calculation that Google reckons would take 10,000 years using conventional computing but others think would take a matter of a few days. I don't have the maths ability to judge who is right.

We've known for ages that quantum computing has the potential to make existing encryption essentially obsolete. Rather like nuclear fusion, the question is how to turn theory into reality.

There are also any number of other problems beyond simple computing power as I mentioned previously. Like with AI, army officers have a habit of treating cyber as the second coming of Jesus without really understanding much about it.
 
Last edited:

Slime

LE
I don't think this is thread drift, although I would point out that one cyber thread has already been locked.

We need to sort our place in the world, and that means militarily as much as anything else. But, we also need to sort what we mean by 'militarily'. Increasingly, that includes an element of the electronic environment as much as door-kickers. It has for some time, in fact, and that needs to be recognised.
Maybe cyber is a dodgy subject. :)
I have China in mind, but am presumed to be thinking of Cheltenham, then Google :)
 

Faded

Old-Salt
A lot of old SQs have now reverted to GD (or soon to be CD-Commando Duties) for example a Heavy Weapons Anti-Tank specialist (HW(Atk)3) is now a GD with the various weapon systems as an adqual (GMG, HMG etc).

Only a handful of SQs remain at the Mne/LCpl level e.g. LCs, AS and Snipes.
 
The 200 seconds refers to a questionable quantum computing paper published by Google that's been heavily disputed. As I said, you've confused quad and quantum. It also wasn't an encryption crack - it was a mathematical calculation that Google reckons would take 10,000 years using conventional computing but others think would take a matter of a few days.

We've known for ages that quantum computing has the potential to make existing encryption essentially obsolete. Rather like nuclear fusion, the question is how to turn theory into reality.

There are also any number of other problems beyond simple computing power as I mentioned previously.
And like fusion, it's only ever "5 years away".

I learned (at the very lowest level) how to do quantum programming in my university degree, in the last millennium....
 
"Encryption" on its own is meaningless. What encryption? Also, how was the data captured and what's the mechanism to obtain more data? It's not just a computing power problem.

Also, I have looked online and quad super computer doesn't seem to be coming up. It's also not a term I've heard before. It's either niche, or you're confusing it with quantum computing.
US Government has one hosted by NASA in California. Very very niche and not much known about them.

Every year IT generates another round of buzzword bullshit mainly to generate sales momentum.
 

Mr_Relaxed

War Hero
From speaking to the RM blokes I work with, that encouragement tends to be compulsory, and often well before LCpl. How else can the corps generate drivers and signallers?
And I suspect that's been the case for a long time - my father told me that when he finished RM basic that the entire squad was told what their SQ was going to be. And they weren't asked for a preference.
 

Mr_Relaxed

War Hero
The 200 seconds refers to a questionable quantum computing paper published by Google that's been heavily disputed. As I said, you've confused quad and quantum. It also wasn't an encryption crack - it was a mathematical calculation that Google reckons would take 10,000 years using conventional computing but others think would take a matter of a few days. I don't have the maths ability to judge who is right.

We've known for ages that quantum computing has the potential to make existing encryption essentially obsolete. Rather like nuclear fusion, the question is how to turn theory into reality.

There are also any number of other problems beyond simple computing power as I mentioned previously. Like with AI, army officers have a habit of treating cyber as the second coming of Jesus without really understanding much about it.
Although I would suggest that could be extended to some parts of the business world - I think that a lot of the banking issues from yester-year were due to very grown-up bankers not actually understanding the IT solution they were being offered. But it sounded good or at least plausible.

Sometimes IT is not the panacea we think it is.
 
There are also any number of other problems beyond simple computing power as I mentioned previously. Like with AI, army officers have a habit of treating cyber as the second coming of Jesus without really understanding much about it.
I've lost count of the number of times I've seen "eVil EnEMy pwns our TyPHoons n sHiPz beCoZ lamer wiNDoZE!! Eleventy!!!" assertions. Normally about embedded systems where it's impossible to change the code without physical access to the device, because guess what? Engineers have worried about this kind of thing for decades (I remember one initial requirement on a military project that required us to wipe all software in the event of the ejector seat firing. Fortunately, saner heads prevailed before we got too far into implementation...)

And it's not just the Army; remember the blind insistence that any issues with a post Brexit NI border, would disappear with the application of Magic IT, because after all: It Can't Be That Hard, Can It? (Hint: Yes, it can). Meanwhile, industry buzzword bingo normally involves the words "Cloud" and "Blockchain", typically uttered by a sales type with a degree in English Literature or Media Studies.

There are plenty of routes for computing to address military C3I, that just aren't taken - because the typical response is "how do we automate an existing process", rather than "how do we rebuild a process to use what we've learned from seventy years of computer science"...
 
Last edited:

potter

Old-Salt
There are plenty of routes for computing to address military C3I, that just aren't taken - because the typical response is "how do we automate an existing process", rather than "how do we rebuild a process to use what we've learned from seventy years of computer science"...
Or, more precisely "how do we automate an existing, photogenic and preferably kinetic process?"

A: Don't. Examine your unsexy logistics, administration and other support areas to do what Gravelbelly suggests, where your day to day savings can be reinvested.
 
I think that a lot of the banking issues from yester-year were due to very grown-up bankers not actually understanding the IT solution they were being offered.
Not just yesteryear. At some point in the last decade, Beloved was involved in sorting out the wreckage of a mortgage system that had miscalculated monthly payments. The FSA took the approach of telling the bank that it was their problem, not the mortgage-payers, and that the bank was going to pay for their underpayment cockups (eight-figure amount, IIRC), and correctly allocate their overpayments - the customer was not to be screwed over.

One possible interpretation of the original conversation inside the bank was:
Grown-Up Banker: "Do us a repayment calculator, would you?"
- IT People: "Sure thing; how do you want us to calculate repayments?"
Grown-Up Banker: "Oh, I don't know - the normal way."
- IT People: "Have you got a proper document describing what you think is normal?"
Grown-Up Banker: "Oh, FFS! Don't be so Bloody Stupid! Just f***ing Google the answer and get on with coding it, or we'll sack you and replace you with a datacentre in Hyderabad! Compound interest, how hard can it be?" [*].

They had to rebuild a model of what the resulting system was, and how it had been compromised, by writing a spreadsheet and comparing it with tens of thousands of customer mortgages until the spreadsheet matched what had actually been sent out. Then fix it.

Having written the new document describing how compound interest repayments were to be calculated, the big problem was finding any of the Grown-Up Bankers actually willing to read it, far less sign off on it. Massive sloping shoulders all around, and a hearty dose of "it's all blinky-lights techie stuff, I don't bother with minor details like that".

[*] So, you start your mortgage half-way through the month - two weeks later, at month end, should you be charged two weeks of interest, or a full month? You pay a little extra into your mortgage half-way through the month - should you recalculate the remaining repayments that day, or should it count at the end of the month? You pay off the remaining mortgage early, the day after your monthly payment
- should you pay one day's interest, or the whole of the remaining month?
 
A: Don't. Examine your unsexy logistics, administration and other support areas to do what Gravelbelly suggests, where your day to day savings can be reinvested.
Not just boring old G1/G2/G4 stuff.

"Orders" is essentially a parallel programming language for sub-units; and we now have decades of understanding which programming languages are easy to use, which ones are hard, and most importantly, why. Ask yourself why some people are consistently good at delivering clean, comprehensible sets of orders; while others often seem to produce confusing and downright baroque ones? It's the same with software engineers.

So why haven't we had a few language-design people look at the Orders format, and see if they can spot anything that could be improved? Our universities are generating hundreds of Ph.Ds in, and thousands of practitioners of this stuff, every year - and any workable breakthrough attracts money at the level of "buy your Ferrari and retire". I assume that the Army's research on the subject is a few people in a doctrine cell (if that; given that Jim Storr's work wasn't exactly mainstream); it's not really a competition, is it?

We also have twenty years of code autogeneration experience (Rhapsody has been delivering deployable mil-spec software systems for twenty years, just up the road from me). So why haven't we got something that will allow you to draw a few symbols on a map, and generate the bulk of a workable set of orders from an APP-6A trace and a fireplan diagram? Or read a set of orders, and generate workable graphics? It is entirely possible, I guarantee you, because I've used the systems that do exactly the same thing for UML <-> software, and written them for hardware.

Or best of all, run a check of everyone's orders, by transmitting them one level up, not just one level down, and flag up any inconsistencies immediately? "Can you deconflict with A Coy on your left? They're going left flanking, you're going right flanking, and you're going to be fighting through your objectives directly towards each other...". We use static analysis tools as a matter of course, because they catch the rather subtle and nasty software bugs that are hard to spot manually.

The analogy would be the old Secure Orders Cards - which (once you'd solved any BATCO delays) were good enough for BAOR to launch armoured battlegroups across the North German Plain with an impressively short reaction time. The actual data content is very low, you aren't sending damn great images across your radio network, and once you've received the SOCs, your software kindly draws it up for you. Draw your boundaries / allocate outline tasks, and the Wng O gets sent within minutes. Arrives one level up, across the same level, and two levels down, immediately. How could that improve Battle Procedure?

How about linking the orders into the IPB output? Spot whether all of your TAIs and NAIs have troops to task? Better still, observe the timelines when those troops will arrive, and when they will leave (because it's the dynamic behaviour that's hard to visualise, not the static behaviour); run rehearsal (rock) drills forward and backward until you're happy. Feed the orders into the G4 system, make sure that the Quartermaster knows WTF is going on.

Another problem is traces - how do we maintain them? Placing a sheet of acetate over the BG map board and tracing 1:50000 using a chinagraph, has its problems when it comes to a third-generation copy (see: SAS/SBS overlapping their patrol areas in the Falklands leading to a blue-on-blue). Keeping track of when it was last updated, and how accurate it is, has its problems too (see: TELIC1 CR2 v. CR2 blue on blue, because the BG trace was over 24hrs out of date). Configuration management and version control is a big deal in software engineering; but not really an explicitly-handled process in a BG HQ when I tried it...

Yes, I'm a weirdo crossover who has done a Computer Science degree, a decade of parallel programming, written a tool for the abstraction of design work, done JDSC and CATC (granted, as a STAB), and been BG Ops Offr at CAST a few times...
 
Last edited:
I do actually have some sympathy with that position: 1960 U-2 incident - Wikipedia and Hainan Island incident - Wikipedia
That was the scenario it was intended to guard against. I don't know why it got binned as a requirement; possibly because any accidental bump of the circuit concerned would mean returning the aircraft to workshops and taking a day or two to reload everything. Meanwhile, there wasn't a download option, or a hard disk to read, so the Bad People were going to be trying to scan the burnt wreckage of a few hundred different EEPROMs if they wanted the software.

Hell, we found it tricky enough to understand the hundreds of thousands of lines of software, and we wrote the bl**dy stuff...
 
Last edited:
You would be able to read any if their encrypted or coded message within 200 seconds (at current rates).
Err...no you wouldn't. PKI type security maybe, but mil level encryption (AES 256), no chance!

A lot of the other stuff, such as location, identification and target acquisition is perfectly plausible as is C3 disruption, but without enough kinetic stuff it's pretty much just a bump in the road.
 

Slime

LE
Err...no you wouldn't. PKI type security maybe, but mil level encryption (AES 256), no chance!

A lot of the other stuff, such as location, identification and target acquisition is perfectly plausible as is C3 disruption, but without enough kinetic stuff it's pretty much just a bump in the road.
This thread makes you wonder why the Chinese think they can do certain things. :)
As things stand, not only are they running rings round us, but we allow them to do it, and our system of democracy makes life much easier for them to ‘get’ from the UK than visa versa.

Security in the U.K. is very poor imho, and with a bit of cunning, and lots of money thrown at a problem our adversaries are doing just fine.

I understand lots of people think we keep secrets well, or have good security measures in place, but seeing copied info being made into real products in China might suggest otherwise.
 

Caecilius

LE
Kit Reviewer
Book Reviewer
This thread makes you wonder why the Chinese think they can do certain things.
If the Chinese think they've cracked quantum computing then that really would be news.
 

Latest Threads

Top