CaciaraAsAServi
Joined 7 years ago
Karma
60
Submissions
26
Member since
Aug 1
Recent submissions
Comment · 4 years ago
Comment · 4 years ago
#shodansafari
Comment · 5 years ago
> All they have to do is piss of a billionaire with delays one to many times..
...and nobody will follow their lead [as quickly as you comment seems to suggest].
I've just come out from a discussion with a customer (young guy, circa 30, not a "boomer"), head of a major wastewater treatment plant in my circa 4 million ppl. metro area...he doesn't trust software, he would rather put relays everywhere and go on like that.
The problem is not only the velocity of those who produce the systems, it is also the mentality at the end users' side.
This is why I say that the transition will be slower than it could be; there are so many parts involved.
If it only were a problem of "rate of innovation produced per unit of time" I would 100% agree with you (and not only 50% as I do :-) )
(BTW, any industrial automation person living in Northern Italy: be wary when working for the company whose name is like "ZIP code" in Italian, there is lots of work to do there, but the technical org is suuuuuch a mess)
Comment · 5 years ago
I meant "the most advanced" vendors ;-)
Comment · 5 years ago
eh, eh, I know what you mean, but in my opinion most vendors are honestly putting effort into modernizing development practices; sure, they're the usual money-grubbers we all know and love ( not! :D ), and gatekeeping is strong, but on the other hand, the sector is so vast, you are dealing with a culture which is so dragged back by past traditions, and last but not least, one's "gatekeeping" is the other's "professionalism".
Edit: Not to say that most of the times we are talking about small operations, where the PLC programmer is also electrician, plumber, chemical eng., mechanic, etc. ...
We are not only talking about big corps where hyperspecialization is the norm, the bulk of the users are (literally!) jack-of-all-trades, software is only a part, and in many cases a marginal one at that. People who have to do with PLCs are IMO far, far more diverse than the other kind of software developers.
Comment · 5 years ago
You are partly right, but it is not so bleak, come on.[1] It is true that the average programming practices in the sector are pretty outdated, but we do have forms of code reuse like function blocks and functions, some form of code generation via the APIs of various IDEs, etc.
The thing is, this sector is SO vast.
(Modern) software will take quite a bit to eat this world, at least simply for its size.
Industrial automation goes from smalltown electricians (this particular LOGO PLC lineup is targeted at these people), to builders of small machines still hugely relying on electro-mechanical components, to world-wide corporations, with varying levels of regulation, tolerance to risk, and so on. Not to say anything about truly advanced deployments in science projects, etc. We are basically talking about the WHOLE of what used to be called the "secondary sector of the economy", and part of the primary, AND part of the tertiary! [2]
The IEC standard, the most advanced products of nearly every vendor, and the most advanced users, are going towards (sure, at their own pace, but still) modernity, but it's just a part of a vast ocean. I personally don't think I would exaggerate if I said that the variety of attitudes towards software in industrial automation is far, far greater that the one in the "normal" software industry; coupled with the other constraints expressed in other comments, that means that is not so simple for modern practices to win, they eventually will, but it will take a quite a bit.
[1] many might laugh at the content, but have a look at the programming guidelines by Siemens https://support.industry.siemens.com/cs/document/81318674/pr... and while I am at it at https://www.plc-security.com
Comment · 5 years ago
If one wanted to be a bit sneaky, one may ask to any tech-bro: and what about you, can you wire a thermocouple?
Comment · 5 years ago
Nitpick (as you well know) - codice fiscale in Italy differs from USA SSN in that, for once, it has never had AFAIK any semblance of secrecy at all, as you can easily construct it starting from name, surname, place and date of birth [1] Funnily enough, this sometimes results in two individuals computing to the same code [2]
Comment · 6 years ago
Yup! SGS from Italy and Thomson from France, in 1987 (not '88, corrected). ST in fact used to mean SGS-Thomson.
Comment · 6 years ago
OT, sorry, but related (well, related only in the language):
https://github.com/esseks/monicelli
(humorous PL based on a cult movie)
Comment · 6 years ago
Heh, I remember learning some German just to understand their lyrics, some years ago.
Funniest one I remember is, in Computerwelt, Flensburg und das BKA / Haben unsere Daten da... where BKA is the federal German police and Flensburg is the city where they held some data about people (or still do, I don't know).
Comment · 6 years ago
Merci ! Je suis en train de réviser mon français, ce lien peut me servir :)
Comment · 6 years ago
TIL! thanks! my native language is more tolerant with capital initials than English :)
1. check if in the .so/.dll you can spot any function referring to any recognizable (occurring only once) kind of binary blob - like images, or strings too
2. find the same function in the raw image, Ghidra's decompiler helps so much in this
3. find the address supposed to be pointing to the same binary blob (assuming that this blob is the same in the emulated and the real version)
4. scan the raw image for that same blob you have in the emulated version
5. do the maths to find the base address of the raw image.
Obviously all of this works if the raw binary image you have all refers to the same flat memory space and there's no partial relocation by the bootloader/program accepting this image going on.
Don't ask me about that time I painfully spent so much time without knowing I had one file with the odd name of "emulator.dll" staring at me all that time...