Slashdot Log In
Getting Software Added to Unix Distributions?
Posted by
Cliff
on Tue Jul 22, 2003 06:18 AM
from the lobbying-for-inclusion dept.
from the lobbying-for-inclusion dept.
suso asks: "I've been working on a set of programs called num-utils that I would eventually like to be considered for inclusion in some of the many free Un*x distributions (on the install CDs, etc). So my question is, how does one put their applications on the track to be included in the main distribution of Red Hat, Debian, SuSE, *BSD, and so on? Is this just something that is up to the maintainers or are there submission forms of some kind?"
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Linux is not Unix (Score:4, Funny)
Re:Linux is not Unix (Score:5, Funny)
Linux Is Not UniX
Prepare to be modded down.
Parent
Re:Linux is not Unix (Score:5, Informative)
*nix is much newer (circa mid-90s, rather than the late 80s Un*x started in) and is actually much less accurate. Un*x refers to Unix(tm), I've heard *nix refer to just about anything POSIX. Why don't more people refer to things by the standards they're actually judging Un*x-a-like systems?
Parent
Usefulness and Popularity (Score:5, Insightful)
Re:Don't use the GPL (Score:4, Informative)
Which systems are you referring to? I know the BSDs avoids GPLed code for drivers and core programs, but user packages is a different story. And OSX includes GPLed code. *BSD, All GNU/Linux, and OS X, I'd say that the GPL can get you into plenty of OSes.
-t
Parent
Write a text editor (Score:5, Funny)
Simple (Score:5, Insightful)
2. get the werd out. If people know about your package, it could solve a problem somewhere that would get it installed.
3. support it. if you support it, people will keep using it. even if it is initially crappy, you'll get bug fixes and advice.
4. package it. no one more than me.. 'cept for those that hate it more than me, hate doing custom compiles on a system that doesn't have
Then you live on w/ your life. If your software is good and fulfills a need, you'll see it get put in.
Then you can go onto 5. Profit. or ????. YMMV
Re:Simple (Score:5, Funny)
2. get the werd out. If people know about your package, it could solve a problem somewhere that would get it installed.
Somehow I get a feeling that he has that one covered. :)
Parent
Make noiseb about it (Score:5, Insightful)
Now, the main question is does it do ogg ?
Re:Make noiseb about it (Score:5, Funny)
It doesn't matter about ogg. Once it reads mail, then it is feature complete.
Parent
Re:Make noiseb about it (Score:2, Insightful)
Feedback forms (Score:5, Informative)
Step-wise procedure... (Score:5, Insightful)
2. Take out a coyright in your name.
3. Apply GPL notices to code.
4. Publish code via ftp.
5. Send code to Source Forge and Freshmeat.
Very difficult?
-
Publish first to website. (Score:5, Interesting)
Two ways:
How we did it (fpc, a pascal compiler)
- First the app was published on our site only, and gained momentum and peer review. This stage took several years.
- for the distributions where ordinary users can submit packages (*BSD ports and Debian) somebody
will do a port in time. You could do that yourself of course and speed up the process.
- After a time the commercial ones pick it up if it is really good. You can lobby for that too, but maintainers might also contact you if you have critical mass.
I found SUSE always the most responsive. RedHat is the only major that doesn't include it, and has been promising it for the next major version since 6.x times.
About SUSE there is a nice anecdote. I mailed our contact that a new version was out, and got a reply back that the final ISO had already been made. Two days later I got a mail back that they had to update a critical bug, and also updated our package to the newer version (which was a fixes only release btw)
The second way is to try to submit your packages to the FSF, so not just GPL it, but really get in bed with the FSF
FSF stuff more readily gets into distro's than third party projects. Of course again, they will only be really interested if your work is phenomenal.
Re:Publish first to website. (Score:4, Interesting)
The second way is to try to submit your packages to the FSF, so not just GPL it, but really get in bed with the FSF. FSF stuff more readily gets into distro's than third party projects. Of course again, they will only be really interested if your work is phenomenal.
That is not true. The GNU project (the FSF doesn't do this directly, the FSF is the foundation that sponsors GNU) will take on any software, as long as it is free, conforms to the GNU coding standards, and is not yet covered by other GNU packages.
Savannah (the GNU equivalent of Sourceforge) also carries a lot of near-dead projects.
Parent
Re:Publish first to website. (Score:4, Funny)
Savannah (the GNU equivalent of Sourceforge) also carries a lot of near-dead projects.
Savannah, where GNUs go to die...?
Parent
Re:Publish first to website. (Score:3, Informative)
The GNU project does not maintain any contributed software. The FSF does take responsibility for suing GPL offenders, but that requires you to sign over your code to the FSF (nothing scary, they grant you a no-strings attached license back.)
As for the coding standards: they are quite strict in enforcing those, in particular the cl
Reputation + Packaging (Score:4, Insightful)
HTh
Rus
GNU? (Score:3, Informative)
Your program will then automatically get into *all* distros
Nandz.
Is your app a virus by any chance? (Score:4, Funny)
Get eyeballs.. (Score:4, Informative)
The larger distributions will not carry your tool until it's become widely adopted by the Linux community - be thankful, otherwise RedHat 9 would require a DVD or two, instead of (just!) 3 CDs...
These utilities you have here, while useful, will probably not see much user adoption. However they would be very useful in shell scripting. If a more mainstream user application requires your utilities to function, the distro will be forced into including your stuff - as a dependency.
Make your own binary packages (Score:2, Informative)
This way you (or someone you know) can be an inofficial maintainer for your package. When your software becomes popular enough, it may eventually be included with the major distributions.
So my advice is basically: patience =)
Watch them closely (Score:2)
Simply send it to SCO (Score:5, Funny)
Money talks but here's some free advice... (Score:4, Informative)
But, of course, that's not what you wanted to hear. I'd check out their FAQs, ask questions in their relevant forums, usenet groups, etc. I'd imagine that each distribution has its own criteria for inclusion so your approach to one vendor might have to be completely different to your approach with another.
Whatever you do, bear in mind two (slightly paradoxical) things:
1. They probably get asked to include lots of software, some good, some bad and some downright ugly.
I know of one major magazine that was sent an application for inclusion on its cover disk that calculated sales taxes for you - by taking the figure you gave it and multiplying by the relevant amount. That's the chaff. You need to be the wheat. So make sure that your software is truly worth inclusion (Does anybody already have a similar offering in their distribution? How does yours differentiate itself? How is it superior?) before you start investing serious time and effort into promoting it.
Also, remember that there will be great pressure, both internal and external, for vendors to keep their distributions free of bloat. Even if your software is unique, does it really offer something that a significant proportion of the target audience will want and use? You could develop the best doll's house design software for Linux ever but if nobody wants to design doll's houses on their Linux machines then you're screwed.
2. If you really do have a product worthy of inclusion then persevere.
Once you find the distributions' relevant contacts, harrass and hassle them about it until you get some sort of feedback. If they say 'yes' that's great, but if they say 'no' ask why it's a not a go.
But remember, although it might be their jobs to deal with new submissions, it isn't their jobs to deal with crap. Don't be offensive, advesarial or overly aggressive and don't become a stalker (leaving two voicemails a day is a no-no) or the only answer you'll ever get is 'no'.
Good luck.
On Perl and command-line utilities (Score:5, Interesting)
Your mathematical utilities would be more useful if you had programmed them in C. Your choice of language will limit their adoption. Basically because using Perl scripts is not as fast as calling compiled C programs. This fact alone will make people reductant of using your utils in their code.
Because FreeBSD doesn't ship Perl as standard part of their distribution anymore, it'll be likely that your utils will not get included in any BSD software because it would pull in Perl. It may be a reason for Linux distributions too for not using your num-utils. Debian may be the only distribution which relies on Perl.
Re:On Perl and command-line utilities (Score:4, Interesting)
I have actually written a lot of this kind of code, working with huge datasets, and you are simply wrong. The performance of these kinds of utilities is dominated by I/O, not CPU. Furthermore, even the CPU-intensive parts of these utilities (conversions, etc.) are implemented in highly optimized C code inside Perl.
Because FreeBSD doesn't ship Perl as standard part of their distribution anymore, it'll be likely that your utils will not get included in any BSD software because it would pull in Perl.
I think Perl is a pretty awful language, but not including it in FreeBSD strikes me as a stupid decision. Perl is useful and works well across many systems. It's also not particularly big. If FreeBSD doesn't include Perl in the standard install, then FreeBSD has a problem, not people who write scripts in Perl.
What is BSD doing instead? Implementing all utilities in C? Gee, that's bright: let's create lots of unnecessary work for ourselves, increase maintenance hassles, make it really difficult to use good algorithms, make sure that there are plenty of opportunities for pointer bugs. That's negative progress: operating systems need less C programming, not more.
Parent
Re:On Perl and command-line utilities (Score:3, Insightful)
C requires painstaking attention to detail, but there is a large number of tools to check C programs for common mistakes such as memory allocation errors and pointer bugs. Scripting languages generally do not have an equally powerful toolset to check for runtime problems such as the typing and dependency errors which may occur when (components of) the scripting runtime are upgraded.
Scripts are fragile. Truly the last thing operating
Re:On Perl and command-line utilities (Score:3, Insightful)
C requires painstaking attention to detail, but there is a large number of tools to check C programs for common mistakes such as memory allocation errors and pointer bugs.
First, these programs cannot find all or even most such errors. Second, these programs cannot help you with the fundamental problem that you have written more code and on average the number of bugs is proportional to the amount of code.
Scripting languages generally do not have an equally powerful toolset to check for runtime proble
Re:On Perl and command-line utilities (Score:5, Informative)
This seems to be easily misunderstood, probably especially by Linux users where no distinction between base system and third-party apps exists (or in a less visible way, at least).
It did indeed mean that some tools in the base had to be reimplemented, either in C or as shell scripts. Obviously the majority of developers decided that this was less pain than having to keep one version of perl around even when users want a newer one, because you could break their systems otherwise, to have to check various important parts of the systems when you integrate an updated perl etc. The result of all this is that having an up-to-date perl is just one "portinstall perl" away, the system is more stable and modular, and, indeed, that trivial perl utilities like those in the article are unlikely to become base components. Big deal.Parent
Re:On Perl and command-line utilities (Score:3, Insightful)
That's obviously what I'm referring to: it's a 100M of binary code corresponding probably to millions of lines of messy C source code. And the notion that a 100M binary install is "lean" is itself absurd.
Also, the overhead of an interpreted language is inappropriate for the kind of command that's expected to be ran often and not take up too much time (like most of the applications found in various toolchains on unix)
That's silly: most of the stuff in a base OS in
Re:On Perl and command-line utilities (Score:3, Insightful)
It is included in FreeBSD, and it is installed by default, it's just not a part of the base system. The same situation occurs with XFree86. The base system is the operating system and environment. Stuff that isn't the OS, or isn't expected to be included with the OS, shouldn't be there. Bash isn't there. Emacs isn't there. Why should Perl be there? If you've ever used Slackware, you could consider the
Debian (Score:5, Informative)
Or, you could file an RFP (Request For Package). See instructions [debian.org].
I don't think it's really all that hard... (Score:4, Informative)
- It should fulfill a genuine need. If you're aiming for wide distribution you can't expect to achieve it with a something that's only relevent to a few people or in a few circumstances. You should also have some sort of document that shows how someone would save time or accomplish new things with this tool.
- It should be small yet robust, minimalistic yet powerful. I don't think anyone would consider adding a tool to a default install that is either too large for the features it offers, or two pedestrian in the type of features that it offers.
- It should be packaged well. Ideally it should compile and install in the proper locations out-of-the-box on a variety of systems. Make sure that it uses well-known methods, such as autotools (i.e. "./configure --prefix=/usr/local") or some other well-know "make; make install" type of setup.
- It should be well documented. At the very least you should have full manpages that your install script puts in the right place. Also consider man2html output on a web site, an possibly texinfo for the purists. You can't expect to get away with "just run --help and figure it out" or "look in the README."
- It should be licensed sanely, and should have reasonable dependencies. No one like a bizarro license, and no one likes a tool that takes sixteen different libraries of particular versions to compile.
- It looks like you're trying to get these tools standardized so that they could be relied upon for scripting... this will always be very hard to accomplish, but you might look into getting them merged with some popular packages, i.e. 'fileutils'. If there's a particular program that they are well-suited to being used with (like awk or something) then see about getting them added, perhaps in a "contrib" dir, to a project like that.
Frankly, though, your post was a little worrysome... in the sense that it almost seems like you're trying to get everyone to use these tools because they're there, not for some intrinsic reason. That just won't work, they have to do something really well or make it much easier to do some other task, etc.... You can get the word out and announce to various interested parties, but you will never be able to force anyone to do anything. In other words, view the situation as one of wanting to make the best programs you can, and if they receive universal support that's icing on the cake.
e-mail (Score:4, Funny)
HE's from SCO! (Score:4, Funny)
Meanwhile for Windows developers... (Score:5, Funny)
Build Mindshare (Score:3, Informative)
Just submit a new ebuild as a bug report. (No, that IS actually the proper way.) After a few weeks in the mill, your package will be out and about and happily rsynced in with every gentoo user. Gentoo are working on porting portage, their source distribution mechanism, to MacOSx and Window (running CygWin).
Of course, instant gratification is not a hallmark of the portage system.
You are competing with everybody else's widget in portage. So just make sure you get in cahoots with the folks who write the install docs, and have your software be made the subject of a few ZDnet articles. Writing a HOWTO based around your product is also a good idea.
How it worked for me .. (Score:5, Informative)
Once upon a time I wanted an MP3 streaming server, none of the ones I looked at did what I wanted. So I did the standard thing and designed my own.
After releasing my first version to freshmeat [freshmeat.net] I had about five subscribers to the project.
These subscribers gave me patches, feedback, and encouragement.
Doing a websearch [google.com] for the project name I discovered by accident that the the package made it into Gentoo [gentoo.org], and similarly Netbsd without any feedback or involvement from myself!
The next step was my becoming a Debian Developer [debian.org] so that I could upload it there - and not worry about other people doing a bad job without me. (Not a real concern; I had wanted to join Debian for some time anyway).
Now life is good - I've no idea if it's in RedHat because I've not touched it for years, but SuSE include it the *BSD's and Gentoo cover it, and Debian gets the latest versions all the time.
Freshmeat lists 120+ subscribers to the project, and it's probably on the verge of becoming an official GNU package sometime soon.
If you use it and like it buy something nice? [amazon.co.uk] </ObPlug>
Version? (Score:3, Insightful)
unique? (Score:5, Insightful)
that make me wonder what round does if it has problems with decimal numbers.
Joe
Transparent Debian (Score:3, Informative)
Either add your package to the wanted [debian.org] list, or become a Debian Developer [debian.org] yourself.
I'm not saying becoming a Debian Developer is quick or easy (though few would describe it as really hard), but the process is very transparent, and available to anyone. In part, I suspect this transparency, in combination with its maturity, is why Debian has so many more packages than any other software distribution.
Never underestimate the power of transparency.
It's in Gentoo... (Score:3, Funny)
Searching...
[ Results for search key : num-utils ]
[ Applications found : 1 ]
* sys-apps/num-utils
Latest version available: 0.3
Latest version installed: 0.3
Size of downloaded files: 28 kB
Homepage: http://suso.suso.org/programs/num-utils/
Description: Set of programs for dealing with numbers from the command line
HAHA don't get so excited...just pulling your leg.
the FreeBSD perspective (Score:4, Informative)
easy (Score:3, Funny)
Oh, wait. Nevermind.
For real though, just post it on freshmeat and if people have an interest it'll get popular quick.
To be included in Solaris... (Score:4, Funny)
- Use the Solaris package tools to create a package for your program, make the default install directory somethig sensible such as
- make sure the package requires a few libraries that will take a least a day of pain to install on to any Solaris box.
- Ensure to include a man page, avoid using words with less 5 syllables, refer to everything as n.
- now do nothing for roughly six years (more if the program is required for other popular applications).
- Once that is done, send the package to sunfreeware (because downloading endless packages from the designed-by-satan website is by far the quickest way of installing essential programs via a text based console).
- It can sometimes only take a few years from this point for Sun to include it on the Solaris CDs!
- Of course, they will first need to put it through the flag-randomiser to ensure no command line switch is the same as what it is for every other OS in known universe. It will also remove --help and -h, to avoid you having to do this yourself.
- Just think, by Solaris 27 (aka SunOS 2.9.1) you can see your package installed by default from a Solaris CD!
cjk
PS remember, if your program involves text editing, ensure it implicitly uses ed, lord knows what confusion it will course otherwise.
For Mandrake Linux ... (Score:3, Informative)
More and more development is being done by the community, so you may want to stop by the cooker wiki [mandrakesoft.com] which may have more up-to-date documents than those on the Mandrakesoft website.
Oh My God. (Score:5, Insightful)
But just in case I'm wrong, here's what you do: Point your browser to CPAN [cpan.org]. Carefully read the instructions. Submit your scripts. If they're good, they'll get used, you'll make a name for yourself, and will be on the way to The Big Time.
I really can't believe this made
Re:Have you considered developing for windows? (Score:2)
Though, it may be useful to have those for shell scripting.
This was ask.slashdot.org. Who would expect a Spanish inqusition?
Re:learn awk (Score:3, Informative)
you wrote 8 apps, in perl, that should take any perl programmer 2 minutes to do (and are so simple, one should use awk for them).
the body of your apps has more text that is dedicated to license and documentation than actual code.
your implementation is crap. i quote from your 'random' man page:
random is slow when dealing with large ranges to randomly find a number from. This is because it creates a list of all potential numbers before picking one. So it can be memory intensive for large ran