Slashdot Mirror
Getting Software Added to Unix Distributions?
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?"
unless, of course, SCO wins their lawsuit.
No boom today. Boom tomorrow. There's always a boom tomorrow. - Cmdr. Susan Ivanova
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.
Stick Men
Write another text editor app, then it will be sure to be included in the distro. Distros dont have enough text editors in them.
1. port it to as many systems as possible, even non-targert systems. possibly AIX, old Digital Unix.. you name it.
/usr/ports or emerge.
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
-
ping -f 255.255.255.255 # if only
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 ?
For starters, you could try looking for feedback forms on the distributions' web sites, such as these forms for SuSE. Forms like these are often intended to bring suggestions to the attention of the distribution developers.
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?
-
If you keep throwing chairs, one day you'll break windows....
in debian it's pretty easy, you just have to find someone willing to package it, including you
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.
After taking a quick glance at the package I didn't see anythink I couldn't do with a quick awk statement or two.
I am sure some if you talk to some UNIX/gnu linux distros, they would tinker with it. Mandrake would be a good company to ask to include programs. Distros like Redhat and such wait until the application is more coming of age.
You could also jump on serveral mailing lists and such. Perhaps, post you thoughts in a public forum to be rediculed.
Place something witty here
Hmm - I wonder if asking people about how to get noticed will actually end up getting me noticed...
Too bad this now won't work for everybody - so yeah how does one do this?
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
Cheap UK and US VPS
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.
If so it will add itself eventually.
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.
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 =)
The Open Source movement, otherwise known as 'Free Software', has been a topic of considerable debate on the Internet's most controversial site. The majority of this debate has centered around the technical merits of the software, with the esteemed editors argueing against adopting Linux by employing the full depth of their considerable intellects, and the other side hurling death threats and similar invective. This has allowed many who would not otherwise receive quality information about Open Source software to be made aware of many of its ramifications, but one issue has been left alone: The overt racism that is deeply embedded in the movement.
Allow me to explain.
Alan Cox; Richard Stallman; Bruce Perens; Wichert Akkerman; Miguel DeIcaza.
What do you see in this list of names? Are there any African-Americans on it? Absolutely not, none of those names sound like one a self-respecting black person would have! No Maurice, no Luther, no Lil' Kim. There are many other lists such as this, you can see one here. Flip through each page, do you see anything other than white faces? Of course you don't, because Open Source and its adherents are ardent racists and they absolutely forbid access to the sacred 'kernel' by any person of color.
Lets look at another list, this time a compendium of the companies using Linux. Are there any black owned companies on that list? Nooooooo. How about these companies? They all have something to do with Open Source software, any of them owned by an African-American? No again. Here is an extensive collection of photographs from a LUG (Linux User Gathering) meeting, more can be viewed at that link. What is odd about these pictures, and every other photograph I have ever seen of a LUG meeting, is that there is not one single black person to be seen, and probably none for miles.
More racist overtones can be found by examining the language of Open Source. They often refer to 'white hat' hackers. These 'white hats' scurry about the Internet doing good, but illegal, acts for their fellow man. In stark contrast we find the 'black hat' hackers. They destroy the good works of others by breaking into systems, stealing data, and generally causing havoc. These two terms reflect the mindset of most Linux developers. White means good, black means bad. Anywhere there is black, there is uncontrollable destruction and lawlessness. Looking further we see black lists that inform other users of 'bad' hardware, Samba, an obvious play on the much hated Little Black Sambo book, Mandrake, which I won't explain except to say that the French are notorious racists. This type is linguistic discrimination is widespread throughout the Open Source culture, lampooned by many of its more popular sites.
It is also a fact that all Unix 'distros' contain a plethora of racist commands with not so hidden symbolism.
It can hardly be coincidence that the prime operating system of choice of the 'open source supremacists' - Linux, features commands which are poorly disguised racist acronyms. For example: 'awk' (All White Klan) , 'sed' (shoot nEgroes dead), 'ln' (lynch negroes), 'rpm' (raical purity mandatory), 'bash' (bring a slave home), 'ps' (persecute sambo), 'mount' (murder or unseat nubians today), 'fsck' (favored supreme Christian klan). I could go on and on about the latent racist symbolism in Linux, but I fear it would take weeks to enumerate every incidence.
Is there a single unix command out there that does not have some hidden racist connotation ? Suffice it to say that the racism pervades Linux like a particularly bad smell. Can you imagine the effect of running such a racist operating system on the impressionable mind ? I don't have to remind you that transmitting subliminal messages is banned in the USA, and yet here we have an operating system that appears to be one enormous submliminal ad for the Klan!
One of the few selling points of Open Source software is that it is available in many differ
You can get a much larger customer base, and hence considerably more exposure if its vaguely useful. You can even charge a small $5 shareware registration fee (and maybe even get $5 if someone likes the software enough).
Once Linux users start realising that they need such a tool, simply release a GPLed version for Linux.
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.
Sorry to say this, but from what I have seen this set of tools can be written in less than a day.
It seems to me that the first step towards inclusion in the major distros is having a more creative
product...
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.
$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.
"Accept that some days you are the pigeon, and some days you are the statue." - David Brent, Wernham Hogg
Give it to sco. They will insert it and then claim ownership wether it is theirs or not.
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.
I've read what your tools are about, however I don't feel like it's something people MUST have unlike bc.
I guess bc is less handy, but it does a great job and has always been enough for command line computations.
He should write a BreakOut or Tetris clone. If he ensures that it has a version number like 0.3.5 and never, ever, reaches 1.0, then it is sure to be included!
Or, you could file an RFP (Request For Package). See instructions.
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.
Make sure it can check your e-mail. No software is complete until it can check your e-mail.
Sorry, but I can't see why would a limited package like "num-utils" would be of any interest.
Perhaps these multiple utilities combined into one with options to alter the behavior, like the way that busybox behaves, might be easier to use. Users will forget the names of these multiple tools.
A lot of tech users would generate these utilities as required with a couple of lines of awk. Appealing to these folks will be difficult. Each of these can seemingly be repilcated without too much trouble.
As was written previously above, correct man pages (nroff -man) (see the man macros) will be essential.
Ask for help developing, and for ideas as to what might be included in the tools. You are the controller but you have to provide what other people want
my $.02
Why is it such a big deal to you that your software gets included in a distribution? Is that the only reason you're writing them? If it is then I suggest you stop now, because you're only going to end up being disapointed. Seriously, you may think that your num-utils are the bees knees, and that everyone would want a copy, but uh, they won't. Your tools are simply not that useful, and can be done hundreds of other ways (As many others have pointed out already).
If you're actually writing num-utils because you have a specific need for them, and you could not find any other way of doing what you needed, then that is fair enough. If thats the case though, why should you care; they do what you need, right?
1) Code /. you've written some C code to do what 2 lines of shell could do
2) Mention on
3) ????
4) Profit?!
He's trying to sour the batch! Don't let him near it! :) j/k
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. ;)
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.
I want to delete my account but Slashdot doesn't allow it.
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.
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.
"Learning is not compulsory... neither is survival."
--Dr.W.Edwards Deming
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 I had about five subscribers to the project.
These subscribers gave me patches, feedback, and encouragement.
Doing a websearch for the project name I discovered by accident that the the package made it into Gentoo, and similarly Netbsd without any feedback or involvement from myself!
The next step was my becoming a Debian Developer 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? </ObPlug>
Right now there is a large effort underway to simplify the architecture in distributions, with redundant programs being removed. This is because one the biggest problems with the desktop is that the user is overwhelmed with programs that all do the same thing. Many distibutions don't come with emacs anymore because its to complex for its purpose (read: edit files). So its mostly either VI(M) or pico/nano that comes installed.
Even gnome/kde are starting to merge some of their core libraries/standards. For example there are plans to stip arts/esd out and replace it with alsa when linux kernel 2.6 comes out.
So if you wan't your tools included, you got make sure it is a) unique b) dosen't suck c) Good documentation d) Uses the standard architechture.
Why?
Stick Men
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").
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....
Since your package is written in perl, it might be a good idea to check out CPAN.
Check if they have anything that looks like your package (there might well be some math packages already (also remember to check what is shipped with perl). If there is, you might consider joining forces with whoever maintains the package that comes closest to yours. Move the logic of your programs into the modules you have found and make your programs as simple as possible, using the features of the combined modules. Then include tests, documentation and anything else you think would be relevant and contact the module maintainer with a patch or a new version. If (s)he accepts the contribution, the result should be a better and more useful package than either of you had before.
If you think you have found the perfect package to join forces with, but the maintainer does not want to hear your arguments, consider closely what you are offering. It might be that (s)he is right to turn you down, or there might be something you need to fix to fit into the package. If you get nowhere - and you are absolutely sure you have found the perfect home for your code, you might be able to make a fork (e.g. if the package you want to fork is GPL). Stop and think once more, whether this is the right course of action! You should have a good argument ready if you fork a known package, and you will need to do it better than the competition.
If you didn't find anything like your package, you might still get it into CPAN. But if you want it to be as useful as possible, you should still consider making it a module (or several) and using that module from your programs/scripts. Also again make sure that tests and documentation is good and plentiful. Then read the FAQ about getting your package on CPAN.
You might also look into the source based distros, the BSDs and debian. They might be more up to including your package than the commersial distros, especially if you make it easy (use the GPL license, provide packages/ebuilds/spells/Makefiles and what ever else is needed for a proper package in their systems).
As countless others have no doubt pointed out, you may also want to look into making C implementations of your programs, get them on freshmeat, sourceforge, savannah and what not. All this is good advice. And most of all, make sure you expand and improve the programs, support your users and generally do your best to find your niche in the software landscape. That way you might be able to avoid getting labeled as "just another quick script submitted to freshmeat" (not that I have researched your package enough to make that judgement). Then inclusion in the distros is simply a matter of being useful to enough people (and making it as easy as possible to include your package).
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 software added to a distro, it's just going to "happen".
that make me wonder what round does if it has problems with decimal numbers.
Joe
Joe Batt Solid Design
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 | averageThis 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-fix)
Also, some countries use spacing to group `thousands` together, where American/English speaking countries use a comma, the French/Germans use commas to indicate decimal points, then there's comma separated values and the locale settings...(at least now I know why your using Perl :)
random, I hope 'rand' uses /dev/null or something internally,numprocess doesn't like me doing ^ (power) first, after the comma, it's fine, expect that (5*1)^2 != 7 and
(5*1)^1 != 4, whatever the carrat ^ does in Perl,it's not power, power is ** (carrat is xor looking at the results).
I'll stop there, sorry for...um, you know..The only other thing I would say (and this doesn't really apply because your using Perl) is if all these functions are supposed to be doing essentially the same thing (code re-use is clear from the source) then the busybox method of compiling all of the commands as functions (saving some space) seems good, then you can softlink the commands to relevant functions. (e.g. 'numgrep file' would call 'all_function --numgrep file', where all_function is the real executable).
(having said all that, numgrep does look useful though, grepping template source code for numbers when the templates have each line numbered is not fun).
BB
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.
Drop the GPL. Your software is much more useful and far more likely to be included in non-Linux systems if the license isn't tainted
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
http://unmoldable.com W:"No one of consequence" I:"I must know" W:"Get used to disappointment"
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 list, or become a Debian Developer 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.
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 something that the normal user would use, so saying "gain popular support" didn't really apply. I guess every distro would have a different way of handling submissions, and it would just be legwork to contact each one.
Since there is no representative for *nix, to go to mobo manufacturers and distros to work out the details, I guess it makes it a little tougher. I suppose a company that had created the API might have an easier time than some guy in his basement, but it still seems like getting code submitted to distros could be a little easier. Do the distro guys scan freshmeat every day? Do they just rely on word of mouth to get new packages?
My beliefs do not require that you agree with them.
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.
this will increase your chances dramatically
Publish it on sourceforge?
help it get distributed/more popular?
iF yOu WAnT to C YOUr iP agaIn gAThEr tWO MilLIon dOLLArS IN Non - cONsEcuTivE TweNtY's AnD AWaiT FuRThER iNstrUctIoN
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.
It isn't a lie if you belive it.
I wouldn't worry about getting it included in any distro. Just write the program(s) to fill the niche. Write the programs for yourself, and if other people pick them up, then great!
There are plenty of fabulous programs for Linux which aren't standard includes like ecasound (it isn't included in Mandrake yet anyway) which is a great tool for mixing and producing sound. Your programs do not need to be a standard includes to be great tools.
Me myself, I am just starting a project for the first time on sourceforge. It is called Sound Orgy. While do wish for wide spread use of the tool set, the main goal is to write it for myself the way I want it to work. There are loads of sound related projects on sourceforge. I am just trying to do the way I want it, and I'll see what happens.
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.
FiGZ.COM - A waste of perfectly good web space
Go to the RedHat project CYGWIN and make it work in Windows. Then you have made it available to all users. Then you can feel guilty and start working on it again in Linux. Then you can do a double take and post it on Freshmeat and the other sites like Sourceforge. Then you can wonder if you should code it for QT or Windows CE. But most of all - don't give up hope! The more places you get it working the longer you can work on it cause it will survive. This is what I am doing for the Starshiptraders Graphical Client!
http://www.lunar-linux.org/
good luck getting it in other distro's.
http://dirk.eddelbuettel.com/quantian.html
These would probably be the first people to include such a set of utils. A Knoppix / Debian variant tailored to numerical and quantitative analysis.
If you can improve on one or both of these, then your name can be in bright lights. It's doubtful you can complete with them in the niche where they've been specialising in for decades using a few lines of perl.
(No offense to perl coders -- I'm doing a great deal of that myself these days.)
1. Make them *trivial* to use with very easy syntax, so they have that specific niche (if it's not trivial to use, then the user might as well write an awk or perl one-liner, and your package wouldn't have any extra value...).
2. Make them work nicely with other traditional unix fila and text utils (tr, cut, find, xargs...). Consider what features are so important that your utils should do it themselves with simpler command syntax (perhaps like interpreting all numbers as decimal even if they have leading zeroes, so you don't have to use sed or something to remove leading zeroes from numbers), and what operations could just require using other tools and pipeing (perhaps like applying to multiple files recursively with find and xargs, instead of built-in directory recursion and wild card handling).
3. Combine them into one binary/script.
4. Do it in standard ANSI C, so it'll compile under just about anything. And use good and consistent coding practices.
The perl script collection, as your tools are now, is sure nice for your personal use, but for other people I'd say it's just a snippet library... But not useful as a stand-alone tool, as it's not worth the trouble to learn using it, and the headache of making sure you have right perl etc. Sure a nice thing to have in sourceforge or something, I'm sure quite a few people would find it useful, but it's not really anything that could get included in several linux distros.
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.
IWARS.
People, in general, disappoint me. Politicians even more so.
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:
/opt/SUNWats/sun4u/bin/thiswillneverbeinyourPATH/p kg1921u9238/
- 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.
You will forget this sig before you next see it
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....
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.
... you can follow the guidelines on their site, 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, 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 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. :)
Why not just include calc, a C style arbitrary precision calculator? You can easily write scripts with calc, and calc is quite fast. Plus, the requirement of Perl would no longer exist. Calc itself is a small package.
-------
Those who can, do, and those who can't, well
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. 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
You could start by giving the executables less generic names. I wouldn't want random utilities named round, range and random lying around polluting my namespace unless I used them a lot.
What are "user packages"? In OpenBSD at least, GPL is avoided in userland programs too, there's ongoing efforts to replace the gnu crap that is there now with free replacements (diff, grep, etc).
If you mean packages from the ports tree, then yeah, gpl is fine, but is that what the question about? I assumed he wants to further bloat unix-like systems with even more useless junk in the default install, but it was pretty vague. If he had to ask how to submit an (rpm/deb/pkg/whatever) then we're looking at a new low for ask slashdot submissions.
1) It *HAS* to be BSD license. If not, it will be almost impossible to add.
/opt directory), free of silly dependancies and the like.
;-)
2) It has to not suck. No offense, but most linux software out there sucks. By sucking, I mean it has to be free of all bugs, free of any linux-isms (like assuming we have an
3) Whatever it does, it has to do it *well*. BSD s dont take half assed programs.
4) It has to be useful. How useful is it? How much will a desktop user use it? How much will a server admin use it? Will it make a compile faster? Etc, etc.
5) If you make a BSD "clone" of a GPL program. Naturally, don't just take the GPL program, change a variable, and give it the BSD license, that's illegal. Re-implement all of the GPL features in a BSD licensed program, and you'll get the BSDs.
Granted, this isn't the only way to get into the BSDs, but these should give you a start.
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 further translations.The articles are all under the GNU Free Documentation License. However, Debian has decided the GFDL is non-free according to the Debian Free Software Guidelines. I plan to change the license to one that satisfies Debian's requirements, but haven't settled on one yet.
Any non-freeness of the GFDL shouldn't prevent you including it in your distribution, the issue is that invariant sections forbid some kinds of modifications. I discuss this further in Which License for Free Documentation?
Request your free CD of my piano music.
...but IMESHO it would be more productive to have a SCO-only splash-screen which says "running under protest" and a yellow flag with a black ball, and offers to fire up a web browser to explain why.
Got time? Spend some of it coding or testing
Write a program that people want to use and eventually one of the distros will pick it up. And if it is really useful then all of them will pick it up. The goal is the program not the distro.
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 the trouble since it adds to the cost because they have to test it.
Adding stuff to Gentoo and Debian are generally easier than Redhat and SuSE because of testing costs associated with commecial distributions versus free/community distros.
“Common sense is not so common.” — Voltaire
and they are actively seeking replacements for all gnu software in the base system
you might develop something that is one up on something that is in the distro. so you think, mine is better, it should be in there! but if you're just one person who never updates his/her website or you post blogs on your site about how busy you are with school and such, well that won't look too good. especially if your project is very young compared to the app that has been there a while and is therefore trusted and people are familiar with. distro's don't want abandonware.
moo...
1. Make your own distro.
2. Include your software with it
3. ???
4. Profit
Well, the odds of getting a new GPL'd program into the FreeBSD base system hover very near zero. On the other hand, if you want to get added to the ports collection, that's fairly easy. All you need to do is follow the instrucations in the FreeBSD Porter's Handbook.
-- Brooks
-- Any statement of the form "X is the one, true Y" is FALSE.
result: everyone knows the program and some even use it.
(and in case you wonder what program I was talking about, see: http://vanheusden.com/multitail/ )
www.vanheusden.com - home of Multitail, HTTPing, CoffeeSaint, EntropyBroker, rsstail, bsod, listener, nagcon, nagi
I've found num-utils interesting. Probably I'll use it sometimes if you continue development.
Don't know much about *nices or Linux distros other than ALT Linux. In ALT individual developers decide whether to include particular package to their RPM repository --- Sisyphus. In fact, everybody (incl. you) allowed to add and maintain any ALT Linux package since they have open development model.
If ALT users will find your package useful it will be included in official releases --- Master and Junior.
1). Make sure your software works, is relatively bug free, and is released under a true Open Source license such as the GPL.
2). Read the Debian guidelines and policies and ensure your program conforms to these guidelines.
3). Post a bug report (aka Wishlist item) against the pseudo-package WNPP
Some Developer might see your item and wish to package it. Or you can package it yourself under the Debian Developer Mentor scheme.
And NT's Posix layer wouldn't really count as a *nix either. GNU/Linux might be Posix compliant, but that's more an issue of GNU than Linux. In general, Un*x refers to the varients of Unix based on Unix code (AIX, Unixware, FreeBSD, etc). *nix means simply Un*x work-alikes which behave reasonably well like a Un*x system. NT really doesnt quality considering its limited Posix layer, but cygwin might. So, in some ways, we're probably more talking about GNU and the like more than the actual OS. But, there's no way to include Unix and GNU is not Unix in a single acronym nicely. If you can think of a better one, I'm all ears.
It should fulfill a genuine need
Yeah, like XEyes!
I wonder if this stuff has its source in Redmond? Or is this just some SCO stockholders venting about their treatment here? Oh, wait. Summer school is out, and the Fall semester hasn't started yet. That explains it. Unsupervised children banging on papa's keyboard in the middle of the afternoon. No wonder mom can't get through on the phone.
Gary Dunn
Open Slate Project
Ya, I'd like to get my Graphical Voter Interface GVI into a distribution or two. I think it's pretty cool. Check it out.
I watch Brit Hume on Fox News
why not just email the distributors? is this really worthy of an 'Ask Slashdot'?
Head over to the FreeBSD website and read the Porter's Handbook. That will explain everything you need to know to get it added to the ports tree. It's actually quite simple.