Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Software Operating Systems Unix

Getting Software Added to Unix Distributions? 267

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?

Comments Filter:
  • 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.
  • 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.

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

  • 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.
  • by sumirati ( 639201 ) on Tuesday July 22, 2003 @08:29AM (#6498156) Homepage
    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, check your facts before posting ...
    ... ah, but this IS slashdot, or?
  • by Anonymous Coward on Wednesday July 23, 2003 @03:39PM (#6514071)
    Of course, again, the notion that there is anything "lean" about a 100M binary install anyway is just laughable.

    I just ran ldd on my perl binary and then wc on the perl and the libraries, try it and then we'll talk about laughter.

    I think the best thing for you to do is stop moaning and write an entire OS with Perl compiled directly into the kernel (for speed*), because scripting languages are so great.

    * most of the stuff in a base OS install either is not performance critical at all

    HAHAHAHAHAHAHAHAHAHAHAHAHAHA!

    Thanks

Intel CPUs are not defective, they just act that way. -- Henry Spencer

Working...