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."

9 of 92 comments (clear)

  1. Feh by Anonymous Coward · · Score: 4, Funny

    I don't believe they really wintend to

  2. Re:EDOS? by mattjb0010 · · Score: 3, Informative

    Please don't tell me that it's funded my Microsoft...

    Bill Gates? That you? On a more serious note, an EU judge has upheld penalties against Microsoft.

  3. Organised? by areve · · Score: 4, Insightful

    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.

  4. Worst acronym EVER? by Anonymous Coward · · Score: 3, Insightful

    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".

    1. Re:Worst acronym EVER? by lumumba · · Score: 4, Informative

      I'm guessing that's because the original acronym is in French. It's Environnement pour le Développement et la distribution de logiciels Open Source, which makes a lot more sense.

  5. how about language-agnostic dependency checks by museumpeace · · Score: 3, Insightful

    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.
  6. bandwagon by jeif1k · · Score: 4, Informative

    Roberto Di Cosmo of University of Paris 7 claims that theoretical computer science is particularly strong in France and that its formal methods can be used to manage complex dependencies to create an "integrated, coherent whole."

    In different words, people in France are jumping onto the open source bandwagon in order to squeeze out another few years of funding for the same old stuff they have already been doing for 30 years.

    If you want to read more about formal methods, look here and here. You can judge for yourself how much relevance you think this is going to have for FOSS. I think its chances are close to nil.

  7. Re:Wow by B3ryllium · · Score: 3, Funny

    Obviously you weren't around for the HTTP-Server-Running-On-A-Potato post.

    Mmm, baked potato.

  8. Re:junk science by jeif1k · · Score: 3, Insightful

    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.