SoylentNews is people
SoylentNews
The European Union's interoperability page reports
The primary school in Saint Léger en Yvelines (France) has nearly completely switched to using free software reports the village's deputy mayor Olivier Guillard. "Do not underestimate the task", he advises others on the forum of Etalab, France's open government portal, "and, most of all, persist".
Saint Léger en Yvelines is a commune some 50 km west of Paris. The village has one school, with 6 classes, and includes pre-school. The Jean Moulin school is attended by all of the around 30 children in the commune up to the age of 11. On [April 15], deputy mayor Guillard published his recommendations for others that want to "free their schools from the commercial agenda of proprietary software vendors". Free software is unhindered by the constraint of financial profitability, he argues: there is no planned obsolescence and no lock-in to specific hardware.
Olivier Guillard urges rigorous testing of solutions before suggesting them to teachers. Just as important is to convince the teachers of the benefits of free software. He also recommends being proactive on maintenance and monitoring.
He cautions patience. The school's transition to free software took years, he writes. "Seven years of convincing. Seven years to find free software alternatives for each new commercial offering. Seven years of creating a dialogue and building communication channels with teachers dedicated to digitisation of education."
The school has not rid itself of proprietary software completely. Whiteboard solutions and office documents exchanged in France's education sector forces teachers to use proprietary software, for which the school keeps apart two PCs with proprietary office tools, the deputy mayor writes.
Blogger, Linux advocate, and retired 1-man school IT staff Robert Pogson has a short (two paragraph) post. [It offers several open-source software alternatives as well as hardware recommendations — fair use precludes including the whole post here. -Ed.]
(Score: 2) by bitstream on Tuesday April 26 2016, @01:43AM
After some time of usage. The functionality can be observed, and if it works for some time. It's likely to continue to do so. Firmware upgrades can be refused. And if register fuckup is a concern, then the supplier can supply proper documentation.
If 30 000 units are used, the cost of RE can be spread across all devices and some person can be dedicated to this task.
Now suppose some FOSS server with a database, middleware talks via the network to whiteboards. Upgrades and security can be kept under control. However if a proprietary driver needs to be used , then perhaps you need to add a powerful local PC with a specific OS version that can't be upgraded due to security because then said driver will not work and it needs constant updates, that someone (person=$$) will need to keep an eye on. This one will then need to talk to some proprietary middleware that only talk to database X v5.0 that will only run under OS v8.2 etc and the dependency hell can run with it. And whenever a major version upgrade comes, the school will need to rewrite any custom software from the ground, again. Because APIs are changed without a rational reason.
(Score: 4, Insightful) by tftp on Tuesday April 26 2016, @02:17AM
After some time of usage. The functionality can be observed, and if it works for some time. It's likely to continue to do so. Firmware upgrades can be refused.
You can do that. What you can't do, however, is you cannot buy a new device as a replacement for the old, broken one. From the POV of the OEM it's the same device, as their driver accommodates all the differences in hardware and firmware. From your POV it's a completely new device that may not work at all (if you are lucky), or may fail intermittently (if you are not so lucky.) Frequently the order of register writes matter, as certain commands affect the other - say, by resetting things. Less frequently, but still annoyingly often, there must be a mandatory timeout between commands. Look at the datasheet of any parallel LCD for a quick example. In my experience I came across quite a few weird things. In the end I solved almost all of them, but not quite. Complex, proprietary data encoding and compression is one popular difficulty. The OEMs are unwilling to tell you how they do compression - perhaps, because they forgot to pay royalties on a patent or two? Who knows; it's all obfuscated.
if a proprietary driver needs to be used , then perhaps you need to add a powerful local PC with a specific OS version
It may be cheaper this way, considering that this is a supported configuration, and if something does not work you can call the OEM and request assistance; and you will get it. The important issue here is a known path to the solution - known both in "how to" and in "how long will it take". A homegrown approach does not come with these. The device stopped working, you call the OEM, but they tell you to run a Windows diagnostic utility that talks to their driver. You don't have a Windows driver. Now what?
One of less apparent paradoxes here is that the hardware is cheap, fixed cost, and one-time expense. Humans are not cheap at all, their costs grow with time spent on solving your problem, and you need to pay them whenever you have a problem. Remember all that talk from Microsoft about TCO? Well, that's one part of it.
And whenever a major version upgrade comes, the school will need to rewrite any custom software from the ground, again. Because APIs are changed without a rational reason.
As opposed to having no major upgrades? It depends on whether you need that upgrade or not. Quite a few upgrades these days are increasing the capabilities of the device - say, increasing accuracy of the scanner or of the touch surface, or reducing power consumption... this is because many devices are now made with MCUs and FPGAs and similar programmable hardware. They release the driver 1.0, and it works, they start selling... and in parallel they continue development, adding functions that they had no time to implement earlier, or fixing hardware bugs, or generally improving things. All that is contained in the binary blobs that they program into the hardware, and in the drivers that they support. Your best bet, as other people already mentioned, is to demand that they support your choice of the OS and provide the driver. As matter of fact, you simply do not deploy 30,000 instances of anything on unsupported platforms.