Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Software GNU is Not Unix Technology

EU-Funded EDOS To Simplify Open Source Development 92

Posted by timothy from the worthy-cause dept.
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."
This discussion has been archived. No new comments can be posted.

EU-Funded EDOS To Simplify Open Source Development More

EU-Funded EDOS To Simplify Open Source Development

Comments Filter:

  • EDOS? (Score:1, Funny)

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

  • Feh (Score:4, Funny)

    by Anonymous Coward on Wednesday December 22, 2004 @08:09AM (#11157334)
    I don't believe they really wintend to

  • Efficiency? (Score:3, Interesting)

    by Max Romantschuk ( 132276 ) <max@romantschuk.fi> on Wednesday December 22, 2004 @08:11AM (#11157337) Homepage
    It sounds like a good idea, and we all know that options and diversity is what open source and free software is all about. I just hope that they don't pour heaps of cash into something which gets bogged down by bureaucracy. The EU track record isn't exactly stellar in that regard.
    • I agree. Its goog to see they are focussing on accomodating many languages. I think this link is a little better though

      ... [mandrakesoft.com]

      "As the amount of Open Source software grows, so does the problem of complexity." Ahhh, the days of theoretical computer science - big O notation bah blah blah...

    • I just hope that they don't pour heaps of cash into something which gets bogged down by bureaucracy.

      Too late. Formal methods are effectively the mathematical equivalent of the EU bureaucracy for software development. :-)

  • Proofreading (Score:1, Offtopic)

    by Xetrov ( 267777 )
    Is it really too much to ask for timothy et al to actually proofread everything before they post it?

  • EDOS? (Score:2, Funny)

    by quamaretto ( 666270 )

    When I first looked at the article, I was thinking "European Disk Operating System. Jesus, those Europeans have to have everything their own way. What next, AntarctiVMS?"

    So, I suppose I should RTFA now out of respect for the poster. Heh. Heh heh.

  • Wonder if they mean to promote distributed revctl (Score:3, Informative)

    by cduffy ( 652 ) <charles+slashdot@dyfis.net> on Wednesday December 22, 2004 @08:27AM (#11157376)
    IMNSHO, distributed revision control is something long past-due for wider adoption... be nice to see it used outside of Linus's BitKeeper adoption and the (reasonably large number of) projects using Arch [sourcecontrol.net].

    The impact of distributed revision control is that someone doesn't need to be trusted with commit access to a repository owned by the maintainers to do revision-controlled work -- instead, they just make a branch inside an archive they control, and changes can be merged back and forth between that one, the "official" branch, and/or any other 3rd-party branches at-will. As a casual contributor to a large number of projects, I find this extremely useful -- I have my own revision-controlled archive containing only my changes, and I don't need to get the trust and/or approval of the project maintainers before getting started.

    Personally, I like Arch, but it's not the only game in town -- Darcs, Monotone and SVK are all in the same problem space (within the Free camp), as well as BitKeeper (in the proprietary camp). I'd like to think that this is what these folks mean by distributed storage (as the revision control archive doesn't necessarily sit all in one place) -- the concept needs all the exposure I can get, so I don't need to go the $#%@ pain of maintaining my own branches (w/o assistance from my revision control tools) again!
    • I have seen several forks of the project. I keep thinking there must be something not quite right with it if people keep forking it.

      Maybe you could shed some light on this.
      • 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?

        By the way, Arch rocks, except from three things: Its UI is constantly changing, it does not have completion of category/branch/ve
        • a small price to pay not to constantly walk all over the id-files with find/grep/sed when you do magical things...

          Replacing find with "tla inventory" works in the common cases, I find -- and baz's patching up "add" to ignore the user's requests when it's told to do something stupid likewise helps with some of the more common (find . | xargs tla add) goofs.

          It's not just about needing to use "tla mv" on moving directories -- you'd also have to use "tla rm" on deleting them, and would otherwise be a mess. A
          • I do use tla inventory for most things. However, there are some problems with this approach. First,
            'tla inventory | while read name; do grep -H -e expression "$name"; done' is a bit clumsier than just 'grep -r -e expression', but that can be solved with some macros :) Second, and worse, is that I both like to include all the Arch-specific dirs and info in distribution tgz:s so that people can easily import that directly into their repo, and I do have some build-scripts that needs to traverse the tree in som
      • Heh. As far as forks go, there's Landry's "arx", which basically came about because of a falling out between Tom and a fellow who was trying to take partial mantainership duties for him, and Canonical's "baz", which is a basically friendly fork intended to experiment with making UI improvements; any changes they make that the community likes will (in theory) get folded back into tla 1.x, and perhaps used as food-for-thought for tla2 (which is a complete rewrite).

        larch and tla are both Tom's; larch was once

  • Organised? (Score:4, Insightful)

    by areve ( 724106 ) on Wednesday December 22, 2004 @08:31AM (#11157386)
    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.

  • Worst acronym EVER? (Score:3, Insightful)

    by Anonymous Coward on Wednesday December 22, 2004 @08:31AM (#11157389)
    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".

  • how about language-agnostic dependency checks (Score:4, Insightful)

    by museumpeace ( 735109 ) on Wednesday December 22, 2004 @08:34AM (#11157394) Journal
    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?]

  • oh my god... (Score:2, Insightful)

    by marco_craveiro ( 551065 )
    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 [zuser.org], 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 ge
    • 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.
      Yup. In this case the only thing being wasted is 2 million Euros of other people's money.

      The words "tonneau" and "porc" spring to mind.

  • bandwagon (Score:5, Informative)

    by jeif1k ( 809151 ) on Wednesday December 22, 2004 @09:00AM (#11157472)
    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 [fmeurope.org] and here [fmnet.info]. 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.

    • Re:bandwagon (Score:2, Informative)

      by lumumba ( 837749 )
      I might be mistaken, but basically what you're saying is that computer programmers should discard computer science methods as irrelevant? Including things like graphs and sorting algorithms, for example (which are studied using formal methods by computer scientists)? As for di Cosmo, maybe you should have a look at the "Free Software" page on his web site :
      http://www.dicosmo.org/ [dicosmo.org]. This guy actually writes stuff that's *useful*.
      • I might be mistaken, but basically what you're saying is that computer programmers should discard computer science methods as irrelevant? Including things like graphs and sorting algorithms, for example (which are studied using formal methods by computer scientists)?

        Yes, you are mistaken. I'm all for the formal analysis of things like graphs and sorting algorithms, but that kind of analysis has little to do with "formal methods" as used by these people. "Formal methods", as used by these people, refer

        • See our Freenix 2002 paper [usenix.org] for one example of applying formal methods to open source development. Worked great for us!

          • Worked great for us!

            Yes, and if you had used UML, code reviews, pair programming, a different programming language, or merely meditated over a copy of the source code for the same amount of time, it might have "worked" even better. We'll never know because you didn't do a controlled experiment. You didn't even quantify the effort it took you or validate the actual implementation, so we don't even have any data about what you did.

            Supporting an approach to software development with anecdotal reports like

            • Re:junk science (Score:3, Informative)

              by po8 ( 187055 )

              Wow, you read our paper quite quickly. Impressive. 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.

              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. My apologies.

              We resorted to the f

              • Re:junk science (Score:4, Insightful)

                by jeif1k ( 809151 ) on Wednesday December 22, 2004 @05:12PM (#11162429)
                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.

                • Sounds like you and I are in more agreement than I originally would have thought.

                  My co-author and I chose to write up the Z and XCB work as a case study, for understanding Z, XCB, and how a formal method could be applied in a lightweight way to open source development. If there had been more room, we would have also included more material describing the development process and the effectiveness of the methodology.

                  One point of disagreement: you write that "'Case studies' of the kind you presented are usef

                  • I have argued, and still believe, that formal methods, specifically Z notation and formal reasoning, were in absolute terms useful to me in solving a particular open source development problem. I agree that any stronger claim is unjustified by our publication.

                    OK, if you put it that way, I think we can agree on that.

                    It is hard to imagine physicists, for example, arguing that calculus of variations needs behavioral studies to discover whether it is a more efficient method of solving problems in physics th
  • a consortium of European research institutions and open source software companies have paired up

    If a total of 10 institutions (yes, I read TFA) "pair up", that means they divide into 5 groups. I know it would be way too much to expect timothy to actually come up with his own words, as opposed to pasting from the article, so I guess this commentary is directed at the original author.

    • All software born out of the effort will be licensed as open source.

      Normally I would attribute minor errors such as these to having a bad day, but this guy needs an editor. You'd expect more from someone who gets paid for their ramblings, as opposed to us slashdotters who nitpick for free ;)

  • obvious (Score:2, Insightful)

    by blackomegax ( 807080 )
    "Environment for the Development and Distribution of Free Software" Sourceforge.

  • oh my god!!! (Score:3, Funny)

    by spectrokid ( 660550 ) on Wednesday December 22, 2004 @10:52AM (#11158246) Homepage
    Did anybody else read the title and think they were going to devellop an alternative to MSDOS?
  • Woa, did anyone else read this and immediatly think of the Tunes project, possibly because they were browsing the site in another window? :) A distributed modular system and a possibility for automated testing by specification is exactly one of the aspects they see required for their hypothesized 'ideal' operating system. Check this link for a brief overview. These guys also mostly come from France and a theoretical computer science background.
  • guess they are not serious about...

    Physics of Abstraction (abstraction physics)

    Abstraction enters the picture of computing with the representation of physical transistor switch positions of ON '1' and OFF '0' or what we call "Binary" notation. However, computers have far more transistor switches in them than we can keep up with in such a low level or first order abstract manner, so we create higher level abstractions in order to increase our productivity in programming computers. From Machine language to

Slashdot Top Deals

HELP!!!! I'm being held prisoner in /usr/games/lib!

Close