Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
Software Operating Systems Unix

Getting Software Added to Unix Distributions? 267

Posted by Cliff 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.

Getting Software Added to Unix Distributions? More

Getting Software Added to Unix Distributions?

Comments Filter:

  • Linux is not Unix (Score:4, Funny)

    by Flounder ( 42112 ) * on Tuesday July 22, 2003 @07:22AM (#6497870)
    unless, of course, SCO wins their lawsuit.

  • Usefulness and Popularity (Score:5, Insightful)

    by turgid ( 580780 ) on Tuesday July 22, 2003 @07:22AM (#6497872) Journal
    If your programs are genuinely useful and well-written, they will build up a user base over time. Eventually they will become viewed as worth putting in a distribution.

  • Write a text editor (Score:5, Funny)

    by Anonymous Coward on Tuesday July 22, 2003 @07:23AM (#6497878)
    Write another text editor app, then it will be sure to be included in the distro. Distros dont have enough text editors in them.

  • Simple (Score:5, Insightful)

    by sporty ( 27564 ) on Tuesday July 22, 2003 @07:23AM (#6497879) Homepage
    1. port it to as many systems as possible, even non-targert systems. possibly AIX, old Digital Unix.. you name it.

    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 /usr/ports or emerge.

    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)

      by trikberg ( 621893 ) <trikberg AT hotmail DOT com> on Tuesday July 22, 2003 @07:32AM (#6497916)

      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. :)

    • "2. get the werd out. If people know about your package, it could solve a problem somewhere that would get it installed."

      Well I know that some memeber of the Linux community can be a bit high strung but I would called the weird

      Rus

  • Make noiseb about it (Score:5, Insightful)

    by makapuf ( 412290 ) on Tuesday July 22, 2003 @07:24AM (#6497882)
    Not to sound flamebait, but you're quite right in doing it : giving it the maximum visibility (for example by posting a link to it on a popular news discussion site) will make a few people notice it exists.

    Now, the main question is does it do ogg ?

  • Feedback forms (Score:5, Informative)

    by Novus ( 182265 ) on Tuesday July 22, 2003 @07:24AM (#6497887)
    For starters, you could try looking for feedback forms on the distributions' web sites, such as these forms for SuSE [www.suse.de]. Forms like these are often intended to bring suggestions to the attention of the distribution developers.

  • Step-wise procedure... (Score:5, Insightful)

    by jkrise ( 535370 ) on Tuesday July 22, 2003 @07:25AM (#6497889) Journal
    1. Write software.
    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?

    -
    • You don't "take out" a copyright. Anything you produce, by definition, has a copyright attached. Whether or not that is compatible with other licensing schemes is a different ball game.
    • 1. Write software.
      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.
      6. ???
      7. Don't Profit!

      :)

  • Publish first to website. (Score:5, Interesting)

    by marcovje ( 205102 ) on Tuesday July 22, 2003 @07:26AM (#6497893)

    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)

      by hanwen ( 8589 ) on Tuesday July 22, 2003 @07:33AM (#6497917) Homepage Journal

      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.

      • Re:Publish first to website. (Score:4, Funny)

        by BetterThanCaesar ( 625636 ) on Tuesday July 22, 2003 @08:21AM (#6498118)

        Savannah (the GNU equivalent of Sourceforge) also carries a lot of near-dead projects.

        Savannah, where GNUs go to die...?

    • I also found SuSE very responsive and helpful.

      For Pure-FTPd, they subscribed to the mailing-list, reported bugs, proposed patches and they helped us to build RPMs, even for other distros.

      The same thing applies to the Polish Linux Distribution.

    • Re:Publish first to website. (Score:2, Informative)

      by Anonymous Coward
      That's pretty much how it works. Let me try to add how it worked for GStreamer [gstreamer.net], the project I contribute to.
      1. Write software that people need.
        This is the most important step. You have to have a piece of software that has value for people (and therefore for a distribution). It may be software that is missing, it may be that it does something better than others.
      2. Wait for those people to show up.
        Release your software, work on it. Since it's good people that need it will show up and use it. Open source softwar

  • Reputation + Packaging (Score:4, Insightful)

    by rf0 ( 159958 ) <rghf@fsck.me.uk> on Tuesday July 22, 2003 @07:28AM (#6497899) Homepage
    Half of it is about reputation and having a good following. The other thing that helps is to supply packages for each distro. i.e rpm for redhat, deb for debian. For others like FreeBSD which have the ports tree see if you can get your files commited

    HTh

    Rus

  • GNU? (Score:3, Informative)

    by metalmaniac1759 ( 600176 ) on Tuesday July 22, 2003 @07:28AM (#6497900) Homepage Journal
    I think Gnu should help. Try submitting on their site. If you code according to their guidelines, and if your software is useful enough they will include it in some package (something like what binutils is).
    Your program will then automatically get into *all* distros :)

    Nandz.
    • Nah this is all but Informative, GNU itself only supports software that fits in their strategy...

      If you make software under the GPL, do not expect direct help from the FSF, it's first not their obligation to do so, second you will only get disappointed.

      They have of course savannah, to help you distribute, but do not expect to become a FSF owned package, these are rahter limited.

  • Is your app a virus by any chance? (Score:4, Funny)

    by Anonymous Coward on Tuesday July 22, 2003 @07:28AM (#6497902)
    If so it will add itself eventually.

  • Get eyeballs.. (Score:4, Informative)

    by Graelin ( 309958 ) on Tuesday July 22, 2003 @07:29AM (#6497905)
    The distro maintainers make these decisions based on popularity and dependency. Why include software nobody ever uses?

    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 these decisions based on popularity and dependency

      i just thought of something....just get a bunch of other packages that depend on your package....and bingo!! you'll be included right away....ofcourse, this is what leads to dependency hell, but, whadda you care? you just want to get your package in a main distro, then get a good job, make lots of money.......

  • I think you should make your own binary packages, or get someone else to do it for you (for the distros/architectures you don't have access to). I've seen you already have rpm's on your site, so that's a good start.
    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 =)
  • If your application is popular enough, or does something that is in high demand, they (insert any distribution) will include it. Of course they won't tell you (actually, FreeBSD occasionally stands out from the crowd and tells you if your app is in their ports system), and they will also not tell you about the bugs they have found, and the patches they use to fix these bugs.

  • Simply send it to SCO (Score:5, Funny)

    by Advocadus Diaboli ( 323784 ) on Tuesday July 22, 2003 @07:38AM (#6497937)
    They will take care of it and will find evidences that your code is already illegally included in all major distributions, the kernel and the rest of the world. And they will offer a license for using it.

  • Money talks but here's some free advice... (Score:4, Informative)

    by WIAKywbfatw ( 307557 ) on Tuesday July 22, 2003 @07:40AM (#6497949) Journal
    $100,000 buys you 10 minutes of face-to-face time with Dubya and I bet a similar "donation" would get you some time with the guys at Red Hat, SuSe, etc.

    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)

    by juahonen ( 544369 ) <jmz@iki.fi> on Tuesday July 22, 2003 @07:42AM (#6497965) Homepage

    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.

    • The other thing is that several of the utilities (or at least 90% of their functionality) can be implemented in 1-2 lines of sh or awk.

      Really, if you're shooting to be included in a distribution, make it for something worthwhile.

    • Re:On Perl and command-line utilities (Score:4, Interesting)

      by 73939133 ( 676561 ) on Tuesday July 22, 2003 @08:13AM (#6498078)
      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.

      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.
      • think Perl is a pretty awful language, but not including it in FreeBSD strikes me as a stupid decision

        It's not in the base distribution.
        That means that it is an additional package that is installed more or less automatically during install (unless you don't install any packages, eg. because you want PERL5.8 and install that later). It's not in the base-system because it makes "make world" more difficult.

        What is BSD doing instead? Implementing all utilities in C?

        Indeed. The base system works withou

        • Indeed. The base system works without PERL (beginning with 5.0-REL).

          I don't view that as a plus. I think a base OS install should come with a full-featured scripting language that gives access to all OS facilities, and as much stuff as possible should be implemented in it.

          If you think about it, it's not a bad system design decission to try to make the base-install leaner.

          The base install would get a lot leaner if it were based on a scripting language and a lot of the utilities were implemented in it-
          • I don't view that as a plus.

            It was reported that PERL often broke make world.
            I didn't have this happen to myself, but smarter people than myself complained, so I guess it had some substance...

            But converting utilities into C code is just completely the wrong direction.

            The effort was very minimal, IIRC. adduser(8) was probably the only bigger one.
            I can install PERL5.6 or PERL5.8 without fearing to ruin the base-OS.
            For me, this is a big ++

      • The benefits of scripting over languages such as C are grossly overrated.

        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

        • 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)

        by __past__ ( 542467 ) on Tuesday July 22, 2003 @09:11AM (#6498399)
        FreeBSDs decision to move Perl from the base system to the ports tree was because it was easier to handle that way, both for developers and users. It was not about not supporting it anymore. In fact, it is supported quite well, including automatic integration of CPAN packages with the package management utils etc.

        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.
        • FreeBSDs decision to move Perl from the base system to the ports tree was because it was easier to handle that way, both for developers and users. It was not about not supporting it anymore.

          Not including it in the base system is what I mean by "not supporting it": I want some scripting language be available out of the box on any desktop or server, and Perl is the obvious choice.
          • Wouldn't the obvious choice be sh scripting, since it is available everywhere, and it's not like it's hard to get Perl into FreeBSD, either select a package that requires Perl when you install your system, or select Perl itself, it's on the install CD.

            It's just that if you do a minimal install, it's not there, which if you're talking 100 megs and Perl is another 12 is a good amount you might not want.

            And also for those of us who don't want Perl on our systems there's no extra work of removing it, adding s
      • Perl - optimised ... nah sorry , those 2 words just don't go together in my mind.

        Replace "Optimisation" with "Obfuscation" and I'm with you all the way!

        You seem to not understand how small utilities are used in unix. They are generally NOT used
        as standalone programs , but rather put in scripts or pipes and called in sequence or
        frequently over and over again in a single script. The one thing you do NOT want when doing
        something like this is having the overhead (and time wasting) of kicking off a lar
      • All base utilities are implemented in C or sh, but there's no reason they wouldn't include a port which uses perl. In fact there are tons of ports which use perl, and they just pull in perl as an installation requirement.

        Dropping perl from the base distribution was an incredibly good decision as it made it easier to keep perl up to date, while also making it easier for people working in embedded systems to keep perl out of the system. If you don't think the 60 megs which is perl matters, look at the cos

      • I think Perl is a pretty awful language, but not including it in FreeBSD strikes me as a stupid decision.

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

      Yes, Perl is no longer a part of the base FreeBSD installation (as long as for 5.x). It is a port instead - like UUCP and some others. And Perl is ALWAYS installed by DEFAULT! [freebsd.org]

      Please, ch
    • It wouldn't be approriate to include mathmatical utilities in the *BSD's, since they (at least FreeBSD) tend towards the server market. They don't install stuff for the sake of having it all.

      Add it to the ports, so that it does ship with the OS, and the user can install if they want to. A cd into the proper directory, and then make install is all that is needed.

  • Debian (Score:5, Informative)

    by nvainio ( 135908 ) on Tuesday July 22, 2003 @07:45AM (#6497982) Homepage
    If you want your program to be included in Debian, you may package it yourself. Debian New Maintainer's Guide [debian.org] is a good place to start at.

    Or, you could file an RFP (Request For Package). See instructions [debian.org].

    • > If you want your program to be included in Debian,
      > you may package it yourself.

      That won't get it included in Debian. Only Debian developers can add packages to the distribution.

      > Or, you could file an RFP (Request For Package).

      Yes.

  • I don't think it's really all that hard... (Score:4, Informative)

    by onomatomania ( 598947 ) on Tuesday July 22, 2003 @07:48AM (#6497989)
    The people that tend to do packaging are not likely to be influenced by you pestering their Inboxes, or filling out forms, or posting to forums, etc. Instead, ensure that your program meets the following requirements, and you should have no problems.

    - 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)

    by jpmorgan ( 517966 ) on Tuesday July 22, 2003 @07:50AM (#6497992) Homepage
    Make sure it can check your e-mail. No software is complete until it can check your e-mail.
  • 1) Code
    2) Mention on /. you've written some C code to do what 2 lines of shell could do
    3) ????
    4) Profit?!

  • HE's from SCO! (Score:4, Funny)

    by servicepack158 ( 678320 ) on Tuesday July 22, 2003 @08:01AM (#6498033) Homepage
    He's trying to sour the batch! Don't let him near it! :) j/k

  • Meanwhile for Windows developers... (Score:5, Funny)

    by Flashpoint X ( 598246 ) on Tuesday July 22, 2003 @08:02AM (#6498035)
    Thankfully in the Windows world I don't have to concern myself about getting included in "official" distributions... I prefer to distribute my software via self-propagating emails. ;)
  • If your app is useful to a large number of people, don't worry, it'll be included. The more people it appeals to, the faster it'll be adopted.

    Just let nature take its course. If no one wants to include your package, there is no point in having it included for the sake of vanity.

    If you are fairly confident of its usefulness, include a debian directory, and a rpm spec file in your source. That'll make it easy for people to package.

  • Build Mindshare (Score:3, Informative)

    by EvilTwinSkippy ( 112490 ) <yoda.etoyoc@com> on Tuesday July 22, 2003 @08:09AM (#6498063) Homepage Journal
    Some distribution, I'm thinking of gentoo, have a user submission feature for new packages.

    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.

  • While I'm all for writing more command line utilities in general (as opposed to the kind of cumbersome GUI stuff everybody does), these particular kinds of command line tools are usually done using awk. For example, to sum up a column of numbers, write:
    $ awk '{s+=$1}END{print s}' < file
    • The ironic thing is that, even if you were using these utils, if the numbers you wanted to sum up didn't happen to be in the first column, you'd have to use awk to extract them anyway...

      (actually, the '' is redundant in that command line ... awk takes input files as commandline arguments)

  • How it worked for me .. (Score:5, Informative)

    by stevey ( 64018 ) on Tuesday July 22, 2003 @08:20AM (#6498104) Homepage

    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>

  • Seeing as how the tools are in Perl... you might try rearranging them until they're acceptable to CPAN first.

    This probably involves making them more module-like and less command-line like. This may be a fundamental change for you and your tools. (It looks like most/many of them would be single lines in Perl... hard to call that a "module").

  • Version? (Score:3, Insightful)

    by pjdepasq ( 214609 ) on Tuesday July 22, 2003 @08:37AM (#6498192)
    Dude, you're only at version 0.3. Don't you agree that it's a little early to be talking about adoption by the distributions?
  • Get your app mentioned on Slashdot.
    Oh, hang on....
  • In my experience, you're only going to get picked up in a distribution if someone who happens to be a maintainer takes a liking to your program. I released a program about five years ago and not long after one of the package maintainers for Debian contacted me about clearing up the licensing because he wanted to add it to the next release. Some time later it was added to the ports tree for OpenBSD (though no one contacted me about that, not that I really care).

    So basically, I think that if you want your

  • unique? (Score:5, Insightful)

    by battjt ( 9342 ) on Tuesday July 22, 2003 @08:46AM (#6498237) Homepage
    Your commands are already installed on my system, or aren't needed.
    average
    awk '{sum+=$1}END{print sum/NR}'
    bound
    awk 'NR==1{min=$1}{max=$1>max?$1:max;min=$1 &lt; min?$1:min}END{print min,max}'
    interval
    awk '{print $1-last; last=$1}'
    numgrep ( 500 < x < 1000 or x is a multiple of 3)
    awk '$1 < 1000 && $1>500 || $1%3 == 0 {print $1}'
    numproc
    awk '{print $1 [[your math expression expressed in standard infix notation]]}'
    numsum
    awk '{sum += $1}END{print sum}'
    random
    awk supports rand(), bash has $RANDOM, Linux has /proc/random for a stream of random data. Any range can be chosen using 'numproc', for instance /1..10/ is 'rand() * 10 + 1'
    range
    Why are you ever instantiatin ranges? It wastes space. Ranges should be abstractly manipulated.
    round(floor)
    awk '{print int($1)}'
    round(nearest n)
    awk '{print int($1/n)*n}'
    These commands are easy to use and have a transparency that makes it very clear what the bugs would be, where as num-utils has warnings like

    round will drop off the decimal places in decimal numbers. This may cause some calculations to be in error, depending on how you are using the data.

    that make me wonder what round does if it has problems with decimal numbers.

    Joe

  • You seem to be working explicitely with files, I tried to type "average 1 2 3" and got a file error, why not use?

    cat numbers.file | average

    This would make the commands script friendlier I think.

    Also, echo '1 2 3' | average output 1, which confused me, I fixed this by changing line 117 in 'average' to read

    while (m/\s*(\-?[0-9]*\.?[0-9]+)/g) {

    ,i.e., the if -> while, and ^ has gone, and the 'g' flag is used, this does all white-space separated numbers on a line. (That can be your first(?) bug-f

  • A big requirement for inclusion in any packaged distribution is the usefulness of the package. This package does not seem useful, from what I've seen already.

  • Transparent Debian (Score:3, Informative)

    by debrain ( 29228 ) on Tuesday July 22, 2003 @08:56AM (#6498293) Journal
    I don't know about the rest of the world, but the process for getting something into Debian is fairly transparent.

    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. :)
  • Just to throw out a variation on this topic...

    I had an ex-coworker ask me a similar question recently, becaues he knows I am pro-Linux. I didn't really know the answer. I looked around at some distro FAQs, and couldn't find anything. He was working with a company who had written some an API for an SSL/IPsec offload chip that was getting included in major motherboards. They needed to figure out how to get it included into the Linux distros, and were currently working to get it into *BSD. Now that isn't

  • It's in Gentoo... (Score:3, Funny)

    by dotgod ( 567913 ) on Tuesday July 22, 2003 @09:17AM (#6498424)
    alexscomp alex # emerge -s num-utils
    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)

    by JDizzy ( 85499 ) on Tuesday July 22, 2003 @09:28AM (#6498496) Homepage Journal
    First off, we dislike having gpl code in the base system, but we do have gpl stuff (but always a bsd fall back) for things like tar, gcc, dialog, rcs, sort, gzip, and just a few others. We keep our /bin and /sbin clean of the gpl. We typically think that awk or perl is capable of this sort of thing, and to get a program like this into the base system requires at the very least a commit bit in the cvs tree, or approval form the core team, or membership to the core team (yeah right). Since a text-processing, or rather a number processing, program is considered to be strictly useless to a base system's functionality, it would most certainly be religated to the ports tree. Don't kid yourself, you might think your software is the best thing under the sun since sliced bread, but to be so bold as to think it needs to be included in the base of any Unix-like-system is a pipe dream.

  • easy (Score:3, Funny)

    by hexix ( 9514 ) on Tuesday July 22, 2003 @09:34AM (#6498532) Homepage
    Just put a blatant plug for it in the form of a question on Slashdot.

    Oh, wait. Nevermind.

    For real though, just post it on freshmeat and if people have an interest it'll get popular quick.
  • Your software just got included in the source-based distribution "lunar-linux"

    http://www.lunar-linux.org/ [lunar-linux.org]

    good luck getting it in other distro's.

  • Just write an ebuild and submit it to www.breakmygentoo.net

    Or, if you have enough of a following, have one of your Gentoo-using minions to write the ebuild for you. Packages that are on breakmygentoo.net have the best exposure you can get while the auditing process on your package over at bugs.gentoo.org makes sure it can be a viable addition to the standard portage tree.

  • To be included in Solaris... (Score:4, Funny)

    by Chris_Keene ( 87914 ) on Tuesday July 22, 2003 @10:32AM (#6498981) Homepage Journal
    For Solaris, once your util becomes an essential application used everyday by 99.9% of Solaris users, Sun and your good self can follow this procedure:

    - Use the Solaris package tools to create a package for your program, make the default install directory somethig sensible such as /opt/SUNWats/sun4u/bin/thiswillneverbeinyourPATH/p kg1921u9238/

    - 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.
  • How many digits are supported? The claim is made to sum the numbers in a file, so I would expect some sort of unlimited precision system, or at least well defined limits. For fractional parts, how do you control the number of digits shown? The average of 1, 0, and 0 would be 0.33333333333333333....

  • For Mandrake Linux ... (Score:3, Informative)

    by buchanmilne ( 258619 ) on Tuesday July 22, 2003 @11:41AM (#6499837) Homepage
    ... you can follow the guidelines on their site [mandrakelinux.com], although it may also be helpful to post a link to an SRPM in your mail (which you should also cc to the cooker list [mandrakelinux.com], since the employee handling contribs is very busy, but there are a lot of non-employee contributors who will be able to add your package.

    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.
  • Note to self...someone is trying to get a program called num-utils installed on as many unsuspecting machines as possible. Must be some new back-door or trojan...do not install. :)

  • Oh My God. (Score:5, Insightful)

    by pongo000 ( 97357 ) on Tuesday July 22, 2003 @11:55AM (#6499998)
    I'm sorry, but I think we've all just been trolled. I don't believe there's really an attempt to ask a valid question here. This individual has written a couple of perl scripts, and truly believes they will change the world. He hasn't done any research (no mention of CPAN, thinks that FreeBSD does Perl, etc.), and truly believes that a few Perl math routines will change the world. Can you spell "ego trip"?

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

  • I have written some articles on the general topic of software quality, which you'll find at http://linuxquality.sunsite.dk/articles/ [sunsite.dk].

    So far the articles are:

    • Why We Should All Test the New Linux Kernel
    • Using Test Suites to Validate the Linux Kernel
    • Use Validators and Load Generators to Test Your Web Applications
    • Free Hosting Service HTML Validation Test Page
    • Pointers to C++ Member Functions

    The Open Source Development Lab has kindly translated the two kernel articles to Japanese. I am actively seeking

  • It's not hard to look up how to do it, when it's possible to do it. For example to add an item to Gentoo you have to fill out a form in their Bugzilla database pointing to your ebuild file you want to add to the tree. I've submitted a few different things, some were accepted, some were rejected.

    Redhat (last I checked, which was 3 years ago) has a much less formal method, you just email one of the people on the team and they may or may not add it in. Usually they won't, unless you can show that it's worth t

Slashdot Top Deals

((lambda (foo) (bar foo)) (baz))

Close