You're talking about industrial PLCs. They're programmed using a-bit-more-fancy Scratch snappy blocks. There is no version control. The firmware contained paths embedded as strings, so we know that firmware for each model and customer was developed in a separate folder on disk. I wouldn't be surprised if they also had .zip files with backups of previous versions.

The IDE for these PLCs actually has VCS integration! It's SVN, but it's still better than nothing.

Its on-disk representation of graphical 61131-3 languages (FBD / SFC) is text-based and somewhat human readable, so there's nothing technically preventing the developers from keeping all of this in any other VCS of their choice.

There is nothing wrong with SVN, it's just that Git allows for some workflows that are better suited to larger teams and more complex projects. But for your average PLC project with a team of 10 and one binary as the output it should be more than enough.

You likely won't see any 'feature branches' or frequent merges in this kind of environment.

> There is nothing wrong with SVN

Except merging things, and handling a lot of files...

There are lots of small things wrong with SVN. But it's indeed usable.

I'm aware of repos with a few million files in it that have been going since 2003 and not a single issue.

Merging things is different than in Git but it works. I use both, and I'm not religious about either, some things are easier in Git, some are easier in SVN. Git provides more footguns. And loads and points them too.

I'm intimately familiar with PLC programming, yes, you can do it the 1980's way but there are also plenty of environments that allow for modern version control.

https://www.google.com/search?q=version+control+plc+programm...

You'd have to be pretty daft to do this kind of development today and not take advantage of version control and even the most visual versions of these systems eventually output (text) files. You may not be able to do an easy line-by-line comparison but you will have a commit log with helpful messages.

Look for 'engage in anti-competitive behavior' in the log message ;)

What about: rogue hackers maliciously squashed our whole repo into a single commit?

I don't doubt that's exactly what would happen, in fact I think that that rogue hacker is about to do his thing, quick, erase the backups!

Yeah.. I've just realized that while it's entertaining to watch how it unfolds or predict what can happen next, it's also sad, because pretty much everybody in the rail industry loses..

One of my business partners works for PKP it's very annoying to see this all unfold and in this particular way. Poland has so much potential, these idiots are ruining Polands image in ways that really matter.

But then again, as a Dutch person I have enough issues locally that I can't even complain...

Ugly times.

I have a friend that runs a business, where he hires Polish developers to do his coding.

He absolutely raves about them. It sounds like he's got some good coders.

Poland has a very strong technology and mathematics tradition that goes back decades. It's one of the reasons Poland has some strong feelings about their role in the breaking of the Enigma, for the longest time that was played down.

Working in security on the operating side (albeit not in Poland):

No, pretty much just the manufacturer loses. Short term the operator loses, but I'm sure that the courts will award damages.

For me, this incident is a welcome argument with which I can tighten the screws on manufacturers in the next round of train buying (at minimum, they will agree to heavy contractual fines for anything like this; at best I get full source code for every train).

For too long the only priority in OT was safety (fine in the 80ies, but the second you integrate an IP stack that posture doesn't work anymore). This has been changing in the industry thanks to EU-regulation; this incident will accelerate the change.

What I meant is that I feel the trust among parties might go down industry-wide. In a sense you admitted that:

> (...)I can tighten the screws on manufacturers in the next round of train buying(...)

But then I can see it might help change things for the better across the board, as you nicely described. Thanks for the illuminating comment!

That's assuming we will get to the bottom of this. And I really hope we will. But I'm kind of concerned that it will all be wiped under the carpet.

Temporarily lost ok. Better to let these manufactures do whatever they want.

If this goes on to criminal charges, then they're about to discover what amazing things a thorough digital forensics analysis can find out from their workstations.

Now you're saying they're about to have a fire.

Oops, rogue hackers deleted our .zip files with the backups! :)

EDIT: BTW having no version control would be pretty telling on its own. It's a critical piece of software, that controls a train..

If it was developed anytime after 1990 (probably before) you will find plenty of programmers willing to be expert witnesses and tell the court that the company not having version control is gross incompetence, the only reason a company would do that would be so they can hide evidence of illegal actions. As such the court should impose punitary damages.

Of course before going on the stand the expert witness will work with a lawyer to word smith the above into something the court will better understand. however I think the generic idea is something everyone here will agree with.

> There is no version control.

I've used a thing that not only doesn't play nice with versioning (your local workspace is a collection of embedded db files) but doesn't play nice with multiple developers (no way to sync workspaces). I still managed to get it into version control, even if useful things like diffs didn't do anything useful.

Do you have more information about this sort of programming? I'd like to read about it.

Google for PLC programming environment.

IEC 61131-3

ah, thank you!