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."
I don't believe they really wintend to
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.
.: Max Romantschuk
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.
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.
*is run over by rotten tomatoes*
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.
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!
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
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.
You should use a less noisy line for you internet access. :-)
The Tao of math: The numbers you can count are not the real numbers.
"Environment for the Development and Distribution of Free Software" Sourceforge.
I read the fucking article. You are correct; I was wrong.
Did anybody else read the title and think they were going to devellop an alternative to MSDOS?
10 ?"Hello World" life was simple then
Obviously you weren't around for the HTTP-Server-Running-On-A-Potato post.
Mmm, baked potato.
See our Freenix 2002 paper for one example of applying formal methods to open source development. Worked great for us!
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 formal methods approach only after failing with most of the approaches you suggested. UML had nothing obvious to offer (according to my UML-skilled friends). The problem was a design problem: meditating over source code wasn't obviously helpful except to discover that a given design was flawed by observing it in the implementation. We were constrained to C in a POSIX environment, which was really at the heart of the problem, so changing languages or platforms wasn't possible. I was certainly paired with someone throughout the whole development process: sometimes an implementor, sometimes a formal-methods guy.
The effort the formal spec took us was about 4 weeks, most of it by me. The key insight actually only took a few days, the rest was just careful checking for other problems. Once we discovered our requirements were inconsistent, it took us another week or so to come up with relaxed requirements and a design that met them.
Ultimately, keep in mind that we applied formal methods to the problem only after failing multiple times to get a correct implementation using more conventional open source methods. You can quibble about whether it's science or not ("Computer Science : Science :: Plumbing : Hydrodynamics" --Strachey), 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.
As for your more general comments about Computer Science, let me observe that CS is pretty much the only science or engineering discipline without any generally-accepted formal descriptive and analytic notation. I'm using Z for this on occasion, and finding that I like it a lot: it helps me to clearly, succinctly, and unambiguously specify all sorts of things. I think that this is somewhat orthogonal from the "behavioral science" approach you seem to be advocating, but I think it is a legitimate need of the discipline. Your mileage, as always, may vary.
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.
Somehow the analogy seems apt. Tunes is a decade old and still has not gotten anywhere. Although the tunes survey subproject has at times been interesting, and was a good resource before wikipedia came along.
With a little luck the EDOS project will be more grounded and a little more down to earh.
Hmm. The more I think about it this looks like a funding hack by mandrake to get other organizations to help them build and test their distribution. Most of the things they were complaining about did not sound fundamental to open source development but did sound a lot like problems a distribution vendor would have.
I guess time will tell if this is a cool practical hack that supports mandrake. Or some academic proof of concept project that is generally useless for getting things done.