5 ms·
I work in an industry that requires 2 seperate implementations of all critical software components; so I have been involved in several reimplemenations to help
by gizmo686 2y ago
I work in an industry that requires 2 seperate implementations of all critical software components; so I have been involved in several reimplemenations to help satisfy that. There are definitely times where I saw a feature and thought "the original implementation was obviously doing X; and this feature does not really make sense given our architecture". However, I have never needed to rearchitect my program to implement the feature. The only real difference is that a trivial feature for one program takes a bit of work on the other. However, I could also point to functionality that took more work to implement on the original program, that the different implementation made trivial on the second program.
I have only had to do 1 major rearchitecturing, and that was on the original implementation, which had some architectural assumptions that forced an exponential blowup. I'm wasn't working on the second implementation, but they started years after us, and managed to avoid our mistake from the beginning.
To take a public example, that is far more complicated than anything I have worked on, consider the problem of running Windows applications under Linux.
Linux is a completly different implementation of a kernel than NT, and doesn't even attempt to be compatible. However, running Windows applications does not require a rearchitecture. Just a few relativly generic Kernel features, and a userspace compatiblity layer. Not to say that Wine does not take a lot of effort to write and maintain; but not nearly as much effort as implementing Windows itself. And, it is running on top of a platform that never aspired to be Windows compatible. Wine does, however, suffer from the problem that the article points outs, in that it is perpetually behind Windows. Wine also exemplifies a second problem, which is that bugs in the primary implementation end up being relied upon, so in order to be bug-for-bug compatible, you need to first discover what all the bugs you need to implement are.
- miki123211 2y agoThere are huge swaths of the Windows API that Wine straight up doesn't even try to implement, the complex APIs that a screen reader or driver would require to function being good examples. There's a good argument that implementing kernel-mode driver APIs would be a complete waste of time, after all, Wine is running on top of another operating system, which should be responsible for interfacing with hardware. However, what the Wine developers didn't foresee was the fact that some applications (mainly games) started requiring a driver to function as an anti-cheat feature.
- maayank 2y ago> I work in an industry that requires 2 seperate implementations of all critical software components Very interesting, what industry if you may discuss it a bit more?
- tonyarkles 2y agoMy guess would be something safety-critical, probably aerospace. I haven't had to do the "2 separate implementations" thing yet but will likely be exploring quorom/voting-based redundancy pretty soon. Fun times!
- stult 2y agoI've seen this in aerospace in cases where testing the software against ground truth isn't possible for some reason[1], so you need to generate an alternative version of an algorithm as a sanity check. [1] This is typically because the expected outputs are not easily known or specified in advance (e.g., interpolating a 3D wind cube to a higher resolution from lower resolution forecast data) and there isn't much if any experimental data, and collecting such data is expensive because it requires flying expensive aircraft around for long periods of time.
- foobarchu 2y agoOn the other end of the windows emulation space, another example is ReactOS, which has always lagged years behind its target.