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, Insightful) by tftp on Tuesday April 26 2016, @01:06AM
I used to make some drivers by reverse-engineering the USB protocol of proprietary devices. This is a dead end, and I do not recommend anyone to do the same. First of all, you have no idea what those registers in the device are doing. You may be voiding the warranty, or causing damage by overloading circuits in the hardware by incorrect programming of FSM knows what bits. Early versions of SANE used to do pretty bad things to scanners - causing mechanical resonance, for example, by running the stepper motor at a certain frequency. The original software was smooth as silk... on Windows.
Secondly, there is such thing as firmware upgrades... sometimes they are really necessary... and they can break your so carefully reverse-engineered protocol. The proprietary driver may be upgraded, or even come with enough smarts to understand the new protocol on the fly. Your driver only knows about the device that you personally had in your possession during the work. The device does not benefit from upgrades of the driver that are pushed out by the OEM. It is common that there are many - sometimes, tens - revisions of hardware and software. It is challenging even for the OEM to herd all those cats. You, as a 3rd party with no knowledge of the issues, have no chance.
Naturally, the last thing the F/OSS community wants is a frantic 3 AM call from the department of education in some faraway country, claiming that the white boards suddenly failed in all their 30,000 schools. What do you do if that happens? Start the rev-eng all over again? How much time will that take? How much money? How much use will be lost to the end users who need those white boards to work? How are they going to teach without them if the process is tied to them - say, if every student receives a PDF with everything that was written on the board in class?
(Score: 3, Interesting) by Whoever on Tuesday April 26 2016, @01:41AM
At least one whiteboard manufacturer supports Linux. Their software is written in Java and runs on Ubuntu at least.
Purchase decisions need to take this into account. It's not just an issue of support for Linux: what happens when the manufacturer decides that it doesn't want to support that older version of Windows?
(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.
(Score: 2) by Demose on Tuesday April 26 2016, @01:45AM
Good point. I suppose I'll have to make my own after my current project is complete.