tlhingan@unsvax.UUCP (Eugene Tramaglino) (04/04/88)
If everyone on the net with the appropriate skills volunteered 5 (five) hours per week of their time, we could write our own OS, editor, utils, etc, and leave IBM, Apple, HP, and everyone else in the dust. Okay, maybe we'd need to tap some folx outside the net community. But ask yourself how much you'd get in software for your 5 hours. I picked 5 hours as an arbitrary number, but I hereby volunteer my 5. Now, we need a good co-ordinator. . . . I said it was Nutty. #==============================================#=========================# # Eugene Tramaglino -- tlhingan@unsvax.uns.edu # USS Mahagonny, NCC-1929 # # 1450 E Harmon 207A, Las Vegas, NV 89119 #=========================# # Data: "All paths are equally dangerous." # Member, Institute of # # Riker: "Let's go!" # General Semantics. # #==============================================#=========================#
james@bigtex.uucp (James Van Artsdalen) (04/05/88)
IN article <231@unsvax.UUCP>, tlhingan@unsvax.uucp (Eugene Tramaglino) wrote: > If everyone on the net with the appropriate skills volunteered 5 (five) > hours per week of their time, we could write our own OS, editor, utils, > etc, and leave IBM, Apple, HP, and everyone else in the dust. Okay, I gather you've never heard of Richard Stallman, the Free Software Foundation, or the GNU project. They are doing it for unix (GNU stands for GNU is Not Unix). Oddly enough, they didn't see the need for another Mess-Dos. :-) -- James R. Van Artsdalen jva@astro.as.utexas.edu "Live Free or Die" Home: 512-346-2444 Work: 328-0282; 110 Wild Basin Rd. Ste #230, Austin TX 78746
bob@allosaur.cis.ohio-state.edu (Bob Sutterfield) (04/06/88)
In article <231@unsvax.UUCP> tlhingan@unsvax.uucp (Eugene Tramaglino) writes: >If everyone on the net with the appropriate skills volunteered 5 >(five) hours per week of their time, we could write our own OS, >editor, utils, etc, ... I hereby volunteer my 5. Now, we need a good >co-ordinator... Please send mail to info-gnu@prep.ai.mit.edu. There's plenty of work for you to do. GNU won't be PD, but it will be free, as are the utilities that are already available. >I said it was Nutty. People have been saying that about RMS for years, but they still use his editors :-) None of the Newsgroups included here are really appropriate for Yet Another Pro/Anti-GNU FlameFest, but then they haven't been appropriate for the already-rolling OS-feature wars here, either. -=- Bob Sutterfield, Department of Computer and Information Science The Ohio State University; 2036 Neil Ave. Columbus OH USA 43210-1277 bob@cis.ohio-state.edu or ...!cbosgd!osu-cis!bob
rmpinchback@dahlia.waterloo.edu (Reid M. Pinchback) (04/07/88)
In article <231@unsvax.UUCP> tlhingan@unsvax.uucp (Eugene Tramaglino) writes: >If everyone on the net with the appropriate skills volunteered 5 (five) >hours per week of their time, we could write our own OS, editor, utils, >etc, and leave IBM, Apple, HP, and everyone else in the dust. Okay, ... stuff >I said it was Nutty. Not such a nutty idea... It might be hard to coordinate, but if we could split the project into small pieces, like one whole, complete program being done by each person (for small utilities), or one major module per person (for large packages, languages, OS), then it just might be possible. Providing, that is, that we could agree on WHAT was to be done, HOW it was to be done, and HOW to maintain the resultant code. Comments, anybody? Reid M. Pinchback -----------------
douglas@reed.UUCP (P Douglas Reeder) (04/11/88)
In article <6276@watdragon.waterloo.edu> rmpinchback@dahlia.waterloo.edu (Reid M. Pinchback) writes: >In article <231@unsvax.UUCP> tlhingan@unsvax.uucp (Eugene Tramaglino) writes: >>If everyone on the net with the appropriate skills volunteered 5 (five) >>hours per week of their time, we could write our own OS, editor, utils, >>etc, and leave IBM, Apple, HP, and everyone else in the dust. > > Not such a nutty idea... > Providing, >that is, that we could agree on WHAT was to be done, HOW it was to be done, >and HOW to maintain the resultant code. > I think it would be quite useful to have a finder-type program for the IIe and IIc, using the mousetext characters and the mouse. I think one could be written that would execute commands extremely quickly. (That is, your only waits would be for disk accesses that you were doing anyway.) This would be best accomplished using a general windowing utility (not involved with the mouse) that supported generic windows of text, which would also have to be written. One would direct screen output to the window program, and tell it what window to send it to. I may tackle this over the summer. Send comments on this and apple's lawsuit to /dev/null, or if not available, put them in the trash can. -- Doug Reeder USENET: ...!tektronix!reed!douglas 10 Cyclopedia Square from BITNET: douglas@reed.UUCP Terminus City from ARPA: tektronix!reed!douglas@berkley Terminus,The Foundation Box 502 Reed College,Portland,OR 97202
jay@splut.UUCP (Jay Maynard) (04/11/88)
In article <9804@tut.cis.ohio-state.edu> bob@allosaur.cis.ohio-state.edu.UUCP writes: >In article <231@unsvax.UUCP> tlhingan@unsvax.uucp (Eugene Tramaglino) writes: >>If everyone on the net with the appropriate skills volunteered 5 >>(five) hours per week of their time, we could write our own OS, >>editor, utils, etc, ... I hereby volunteer my 5. Now, we need a good >>co-ordinator... > >Please send mail to info-gnu@prep.ai.mit.edu. There's plenty of work >for you to do. GNU won't be PD, but it will be free, as are the >utilities that are already available. Well, almost. The only problem is that RMS holds PCs in contempt, and refuses to even consider making GNU work on them. In short, he's a 68000 bigot when it comes to micros - and he will require them to support demand-paged virtual memory. (Goodbye, GNU/Mac.) A better place for your efforts would be in extending Minix; it's not PD either, but it's cheap, and you even get a text in OS construction with it. See comp.os.minix for more info. (Note: I'm not running minix; I learned about it after I spent $500 for Microport System V/AT.) >None of the Newsgroups included here are really appropriate for Yet >Another Pro/Anti-GNU FlameFest, but then they haven't been appropriate >for the already-rolling OS-feature wars here, either. Followups to this one have been redirected to comp.sys.ibm.pc only, as the comments really only pertain to the PC. -- Jay Maynard, EMT-P, K5ZC...>splut!< | GEnie: JAYMAYNARD CI$: 71036,1603 uucp: {uunet!nuchat,hoptoad!academ!uhnix1,{ihnp4,bellcore}!tness1}!splut!jay Never ascribe to malice that which can adequately be explained by stupidity. Pledge #29: Vote for Kent Paul Dolan and the Birthright Party in '88!
asg@pyuxf.UUCP (alan geller) (04/13/88)
In article <6276@watdragon.waterloo.edu>, rmpinchback@dahlia.UUCP writes: > In article <231@unsvax.UUCP> tlhingan@unsvax.uucp (Eugene Tramaglino) writes: > >If everyone on the net with the appropriate skills volunteered 5 (five) > >hours per week of their time, we could write our own OS, editor, utils, > >etc, and leave IBM, Apple, HP, and everyone else in the dust. Okay, > ... stuff > >I said it was Nutty. > > Not such a nutty idea... It might be hard to coordinate, but if we could > split the project into small pieces, like one whole, complete program being > done by each person (for small utilities), or one major module per person > (for large packages, languages, OS), then it just might be possible. Providing, > that is, that we could agree on WHAT was to be done, HOW it was to be done, > and HOW to maintain the resultant code. > > Comments, anybody? > > > Reid M. Pinchback > ----------------- Actually, it strikes me as a rather good idea. Certainly, there are already top-quality shareware/PD products already available for MS-DOS; all we'd need to do is make sure that a new OS/compiler/etc. would be backwards-compatible. The two main problems are the difficulty of coordinating a large group of volunteers, and the difficulty involved in doing PD hardware. Hardware is important because every two PCs out there have some sort of difference in their configuration, and you either have to write to the lowest common denominator (bleagh!), or have a million routines built in to support every possible options (MS Windows), or somehow force everyone to have (more or less) equivalent hardware systems (Macintosh, although the II is already giving Apple problems here). At a more limited level, I would love to see more PD language systems, such as XLISP and Little SmallTalk. I would happily participate in a project that aimed at producing a production- quality C++ compiler, or regular C, or Modula-2, or even something completely new; I would also like to help take systems like XLISP and tune and extend them so that they could be used as serious production systems on a PC or Mac. If anyone is really interested in doing something along these lines, my particular interest is in compilers (parsing a specialty, not so strong on optimization), databases, and operating systems (have I got a scheduler for you ... :-), but I'm willing to work on pretty much anything. ...!{rutgers, princeton}!bellcore!pyuxf!asg Alan Geller Bellcore {who knoweth not, and careth less, from the above}
FFDDO@ALASKA.BITNET ("It's only me"@BRL.ARPA, David) (04/15/88)
AS far as this "nutty" idea goes, I would be interested in trying out anything that this volenteer group would eventually produce. Not being a programmer myself, I just like to run things through their paces. So, now we have some volenteer programmers, and a self admitted beta tester. Now all we need is a co-ordinator! David Oberhart <FFDDO@ALASKA> CIS 72047,1004
richard@bud.UUCP (richard karasik) (04/15/88)
Sounds like the kind of undertaking that could catch a lot of interest. Heck -we have people here posting evaluations of products all the time including shareware. We could draw on those for lessons learned. We could take a hard look at the issues of multi system portability (and perhaps break our eyeballs), but the idea has a certain flair to it. What pieces does anyone think we need? I mean an OS is a bit much to go multimachine with, but tools are another thing entirely. How about the best of all tools -with some team just working on and presenting "what's best" -much like the voting for a new group. ANother thing to consider is the impact of windowing systems on the scope of the tools we can hope for. If nothing else -we can end up with a shopping list to beat up sleazeware manufacturers about. (ie buy one disk now and open the package to find that you only need another 40 diskettes to make the tool almost really useful). Jump on in, it beats collecting bellybutton lint. Richard -- ----------------------------- sun!arete!bud!richard ||"No, I said the BITS .. massage the BITS" " ! " ! " !kass!richard || Richard Karasik " ! " !richard || Arete Systems Inc 408 922 8271
dhesi@bsu-cs.UUCP (Rahul Dhesi) (04/18/88)
Let's not forget the economic concept of relative advantage. Rather
than getting lots of people to each volunteer 5 hours of their time to
write public domain software, it might be better for these people to
volunteer 5 hours of their wages, pool the resulting money, buy the
rights to good existing software, and release it to the public domain.
--
Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesigeoff@desint.UUCP (Geoff Kuenning) (04/20/88)
You know, I really hate to rain on anyone's parade, especially when people
are so eager to volunteer their time for what they feel is a good cause.
But it's fairly obvious that nobody who is supporting this idea has
much experience with managing software projects. Yes, the idea *is* nutty.
Here's why:
Coordinating different workers on the same project is difficult and
time-consuming. With 3-5 workers, it's a full-time job. With
more, because of the combinatorics involved, the complexity rises
exponentially (*not* linearly). Read "The Mythical Man-Month" by
Frederic P. Brooks for a thorough discussion of this issue.
As an example, in the past year I have devoted between 500 and 1000
hours to a single program, ispell. The current version is something over
8000 lines of code, plus about 1000 lines of shell scripts, which is not
all that large a program compared to an editor, a kernel, or troff.
So, if I had volunteered my time at 5 hours per week (I've devoted *lots*
more than that, as you can see from the total) it would have taken me
between 100 and 200 weeks (that's 2-4 *years*, folks) just to get that
one program done.
The alternative suggested is cooperative effort. To keep things realistic,
I'll assume a 6-person project for ispell; at 5 hours per week, that produces
20-40 weeks of work, or about 1/2 to 1 year (1 of the 6 people will spend
all of her time coordinating the rest of us). Now go look at the number of
programs in /bin, and multiply these by an average of 3 people per program.
That's the number of volunteers you'll need. Then you'll need coordinators to
coordinate the coordinators, because of the large numbers involved.
And I'll bet money my estimates are grossly optimistic.
This is not to say the project is impossible. But I think people are
underestimating its size by several orders of magnitude, as well as
ignoring some logistical problems that are, in fact, larger than the
programming project itself.
Ask yourself this simple question: have you ever completed a 1000-line
or larger program in the time you estimated it would take? If the
answer is no, the chances are excellent that you're underestimating this
project, too.
(BTW, if nine women would like to get together and produce a baby by
next month, I'll commit to raising the thing... :-)
--
Geoff Kuenning geoff@ITcorp.com {uunet,trwrb}!desint!geoffmadd@bu-cs.BU.EDU (Jim Frost) (04/21/88)
In article <1722@desint.UUCP> geoff@desint.UUCP (Geoff Kuenning) writes: | Coordinating different workers on the same project is difficult and | time-consuming. With 3-5 workers, it's a full-time job. With | more, because of the combinatorics involved, the complexity rises | exponentially (*not* linearly). Read "The Mythical Man-Month" by | Frederic P. Brooks for a thorough discussion of this issue. This is a good text, however it is somewhat dated and techniques have changed somewhat. The basic problems discussed have NOT. When you deal with a large programming project, the way to go about it is to build teams of about 10 people. Fewer than 5 should be programmers. One person is a lead programmer, another is an assistant, and two or three are auxiliary programmers. You should have one manager (preferably with programming experience), a secretary, and someone for maintenance. Depending on the project, you might want other people as well. You break up the project ONLY IN PLACES THAT ARE RELATIVELY INDEPENDENT, and give each portion to a different programming team. Otherwise the communications costs rise exponentially and things slow to a crawl. This is what happened in the OS/360 development, which is what the book suggested above talks about. The way to go about getting a late project done faster is to continue as you were, not to hire more people. That causes slow-down that is unbelievable -- new people have to be taught, and they increase communications costs. This is a mistake that is made repeatedly. Back to programming teams. Why build them as I suggest? First, cream-of-the-crop programmers are hard to find, but really can get the work done. Thus, you let them do most of the all-out hacking necessary to get the job done. You have an assistant programmer who works closely with the lead programmer. He should be familiar with the work of the lead programmer. This is because good programmers have this tendency to follow large monetary offers. If your lead programmer steps out, the assistant can take over with minimal hassle since he's already familiar with the code. The assistant can also work on periferal tasks that the lead programmer needs done but doesn't have to do himself. Since he's familiar with the work of the lead programmer, he's not likely to have many misunderstandings with regards to subroutine calls, etc. Auxiliary programmers are there to get rid of tedious portions of coding that must be done to make things work. They don't have the experience of either the lead or the auxiliary, but they will gain experience as they work and they will be pretty familiar with what's going on -- thus they can replace the assistant programmer with a minimum of hassle if either the assistant or the lead programmer should leave. Secretaries and managers are around to get the paperwork done. They talk to other programming groups and inform upper management of status. This keeps the programmers free to program, which is what they like to do and what you're paying them for. Managers also handle things like funds and requests. KEEP MUNDANE TASKS AWAY FROM PROGRAMMERS. The more silly little things they have to do, the less programming they'll get done. Maintenance people do things like system management that would slow programmers down but which must be done. Often maintenance can be spread between programming groups to reduce costs. If you undergo a programming project following guidelines like these, you'll find it goes smoother and things get done. This type of group is robust enough to withstand even the removal of the lead programmer, and has very low communications costs. It has been used effectively in many programming projects. Other tips to keep in mind: Take your estimate of how long it's going to take to get something done and multiply it by at least 1.5 before telling anyone. You'll be much more accurate, which will please management. Personally I recommend multiplying by two, following the rule "the first 90% of the job takes 90% of the time, and the remaining 10% of the job takes the second 90% of the time." If you multiply by two, you'll probably finish early :-). Before starting the project, plan out the architecture completely before you start. Examine different architectures. Allow those working on the project to submit ideas. You'll come out with a much cleaner program; often this can help in the partitioning of work into programming groups. Even using 20% of your allotted time might be useful, since a well-designed project is easier to implement and debug. Leave programmers alone. The biggest mistake you can make is to hassle them (unless, of course, they consistently don't show up for work and instead go play pool). A programmer who's sitting in a chair doing nothing is probably brainstorming. Don't make programmers stick to 9-5 schedules unless absolutely necessary. Good programmers will still put in the hours, but often prefer to work off-hours. Most of my best hacking is done at 2am and in marathon stretches of over 24 hours; I've found a good many others who think the same. Don't make programmers dress up. Let them be comfortable. They're not going to be seen by the public anyway. Dressing up management is a good idea, since uniformity in management usually leads to better productivity. Programmers tend to be more intimate, and uniformity leads to stress and not increased productivity. Stress clean, reasonably documented code, but do not strictly enforce a particular programming style. Programmers won't follow it anyway, so why waste your time. If a programmer's style is readable, leave it as it is. Most programmers use nearly the same code formatting style nowadays anyway. As for the programming project that was brought up, Geoff is correct. You'd be dreaming to think that a lot of programmers each devoting a little time would make it work. To make the operating system, you need a small team of good OS hacks with a lot of time. A distribution of effort would work while developing the applications for such an OS, though -- this has been clearly demonstrated by the MINIX people. | Geoff Kuenning geoff@ITcorp.com {uunet,trwrb}!desint!geoff jim frost madd@bu-it.bu.edu
tsouth@pro-pac.cts.COM (Todd South) (04/23/88)
I certainly am interested in this idea, but what exactly would
be the use of a widely distributed group of programmers working on a
project (in their SPARE time I might add) when there is no grounds to
work off of.
How about this:
o Get one or two guys/gals that can devote a large amount of time to
this and are generally trustworthy.
o Take donations to buy media and tech info that they will need for
the project.
- This would include FIRST making a list of the necessary
equipment, information and media they would need and
publically posting it, so that people know what they are
contributing for. (I certainly am not going to buy someone
an 80 meg drive when I haven't even paid of mine yet!)
- Having someone in said group monitor not only the funds
but also the progress of the group, posting it to the
net as it went along.
o Once the groundwork is layed (and I am damn sure that it will take
more than one or two beer and pizza nights to complete the planning
stages!) let the programmers go to work on what they do best! During
this planning stage, it might behoove the main group to request
comments/suggestions on what the various Apple usres in the net
would like to see implemented in this O/S.
o Now, when the programmers find that they need certain things done
for the project that could be looked at in more than one way, post
the projected goal of a particular routine/implementation to the net
and allow others to submit ideas/sources on how they might approach
the problem.
This would hopefully be a step in the right direction. Oh, also,
let's not create some group that will mandate the distribution of anything
associated with this project. THIS IS SUPPOSED TO BE A PUBLIC DOMAIN O/S
that will be freely distributed, SOURCE AND ALL!!! Anything less, and I
truly see no need of anyone even discussing the matter further. We do not
need an alternate to the APDA, and I would not contribute to anything or
one that tried to create such a group or association.
> (BTW, if nine women would like to get together and produce a baby by
> next month, I'll commit to raising the thing... :-)
> --
> Geoff Kuenning geoff@ITcorp.com {uunet,trwrb}!desint!geoff
Count me in!!!
Todd South
:-----------------------------------------------------------------------:
| Todd South : Ewa Beach, HI ||| Pacific Proline: (808) 499-2831 2400bd |
| Uucp: {nosc, ihnp4, cacilj, sdcsvax, hplabs!hp-sdd, sun!ihnp4} |
| ...!crash!pnet01!pro-simasd!pro-pac!tsouth |
| ARPA: crash!pnet01!pro-simasd!pro-pac!tsouth@nosc.MIL |
| INET: tsouth@pro-pac.CTS.COM BITNET: psuvax1!tsouth@pro-pac.CTS.COM |
:-----------------------------------------------------------------------:brad@looking.UUCP (Brad Templeton) (04/24/88)
In article <2642@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: >Let's not forget the economic concept of relative advantage. Rather >than getting lots of people to each volunteer 5 hours of their time to >write public domain software, it might be better for these people to >volunteer 5 hours of their wages, pool the resulting money, buy the >rights to good existing software, and release it to the public domain. >-- >Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi Finally somebody says something sane on this issue. Anybody who's ever actually worked on a real programming project knows that thinking you can get a program out of 5 hours from 500 programmers is like thinking that 9 women can have a baby in 1 month. And Mr. Dhesi is also correct that it would be best to buy existing software. Software written by somebody who believed that it would have to please customers who paid real money, and somebody who believed that they would have to support the software after it was done. If you tried to start a new project, you would have to trust the administrators and coders a great deal. Even then, there would be a good chance of failure. And what if it got behind schedule (we know that never happens 8-)) or went over budget (we know that never happens 8-)). You could buy a surprising number of packages for $100K. None of the real good ones, but many of the medium to good ones. -- Brad Templeton, Looking Glass Software Ltd. - Waterloo, Ontario 519/884-7473