Slashdot Mirror
EU-Funded EDOS To Simplify Open Source Development
An anonymous reader writes "a consortium of European research institutions and open source software companies have paired up to manage the complexity of large scale, modular projects by establishing a program called EDOS, Environment for the Development and Distribution of Free Software. Planners intend to move away from centralized builds and storage to a distributed process, form a language-agnostic bug testing system and turn to theoretical computer science to safeguard dependencies."
All they'll end up with is EDOS Linux, yet another distibution with it's own cultish following. We already have organisation. Debian. 3.4 million euros for the open source community will be nice though, it may pay some of the court costs for patent claims.
Environment for the Development and Distribution of Free Software
The fact that they got EDOS from that name boggles my mind. This acronym business is entirely out of hand, and this is the stupidest one by far, ignoring a proper noun and an adjective but including "of".
while they are at it. I have a job to turn a pile of ada into a compiling set of c++. I can just build and sort through the error messages to find out which WITH'ed or #INCLUDE'd files are missing or broken but its turned out faster to write a cascade of filters in AWK which build a report of dependencies as an HTML page. Any module is listed and each module referenced goes into a sublist. It generates anchors and HREFs to lead the way around the dependency tree and color codes the module names according to the availability of the module.
I hope they come up with a less confusing metaphore than Clear Case when they design the version control GUI.
The larger the development project, the more likely it has to incorporate reused code and code in more than one language so here's my salute to their good intentions...and good luck!
[they will need more than language neutrality: they need archtectural neutrality to encompass OO languages alongside scripting languages and procedural languages. and what about languages that support templating?]
SLASHDOT: news for people who can't concentrate on work or have no life at all and got tired of yelling back at the TV.
now, there's a perfect example of a solution in search of a problem. and, if that's not enough for you, it seems its also designed by comittee. good god. well, lets wait and see. somehow I can't help but think it will use Z, that dream in formality that is a nightmare to anyone who actually tries to do something useful with it.
... i suppose this is one of the greatest things about open source: if someone comes up with the strangest idea, one that no one else thinks is even remotely useful, well, she|he gets to have a go and try it without wasting anyone else's time. can you imagine if this was a company or a research lab: "linus, old chap, can you stop faffing around with that kernel crap and come and do some Z with us."
call me a cynic...
soup
"Environment for the Development and Distribution of Free Software" Sourceforge.
See our Freenix 2002 paper for one example of applying formal methods to open source development. Worked great for us!
Hm, isn't this actually a proof that the system _works_: a distributed revission control system is meant exactly to ease forks and remerges of projects, so if the RCS itself has a tendency to fork and remerge, it is a _good_ sign, as long as the use their own RCS to version control the RCS source (as does Arch and most others :)... Kind of fluffy meta-abstract feeling, isn't it?
.arch-ids-directories within {arch} in the checked-out-copy. The last would force you to use 'tla move' even on directories, but that is a small price to pay not to constantly walk all over the id-files with find/grep/sed when you do magical things...
By the way, Arch rocks, except from three things: Its UI is constantly changing, it does not have completion of category/branch/version/patch names, so you have to write the whole thing all the time, and it should have put all the
--The knowledge that you are an idiot, is what distinguishes you from one.
I also regret that space constraints precluded much of the reporting that you would have liked to have seen. Much of it was presented at the talk, but that is indeed insufficient.
I don't think that's the problem. You could have written a paper trying to demonstrate the utility of "formal methods" using Z. In that case, you could have left out most of the details about XCB, giving you more than enough room to talk about experimental design and controls. But you didn't. Instead, you did, as you say, present a case study of applying Z to a particular problem. That may serve as a useful tutorial on Z or XCB, it may convince people that XCB is correct, but it tells the reader nothing about whether using "formal methods" actually leads to improvements in software development.
You may have noticed the part where we described the paper as a "case study". I don't claim that we proved anything too generalizable with this work, although there are many such case studies in the literature that reach similar conclusions.
But (effectively) saying "this is anecdotal evidence" in the introduction to a paper doesn't remove the criticism. "Case studies" of the kind you presented are useful for people to understand how something works, but not as evidence that something works better than something else. Yet, you have been trying to use it as the latter.
but subjectively I solved a problem using Z that I and two other smart people working together hadn't solved without it even given a lot of effort. I'll mark this one in the success column.
But the "formal methods" community claims that their methods lead to objective improvements in software development (cheaper, more robust, etc.). Either the "formal methods" community needs to support those claims or it needs to drop them.
What is particularly bad about the use of the term "formal methods" is that the term suggests that it comprises all well-founded methods for reasoning about software and software reliability, but that is clearly not the case.
I think that this is somewhat orthogonal from the "behavioral science" approach you seem to be advocating
I'm not advocating a behavioral science approach. I'm saying that if you choose to make behavioral science claims, then you have to support those claims adequately using the scientific methodologies generally accepted in support of claims. And the claim that the use of formal methods by software developers may lead to higher quality software and/or lower development costs is a behavioral science claim, no matter how much mathematical notation it involves.