berenger.morel@neutralite.org wrote:
That's why some professions have needs for legal stuff. We can not really compare a doctor with the usual computer scientist, right? And I said "usual", because most of us do not, and will never work, on stuff which can kill someone. And when we do, verification processes are quite important ( I hope, at least! ), unlike for doctors which have to be careful while they are doing their job, because they can not try things and then copy/paste on a real human.Actually, I would make that comparison. A doctor's mistakes kill one person at a time. In a lot of situations, mis-behaving software can cause 100s, 1000s, maybe 100s of 1000s of lives - airplane crash, power outage, bug in a piece of medical equiptment (say a class of pacemakers), flaws in equipment as a result of faulty design software, failure in a weapons system, etc. Software failures can also cause huge financial losses - ranging from spacecraft that go off course (remember the case a few years ago where someone used meters instead of feet, or vice versa in some critical navigational calculation?), to outages of stock exchanges (a week or so ago), and so forth.But doctor's can not take as much time as he would want, and can not be helped by as many people as us. We can simply open our source code, and we can be reviewed by lot of pairs. We can also set-up automated tests, to ensure that we are not doing stupid things.
Maybe. The thing is, most mission-critical, safety-critical, and life-critical software is written by commerial firms, and often under government contract. Between deadline and budget pressure, proprietary considerations, and sometimes security classification - the changes are that the stuff that must work best, is NOT being done as open source or with particular transparency. At best, we can hope for serious design reviews and testing - not always the case.
Which takes us back to a pretty good case for professional licensing and review - of the sort applied to doctors, civil engineers, architects, and so on.
What I see in some of your samples is a lack of testing. It is obvious that if you do not take enough time to made quality, you will never have it, and if software programming can kill people, then even bakery can do.
Part of the reason for outside licensing and regulation is that this creates a separate set of checks-and-balances outside of the project management chain that's driven more by deadlines and budget pressures (at least until an airplane crashes and the lawsuites ensue).
Imagine what would happen if your baker did not paid enough attention and used some cleaning liquid instead of water? That could kill, but I hope they take their job seriously enough. Oh, I said baker, but it is true for all kind of works. Building houses, creating cars, etc. Will you compare those to the doctor's job?
Well, there are safety and sanitary codes applied to food preparation facilities, at least here in the US. Sushi chefs who prepare fugu (blowfish) are tightly regulated in Japan. Heck, in the US, barbers are licensed - probably not a bad thing for folks who might literally hold a knife to one's throat.
Especially on the feet/meter problem (one that I would not have thought about I admit, since we only use units from SI - strange, is it true that the French acronym is used? Wikipedia says it, but it seems really strange to me - in France, since many decades, so I tend to forgot that other countries can have that problem :/ ). Converting units is not hard, and in strong typed languages, such error could never happen if correct types have been defined.
Which kind of brings us back to what standards get applied to the people who write code, the platforms it gets written on, and the review and testing processes applied.
<collapsing this discussion just a bit>
But when it comes to packaging up software for delivery to users/customers; it sure seems like it's easier to install something on Windows or a Mac than anything else. Slip in the installation CD and click start.You mean, something like that ? http://packages.debian.org/fr/squeeze/gdebi http://packages.debian.org/fr/wheezy/gdebiSeems to be that there's a huge difference between: - buy a laptop pre-loaded with Windows,Pre-loaded, so you did not made the install. You can not use that to say that the install is easier: you did not made it. Plus, it is possible to buy computers with a linux distribution installed on it.That's exactly what allows GDebi, installed by default by the gnome package, which is the default DE for Debian.and slip in an MS Office DVD, and- buy a laptop, download debian onto a DVD, run the installer,Unrelated. There are computers sold with Debian.I never bought any, but I would bet that they have all necessary drivers installed. Including non-free ones.get all the non-free drivers installed,Actually, I have seen lot of computers with windows not having MS office installed by default.then apt-get install openofficeThat's useless. For a lambda user, he will only install, and never care about the recommended stuff. The difference here against windows is, that you can trust the Debian repo to not having malwares installed with them. Plus, you won't have to enter *any* security key. Those are a real pain... and are very common on Windows' softwares.and wade through all the recommended and suggested optional packages -
"Lambda user?" What's that?In any case, the major point here is that Windows is a popular development environment, particularly for commercial software, because that's what's on desktops; and it's on desktops because it's easy - it comes preinstalled on everything (yes, you can Linux installed on some machines, but you have to go searching, and they're probably not the ones on a typical office desktop).
and then, maybe, have to deal with issues around which JRE you have installed?I do not know, I never install Java. Are there really lot of issues with JRE, or is it simply fud?
Well... if you're running open office, you need to have a JRE installed.As to issues, yes - some things run just fine on various JREs, others are particularly finnicky about running on the Sun/Oracle platform.
Re. open office, the release notes say:The Java Runtime Environment (JRE) 1.5.x, is the minimum version required to use full Apache OpenOffice functions that need Java. (see Java and Apache OpenOffice <http://www.openoffice.org/download/common/java.html>.) However, we strongly recommend the last version of Oracle Java 1.6.x, patch level 45, or the latest Oracle Java 7, or, for Linux users, OpenJDK 6, build 27, or OpenJDK 7.
Ok... what is an average user to make of that?
I will not even speak about the fact that selling only computers with MS-Windows pre-installed is illegal in France ( to be more exact, it is illegal to sell hardware stuff and force the client to buy services, and software licences are considered services here. ), but MS just do not care about our laws. I have nothing against windows, but I really dislike MS for their law disdain. I have nothing against the technical product, really. It's only their attitude that I hate.Oh, and if I did not mentioned wine, it is because I do not think it is very relevant, but I could argue that it makes things as "simple" as on windows ;)Just for reference, I use a Mac and mostly commercial software for office kinds of stuffNever used any mac, can't judge. I do not really intend to buy one anyway, they are far too expensive for what they do, and more closed than windows. Do not fit my needs, in short.
Heck no. Macs are basically BSD unix underneath, and they support multiple virtual environments. I run all KINDS of stuff on my MacBook - native Mac applications, native BSD applications, Windows and Linux code in virtual machines - pretty much the most flexible platform around.
I will note, that for a lot of server-side stuff (particularly my mail processing and list manager) I find I get much better results (and newer code) by compiling from source, than by using the package system.Maybe you should take a look at gentoo, then. If you use official repos of softwares, use an OS made to compile every softwares you have. I think I'll take time to install it one day, when I'll finally be successful in understanding how to compile an efficient kernel. Not tomorrow...
Tried it. Too much trouble, and too slow. On Debian, I load the binaries of all the standard stuff, then build trickier stuff from source. Also, I kind of question the gentoo approach - why package source code in the gentoo ports library, instead of pulling a tarball from upstream and ./configure; make install.
Miles -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra