Slashdot Mirror
Open-Source Component Repository?
The following was submitted by Aiken:
Premises
- Companies that do extensive programming develop their own software libraries... binary trees, networking code, graphics routines, things that need to be done in all sorts of programs.
- While the open-source community has developed excellent tools (emacs, ecgs, etc.) to do their programming on, we have not developed such components.
- A critical issue facing open-source developers is how to find other developers who will contribute to their project.
- Having access to well-tested and proven components such as these could greatly decrease development and testing time needed for other software.
Conclusion
The development of a central GPL'd component repository would be an asset to the open-source community.
Elaboration
Consider the Standard Template Library. Linked lists, stacks, queues, and the like can all be used without having to write them from scratch and debug them. This saves time and improves readability, since they follow a common syntax and have common operators.
The open-source community is not bound by restrictions held on the standard library. We can write code that deals with networking and image formats that are commonly used, regardless of whether or not they are in the standard.
Generating repositories of these components would allow casual programmers to dip into a vast resource base. Instead of spending their limited time finding other programmers to help out, they could simply take and use the code that was already written for them. Rather than create a subroutine for a single program, you would create a component which could be used in hundreds of programs by developers you didn't know existed.
Issues to Consider
Just some kinks in the idea that I can see needing to be worked out:
- How to ensure that components are GPL'd... e.g. that some student's university doesn't want to claim credit for the code they wrote
- How to ensure quality code and documentation
- Who should run the repositories
- What components to provide
Thoughts? aiken@quakemail.com.
The various libraries gnome uses?
The CPAN PERL modules.
MiscKit. gnustep.
To name a few off the top of my head.
There is such a repository, it's the internet.
Networks Never Lie
It's like the Giant Java Tree... I don't see any reason why it would be a bad idea. The worst that could happen is that a few projects get a new home.
æeee!
Freshmeat is a references repository where you find the links to each project's home page and download places, but (as Murphy said) when you find in Freshmeat the app you need the most, the ftp server where the app is suposed to reside is offline and the project's home page is offline also. You then just end with a bunch of useless references.
The need is for a central FTP repository (with enough mirrors) where every project leader should upload every project's release.
Then Freshmeat should have the reference to the project's home and to the directory in the repository where you can get the sources.
--
Perl has just such a thing (as I'm sure most of you know) - CPAN, the Comprehensive Perl Archive Network. I've done Perl development from time to time and I've often found very useful things in CPAN which I could directly apply to my work.
I program primarily in C and have never seen the C CPAN equivalent... I would love to see a widely mirrored repository of reusable C code.
As far as quality goes, CPAN seems to be of very good quality... I have no idea how submissions are handled, but I assume there's some sort of acceptance process. If it's all self-regulated I'm impressed.
/* The beatings will continue until morale improves. */
A new site perhaps? GPLStuff.com?
-----------
"You can't shake the Devil's hand and say you're only kidding."
It seems to me that this *has* been done before, with much success. I'm referring to the Comprehensive Perl Archive Network.
CPAN enables the Perl programmer to not re-invent the wheel one more time. I'm sure that most of the people here are aware of it (being that there seem to be a lot of Perl bigots here).
I think that something similar could be set up for C/C++ code, but I'm not volunteering! =)
I don't really know if freshmeat is the right location for something like it, but that's purely subjective.
This sounds like a great idea. There's numerous time's I've had to 'fix' someone else's program, and lots of the routines are just 'hacks' which barely do their job... If instead of
each programmer hacking together a barely-working, spagetthi-code routine to read x or y format, they could use a standard, well-tested library... This would greatly help
the problem of many linux programs being less than bug-free, and would add to their maintainability. This sounds like something open-source programmers should *definitely* embrace.
Proud Coward, too lazy to create an account...
If it's going to be GPL'd only components, then the majority of Open Source licenses will not be able to use any of them. So why call it Open Source? Why not simply "The GPL Component Repository" instead?
Far be it for me to tell the repository maintainers which components they can or cannot accept, but I think if they were a bit more flexible, and allowed at least LGPL components, then it would be much more useful for the Open Source community. I think the freshmeat method of listing which license a component is under would be even better. Then we could have GPL'd, LGPL'd, BSD'd, AL'd, MPL'd, etc, components, and a developer could choose which component best met their needs.
A Government Is a Body of People, Usually Notably Ungoverned
The General Public Virus is all very well for something like Linux, where the only thing you are likely to derive from the existing codebase is -- another Linux. Components are meant to be generic and widely-usable by their very nature. Will putting them under GPL mean that they infect the code that utilises them? That is the GPL's intent. This will make such components unusable not only in proprietary software, but also in BSD-licensed software (and public domain software for that matter). Such a severe limitation is counterproductive, in my estimation, and will probably limit the potential success (measured in terms of active users and contributors) such a project might otherwise enjoy.
I would therefore suggest that the LGPL be used in preference to the GPL, if one insists on a GNU-derived license.
proof, n. A demonstration that a conclusion is implied by certain premises and axioms.
Well, I've had a similar idea to this. Such a site could be used as well as a central repository not only to software components, but also to open sourced projects as a whole. Also, it could serve as a place for people to start when looking for information and for the people who are in charge of certain things. I've done a fair bit of thinking and have already started some preliminary work on such a project. I'd LOVE some help/to help someone else out who might be further along than I :) email me :) johnston@itactics.com and i'll get back to u ASAP
The next big thing is documentation. Some sort of XML standard for code and project and app documentation (separate, of course, but related), would be just dandy for everything. Relating everything ala one standard is what makes things work in nifty ways.
And a centralized source would be great. ie. something to Linux what CPAN is to Perl. That'd be a *huge* repository, difficult to update, on ultra-fast servers. That makes things very difficult to find as well. (See microsoft.com)
These things are difficult to implement without a given infrastructure. Without said infrastructure available to everyone, and used ubiquitously, things will probably centralize around companies such as Caldera, Red Hat, Corel, et al. The only difference is that, instead of a centralized repetoire of Linux software, it's distributed (perhaps with lots of overlap) between companies. That might be a good thing, though, as there is no central point of failure, and it is a competitive system.
My wish list. :)
IIRC, they're still on the web (though not as comprehensive as I remember them). http://www.brokersys.com/snippets/
they'd be a good start for something, in any case. There are lots of goodies (though some really old, irrelevant stuff too) in there.
Then I realized that I could in fact use such a repository after all. Lately I've been thinking about looking into writing device drivers. I've never done such a thing before, and wouldn't know where to start (except searching for some basic knowledge on the topic). If I could go to this hypothetical repository and grab a few device driver templates, that would go a long way towards my education. I'd probably still end up building them from the ground up, but at least I'd have some training wheels to use before reaching that stage.
That's that I think would be most promising about the repository idea. Not being a source of code that I can rip and put into my own projects, but rather a source of examples to learn from. The more I think about it, the more I like it.
-- $SIGNATURE
Guys, before we can have a component repository we need a component model. We don't have one.
Your comments remind me of comments made by Maddog Hall at the last Linux World Expo here in San Jose.
He brought this up as a very understandable example of the value of open source in general... Lots of companies develop tools and components which are not really part of their products - generic applications for doing standard boring business things. These companies wouldn't hurt themselves by sharing such applications, at least from a marketing or legal perspective, and they're constantly wasting money developing these things when others already have them lying around.
I don't see why this concept should apply only to whole applications and not to smaller code fragments (e.g. a good hash table implementation).
/* The beatings will continue until morale improves. */
To an extent, this is already dealt with in the form of domain-specific repositories like CPAN for Perl...
:)
I hereby volunteer to set up such a thing for Mason components... Easier than for C++ since Mason is innately component-based...
I had already planned on distributing Mason components on my site -- those that I developed at least... I think it works well to expand that idea...
Jon Frisby, Sr. Software Engineer,
Personal Site (MrJoy.com)
MrJoy.com -- Because coding is FUN!
around the area of an object repository. Not
just library implementations; most linux dists
have waay too many libraries that do far too little.
Perhaps we could build some kind of description
format, like which design pattern it follows,
dependancies, runtime costs, time complexity,
etc...
Something to think about.
--
Insanity Takes Its Toll. Please Have Exact Change
Care about electronic freedom? Consider donating to the EFF!
Yep, there's no reason Freshmeat couldn't be used for this.
:)
It has a section for "License", I guess if you could search by that, or search for what you want and check the "License" field, it'd work perfectly fine.
Or, for the really lazy, write something that searches Freshmeat and parses the output if you don't want to do it the old-fashioned way. (i.e. reading it yourself.
---
pb Reply rather than vaguely moderate me.
pb Reply or e-mail; don't vaguely moderate.
The problem with creating a single monolothic open source repository stuffed with functions and class libraries for everything under the sun is that people's needs are far too diverse. The current model, where tidbits of functionality for specific topics are maintained by various organizations considered "authoritative" in that field, has proved fairly effective. Some notable examples include netlib, libwww, ARPACK and of course CPAN.
I'm not sure what purpose would be served by bringing all of these various efforts under a single roof. They all have differing philosophies, goals, and styles. Some, such as ARPACK, are highly domain specific, and its maintainers are unlikely to care about "generic code repositories." The STL filled a very important niche, but having gotten the basic algorithms and data structures out of the way, creating a massive interdisciplinary code repository is an unachievable and perhaps undesirable feat.
This is not a bad idea, but there are some issues you are going to have to deal with.
First, for this to be of maximum effectiveness, you need to make some evaluation of the quality of contributed code. One of my big problems with Freshmeat is that, when I am presented with 17 http proxy servers, I have no idea whch one is the freeware standard under active development and which one is some guys perl script until I download them.
Second, in an ideal world there would be some standards applied to the modules. What do you do when you have three different tcp/ip socket abstractions, dependent on three different string classes? And you also want to use the database class, which is dependent on a fourth string class?
Also, don't confuse components with just code modules. Components are bigger, and have a simpler interface. Typically, they represent a significant body of code, unlike a function. Component based programming is about plugging together the components with very little glue code: hardly the same thing as a "function library".
Also, it seems to me that for maximum effectiveness in components, you need a standard in interfacing them above and beyond a functionc all interface. Currently, GNOME uses CORBA, KDE is using something of their own spinning based on libICE and their own RPC mechanism and CORBA (ARG!), and everyone else is spinning and just using libraries.
So, you have three choices. Pick between GNOME and KDE (and have a lot of components that a lot of people can't or won't use), develop your own component standard (how many ways can I say bad idea?) and carry two sections, one with KDE components and one with GNOME. Oh yeah... You could say that your repository is less for components than libraries: still a worthwhile project.
What I would really love to see is you foster development of new software and adaptation of existing software to work within a given component framework. I dearly wish GNOME and KDE would standardize, but it looks like they won't. I really don't know which is better: GNOME seems better developed, KDE seems to likely engender better support in the OSS community.
Anyway.. Those are my thoughts, do with them as you wish. Let me say that I would LOVE to see a component archive -- but I think it's going to have to come with standardization of some kind. Guys: we have got to agree on a common standard environment, including at least interoperability.
One thing you could do is this: develop some components under straight CORBA, avoid doing GUI components altogether for the time being (until some standards develop), and hope that KDE actually continues with CORBA now that they've partially "dissed" it.
-- Slashdot sucks.
If the issue here is an Open Source-only Apps site, it already exists. Check out AppWatch.
While I realize that /. is primarily a linux-related area, I would like to call attention to those fledgling programmers who would like to develop open-source software on other, more propriatary platforms. I use BeOS.
:)
While I realize that C code is C code, I would just like to mention/propose that other OS-specific code be accepted also. I have no clue how to impliment a BWindow()
"AOL, CIA, NSA, whatever, they all collect information, and they are all out to screw the american public"
have you checked out Abisource? I think that's more or less the kind of thing you mean.
They are working on productivity apps, but I believe they also have a repository of useful code that would fall under the "components" heading.
Of course, I could be wrong, in which case it would be just swell if somebody would correct me...
--
grappler
Vidi, Vici, Veni
I hope you don't mean that *only* GPLed code would be allowed in the repository. A repository of reusable C and C++ components would be of much greater benefit to the Open Source community if other Open Source licences were permitted, as well as public domain source code. That's because the GPL is incompatible with most other Open Source licences (eg, original BSD, MPL, QPL), and there are quite a few Open Source projects that don't use the GPL. My personal preference for reusable C/C++ components is the public domain, because that is compatible with *all* Open Source projects. I'm hoping to publish some reuseable C++ components next year, and I'll make them public domain for this reason. Will I be permitted to contribute to this proposed repository?
I have written a truly remarkable program which this sig is too small to contain.
A few issues:
Once a component goes into the repository, what's the best way to keep backwards compatibilty?
Who controls versioning for each component, and decides what goes into it?
Most coders hate writing doc. How do you maintain consistancy for your docs?
Someone pointed out that you need a component model; there's at least one group that's working on that (name escapes me at the moment).
Which languages do you support? Do you have interoperability between languages? What do you use now? Corba? It's going towards the JavaBeans model in the next version ....do you go for that?
Those are just a few of the things to worry about.
Don't get me wrong, I think this is a great idea. It's going to take a LOT of work to coordinate.
I think the best way to handle this is to get a very small group (four or less) people together, and decide these, and the other issues that will arise. Don't use any more people than that...if you do, the committee will argue until they're blue in the face, and you'll never get anything done.
What if you could take the CPAN system's support for automated download and install of modules and apply the concept to, say, Java environments in some of the following ways:
In other words, making a freshmeat not for direct human access, but for automated machine access and autodiscovery.
It would be very nice to have one common place for component/(C++ class) shopping. I think that the open source community by its nature would greatly enhance the quality of such components. For example, instead of 50 people writing 50 different Date classes for their individual projects, the effort could go into producing a high quality Date class. There are many people that could contribute their expertise. I'm sure there are thousands of developers more knowledable about re-entrancy issues than I am, and they could add their modifications to the code for the benefit of everybody else.
So next time that you need a drop down combobox with multiple selection and user defined icons for KDE or gnome.... or you need graphical speedometer component, you just might find it at the code repository.
Willy
Metalab does a bang up job, especially since they require an LSM submission for stuff that goes in /pub/linux
The repository specifies interfaces, [ie The Prototypes of the public methods, and the names of the public constants.] Individuals deposit implementations of the interfaces. The result: 4 different String's, which are interchangeable.
I know this is OOP dependant, but for this to work, objects or clusters therof are a neccessity (this last assert()ed without proof.)
It may not be just, but it is fair, and that is more important.
This site seems to only support OpenSource applications, and better, those that have quality and are actively developed. What you need more? Freshmeat has a large database, with more than 6000 applications, but most of them are or bad stuff, or no longer maintained, or simply have broken links, exaclty what one said before. AppWatch also seems to announce any application faster than any other site. I have seen some sites copying new releases that were announce on both Freshmeat and AppWatch. This is why I can say that we only have these sites, and AppWatch seems to be better if you really want to only support OpenSource software.
Given the increasing popularity of Linux, and centralized repository of GPL'd files and source code will be a HUGE boon for Linux itself.
That way, Linux users won't have to hunt all over the 'Net TRYING to find the files they want. This is going to be more critical with the release of the Linux 2.4.x kernel the end of this year with its increasing support for USB (and eventually IEEE-1394) devices.
Complain all you want about Microsoft, but the fact that MS has a very good download library makes it relatively easy to do things like patches and upgrades.
I think Freshmeat should be converted to this, with FTP servers directly connected to the Freshmeat HTTP server for easy downloads.
Raymond in Mountain View, CA
As has been mentioned before:
There's no reason for this to have to be GPL-only.
Yes, freshmeat is a bunch of links to a bunch of software.
Also:
Maybe 'component' wasn't the best choice of words here. How about 'reusable code', or 'useful functionality'? Is that a better buzz-phrase, guys?
There are already central archives. They are called public, anonymous ftp sites. Like metalab.unc.edu or ftp.cdrom.com.
Feel free to use one of those, but all you really need to make is a database with info about what is available where, under which license. And Freshmeat already does an okay job of that, at least.
So go make your own Freshmeat with an archived repository, license info, and links.
Comments?
---
pb Reply rather than vaguely moderate me.
pb Reply or e-mail; don't vaguely moderate.
I have been thinking about that too, and i think one natural way to do that would be to have the teaching institution manage that. Instead of trying to find toy assignments for C/C++ students, having them all work on a mega STL would seem less pointless.
Maybe the french open source senators (tm) could get funding to hire some gurus to lead the project too
Laurent
---
Dev elpizw tipota, dev phoboumai tipota eimai lephteros http://euclidian.org
You're right, it does exist. But, I think it could be better.
Delphi has had sites like this for years and they are huge in both size and importance. For example, lets say I want my application to do Blowfish encryption. I do a search on the "Delphi Super Page" for a freeware with source blowfish component. And viola, 3 show up. They literally have thousands of components and several dozens uploaded daily.
If you want to see this for your self, check out:
main site:
http://delphi.icm.edu.pl/
or mirror sites:
ftp://ftp.cdrom.com/pub/delphi_www/index.htm
http://community.borland.com/homepages/dsp/
I'm not suggesting a copy of this site. I think the interface is awkward and there is a lot of shareware crap, but it has been an invaluable on many occasions.
There has also been other sites out there that had programming FAQ. Kind of a dejanews except dedicated to Delphi only. I think that programming *nix in general could massively benefit from centralized knowledge/component base.
But be warned. It is a lot of work to maintain sites like this. Several Delphi such sites have vanished for unknown reasons, such as www.delphi32.com and www.delphiexchange.com, among many others. The Delphi Super Page and Torry's Delphi page from Russia are the few good ones left.
Ozwald
I think this is a great idea, I'd love to see it done. I hate coding simple (not to mention complex) structures that I know have already been dealt with before. The thing is, I think this is something that will suffer due to the "Achilles' Heel" of OSS, which is that without the fiscal benefits, no one wants to do the lame stuff. I think this is why interfaces to everything will be consistently less "tweaked" than their non-OSS brethren: tweaking GUIs is boring. As awesome as this would be, it would be a tremendous amount of work to get it all going properly and the make-or-break parts of it would be especially boring. What would make this work would be extensive documentation, ratings, testing, etc., aka: the boring stuff. Does anyone see a way that OSS will eventually deal with the boring stuff? Are their people out there that really like come up with comprehensive documentation for components? Look at the JDK API docs at java.sun.com for some clues as to how huge and critical and undertaking just documenting some of this stuff would be. To those who say, "but building an OS is surely a larger undertaking...": yeah, it is. But is interesting and fun and the rewards are directly experienced by you. Carefully documenting, testing, and all-in-all preparing for distribution some component you wrote for another project is of no direct benefit to you, valuable as it is to the community. I don't know people who like doing this kind of stuff.
So, what's the point of the proposed repository? I guess, it wouldn't be very useful to implement the functionality that we already have all over again. What would really be needed is a site that makes it easy (especially for less experienced programmers) to find the library (or component, if you insist) that they need.
A search on freshmeat isn't terribly effective if you do not already have a rather clear picture of what you are looking for. In other words, it would be helpful to provide an index that makes it easy to find the functionality that you need. The index could then for example point to the freshmeat entry of a selected software component. Organising such an index in such a way that it is easy to navigate is definitely a challenge, but it would probably also be very helpful.
Chilli
-=- Just a random lambda hacker
Isn't Linuxberg kinda like this? Tons of mirrors, broken into categories, etc. I know freshmeat is kind of like it, but as someone said, most of the time it's just a reference, b/c the web site or ftp area is down. But I would think that they've already got the idea down.
./brm
The discussion appears to be more about algorithms rather than components.
I think this would be an interesting challenge though. It's been my experience that in the commercial world, most components are either too limited because of the lack of source or too hard to use becuase they don't want you to have the source and they are too focused on being a "component" or "reusable" and generally end up sucking. It's a rare balance of ease of use and power that makes a good component. opensource throws all that out the window because you can customize and tailor pieces for your task and as a result not too many are focusing on producing just pieces. You have to do more work to get at the pieces but you can make them do what you want.
It should be an interesting experiment, if nothing else. It will be interesting to see what is "good" and what isn't. It will also be interesting to see the "component granularity" that is popular. (the classic example is to have reusable hashtable, tree and list classes but those are very easy to implement and don't buy you a lot by reusing them. An HTML widget or an RTF widget, on the otherhand, is a substantial amount of effort and can buy a lot if they work nicely.)
There should be a place where we can go to download all the new GPL stuff as well as the older stuff. I know of several people that would just get goose-bumps knowing that everything is in one easily findable location. There are also times we have spent searching the Internet for several hours trying to find a link that wasn't dead or temporarily dropped due to servers being down or overloaded. I'd love to see one site with enough bandwidth to handle the "/. effect". I know how this crew gets when there is a new site with some really cool stuff on it...
**There are varying shades of darkness, I am but one of the many.**
Exactly. I want my work to be licensed under the terms of the GPL, therefore I use the GPL. I do maintain the copyright of all my code, so I can dual-license it where I want, but otherwise the GPL outlines the terms I have applied to my code. If I don't feel the GPL is quite right for what I do (like GTK/libc), I'll use the LGPL, or whatever suits my needs. If you don't like it, don't use my code in your projects. It's as simple as that.
--------
"I already have all the latest software."
Somebody has already started something along these lines for Java programs called the Giant Java Tree. Check it out at www.gjt.org . Everything there is either GPL, LGPL or public domain. There's some great stuff there, like JCVS for example.
-----
Free P2P Backup, Windows & Linux
Only I want to take it even further. First off, let me reference two previous posts on SlashDot: 'Its the API's Stupid!' and 'Again: Its the API's Stupid!'. In those posts I made the case for developing an API that was both an Open Source Component development/delivery/runtime system and a set of standard Components built with/for it. Quote from those posts:
"We need a fast, simple, powerful and complete Open Source solution for component based development. An API (preferably a cross platform one) that you can write code to in any of the most popular languages. And it must have a reference implementation that is open source with a GPL license. It should be highly Object Oriented and should provide base objects for every major Design Pattern. It should front-end the OS so completely that you can write a new OS which directly provided the relevant API's (making it a kind of Meta-OS). The API itself should be open and there should be a standards committee that isn't loaded with representatives from the big companies. Plus, no-one is penalized for producing a non-compatible version (other than the fact that compatible versions would probably receive a greater market share)."
Also Quote:
"I have been working on my own for some time to develop the beginings of such a standard. A kind of hobby for me. And I know there are plenty of people out there who will claim such a thing already exists in (choose one) PERL, Python, Smalltalk, Gnome or some flavor of the month. I don't think any of those things meet all the criteria of the environment I want to see, but I can state one thing rather confidently... Until we pull together a produce such a thing the Open Source movement will have a lot of difficulty competing against Sun and Microsoft in the Business Systems space. "
One person sent me a pointer to Bamboo, an Open Source project to develop a component runtime system (partially using Mozilla code, which is cool). Others have referred me to CORBA and even ZOPE. Personally I think all of these things are good (although CORBA may be too heavyweight). But none of them go as far as I would like.
Although I want to see real code as well, I think the process should start the way any good development process should start: With a good design. With an architecture. I am currently calling this the 'COA' or 'Common Object Architecture'...
In one of my design documents I describe it this way: "A shared set of class and interface specifications that may be implemented in any language and/or with any distributed object methodology. The COA is a Specification, a Platonic Ideal - any implementation of the architecture is coupled to the COA only to the extent to which it correctly exposes the interfaces of the architecture. The intent is to create a standard system workspace for programmers to use that transcends operating systems and programming languages. Furthermore the COA is intended to facilitate the creation of distributed applications where the objects may reside on any system on a network, but look like they are local to the calling application."
Then, once the design is complete, we throw it open for development. Much like a protocol, anyone can develop both open and closed source versions of the COA. Of course I expect the Open Source versions to get more use...
And these versions might be developed for any platform and in any language because one basic part of the COA would be a split of the class definitions into two types: Native and External. Native classes have standard method calls that may be directly implemented in whatever language/object environment is being used. External classes may only be accessed through a common messaging interface defined in the COA Messaging library.
This means that Native classes are generally 'synchronous'. They return control to the calling code immediately, allowing them to be implemented as 'In-Process' and 'In-Thread' with the calling code. In most cases Native classes will be fairly small grained 'tool' classes used as components in building larger, more functional, objects.
External classes are extremely large grained 'Actor' objects that expect 'prompts' and execute 'behaviors'. They operate asynchronously, the only way that calling code can know they have completed a requested function is when they return a message indicating this fact. Although an External class may actually be implemented to run in the same process space and even in the same thread space as the calling code they function as external servers where the calling code is the client. In many cases the calling code may only be connecting to a lightweight message interface class which front-ends an External class running on another machine entirely.
These two types of classes exist to provide an opportunity to "Have our cake and eat it too." The Native classes may be bound at compile time (for those implementations that support it) and will operate with the least possible amount of interface overhead. Plus they make it possible to create implementations of the COA in environments that do not provide for multi-threaded programming. Meanwhile the External classes allow for disconnected operation and execution across system boundaries with the least amount of overhead possible.
Sometime soon I expect to set up a discussion group on this topic. Anyone interested? Email me and let me know...
Jack
- -
Are you an SF Fan? Are you a Tru-Fan?
This is a GPL'd system written in a GPL'd language that's available on a wide variety of platforms. Why reinvent the wheel to prove that we don't have to reinvent the wheel? :)
Gates' Law: Every 18 months, the speed of software halves.
Interestingly, the Delphi community has produced VASTLY more components, many free or quite inexpensive (with source available) than the much larger groups of people using VB, C++, etc. The only other community with such a large set of components is Perl (CPAN).
Just one category, database access components, sports over 50 entries.
(minor plug warning:) I operate a web site that contains extensive information about database access components:
http://kylecordes.com
It's a lot of work to maintain my list of 50 or so products... maintain a global registry of similar detail would be full time work for several people.
Just imagine we had this component library. Imagine that we had a huge database of reliable components that would work together easily. If this library were GPL'ed it would actually not be available for general usage buy just anyone. The program you were plugging it into would have to be GPL'ed as well. This would be a great incintive for newly developed programs to use the GPL as well. The result is the ability to tell management that by using the GPL you could get your product to the market faster, with less bugs and with more standard features. Although the LGPL is great it does not promote open source applications to this degree.
This isn't viral behavior but there is a bandwagon or "me too" effect that is associated with the GPL.
Be insightful. If you can't be insightful, be informative.
If you can't be informative, use my name
Bowie J. Poag of Propaganga fame is already starting exactly this at www.system12.com
Secondly, the lack of a user name tells us a bit more about this in'duh'vidual.
Lastly, The whole GPL idea is to keep people from patenting the idea published. We write the code, or we modify the code written by others to suit our needs. Patents are pointless through this method. Nobody's getting very rich, but we are making one of the best OS's out there even better by pulling ideas from programmers all over the world. Nobody has even tried to patent any of these programs of code enhancements, as far as I know.
By the way, I'm sure that it would've been posted on /. if somebody had tried it...
**There are varying shades of darkness, I am but one of the many.**
I think such a repository is necessary and would need to be able to serve as an apt source for debian packages and have an apropriate structure for updates by other distributions. I know debian isn't the only one with the ability to check a repository for updates, but it would be nice to have a central unofficial debian source
I don't know why you're complaining. Metalab was made to upload your projects. BTW, Freshmeat has tons of links pointing to sunsite.unc.edu, the wrong site. They have lots of dead links, and don't seem to know a way to replace sunsite by metalab in the links. Poor guys.
It is important to realize that projects are way bigger than just software. There are jpeg, midi, HTML, txt, etc. files that need a GPL'd component repository too. In fact, any work that can be copyrighted needs to find a friedly home in the Component Repository.
The Component Repository needs to be a home for artists, musicians, mathematicians, architects, philosophers and poets. Let's see, did I leave anyone out? Oh yes, programmers too.
http://www.rocketaware.com/
Includes special sections for GNU software, BSD man pages, FAQs, AskSlashdot (back to the beginning), Programming related books. Even has links to cosource.com, dmoz, yahoo, fatbrain, amazon.
Over 15,000 off-site programming related links. You must check it out. A single idea just like the one that started this thread was discussed about 18 months ago. This is the result.
On tap: (coming up) on site discussion, all of the unc metalab linux archives, and anything else we think of or get suggestions, or gets submitted.
1st point: irrelevant 2nd point: irrelevant 3rd point: That won't stop those who patent. 4th point: irrelevant
An interview with Bowie J. Poag just went up today on linux.com. Here's an excerpt:
linux.com: What's System 12 all about?
Bowie J. Poag: System 12 will be a resource stockpile for Linux application developers. For lack of a better buzzword, we don't really know what to call it yet, but the basic premise is this: System 12 (hopefully) will do for Linux application development what Themes.org did for windowmanagers. We're going to be offering a series of free "component toolkits" for developers to include in their own work. In exchange for using our work, we will be offering them free hosting space on our server so they can showcase their work to the community.
Visit the System 12 site if you're anxious.
I don't know why you need to register another site. Metalab is actually the best place to upload your files, and is mirrored all around the world. AppWatch is the only site that tracks only OpenSource projects that are actively developed and good. They also don't seem to like broken links (check their FAQ). No need to reinvent the well. Metalab AppWatch
This is a great idea (i think)! moderate this post up (please?)!
The internet is fine for a distributed, poorly catalogued repository. If, that is, you know where to look. As a casual (i.e. non-professional) programmer I haven't the slightest idea where to start if I want a GPL module to do task-x in any language other than Python or Perl. Sure there's lots of places for code but I've had to wade through commercial garbage for hours and still not find anything useful.
I'd like to see a site that kept material up to date and indexed by task and by language. And not just say basic but also who's version of basic (or C/C++, Pascal, etc). Something that could say to the green programmer "What do you want? We have this abailable for platform X, language Y, etc."
If what I said is nonsense,
I'm making a point with it.
If what I said makes perfect sense,
you obviously missed the point.
They suck all announcements from sites like Freshmeat and AppWatch, and announce 90% of old stuff. Yes, it's just a repository for applications, but too bad. If you are just looking for a repository, there's no need to use Linuxberg. Try Sunsite or any other with an Incoming.
If the only language is C++, then your project will be rejected because some people prefer to use C, Objective C, Scheme, Perl, Python, and Eiffel.
If you plan to use many languages, then you probably have ONE choice for a structure on which to build this, namely ILU (Inter Language Unification). Unfortunately, that leaves you with a set of data structures that are to some extent a "lowest common denominator" of the things supported by all of the languages.
In effect, the only choice for the sort of "componentizing" that you're describing is some variation on CORBA. You probably need to get a copy of the Henning/Vinoski book on CORBA, and to start writing chunks of IDL to represent all the sorts of interfaces that you want to be able to have "published."
Unfortunately, there's still an impedance problem, as:
If you're not part of the solution, you're part of the precipitate.
Why? I don't see a reason to support deb or RPM. Make you own specs using the sources.
A CPAN like mechanism would work well for languages that have very well defined, unambiguous specifications. Perl, for instance, behaves pretty much the same way on all (at least Unix) machines. Java and Python, as well as most other "interpreted" languages also share this characteristic.
C and C++, being much older, with more carryover "baggage", however, do not have the luxury of a fully specified language definition. In the ANSI spec for C/C++, there isn't even a set size for the basic data types! All that is required are various ambiguous properties such as sizeof(long) >= sizeof(int) >= sizeof(short)
A generic C/C++ code repository would face much difficulty in maintaining portable code that would just work for anyone, given the nature of these languages. As far as Perl, Java, and Python go, there are already many code repositories available: CPAN, Gamelan, and Python.org all contain links for downloadable "modules" for these languages, repsectively.
The example that I keep citing (and nobody has ever done anything to bring to fruition) is that of the calendaring systems. GNOME and KDE both have calendar programs that "grok" the iCalendar specification, but only partially. In particular, iCalendar was designed to allow "Calendar clients" to connect to a "Calendar server" that could provide schedule information for multiple users.
What they should do is to define a CORBA interface to talk to a Calendar server; by having common IDL that would be free of ties to any GUI there could be one implementation of a Calendar server that both the GNOME and KDE clients would talk to.
This is much same idea as the notion that any sort of web browser can talk to an HTTP server.
Don't be so sure that KDE has "dissed" CORBA as dramatically as you're thinking; what they have concluded is that running raw GUI calls through CORBA to implement compound documents is quite ridiculously inefficient. Note that the GNOME guys have largely concluded the same thing. (ORBit appears more efficient than MICO, so GNOME may get away with doing more with CORBA than KDE can...)
The point is that CORBA has enough overhead involved that you don't want to be shipping around tens of thousands of CORBA calls per second.
On the other hand, using CORBA to request:
... That a text editor be invoked to edit a file, ... That a document, specified as a tree, be submitted to a printer, ... That a bundle of configuration data be retrieved
all represent areas where there's large enough "granularity" that CORBA can be useful.If you're not part of the solution, you're part of the precipitate.
Which vendor's CORBA to use: IONA, TAO, MICO, OmniOrb, Orbacus? Which threading model? Bi-directional IIOP or not? BOA or POA? They are not source-level compatable despite what you may believe. CORBA is the best non-standard standard I've ever had the misfortune to use. Just say no to CORBA.
1) I haven't particularily wanted to write because i know it's been done before and would be happy to reuse somebody else's code but couldn't find any and didn't want to wade through the code for a slew of other tools hoping i could find the code i needed.
2) I would love to share in a "functional" form, rather than just as complete source code for a tool i have written. (although the latter would be available, also)
3) I would love to contribute fully functional (background) engines and functions for things i have written as a "proof of concept" but had no intention of polishing an entire package to be releasable. The code snippets would be of value to others, but the form of the tool for which i wrote them certainly wouldn't be of use.
This is just a damn good idea. I don't have the resources to set this up, but if somebody did, I would certainly contribute! ...and use it!
It strikes me that a lot of Open source code is out there in CVS repositories, much of it available by anonymous CVS. It also strikes me that the maintainers of this code *want* to maintain control of their repositories to make sure that things like backups happen to their satisfaction, etc, so it seems unlikely that a *centralized* place for repositories will appear, and even if it did, it doesn't seem too appealing. The decentralized disorganized spread-out chaotic highly-excessively redundant nature of the current state of things probably has something to do with its success.
So, back in the old days, there was archie, which used to go out and search FTP sites anonymously and make a giant index of what was out there. Now we have web crawlers.
How about something like archie or web-crawlers except it goes out probing port 2401 (cvspserver) and catalogs what it finds (maybe does a "cvs co -c")
An extension to CVS to allow a sort of description of what's in the repository (freshmeat style?) to be probed might be cool.
i.e. maybe a "cvs -d wherever whatchagot" command, that could just spit out the contents of some files in CVSROOT, perhaps without even requiring a "cvs login" And a standardized anonymous CVS login and password might help...
Hmmm. Maybe I'll propose this in info-cvs@gnu.org. But it's kind of a chicken & egg thing. Without the cvs-indexer-robot, what use is the new command, (and everybody would need to upgrade to the newer CVS server) and without the new command, the web-indexer isn't really feasible.
Hmm. Maybe I'll just implement the damn thing (the cvs mod, not the cvs robot, I'll leave that to someone else with the bandwidth and the hardware to do it with.) and submit the patch to bug-cvs@gnu.org...
Later, got to look into some code!
Bang the head that doesn't bang!
CPAN depends on testers (of known quality) to approve items. Not every language has as centralized a community. This may mean giving people of known quality temporary autocracies to recruit a pool of testers of known quality. After the high standards are set, a more democratic (or anarchist, depending on your POV) can take over.
Gates' Law: Every 18 months, the speed of software halves.
A Few Comments:
1. Great Idea!
2. Can we break up existing code into pieces and organize them? There is a lot of it out there in all the other Opensource projects
3. The infrastructure and ideas are similiar to the Trove Project (which is similiar to Freshmeat)
http://www.tuxedo.org/~esr/trove/
That's all
you put your comment on the wrong story. this goes with the rare glitch project.
I think the only way that something like this would work is to allow any type of license.
Having said that, I think it's a great idea. Personally, I've dealt with RogueWave components a lot, and I'm not impressed, even if they have started releasing Linux versions :) I think open source could reach their mark very quickly.
Now, you may say "HTTP doesn't do anything!!". Au contrare. When coupled with XML, you can implement a variety of RPC protocols such as SOAP or XML-RPC. As much as it pains me to agree with them, Microsoft is right about XML - it is going to demolish these cumbersome middleware technologies - including its own DCOM. Unfortunately the linux community, forever chasing tail lights, still see CORBA as viable.
CORBA never really had much of a chance. The development community really never latched on to it - its simply too complicated in a world where the dominant protocols are getting simpler all the time.
Doesn't open source software get tested? Test plans, cases, and scripts would be great resources!
The linux community is making a disastrous commitment to CORBA, a technology that frankly has been killed off by the web. IIOP never became meaningful to anyone - HTTP-based XML RPC is poised to crush COM, CORBA, and all of these other top-heavy middleware solutions.
CORBA died for a reason. Its bulky and complicated. Try moving slightly ahead to a world where data is abstracted as XML, and transferred using HTTP.
Putting the license issue aside for a moment, I wonder how something like a /. model could woulk for rating the quality of code?
Someone could submit an object/component to a team of people who would weed out (loosely) the duplication and plain useless things. These people could be picked by a vote of peers or some such method to establish a core of competence that the community at large trusts. Once it passes the initial quality check (one or more times) it could be up for a peer moderation style review.
When searching for a particular object you could set a quality threshold on your search. The higher the threshold the less likely you may be to find something exactly like you want, but the code you do get should be of high enough quality to impress the people who used it and rated it, in fact may be built well enough to allow you to modify it to suit your needs, maybe even to the point of creating something which may be of value checked back into the moderation system as a new object.
I love you... Ok I love you AND the UNIX operating system, but then I've know it longer.
Get the cpan module. It gives you a cpan command shell. Then type in "i /Gtk/" to get a list of all Gtk related stuff. Type "install Gtk" and it downloads it, compiles any parts written in C, installs, and than tests it for you. Also reminds you of what modules are out of date and updates them for you. Gotta love it!
Most things on the internet seem more like a suppository.
Here's an idea: rather than use the GPL for all the components, use a BSD/Artistic style license. Why? The GPL prohibits the code from being used in classic "cathedral" closed source projects. Why is that important, you ask? Well, if there were enough free (speech and beer) libraries do, oh, say, anything on Linux or *BSD, they suddenly become a much more attractive development platform than they already are. Time to market and cost of development drop through the floor. Linux and BSDs market share shoot through the roof as they become the preferred developer platform... since it's so damn easy to write code for a platform with extensive libraries.
And the upshot of it all is that it means less messing around with Microsoft products and more jobs working in the environments we love!
--
--
"In Cyberspace, no one can hear you be sarcastic"
The usage of the term ``General Public Virus'' all but confirms it. Serious usage of this term indicates a lack of understanding, and is strongly indicative of the notion that the person using said term dreams of software that they may not only use, but abuse as they see fit (and, indeed, extends this dream to cover all software ever created.. apparently this isn't just restricted to people who deal in warez anymore). No one is forced to GPL their software, and if you wish to build your work upon the work of others, you must abide by their licensing scheme. If you don't like it, do it yourself. It's rather simple.
Complaining that the GPL doesn't achieve your aims and objectives very well is ludicrous. Just don't use it. What can not be argued (reasonably) is that the GPL fails to achieve its own aims and objectives. It has done so with flying colors. So, if you like the GPL, use it, if you don't, then another license will suit you better. Complaining that you can't turn GPL'ed software against its intended goal is paramount to complaining you can't enslave people anymore.
The other obvious hole in the logic presented here is the notion that you can't use GPL'ed code in a public domain software package. This isn't entirely true. Public domain means that there is no copyright license. You are free to fork the unlicensed software package and relicense it. So, while it is true that you can't use GPL'ed code in public domain software and still have it be public domain (it is now under a copyright license -- at least your fork of it -- the GPL), it is not true that you can't do it at all. You could relicense it under any other license as well. Of course, the original would still be public domain, but your ``distribution'' of it wouldn't have to be.
~ Kish
Just to clarify a few things....
A) The interview I gave with linux.com took place yesterday afternoon. Apparently, this Aiken guy probably read it when it was posted earlier today and decided to apply the same idea to sourcecode in his post to Slashdot. Ideas dont hurt anybody, so quit railing on him.
B) The sort of thing we're doing at System 12 doesn't encompass code-based components. Sound, graphics, and font component kits, yes..but not code.
C) This idea isn't new (or unique) and I certainly cant claim to be the originator of the idea... In my case, i'd been kicking the idea around for a good 2-3 years before finally having the opportunity to have a go at it this summer. However, as many people have pointed out, other people have been similarly kicking around the idea for quite some time, it appears.
Bowie J. Poag
Bowie J. Poag
I am a firm believer in Open Source for a number of good reasons of which we are all likely aware. The issue of licensing always comes up and often good Open Source code can't work together with other good Open Source code because of incompatibilities with licenses.
Often, a developer will release code under one license, and since s/he's the developer, also later release it under another license (it's proprietary and then GPL'ed, or Qt-licensed then GPL'ed, etc.). What would happen if, given that there are say 5 "blessed" Open Source licenses which happen to be incompatible with one another, a developer took his code and released a copy under every one of these 5 blessed licenses?
While this is not sufficient to solve incompatibilities, since the next developer on the BSD (say) branch adds his code in and just keeps it BSD-licensed; if everyone were doing it then the new code could be released under all the blessed licenses. This of course does nothing to make currently GPL'ed code compatible with BSD-licensed code, but is something gained by doing this for later code?
Is there a license that one could write which is something of a meta-GPL? In the sense of saying: "Code under this license must be redistributed under this license and under (blessed licenses 1-5)"... I'm not sure that's particularly cogent, but maybe someone gets my drift.
It's late enough that I can't tell if this is absolutely idiotic or somewhat sensible. Oh well, that's what flames and moderation are for.
"Cause there's 40 different shades of black, so many fortresses and ways to attack, so why you complainin'?"
Isn't the point of component repository to hold programming solutions to common problems. I believe that it shouldn't just be a collection of all the open source libraries.
It should contain complete solutions with simple, consistant interfaces. In a sense, it would be like a collection of abstract data types or design patterns.
How many of you have written your own FIFO routines? Or better yet, how many times have you written FIFO routines? A FIFO is a very common design pattern (that's why its part of the C++ STL). Yet without such a repository, we are doomed to re-write it each time, unless we each keep our own repository, but then that wouldn't benefit the next guy. With a public, open source component repository, everyone would have access solutions to problems someone else has solve before, and may only need to tweak a few minor internals (i.e., what type of object get put into the FIFO).
What I think will probably be needed is not only a server w/ mirrors to host the site, but a group of developers, that would act as moderators for what gets put into the repository. They would ensure that the code fairly autonomous (i.e., it doesn't need a lot of support functions written by the user of the component), it is inspected for quality (i.e., peer review type activity), it compiles cleanly, and ensure that the code can be released under an appropriate open source license.
Some added benfits of such a repository, could include software patent protection if some company tries to patent a solution to a programming problem and the solution already exists in a pulic forum.
First off, quality. Probably a simple voting system requiring a registration would suffice. Since it's not a religous issue (no freshly developed code fragment has the religous overtones of VI or EMACS) there shouldn't be too much ballot stuffing. Email registration takes care of the casual skript kiddy.
Simply rating the software on it's stability and efficiency would be nice. Comments on it's usability (how clean is the API) and the like would also be good.
Finding what you're looking for. A much harder topic indeed. Not many people go in looking for a Red-Black tree code fragment, so there probably needs to be some documentation on what functions do what you're after. Pointers to some excellent books on programming also apply.
How about Compatability? The whole thing is useless if every component depends on yet another different piece of software. (Which is why I'm so happy that aprintf is in glibc. That's a major improvement) Perhaps defining common APIs for common functions is a good idea? There's not too many ways to handle string classes, so if they were compatable, eventually they would be mergable into one well-done class instead of 35 mediocre classes. Identifying what is good and what sucks and standardizing should be the primary goal.
Lastly, Licence conflicts. If such a thing is done, to be truly useful it will have to be usable by everyone, not just GPL software. Nobody will contribute if we lock out all BSD style licences. My reccomendation here is that anything that's more then just a fragment of code be LGPL. Moreso, all of it should be linkable into a single LGPLed library. This avoids namespace bloat, as well as ./configure bloat. Code fragments? If you really want to GPL the code to free the first node of a linked list, you need to take a large, blunt object and beat yourself with it. Save the GPL for a PROJECT, leave simple coding examples public domain. Let the download counter of your snippet be your reward.
And as soon as such a thing exists, I've got a handful of code of varying utility I'd put in there. timer management, IO, buffering, whatever I've had to write. I'd like to clean out my attic and see if anyone else gets a use out of it.
--Dan
"Write your own and don't whine that you can't steal from us."
:-)
It's not stealing, it's sharing code with my friends
A Government Is a Body of People, Usually Notably Ungoverned
I wonder how many have considered an idea that I have been tossing about in my head as of late. I don't believe this is very far-fetched: proper use of the Unix process model could be considered a form of component-based programming!
I can hear it now: "Boo! Hiss! Components have to be built on CORBA or DCOM or (name your acronym)!" Let me try to describe my view. Feel free to disagree!
The major benefits, in my view, of component-based programming are:
1. Components can be assembled with minimal effort.
2. The system scales well because additional hardware can simply be added.
3. Components are isolated from each other, so debugging is much simpler.
4. The developer has many choices of programming languages and platforms.
Which of these things can't be duplicated by a Unix script? Since multitasking is inherent and clustering is available, assembling a system using familiar Unix languages and multiple processes can be just as efficient as a CORBA equivalent. A Unix process does indeed have a component-like interface, though it may not be apparent at first: command-line arguments, the environment, pipes, signals, and sockets.
Therefore, it could be argued that the "component repository" is already on any Linux user's HD. Image manipulation utilities, formatted document generators, network protocol implementations, forms-based GUI generators, widgets, etc.
I'm going to provide a counterargument as well, however. An object-oriented component model needs to have easily defined and flexible interfaces. All Unix-based interfaces depend on a serialized stream of bytes. That is not appropriate when you want to send a polymorphic object!
Thought number two (much simpler thought and probably more useful): as long as we can first decide on a standard model (CORBA would be a good choice), we could begin building components out of the GPL utilities already out there. "wget", "ispell", XML processors, and more are good candidates.
Thought number three: The KDE people are already building lots of components. We have to build on their efforts as well as others'.
Is there a license that would allow code to be re-used in a commercial application, but would force the commercial site to re-publish any changes that they made to the source?
"AOL, CIA, NSA, whatever, they all collect information, and they are all out to screw the american public"
Why would it matter to a consulting firm if they have to release their code to the client under the GPL? They're not making money from selling code licenses, they're making money by providing services to the customer. Of course, they might also build up an internal repository of components, but if they can get a vast number of components for free, they might consider it worth giving up the advantage they get from having proprietary code for that advantage of having all this free code available to them.
For consulting firms specialised in niches, this might not work out to their advantage, but for most consulting firms, I would expect it to make sense. Though I don't have any experience with consulting firms and their code libraries, so I might be way off, but I suspect I'm not for most outfits.
We don't need a component site. We need a component index. That index would list names a brief functionality description, an evaluation and pointers to similar components/libraries. We already have this for applications (eg. freshmeat/tucows/google) but not for components.
But your friends don't share
and if they don't share, well they're
no friends of mine
</DIV>
What is happening with the Trove project?
-- Ed Avis ed@membled.com
Another GNU GPL "module" or "component" structured system is being built up by Arsdigita.
For more information check out:
the guide to the Arsdigita Community system,
Arsdigita.com,
and the photo.net web tools review
.
. hmmm
I'll start off with a quote from the story/Ask Slashdot thingy:
-> How to ensure quality code and documentation
Quality code? The open source community is full of talent: and the peer review system inherent in open source provides ideal motivation for contribution. Reuseable code is one of the many Holy Grails of coding: component technology, object oriented languages etc all endeavour to achieve this, and none have reached the full potential of the concept.
Why? The inherent nature of companies and firms, (the world's largest software company is an ideal example) to promote aggressive THEIR technology at the cost of their competitor's technology. Visual Basic Controls are a form of code reuse: so is the Perl CPAN system.
In light of the above, it seems logical to rely upon raw source code for reuseable code, instead of company/firm controlled binary formats.
However, we have to realise that while much code is generic and reusable, the general case is that we're gonna have to adapt the code found in said repository for our own uses.
Documentation is key. Excellent documentation, or even step by step tutorials for those embarking upon their first open source project/first coding project even. Everyone is free to contribute and hack to the full extent of their own talents. Excellent documentation, for eg(my thoughts as an example: others may disagree) detailing the workings of the code, possible flaws etc etc, original intent would be a great aid to the maintainence and continued advancement of this collective pool of knowledge. Documentation help makes code even more reusable.
just my 2 cents
Be kind. There are too many mean people out there already.
Do you wish to insult all users of components? Have you not noticed the use of components in both KDE and to a large extent GNOME?
Do you wish to insult all consultants? What do you think a lot of open source hackers do to make their daily bread? Why assume that consultants
cannot consult based upon open source? Why insult all components and the idea of components just because you didn't like a particular
set of components? Do you even understand what components are and are not?
Primarily for use in C, but bindings exist for numerous other languages, too.
"The invisible and the non-existent look very much alike." -- Delos B. McKown
why not just be sure that the code works?
there are methodologies out there that guarantee robustness, performance and absolute adherence to requirements. a nice by-product is complete system documentation that actually reflects the implementation. (what a concept!)
what open source needs is a set of tools to support these methodologies. (not to mention the actual awareness, appreciation and understanding of this technology.)
real system engineering anyone?
contact l2b for details.
..I wasn't even arguing with your views on the subject of a component library, merely how you presented them. Slanderous terms such as the ``General Public Virus'' do not promote understanding. See Bruce Perens' long list of running commentary on the subject for more about the ``viral behavior myth''.
And since you bothered to claim that for everyone except RMS and myself it's a ``no brainer'', perhaps I should point out that despite the fact that *BSD has been around far longer and was fully functional before the conception of GNU/Linux.. well, which is more popular today, do you think? And, ah, why do you think that is? If it was a purely technical edge, there would be no room for GNU/Linux, as *BSD has been mature for far longer. And since the GPL isn't a ``truly free'' license, it couldn't be philosophical, either, eh? Quite simply, your argument holds water like a sieve. Good job!
At any rate, you're doing very little to prove yourself as anything other than a bigot to me, especially since you opted for another low blow by implying that GPL'ed software is not truly free. The GPL is free in the sense that it wants to be, and there is more than one kind of freedom.
So.. so what? All this proves is that you should choose your words more carefully, and have a better comprehension of what you're talking about. I certainly didn't ``prove your point'' for you, since what I said didn't have a damn thing to do with what you said except for the fact that I disproved an offhand remark of yours. Then again, very little of what you've said hits me as being very clueful.
If you really want to make your case on these kinds of issues, do so in a calm, eloquent manner.. one that promotes understanding rather than bandying about all sorts of flamebait-loaded terminology. You certainly don't come off as being very informed.
To top all of this off..
And somehow you feel that your particular brand of bigotry is any better?
Yeah. That's precisely what it is. Now to explain: There are *BSD bigots. There are GPL bigots. There are all sorts of bigots. However, just because, say, some black person calls a white person a ``cracker'' or ``honkey'' doesn't make me glad I'm not black any more than some white person calling a black person a ``nigger'' makes me wish I wasn't white. Again, your arugments don't make sense. Apparently you spend too much time paying attention to the lowest common denominator rather than informing yourself about the issues at hand and then going on to make an educated decision.
To clarify: I made some inflammatory remarks in response to your rather obvious bigotry. I was not making inflammatory remarks toward people who support licenses other than the GPL (even proprietary ones, and certainly not other free software ones), just those who slander the GPL for reasons that are completely unfounded. Being slanderous just to be slanderous is what we call either ``flamebait'' or ``inflammatory''.
As an aside, I'm not completely against proprietary software. I don't think it's ``give me GPL or give me death!'' I think PINE and PICO are nifty. There are better tools, like Mutt and Emacs (or just Emacs with Emacs/Mutt), but PINE and PICO still fit their niche. I don't see a reason for them to be GPL'ed. I also don't see a reason for games like Quake to be GPL'ed. While it would be nice, computer games aren't quite as important as your basic tools, such as your compiler and debugger and what have you. Critical pieces of your overall system (such as the OS) do well as free software because, quite simply, they need to work, and if you have to beg someone to fix their fuckup, it's not going to seem very worthwhile to use that OS.
Public domain and, say, BSD-licensed software are free software just as GPL'ed software is free, except that without a copyleft, there's no guarantee that they'll stay free. There's less incentive to contribute to the main branch. There's more incentive to fork it into a commercial work. Generally speaking, there's less incentive to share. Those who uphold any semblance of the Hacker Ethic would want to share, and would want others to share too. The perceptive ones, such as RMS, would realize that most people do not want to share, and that if they're going to make software that can not be shared, they sure as hell are not going to use his software in the same manner as their proprietary works.. And thus was born the GPL, a license which forbids others from restricting the rights of users to share GPL'ed software and code. The only ``advantage'' BSD-style licenses have is that they may be made proprietary. This is sort of counter-productive to people who believe in sharing, since proprietary software is not meant to be shared.
~ Kish
Excellent Thread.
I've been thinking along the same lines for a while.
I think the key will be the "citation index", to use the scientific research term. Just like research papers.
Usually well documented code points back to where it came from, just like the web.
But more useful are forward pointing links.
ex:
"I see this really neat "pattern" from 6 months ago,
but it is not quite right,
let's look forward to see what someone had done with it, and perhaps they are closer to what I need."
This is exactly what scientific papers and such already have: citation indexes. I used the paper version (age showing) of "current contents" when doing research in a University environment. A version is now online here ISI: Online Current Contents
A standardized set of XML-ish tags or commands to let the web spiders like Altavista or google find these sites would also be very useful...
Naturally the GPL is a restrictive license. There is no other way for it to remain free software (for sure). The author of the GPL, RMS (this is not counting the gang of lawyers that helped him out), doesn't even believe in copyright licenses. He wishes everything could all be public domain. The obvious problem is that most people aren't hackers, don't give a damn about the Hacker Ethic, and certainly don't feel like sharing.
The GPL makes sure that there is still software you can share. Unfortunately, it is written in such a way that it can not ``play nice'' with the other free software licenses, but if it were to do so, it would also open up holes that proprietary software licenses could take advantage of, and thus be able to transform the GPL'ed work into a non-free software package.
This was clearly against RMS' intentions.
Copyright law is intended to serve as a safeguard against the natural right to copy. The right to copy is one of the freedoms the GPL upholds. Yes, it is the FSF's brand of freedom that the GPL upholds, but when you talk about being free, you talk about your freedoms. Pluralized. This is because you have several freedoms (this is from the point of view of a U.S. citizen, FYI). In the U.S. you are not completely ``free'' in the sense that you have every available freedom known to humanity. This is because there is more than one kind of freedom. The GPL does a very good job of defining which freedoms it upholds, so calling it ``non-free'' is an exercise in counterproductive nonsense, as it is paramount to saying that ``anything less than anarchy is not free, and if I can't be free, I'm going to create an anarchy''.
The problem with any anarchy, however, is that there are no laws or governmental bodies to protect your freedoms, and thus, you can lose your freedoms the first time someone comes around whom you can't best in a fight. The notion doesn't sound very appealing. Of course, anarchies wouldn't be a problem if everyone was an essentially good person. Only the most naive of us believe this is the case.
Much of this could be applied to proprietary software licenses as well. It is simply the nature of the beast. Unless everyone feels like sharing software freely as was done in days past, there will be a need for the GPL. And since the GPL must uphold the freedoms it promises its users, it's going to have to be a restrictive license. I'm sure that RMS would agree with me that this is an unfortunate situation.
Quite naturally. However, I was never commenting on the overall topic at hand, merely the slanderous usage of terms such as the ``General Public Virus''. I would actually agree that a repository which contained software from all of the free software licensing schemes would be a Good Thing. I would also wager that a separate repository for GPL and LGPL stuff only could be a Good Thing as well. If you went through all of the above simply to state this, you need not have bothered. I knew this well enough before I even clicked ``read more''.
All I ever asserted was that GPL'ed software was free software, not that it was the only free software. Therefore, neither of those comments apply to myself particularly well.
~ Kish
Perhaps a new distro would be a better idea
I wonder why something like BSD's ports collection doesn't exist in the Linux World. I frequently find myself hunting for a
(I don't like tarballs because I tend to lose track: what's installed, where it is installed, what file belongs to which package... Plus I like having the patches that integrate the software in the distro.)
(I know there are other package managers but AFAIK they don't support source packages as well)
I havent used it much, but its a start.
If I take a copy of the King James version of the Bible (which is in the public domain) and slap a copyright notice on it, the copyright isn't valid: only the author of a work can copyright the work. If someone simply slaps a copyright notice and a GPL onto my public domain source file, it isn't valid.
If someone makes improvements to an open source software project, there are strong social pressures to contribute the changes back to the project maintainer, rather than creating a fork. For example, Softway Systems (a for-profit company) has contributed all of their changes to the pdksh back to the project maintainers. Since pdksh is public domain, Softway released their changes to the public domain. In short, people do contribute to public domain software projects, and forking is not inevitable.
If I was paranoid, and wanted to prevent people from forking my open source code, I wouldn't choose GPL over public domain for that reason, because GPLed code is just as easy to fork as pd code. I would instead choose a fork-proof licence like the QPL.
The real benefit of the GPL is that it has restrictions that prevent bad people from doing bad things with your code (ie, making the code unfree). The real benefit of the public domain is that it is compatible with every software project. That means more people using the software, and more people contributing useful changes back to the project maintainer. Notice the difference in emphasis here.
I have written a truly remarkable program which this sig is too small to contain.
A component repository implies the existance of a framework which allows interaction between elements which constitute the repository. In many cases, these components can be utilized without the need to study and understand the code. An understanding of the interface is sufficient. To be successful, such a project must define something at the level of a framework. CORBA is an interesting framework which allows integration of many languages into such a framework. But it has two problems: the specification does not define enough detail for specific environments, and it has a SIGNIFICANT learning curve. Now let's take a lesson from history and our peers: KDE and Gnome have been in talks for a while regarding a component architecture which allows inter-communication of their respective elements. It has gone under the name of OpenParts, and the technical issues have been quite contraversial. Now let's take a lesson from our rivals. Their component standard is the illustrious ActiveX. It is a formidable, robust, mature rival technology. (It also has a significant learning curve, which is only aleviated by well-integrated development tools.) I know little about OpenParts, so a comparison on my part would be an injustice. Perhaps some day we will see Wine provide an ActiveX to OpenParts gateway. That day is still a LONG way away. There are many more component technologies and frameworks. Many are suited only to a particular language or class of applications. Name your poison. Doesn't this call for an objective SlashDot feature on component technologies?
I think it is not easy to make such a component repository work well. Ideally you would expect all components to behave well and work well together. But this is not obvious. Imagine someone builds a nice graphics polygon class (just an example). It uses some Vertex class to represent the vertices. Another person builds a bezier curve class which is also controlled with vertices. Unfortunatelly he/she made his/her own version of Vertex because the work was done independently of the work of the Polygon creator.
This is difficult to avoid if you just throw together components made by several people. The problem here is that components are often based on/or use smaller sub-components (like Vertex). So there will be many implementations of those classes. And they will most likely not be compatible (although hopefully easy to convert).
So a good component library should preferably avoid this and try to reuse globally accross all components. This is no longer an issue of just reusing components, it is also an issue of making sure that the components themselves are also making the best use of available components.
This is not an easy task. But it can be done.
Greetings,
Project Manager of Crystal Space (http://www.crystalspace3d.org). Support CS at http://tinyurl.com/cb3x4
I was planning on beginning work on this sometime next week, oddly. I've expanded heavily on the idea, and I think that making sure they're all GPL isn't all that important. BSD license would be fine. Code without a license would also be fine. Basically, what you'd need to worry about is whether or not it's freely redistributable.
:)
Obviously, one wouldn't want to put up the source distrobution of Sun's JDK. Sun's community license prohibits it, and Sun would probably come yell at you. If, on the other hand, you find a piece of code that has as a license header:
'Hope this code is useful to you. Enjoy'
Then you -can- post that, since the author clearly doesn't much care what his code is used for.
Now all I need are ideas for domainnames.
--Sagev
wales001@my.bomis.com
Thank you for responding Kent!
First, let me say that I am actually considering Bamboo as one of the underpinnings of the COA. As you pointed out -- in this case being lightweight is an advantage. Actually a huge advantage.
But let me quote from my original post (referring to Bamboo, Corba and ZOPE): "But none of them go as far as I would like." As a basic technology underlying the COA Bamboo is very nearly perfect. Much as the ZOPE Object Database design (ZODB) is nearly perfect for COA persistent storage. Only thing is, these are peices of what I see as a larger whole...
The real point is that I want to design first and develop afterwards (what a thought!). Not being a foolish egoist, I have every intention of incorporating any existing technology that would work as part of the whole. And I do see Bamboo as possibly filling a specific role, both in code and architecture. I would welcome your help in making this so!
So what do I need right now? Something you are probably doing anyway: Architectural documentation for Bamboo. Preferably with UML diagrams and with more detail than the overviews I found drilling down from the Bamboo web site. And I would really appreciate your active participation in the COA effort. Everyone involved has real jobs of course, and so we will probably proceed in fits and starts. Plus there is the usual possibility of the whole thing just fading away. But I can guarentee you one thing; this is an idea whose time has come. If it isn't the COA it will be something else.
Jack
- -
Are you an SF Fan? Are you a Tru-Fan?
The question that immediately comes to mind is how to organize the code. CPAN is PERL-specific, and other repositories tend to be similar in terms of supporting a single language.
.02
On the other hand, the purpose of the proposed repository is to support the distribution, improvement, and archiving of GPL code. IHMO the specific language should be secondary; i.e. the repository directory for a given type of network interface would contain C, C++, Java, Perl, and other code.
Confusing? Yes, somewhat. There would certainly be disjoints where there is no equivalent code, and the repository hierachy would have to be somewhat general. But doing so would have the implicit effect of encouraging porting, cross-platform development, and ultimately support sharing and development of GPL code in a manner that's not been done before.
-just my
I think not...(*poof*)
I was wondering how one might design a site to entice readers to evaluate source code for a public repository, and I realized that I'm looking at a pretty interesting one here on slashdot: meta-moderation.
I'm wondering if anyone has considered setting up a server like slashdot for code, allowing code modules to be submitted publicly like articles, with some header that describes the code. Interested readers could click to see the full code as well comments that others have made, and of course they are free to submit comments of their own. And if their inputs are valuable (reflected by ratings numbers), they may even be invited to meta-moderate new submissions and comments.
Ending note: How is meta-moderation working out on slashdot? Most of comments I see (generally score 3+) are worthy of the rating, but is there any abuse? Any comments getting excessively down-moderated? Just curious.
Well put. XML/HTTP is the better way - the language of the web. CORBA/IIOP compatability is just not there, nevermind the 1000 page spec from hell for CORBA.
It's an exciting idea. I'd be very interested in working with somebody on something like this, either an existing website or a new one. Email me (ryan@l-s.com) if you'd like to know what I could do to contribute.
Ryan
Why should it bother *you* that *my* friends don't share?
Software should not be owned. If my friend asks me to make a copy, it would be wrong to refuse. By putting a copyright on the software, you are asserting ownership over it, and denying me my natural right to share it. People not only deserve free software, they deserve software without conditions.
A Government Is a Body of People, Usually Notably Ungoverned
I agree with the comment that the entire Internet is such a library.
Having multiple specialized sites, perhaps centrally indexed ensures that one language won't get ignored by the people that run the a general interest site.
Build it and they will come!
Greetings,
.tar.bz2'ed source files, and I'm not indexing anywhere NEAR all of them, because a small subset quickly outruns MySQL's 2G file limit, and just a few more quickly outruns ext2's 4G single-file limit. (I have about 40G at home that I'm using to do the indexing on... I bought a pair of 20G drives just to experiment w/ this problem.)
Wouldn't this be nice to type into a search window:
'C++ class !(public constructor) && (public static method returning selfclass)'
This would find all C++ classes in all projects that contain no public constructors, and have a public static method (class method) that returns the same class as it's defined in. This would be an adequate 'search for singleton class' function, for anyone who knows Design Patterns. (Yes, it would probably become a macro, so you could search for 'singleton && "config"' to search for singleton classes that contained the word 'config' someplace in them.)
I'm working on this myself, although I've completely surrendered on C, because there are virtually zero projects that don't abuse the pre-processor in ways that make the code unparseable (semantically) without being run through the pre-processor first. (And if you try to do that, you need to know how the project is built, what defines are declared, etc, and your include files need to be the same as X platform, etc... This rapidly becomes a nightmare, trust me.) C can be indexed using 'glimpse' or something similar, but semantic indexing is pretty much just impossible without lots more information, and therefore non-automatable, which is my number-one priority.
C++ is nicer, because fewer people do Stupid Things with the preprocessor. (WHY would you define 'FOREVER' as 'while(1)'?!? Think it's cute, or something? Bleh...)
Java is *GOLDEN* because it's completely semantically parseable with no problems with the preprocessor. It doesn't HAVE one. I love indexing Java.
On the other hand, I have about 1.2G of
ReiserFS might work, that's on my list to try (if it's stable), but I need to get the indexing working better for C++, and then see if I can't shrink the database files some.
Ahhhhhnyhow, basically, it's a hard problem to properly index and search large source bases, without simply abusive resource utilization problems. If all you want to do is 'glimpse' index it, that's easy, but it loses a lot of what you'd want to search for I feel. (Context isn't preserved, because glimpse indexes non-structured content. This is a great generic solution, but I believe firmly that code can be better indexed with a custom solution.)
On the other hand, you also NEED to 'glimpse' index on the comments, and the non-source files in a project tree. (Figuring out which is which is harder than you might think, sometimes.) This lets you search reasonably for 'This needs to be fixed!' long after it's been forgotten by the original author.
This is my main personal project these days, the coding project that keeps me sane while I'm having to reverse engineer and document what's been done by the hardware engineers (who no longer work there) at my company, instead of programming like I was hired to do.
At least I don't need to be in a server room on New Years. *wry grin*
Anyhow, if you have any suggestions (yeah right, this is sadly already off the radar for most slashdot readers, I guess...) feel free to drop me a line at cyberfox@vixen.com.
I don't know of anyone (outside of commercial companies) working on this kind of problem right now. I think it would be a good resource, and it's a fun project for me... Oh, and of COURSE the code is going to be GPL'ed if/when I ever make it useful to anyone outside myself.
Cyberfox!
There's a large list of sites with reusable software for several different languages here.
- very good one
or better than that.But the applications and libararies and more than you want to deal with is on sunsite and the mirrors.
Have you really gone through it recently?
sample mirrors that are semisets (part subset part superset)
ftp.cdrom.com
ftp.rge.com
CPAN is a subset of these sites.
The cataloging is probably really important. Ex: looking for fast lookup. Examine zdbm. What? oh that is included with c-news or inn.
By the way, there were only three points. The fourth line was simply a comment.
**There are varying shades of darkness, I am but one of the many.**
Not true. This is a widespread misconception. This is no more or less legal than taking a GPLed source file, deleting the original copyright notice and inserting a BSD copyright notice.
Here's a quote from US copyright law:
In other words, if you add a copyright and GPL notice to the top of a public domain source file, without making any other changes, then the copyright and the GPL licence only applies to the copyright and the GPL notice, not to the rest of the file. The copyright and GPL notice do not place any restrictions on the original public domain source code ("does not imply any exclusive right in the pre-existing material").But wait, there's more. Consider this:
If you take a public domain source file that I wrote, and insert a "Copyright 1999 Patrik Nordebo" notice (plus a GPL notice), then you are committing a criminal offence.I have written a truly remarkable program which this sig is too small to contain.
Hey Jack,
We agree that Bamboo only represents a part of the whole solution,
however, we would not be so bold as to presume that we know the
correct component architecture needs for all possible future
applications. For that reason, we believe that currently the
proper place for such an architecture would best be served
within a Bamboo module, rather than in the Bamboo kernel itself.
That being said, we would love to collaborate on the design for
a COA module. Our internal projects are in need of just such a
solution. Unfortunately, our current resources and schedule can
only allow us to commit to helping with the specification, and to
adding whatever Bamboo kernel support is necessary, if any.
We hope to hear back from you on your thoughts.
Yours,
Kent and Howard