SoylentNews is people
SoylentNews
Munich still uses 41 proprietary apps that will only run under XP or 2000. The city has estimated it will cost $18M to replace them over a 4-year span.
Nick Heath at TechRepublic reports
Windows XP and 2000 are used by fewer than 1,500 of the more than 16,000 staff at the council, which relies on the aged Microsoft systems to run 41 applications.
[...] In order to stop using Windows XP and 2000, these 41 applications will either be migrated to a newer, supported operating system, replaced with more modern software, or phased out--as part of a four year project costing €16.6M ($18.03M).
[...] Munich carried on using XP and 2000 due to these 41 applications being used for crucial work in the city, from monitoring emissions for air pollution to flood protection.
To secure the OSes, Munich ran them on virtual machines and on standalone computers, as well as using what it calls "restrictive data interchange", quarantine systems, and additional protective measures.
The council has decided to stop using these older unsupported versions of Windows now as, not only are they a security risk, but according to a report [PDF, Deutsch] they have limited support for network and data security features the council wants to use.
[...] Often it can be the case that organisations can't update the application to run on a newer OS because the people with the necessary skills are gone or the company that originally wrote the software no longer exists.
[...] The project at Munich will be split into two phases: The first will assess the work needed and the second will carry it out. Work got underway at the end of [2015] and is expected to be complete by the end of September 2019.
(Score: 3, Insightful) by Beige on Friday January 22 2016, @11:18AM
Issues pertaining to legacy systems are by no means unique to closed source software.
Since the "apps" only run on XP or 2000 I'm assuming they are 16 bit Dos programs. They were likely developed long before Windows XP came out, so it's plausible the city got 20+ years of use out of their initial investment. This is actually not too bad from an overall TCO perspective and it's hard to imagine the situation being much different had the software been written for some ancient Unix using some now-obsolete libraries, and data files with endianess issues etc. They'd be stuck getting new hardware, new software, new support contracts etc. either way.
I'm actually curious about the premise of the headline. If the city went and bought new software which was e.g. built with Node JS, a HTML5 browser UI or whatever, could they realistically expect to get another 20 years out of that investment without having to pay developers to "upgrade" the software every few years just to keep it working?
(Score: 0) by Anonymous Coward on Friday January 22 2016, @11:41AM
I'm assuming you're wrong.
Never heard of FreeDOS, DOSBox, DOSEMU (all FOSS)?
Should be duck soup to get DOS apps running without any MICROS~1 code.
-- OriginalOwner_ [soylentnews.org]
(Score: 2) by Beige on Friday January 22 2016, @09:58PM
"Should be duck soup" is easy to say if you've not actually done that much legacy system porting :-) Things like legacy parallel port copy protection dongles, legacy hardware (e.g. barcode readers intended for AT or XT keyboard connectors), ancient network drive setups etc can pose interesting problems on modern OSes even if you can spin up the 16 bit client in an emulator. A lot of tweaking, some reverse engineering and even reassembly is usually needed to work around such issues, and it's frankly not worth the effort in most cases. However, there's always the odd "company is fubar unless we get this system from the 80s back online"-type emergency.
(Score: 0) by Anonymous Coward on Friday January 22 2016, @11:23PM
you've not actually done that much legacy system porting
If -zero- qualifies as "not that much", you're right on the money.
OTOH, I haven't heard of any problems taking apps that run under MICROS~1's DOS and running those under FreeDOS.
In fact, I read that FreeDOS can get USB going where MICROS~1's DOS never did.
dongles
Dongleware is another area where I'm completely ignorant.
I never saw any that I thought was worth the asking price (in bucks or in freedom).
I remember a narrative years ago in sci.electronics.design by a guy who had a stack of dongles out the back of his PC.
The cleaning crew moved his computer and CRUNCH; no usable stuff for a while.
it's frankly not worth the effort in most cases
We need to hear that more often--especially WRT closed proprietary stuff.
Start fresh and make it open this time.
-- OriginalOwner_ [soylentnews.org]
(Score: 0) by Anonymous Coward on Friday January 22 2016, @12:10PM
The key to legacy systems is to ensure the system/data/network requirements for them are well documented and reviewed often enough (and by enough people). Any software can be re-written - even if from scratch - with enough resources and project commitment (which Munich appears to have). But ...
... sometimes the devices used (e.g., for data gathering) no longer have drivers that are supported on current/newer/less-archaic platforms. In these instances outsource the development/re-engineering of the drivers to a specialty firm (but always retain rights to requirement & development documents, and the source code). The time and cost associated to hiring the right staff (with the specific skill set), bringing them up to speed, and developing/testing the replacement drivers is not practical. Outsourcing will look like it costs more up front, but you don't want someone who isn't a "driver person" developing a driver for you.
(Score: 4, Insightful) by GreatAuntAnesthesia on Friday January 22 2016, @12:15PM
> They'd be stuck getting new hardware, new software, new support contracts etc. either way.
Yeah, but at least if they have the source they can shop around for contractors:
If the source is held by the people who made the tool then the client can only go to the provider, who is then in a position to set whatever outrageous prices they like. They do this because (a) they can and (b) they'd much rather be working on some big new project that futzing around trying to patch that over-priced rickety heap of shit they just barely got duct-taped together and out the door 2 years ago. So they jack the prices up to the point where the client decides to make do with workarounds and put the necessary work off for years or decades until they really an't ignore it any more. By then the people who knew the product are all retired / dead / living off grid in a yurt in Nepal and the client has no choice but to have the whole damn thing rewritten from scratch (usually by the same providers) which will of course cost an arm and leg because every big CEO knows that .gov / .mil contracts go over-schedule and over-budget and the contractors laugh all the way to the bank, and the whole cycle repeats.
With open source you can make small, periodic upgrades as necessary. You can change contractors at any time, because nobody is holding your source code and data hostage, which means you acn keep control of prices.
(Score: 0) by Anonymous Coward on Friday January 22 2016, @04:57PM
The city could have had a term in their contact saying they'd get the source code along with every release. That doesn't make the code open source but it would let them shop around. Far too many people push open source for it's own sake. They stick fingers in their ears and yell open-source, open-source over and over again, like the article title. Everything that's happening with Munich right now could still be happening even if the code was freely viewable online. Their issues have nothing to do with the software being closed-source.
(Score: 0) by Anonymous Coward on Friday January 22 2016, @07:22PM
freely viewable
What Munich is going for is CONTROL of their software ecosystem.
You don't get that with "viewable".
What they need is not some EULA-restricted[1] openwashing, but rather license terms that give them **actual** freedom. [googleusercontent.com] (orig) [gnu.org]
[1] See the recent dust-up with Remix OS.
-- OriginalOwner_ [soylentnews.org]
(Score: 2) by requerdanos on Friday January 22 2016, @01:13PM
This. I worked a contract in the late 1990s for a major manufacturer [cummins.com], porting some of their legacy in-house data acquisition and reporting software at one of their U.S. factories from 16-bit to 32-bit. They were all Visual Studio projects under Microsoft's Windows. Even though I had their source, and I was going from an older version of Visual Studio to a newer one, the project was not trivial.
(Score: 0) by Anonymous Coward on Friday January 22 2016, @03:37PM
But what is unique to proprietary software is that it does not respect your freedoms. Want to make some changes to the software yourself, or hire some independent third party to do so? Too bad; you're a slave to the developers of the proprietary software. Not only that, but slimy companies like Microsoft often intentionally make their software incompatible with other, similar software so as to increase the costs of someone moving to competitors. Their software is inherently and intentionally defective. You don't find that with Free Software.
(Score: 2, Informative) by Anonymous Coward on Saturday January 23 2016, @05:12AM
But both gcc and glibc were intentionally broken multiple times in order to avoid leaving stable interfaces proprietary software could use to hook into the toolchain, while still claiming it didn't fall under the GPL.
It should be trivial to google and find the supporting links. But it was a major problem for pre-millenium linux development outside of the linux specific moving targets of that era, and was considered a major hurdle to wider adoption of gcc as a backend to other compiler frontends, outside of the normal GPL restrictions (since it had made even GPLed developments non-trivial to implement.) It is also part of the reason for the massive code generation incompatibilities between versions, since unnecessary changes were being made that broke things in subtle ways.
LLVM's popularity combined with the switch to C++ is only going to make things worse, as well.