This whole realm is already at least partially mapped out by a number of researchers. The ones referenced in the article are actually the least impressive of the lot, in my experience.
My personal pick for most notable researcher in this area is Joshua Epstein. He's with the Sante Fe Institute. The best book of the several he's written is:
Nonlinear Dynamics, Mathematical Biology
and Social Science (Santa Fe Institute
Series, Lecture Notes, Vol 4)
Joshua M. Epstein
Perseus Publishing
ISBN: 0201419882
It presents a number of mathematical models (games theory), including a variant of a Non-linear Richardson called "GloboCop", which does a fairly good job of modelling "core team" based Open Source software projects (IMO).
There has actually been a lot of work along these lines; the first I ever heard of it was an article in Analog Magazine's "Science Fact" column, entitled "Toward a Science of Psychohistory".
You can fake having some measure of skill, if you have a machine in front of you.
As a lot of people have already noted, there are people who use a compiler as a crutch, to catch errors. Just as people use a calculator as a crutch, or a spelling checker as a crutch.
I would not hire a reported for a newspaper who could not turn in good work without a spell-checker (or worse, a grammer-checker).
I would not hire a mathematician who needed a claculator in order to take a square root.
And I would not hire a programmer who needed a compiler in order to write good code.
I think that it's very important that the skills reside in the people, not in the tools.
I also think that people who approach problem solving through successive approximation, using an editor and a compiler to judge their work product, are much less likely to solve a problem correctly the first time.
Yes, it's amazing the number of problems you can solve with brute force. But a brute force solution will inevitably be suboptimal, and require rewriting by someone else... someone with better work habits.
There's a lot of merit in knowing how to arrive at a solution, but there's also merit in knowing the answer before you start.
Knowing how to use a tool is good; knowing how to build a tool, because you know how a tool arrives at its result, is better.
As a final note, I will say that I have known a lot of programmers from the "sit down and code" school of computer programming. Without exception, these are people who I would not hire for a design position on a bet; I would prefer not to hire them at all, but if it came down to it, they could do OK in the production of prototypes. They are people who don't understand the value of planning, or provability, or process, and they are the people who will become upset when they are forced to use source code control, or to work in teams. They are people who can not solve complex problems, except by way of kludge. I guess the worst part of this is that these people often believe that they are "code gods", simply because they can produce code that, with a restricted set of inputs, gets the expected set of outputs, and they can produce it quickly.
So far, everyone has been talking about the employer's part in the process. That's not what you should be examining, anyway.
Let me prefix this by saying that, if you have already accepted the first offer, the answer should be obvious: you do not accept the counter offer. You are only as good as your word, and if you have agreed to work for someone new, then you need to keep your agreement. If that's the case, accepting or even entertaining a counter offer, is an incredibly bad thing.
That out of the way, you need to understand why you were looking in the first place.
If you were looking because you were unhappy with the pay at your present job, you should have brought this up with your current employer directly, rather than trying to get a lever on them. Now that you have this lever, though, what you should do with it is pretty clear: you shouldn't have obtained it if you weren't willing to use it. I agree with most of the sentiments of "bad blood"; however, this only really applies if the only thing you are trying to lever out of your employer is money. If you are after intangibles, or non-monetary compensation (equity, elder care insurance, etc.), sometimes a lever is OK... though I would personally never be that blunt about it, but would instead start with "this is what comparable companies are doing...".
If you were looking because you wanted to measure your value in the market, well, then you probably have less value than you now think you have. The problem is that if you didn't start out with some idea of your value in the market, then what you now are is "sold goods": the value you think you have is based on your ability to sell yourself to an employer, not based on your ability to do the job for which the offer was tendered. Be very careful here. If you have padded your resume one iota, then you have shot yourself in the foot (in general, it's better to be completely honest on resumes, in my experience; it changes the interview dynamic significantly in your favor).
If, instead, you were looking because you were unhappy with your present job, how is money going to fix things? Unless the counter-offer includes the power to change the things which sent you looking in the first place, you will ultimately be unhappy, and leave anyway. Money can be a salve; it can make you put up with a lot. If you participate in a volunteer/Open Source project of any kind, you will understand where people's true tolerances, without the salve of money, really lie. Many people put up with their coworkers not because they are easy-going or "nice people", but because that's part of what they are being paid to do.
The only other reason to be looking is because you have wanderlust. If you need to wander, then wander. My recommendation is that you try to stay in one place as long as possible. An employment history rife with wanderlust signals a potential employer that you are unlikely to stay long. If you don't have the self control for this, then you really need to change your idea of work from "full time job" to "contractor". Otherwise, your wanderlust will damage your ability to get future work, as you get older, and settle down.
In general, I think that if things have progressed to the point of monetary counter offer, then you have already left your current job; even if you don't know this, your employer, who is presumably a preofessional manager, will.
I think it's ironic that this is being herladed as "the death of copper".
It's my understanding that what held it up was the optical parts vendors couldn't make transceivers that went fast enough.
You've actually been able to buy 10Gbit *copper* hardware from HP for almost a year now, and the copper part of the draft standard has remained unchanged since then.
I rather expect that the next speed increment will have similar problems with the relative ease of making copper vs. optical transceivers, so the next bump will end up being "copper first" again.
"Dammit! He got me! Lets see if he can do it again."
Reading your post, I almost fell out of my chair laughing.
Imagine a press conference after a fierce battle, where the spokesperson for the losing side has to admit that the battle was lost because "our pilots ran out of quarters"...
I would put most of my source code in the Public Domain, if I could.
I can't.
Not "I won't".
I *can't*.
My problem is that, without a license, I can't attach a "hold harmless", or prevent my name being used to sell code derived from it, but of which I personally would not approve.
So to keep rights to my good name, and protect myself (as much as possible) from litigation arising from the use of my gifts to the public, I have to attach the minimum possible license that still gets me these things (the BSD license).
It's not that I *want* to do this, it's that there are no implicit legal protections for the authors of works placed into the public domain.
Without such legal protections, I simply can't *afford* to make the gifts that I want to make to the public.
This is all about the fact that the calbe companies entire infrastructure is geared at pushing content at you. It's why everything is assymmetric in the first place: "DRINK FROM THE FIREHOSE!"
I rather expect that they are also seeing much less of the camel-nose-tent effect than they hoped for, with cable modem users NOT also subscribing to cable television.
If they are *truly* concerned about their bandwidth, then they can stop sending "Barney" and home shopping channels and commercials down the wire to my house. That ought to free up an incredible number of bits right there. Then, if that's not enough for them, they can charge less for digital than analog so we all get digital, and not send the bits that no one is looking at on any given segment at any given time.
But, in fact, this is really about uploads: they don't want you sending *anything*. The really annoying thing for them is that you are sending TCP ACK's at all, and they *have* to permit it for their service to work. That's why, despite the fact that they give you a practically infinite DHCP lease, they are unwilling to assign you a static IP address, unless you pay the "business rates" for the service. And why many providers terms of service prohibit running servers, and do port filtering, scanning, and so on to verify that you aren't running anything.
This is all totally obnoxious on their part, and they are stupid if they think that consumers don't see what they are really doing.
Your rule about "the name must be in active use" is, excuse my.fr, assinine.
I've owned a ".org" domain name since 1992. If you'll check, you'll find that that was way before they charged for the things (and if you check deeper, you will see that the reason they started to charge for the things in the first place was that Dupont and P&G registered all their trademarks as domains in a single day).
My domain has occasionally been "inactive". It's *always* been "inactive", if your definition of "active" only includes port 80 or the host "www" being in the DNS.
Your suggestion is tantamount to the idea that we should give most of Southern Utah to the strip mining companies because they would *actively* use the mineral rights to extract the coal from the largest known coal deposits on the planet.
Excuse me, if I think that ownership should not go to the first person willing to use something up.
If we follow your rule, then IP addresses should all go to SPAM'mers, since they will most certainly "actively use them until they have no more use left in them".
There's "best use", and then there's "active use". The two are rarely, if ever, the same.
Back at Novell, when I worked with you, Gary Tomlinson, Jim Freeman, Ron Holt, Darren Davis, and most of the other people who left to start Caldera, the kickoff seemed to be a meeting Novell had in 1994 to try out an announcement on their own employees, which they subsequently made to the press.
In that meeting, it was announced that UnixWare was going to be deemphasized on the desktop; never one to take messages from the mountaintop at face value, I asked the V.P. (Kanwal Rekhi) the question "If not UnixWare, what *Novell* OS will people run on their desktops?"; his answer was "They won't run a Novell OS, they will run Windows". Ray Noorda then got up and left the meeting, well before it was over. I took that to be a good sign.
It's my understanding from all the conversations I had with you guys in the second floor break room at the Sandy, UT facility, that the primary motivation for forming Caldera, including you and Gary sinking your own money into it before the Noorda Family Trust funded the company, was because Novell USG -- and, in particular, the former USL management -- would not let you build the product you wanted to build. They made you use stupid technology out of "Not Invented Here", and so on (e.g. the USL-built desktop vs. Visix Looking Glass, etc.).
It seems to me that this was a desktop product, in the same sense as the intent had been for the original UnixWare (those of us left behind even jokingingly called Caledera "Linivel", after the Univel joint venture between Novell an AT&T, prior to the Novell purchase of USL).
So far, from the published reports, it seems to me that you are cutting the roots of Caldera, and are going to limit the distribution to the server market, once again abandoning the desktop to Microsoft. I would hope that that were not the case, though I know that the Linux community has, historically, not been a friend to Caldera because Caldera has never made any bones about it being anything other than a commercial venture, which hoped to be able to help Linux out on the way (I guess there is no room in a lot of prople's minds for both the GPL mindset AND the idea of mutual benefit, if one of the beneficiaries is a commercial interest).
So, with that background, here's my (two part) question:
What is your current vision for Linux in general, and Caldera in particular, going forward, and how does United Linux contribute toward achieving that vision? How does this differ from the original vision, and why were the directional changes that you've made necessary?
As soon as you drop a cruise missle running GPL'ed guidance firmware onto an enemy target, why, then you've "distributed it to them", and owe them the source code.
...you need to ask "If you own a PDA, be quiet; if you do not currently own a PDA, why not?".
I personally do not own a PDA. Therefore, I am qualified to answer. Here is why I do not own a PDA:
#1: Batteries
The batteries don't last long enough. Even if they did, it would not be enough. One fix for this might be a 60Hz LC-tank circuit to charge the batteries whenever you are in an office building wired to power the thing. You'd need to include a 50Hz tank, as well, for foreign countries and half of Japan. Meanwhile, the batteries back the RAM. When the batteries go, your RAM goes. When your RAM goes, everything you haven't synchronized goes. This leads us to:
#2: Storage
The storage is too small. It's not enough. A small hard disk, of the type IBM sells (and, I guess, which Hitachi will sell) for inclusion in cameras... the size of a quarter, holding several gig... is a minimum. Of course, being electro-mechanical, it will further reduce battery life (see #1). This can be worked around, half by adding more RAM, to be used as cache, and to allow the drive to be slept. The thing needs more RAM, anyway. Eating more power is bad; on the other hand, it will reduce the need for a synchronization umbilical:
#3: Synchronization
The problem with synchronization is that it requires that I have something much more powerful and much more useful than the PDA itself. This pretty much means that the only thing a PDA is good for is transportability. I prefer another technology to solve that problem: printers. So, transportability isn't a "killer app", it's only an enabler. Without a "killer app", the product is pretty much limited to the early adopters, which brings us to the glaring problem, from an early adopter point of view:
#3: Crappy CPU
The CPU is a Motorolla 68*328 -- Dragonball -- processor. This is a 68K processor, which has many of the instructions of the "good" 68K family of processors, but still lacks an MMU. This makes it impossible to run a true protected mode OS on the device (e.g. NetBSD 68K, etc.). It also makes it much less interesting to hack on. Which brings us to:
#4: Fragility
The whole thing is too fragile, from a software persepective. One bad application can crash the whole thing, and one malicious application can wreak havoc. You might as well be running Windows 3.x, GEM for x86, or DOS. Like those OS's, it's got bad human factors design written all over it; bringing us to:
#5: User Interface
The user interface rots. Specifically, the need to use a cryptic non-standard alphabet is awful. It might have a high "geek appeal", but it means the product can never "cross the chasm", as Geoffrey Moore would put it: the appeal comes not from any intrinsic value, but from the extrinsic value of "I know grafitti, and you don't". There's also a common complaint among users that prolonged use of Grafitti damages normal handwritings skills; anecdotally, I'd have to say this is true. The value of the device would go *way, way, up* if only it could recognize what the user writes, instead of making the user write what it recognizes.
That's basically the major points; I could nit-pick on features, like everyone else (e.g. IR or 802.11a/b or BlueTooth sbased synchornization, etc.), but there's no point: those are feature complaints, not product wholeness complaints.
IMO, PDA's are "not ready for prime time", and won't be, until their obvious deficiencies, which make them incomplete products, are addressed.
E.g. the "Infininty" game console from Bally/Midway runs on FreeBSD, not closed source.
It even has Jordan Hubbard (and other people, like, oh...me) in the "greets".
The games themselves are proprietary (some of the content is licensed, even), but the basic system itself is Open Source based.
The obvious workaround to that is to define the entire work itself as "the serial number", thus creating a legal loophole that reduces in the limit to the same thing RIAA and MPAA wanted in the first place.
Then when you buy an Elton John CD, you aren't buying a CD, you're really buying a 640MB serial number... so what if it's no different from everyone else's serial number, except by the low order 32 bits?
May I humbly suggest that the amount you lose by being "cheated" will be significantly less than the amount you lose by assuming every paying customer who calls you is out to cheat you?
Is sharing your fingerprint with their "partners" because you didn't know you had to opt out before you were born.
The less people who have access to biometric information from which they can infer genetic information that they could then use to discriminate against me, the better.
"I'm sorry sir, but our partner Thriftway provided us with information that indicates that you have a genetic predisposition to liver cancer; we are going to have to deny you medical insurance."
This isn't like RSA; you haven't hit half the search space when you hit 500,000,000 results. Statistically, a "catch" is no closer or further away than it ever was.
This is seriously fictitious milestone: it's only meaningful to humans, who think it's a large number, and who think it has more significance than other large numbers because they happen to have 10 fingers.
Trying to brute-force the protein folding problem is like trying to brute force arrive at the idea of branch path prediction, register windows, and peephole optimization by examining Windows executables.
As the author of the original 386BSD 0.1 PatchKit software, I have to say that your "air traffic control" approach will not work.
The 386BSD 0.1 patchkit used a serialization of patch numbers, with central assignment. The reason for this was that the patch dependency management was done by manually applying patches posted to Usenet, and then diffing the modified version of the code against a version with the previous N-1 applied.
Effectively, it was a "human CVS repository" system.
Ir was necessary, because the latency in the Usenet system meant that you couldn't "lock down" a file or set of files for some major change: you had to do what you wanted to do against what you had, which was almost never "the most currnet concensual version" of the code, and then hope someone else didn't win the race to "the repository" (at the time, terry@cs.weber.edu's incoming email, and then, later, Rod Grimes', Nate Williams', and then Jordan Hubbard's... no one wanted it for very long).
This led to all sorts of problems; the major one was that the patch kit format was "reverse engineered" (not hard; the patch tools, except the creation software itself, were widely distributed), and a group started releasing patches in the "1000+" ID range, under the incorrect impression that the concern was over the patch namespace collision, not topological application problems. This eventually led to a big argument, and other people going off to play in their own sandbox.
You've probably heard of "NetBSD". A couple (not all, of course) were motivated by communit rejection of the 1000+ numbered patches, which, while they were not colliding in serial number space, seriously blew out topological dependency space for modified files.
In any case, that's exactly what you are doing with your code, when you plan on assigning patch numbers based on expectation of completion.
With the number of people you have, the comments about contested interfaces being agreed to beforehand, and the comments about you having no real problem here in the first place are probably accurate.
You can basically take a couple of approaches.
The first is: don't accumulate patches, just check the code in. This respolves the problem of stale patches by not permitting them to become stale in the first place.
The second is: "cvs tag" before any major commits, so that there is a baseline from which to work to resolve conflicts.
Really, you should not be accumulating large patch sets, with as few people as are involved.
If you have a huge offline latency from a developer or group of developers (e.g. you send a CDROM to Antarctia, and two months later the send back a CDROM with their patches on it), or if you have a huge number of developers, you should reconsider your chioce of tools.
The 386BSD patchkit serialization of patch sequence numbers through a couple of human beings was a serious mistake. It had the emergent property of having a tiered set of priviledge. I'm convinced that this is what resulted in the current "core team/committer/less-than-dirt" striation in the BSD camps today.
I mention this, because CVS has a similar, though somewhat less profound, emergent property of "The One True HEAD Branch". By its nature, it encourages a single direction for all experimentation and all forward looking thought, denying nourishment to any contradictory lines of inquiry, by chopping off the roots. CVS is, in a nutshell, anti-research. It prevents people from going off 90 degrees from where everyone else is headed, and discovering new territory.
Perhaps you've heard of OpenBSD. It emerged because there was "One True HEAD Branch" in NetBSD (an early adopter of CVS, in Open Source-land), and several people felt strongly enough that the focus of the project should be secure systems research, that the resulting code directions were incompatible.
Tools issues are at the base of nearly any strong divide you can name in an Open Source community.
Linux currently has issue, where Linus is investigating the use of Larry McVoy's BitKeeper (Larry was smart, in that early on, he recognized the emergent properties tools choices force onto projects, and tried to design around the problem). It turns out that a single human CVS repository doesn't scale infinitely.
FreeBSD is in the throes of a "To use Perforce or not to use Perforce" decision. Perforce supports seperate lines of concurrent developement.
It fosters, as my former boss' boss, Ray Noorda, used to say, "coopetition": help each other make the best implementation according to their design, and then may the best design win.
Perforce lets this happen, but it also tends to balkanize developement, if not everyone is using the tool. There are complaints in FreeBSD that significant work is taking place in Perforce branches that aren't visible to normal CVS users. The Perforce users complain back that there would be no need for Perforce, if the develeopement were permitted in the main CVS tree -- along with the breakage that would entail. Both arguments have merit. Right now, there is a truce... more of an agreement to disagree, and not force the issue today, but a promise that the battle will be fought to the death at some later date.
For your project, a tool which supports multiple concurrent "One True HEAD Branches" seems like it fitys the bill (though as I wrote that, I still asked myself why, with so few people, it was an issue for you in the first place).
Whether the tool you pick is Perforce, Bitkeeper, or some other tool that can support that developement model is irrelevent.
What is relevent is that you understand that our tools shape the way we think about solving problems, and if you have already arrived at an approach that doesn't -- or *can't* -- fit into the shape dictated by CVS, then it's probably time to look at another tool.
Not matter what you do, I can guarantee you that layering another, less adequate, tool on top of an already inadequate tool, will not fix your problem.
I can also guarantee you that if you can't change your model to fit an existing tool, you're going to find yourself in the source code control tools business, instead of the business you intended to be in.
Probably, you should rethink whatever premise it is that's resulting in large, infrequently integrated patch sets. If it's just your release engineering department not wanting to do their work on a branch, well, that's tough. Branch tag for releases as a matter of policy, and move on. If on the other hand, it's something more profound, perhaps you need to rethink your assumptions in favor of what the tools can do, vs. what you would like them to be able to do.
Alternately, welcome to the source code control tool business.
Slashdot Mirror
This whole realm is already at least partially mapped out by a number of researchers. The ones referenced in the article are actually the least impressive of the lot, in my experience.
My personal pick for most notable researcher in this area is Joshua Epstein. He's with the Sante Fe Institute. The best book of the several he's written is:
Nonlinear Dynamics, Mathematical Biology
and Social Science (Santa Fe Institute
Series, Lecture Notes, Vol 4)
Joshua M. Epstein
Perseus Publishing
ISBN: 0201419882
It presents a number of mathematical models (games theory), including a variant of a Non-linear Richardson called "GloboCop", which does a fairly good job of modelling "core team" based Open Source software projects (IMO).
There has actually been a lot of work along these lines; the first I ever heard of it was an article in Analog Magazine's "Science Fact" column, entitled "Toward a Science of Psychohistory".
-- Terry
You can fake having some measure of skill, if you have a machine in front of you.
As a lot of people have already noted, there are people who use a compiler as a crutch, to catch errors. Just as people use a calculator as a crutch, or a spelling checker as a crutch.
I would not hire a reported for a newspaper who could not turn in good work without a spell-checker (or worse, a grammer-checker).
I would not hire a mathematician who needed a claculator in order to take a square root.
And I would not hire a programmer who needed a compiler in order to write good code.
I think that it's very important that the skills reside in the people, not in the tools.
I also think that people who approach problem solving through successive approximation, using an editor and a compiler to judge their work product, are much less likely to solve a problem correctly the first time.
Yes, it's amazing the number of problems you can solve with brute force. But a brute force solution will inevitably be suboptimal, and require rewriting by someone else... someone with better work habits.
There's a lot of merit in knowing how to arrive at a solution, but there's also merit in knowing the answer before you start.
Knowing how to use a tool is good; knowing how to build a tool, because you know how a tool arrives at its result, is better.
As a final note, I will say that I have known a lot of programmers from the "sit down and code" school of computer programming. Without exception, these are people who I would not hire for a design position on a bet; I would prefer not to hire them at all, but if it came down to it, they could do OK in the production of prototypes. They are people who don't understand the value of planning, or provability, or process, and they are the people who will become upset when they are forced to use source code control, or to work in teams. They are people who can not solve complex problems, except by way of kludge. I guess the worst part of this is that these people often believe that they are "code gods", simply because they can produce code that, with a restricted set of inputs, gets the expected set of outputs, and they can produce it quickly.
-- Terry
So far, everyone has been talking about the employer's part in the process. That's not what you should be examining, anyway.
Let me prefix this by saying that, if you have already accepted the first offer, the answer should be obvious: you do not accept the counter offer. You are only as good as your word, and if you have agreed to work for someone new, then you need to keep your agreement. If that's the case, accepting or even entertaining a counter offer, is an incredibly bad thing.
That out of the way, you need to understand why you were looking in the first place.
If you were looking because you were unhappy with the pay at your present job, you should have brought this up with your current employer directly, rather than trying to get a lever on them. Now that you have this lever, though, what you should do with it is pretty clear: you shouldn't have obtained it if you weren't willing to use it. I agree with most of the sentiments of "bad blood"; however, this only really applies if the only thing you are trying to lever out of your employer is money. If you are after intangibles, or non-monetary compensation (equity, elder care insurance, etc.), sometimes a lever is OK... though I would personally never be that blunt about it, but would instead start with "this is what comparable companies are doing...".
If you were looking because you wanted to measure your value in the market, well, then you probably have less value than you now think you have. The problem is that if you didn't start out with some idea of your value in the market, then what you now are is "sold goods": the value you think you have is based on your ability to sell yourself to an employer, not based on your ability to do the job for which the offer was tendered. Be very careful here. If you have padded your resume one iota, then you have shot yourself in the foot (in general, it's better to be completely honest on resumes, in my experience; it changes the interview dynamic significantly in your favor).
If, instead, you were looking because you were unhappy with your present job, how is money going to fix things? Unless the counter-offer includes the power to change the things which sent you looking in the first place, you will ultimately be unhappy, and leave anyway. Money can be a salve; it can make you put up with a lot. If you participate in a volunteer/Open Source project of any kind, you will understand where people's true tolerances, without the salve of money, really lie. Many people put up with their coworkers not because they are easy-going or "nice people", but because that's part of what they are being paid to do.
The only other reason to be looking is because you have wanderlust. If you need to wander, then wander. My recommendation is that you try to stay in one place as long as possible. An employment history rife with wanderlust signals a potential employer that you are unlikely to stay long. If you don't have the self control for this, then you really need to change your idea of work from "full time job" to "contractor". Otherwise, your wanderlust will damage your ability to get future work, as you get older, and settle down.
In general, I think that if things have progressed to the point of monetary counter offer, then you have already left your current job; even if you don't know this, your employer, who is presumably a preofessional manager, will.
I think it's ironic that this is being herladed as "the death of copper".
It's my understanding that what held it up was the optical parts vendors couldn't make transceivers that went fast enough.
You've actually been able to buy 10Gbit *copper* hardware from HP for almost a year now, and the copper part of the draft standard has remained unchanged since then.
I rather expect that the next speed increment will have similar problems with the relative ease of making copper vs. optical transceivers, so the next bump will end up being "copper first" again.
"Dammit! He got me! Lets see if he can do it again."
Reading your post, I almost fell out of my chair laughing.
Imagine a press conference after a fierce battle, where the spokesperson for the losing side has to admit that the battle was lost because "our pilots ran out of quarters"...
I would put most of my source code in the Public Domain, if I could.
I can't.
Not "I won't".
I *can't*.
My problem is that, without a license, I can't attach a "hold harmless", or prevent my name being used to sell code derived from it, but of which I personally would not approve.
So to keep rights to my good name, and protect myself (as much as possible) from litigation arising from the use of my gifts to the public, I have to attach the minimum possible license that still gets me these things (the BSD license).
It's not that I *want* to do this, it's that there are no implicit legal protections for the authors of works placed into the public domain.
Without such legal protections, I simply can't *afford* to make the gifts that I want to make to the public.
It's just too dangerous.
-- Terry
This is all about the fact that the calbe companies entire infrastructure is geared at pushing content at you. It's why everything is assymmetric in the first place: "DRINK FROM THE FIREHOSE!"
I rather expect that they are also seeing much less of the camel-nose-tent effect than they hoped for, with cable modem users NOT also subscribing to cable television.
If they are *truly* concerned about their bandwidth, then they can stop sending "Barney" and home shopping channels and commercials down the wire to my house. That ought to free up an incredible number of bits right there. Then, if that's not enough for them, they can charge less for digital than analog so we all get digital, and not send the bits that no one is looking at on any given segment at any given time.
But, in fact, this is really about uploads: they don't want you sending *anything*. The really annoying thing for them is that you are sending TCP ACK's at all, and they *have* to permit it for their service to work. That's why, despite the fact that they give you a practically infinite DHCP lease, they are unwilling to assign you a static IP address, unless you pay the "business rates" for the service. And why many providers terms of service prohibit running servers, and do port filtering, scanning, and so on to verify that you aren't running anything.
This is all totally obnoxious on their part, and they are stupid if they think that consumers don't see what they are really doing.
-- No camels in my tent!
..."doesn't have nothing to do with physical power or the ability to affect the physical world"
Tell that to Robert Oppenheimer.
-- Terry
Your rule about "the name must be in active use" is, excuse my .fr, assinine.
I've owned a ".org" domain name since 1992. If you'll check, you'll find that that was way before they charged for the things (and if you check deeper, you will see that the reason they started to charge for the things in the first place was that Dupont and P&G registered all their trademarks as domains in a single day).
My domain has occasionally been "inactive". It's *always* been "inactive", if your definition of "active" only includes port 80 or the host "www" being in the DNS.
Your suggestion is tantamount to the idea that we should give most of Southern Utah to the strip mining companies because they would *actively* use the mineral rights to extract the coal from the largest known coal deposits on the planet.
Excuse me, if I think that ownership should not go to the first person willing to use something up.
If we follow your rule, then IP addresses should all go to SPAM'mers, since they will most certainly "actively use them until they have no more use left in them".
There's "best use", and then there's "active use". The two are rarely, if ever, the same.
Hi, Ransom; my question is at the end.
Back at Novell, when I worked with you, Gary Tomlinson, Jim Freeman, Ron Holt, Darren Davis, and most of the other people who left to start Caldera, the kickoff seemed to be a meeting Novell had in 1994 to try out an announcement on their own employees, which they subsequently made to the press.
In that meeting, it was announced that UnixWare was going to be deemphasized on the desktop; never one to take messages from the mountaintop at face value, I asked the V.P. (Kanwal Rekhi) the question "If not UnixWare, what *Novell* OS will people run on their desktops?"; his answer was "They won't run a Novell OS, they will run Windows". Ray Noorda then got up and left the meeting, well before it was over. I took that to be a good sign.
It's my understanding from all the conversations I had with you guys in the second floor break room at the Sandy, UT facility, that the primary motivation for forming Caldera, including you and Gary sinking your own money into it before the Noorda Family Trust funded the company, was because Novell USG -- and, in particular, the former USL management -- would not let you build the product you wanted to build. They made you use stupid technology out of "Not Invented Here", and so on (e.g. the USL-built desktop vs. Visix Looking Glass, etc.).
It seems to me that this was a desktop product, in the same sense as the intent had been for the original UnixWare (those of us left behind even jokingingly called Caledera "Linivel", after the Univel joint venture between Novell an AT&T, prior to the Novell purchase of USL).
So far, from the published reports, it seems to me that you are cutting the roots of Caldera, and are going to limit the distribution to the server market, once again abandoning the desktop to Microsoft. I would hope that that were not the case, though I know that the Linux community has, historically, not been a friend to Caldera because Caldera has never made any bones about it being anything other than a commercial venture, which hoped to be able to help Linux out on the way (I guess there is no room in a lot of prople's minds for both the GPL mindset AND the idea of mutual benefit, if one of the beneficiaries is a commercial interest).
So, with that background, here's my (two part) question:
What is your current vision for Linux in general, and Caldera in particular, going forward, and how does United Linux contribute toward achieving that vision? How does this differ from the original vision, and why were the directional changes that you've made necessary?
Thanks,
-- Terry
As soon as you drop a cruise missle running GPL'ed guidance firmware onto an enemy target, why, then you've "distributed it to them", and owe them the source code.
8-).
You know the effects that gravity currently has?
Well, the effects of antigravity would be the opposite of those.
...I'm just glad I could help out...
...you need to ask "If you own a PDA, be quiet; if you do not currently own a PDA, why not?".
I personally do not own a PDA. Therefore, I am qualified to answer. Here is why I do not own a PDA:
#1: Batteries
The batteries don't last long enough. Even if they did, it would not be enough. One fix for this might be a 60Hz LC-tank circuit to charge the batteries whenever you are in an office building wired to power the thing. You'd need to include a 50Hz tank, as well, for foreign countries and half of Japan. Meanwhile, the batteries back the RAM. When the batteries go, your RAM goes. When your RAM goes, everything you haven't synchronized goes. This leads us to:
#2: Storage
The storage is too small. It's not enough. A small hard disk, of the type IBM sells (and, I guess, which Hitachi will sell) for inclusion in cameras... the size of a quarter, holding several gig... is a minimum. Of course, being electro-mechanical, it will further reduce battery life (see #1). This can be worked around, half by adding more RAM, to be used as cache, and to allow the drive to be slept. The thing needs more RAM, anyway. Eating more power is bad; on the other hand, it will reduce the need for a synchronization umbilical:
#3: Synchronization
The problem with synchronization is that it requires that I have something much more powerful and much more useful than the PDA itself. This pretty much means that the only thing a PDA is good for is transportability. I prefer another technology to solve that problem: printers. So, transportability isn't a "killer app", it's only an enabler. Without a "killer app", the product is pretty much limited to the early adopters, which brings us to the glaring problem, from an early adopter point of view:
#3: Crappy CPU
The CPU is a Motorolla 68*328 -- Dragonball -- processor. This is a 68K processor, which has many of the instructions of the "good" 68K family of processors, but still lacks an MMU. This makes it impossible to run a true protected mode OS on the device (e.g. NetBSD 68K, etc.). It also makes it much less interesting to hack on. Which brings us to:
#4: Fragility
The whole thing is too fragile, from a software persepective. One bad application can crash the whole thing, and one malicious application can wreak havoc. You might as well be running Windows 3.x, GEM for x86, or DOS. Like those OS's, it's got bad human factors design written all over it; bringing us to:
#5: User Interface
The user interface rots. Specifically, the need to use a cryptic non-standard alphabet is awful. It might have a high "geek appeal", but it means the product can never "cross the chasm", as Geoffrey Moore would put it: the appeal comes not from any intrinsic value, but from the extrinsic value of "I know grafitti, and you don't". There's also a common complaint among users that prolonged use of Grafitti damages normal handwritings skills; anecdotally, I'd have to say this is true. The value of the device would go *way, way, up* if only it could recognize what the user writes, instead of making the user write what it recognizes.
That's basically the major points; I could nit-pick on features, like everyone else (e.g. IR or 802.11a/b or BlueTooth sbased synchornization, etc.), but there's no point: those are feature complaints, not product wholeness complaints.
IMO, PDA's are "not ready for prime time", and won't be, until their obvious deficiencies, which make them incomplete products, are addressed.
-- Terry
Oh, the world looks mighty good to me,
'Cause Open Source is all I see.
Whatever issue I think I see,
It becomes a reason for Open Source to me!
Open Source, Open Source, B S D and GNU!
Oh Open Source, I think I'm in-love-with-you!
Whatever issue I think I see,
It becomes a reason for Open Source to me!
[ suscipio ergo sum -- I advocate, therefore I am ]
E.g. the "Infininty" game console from Bally/Midway runs on FreeBSD, not closed source. It even has Jordan Hubbard (and other people, like, oh ...me) in the "greets".
The games themselves are proprietary (some of the content is licensed, even), but the basic system itself is Open Source based.
I think the most useful thing anyone has ever implemented in "Flash" is the "Bypass Flash intro" button...
-- Terry
The obvious workaround to that is to define the entire work itself as "the serial number", thus creating a legal loophole that reduces in the limit to the same thing RIAA and MPAA wanted in the first place.
Then when you buy an Elton John CD, you aren't buying a CD, you're really buying a 640MB serial number... so what if it's no different from everyone else's serial number, except by the low order 32 bits?
I managed a support department at one time.
May I humbly suggest that the amount you lose by being "cheated" will be significantly less than the amount you lose by assuming every paying customer who calls you is out to cheat you?
Is sharing your fingerprint with their "partners" because you didn't know you had to opt out before you were born.
The less people who have access to biometric information from which they can infer genetic information that they could then use to discriminate against me, the better.
"I'm sorry sir, but our partner Thriftway provided us with information that indicates that you have a genetic predisposition to liver cancer; we are going to have to deny you medical insurance."
This isn't like RSA; you haven't hit half the search space when you hit 500,000,000 results. Statistically, a "catch" is no closer or further away than it ever was.
This is seriously fictitious milestone: it's only meaningful to humans, who think it's a large number, and who think it has more significance than other large numbers because they happen to have 10 fingers.
-- Terry
Trying to brute-force the protein folding problem is like trying to brute force arrive at the idea of branch path prediction, register windows, and peephole optimization by examining Windows executables.
As the author of the original 386BSD 0.1 PatchKit software, I have to say that your "air traffic control" approach will not work.
The 386BSD 0.1 patchkit used a serialization of patch numbers, with central assignment. The reason for this was that the patch dependency management was done by manually applying patches posted to Usenet, and then diffing the modified version of the code against a version with the previous N-1 applied.
Effectively, it was a "human CVS repository" system.
Ir was necessary, because the latency in the Usenet system meant that you couldn't "lock down" a file or set of files for some major change: you had to do what you wanted to do against what you had, which was almost never "the most currnet concensual version" of the code, and then hope someone else didn't win the race to "the repository" (at the time, terry@cs.weber.edu's incoming email, and then, later, Rod Grimes', Nate Williams', and then Jordan Hubbard's... no one wanted it for very long).
This led to all sorts of problems; the major one was that the patch kit format was "reverse engineered" (not hard; the patch tools, except the creation software itself, were widely distributed), and a group started releasing patches in the "1000+" ID range, under the incorrect impression that the concern was over the patch namespace collision, not topological application problems. This eventually led to a big argument, and other people going off to play in their own sandbox.
You've probably heard of "NetBSD". A couple (not all, of course) were motivated by communit rejection of the 1000+ numbered patches, which, while they were not colliding in serial number space, seriously blew out topological dependency space for modified files.
In any case, that's exactly what you are doing with your code, when you plan on assigning patch numbers based on expectation of completion.
With the number of people you have, the comments about contested interfaces being agreed to beforehand, and the comments about you having no real problem here in the first place are probably accurate.
You can basically take a couple of approaches.
The first is: don't accumulate patches, just check the code in. This respolves the problem of stale patches by not permitting them to become stale in the first place.
The second is: "cvs tag" before any major commits, so that there is a baseline from which to work to resolve conflicts.
Really, you should not be accumulating large patch sets, with as few people as are involved.
If you have a huge offline latency from a developer or group of developers (e.g. you send a CDROM to Antarctia, and two months later the send back a CDROM with their patches on it), or if you have a huge number of developers, you should reconsider your chioce of tools.
The 386BSD patchkit serialization of patch sequence numbers through a couple of human beings was a serious mistake. It had the emergent property of having a tiered set of priviledge. I'm convinced that this is what resulted in the current "core team/committer/less-than-dirt" striation in the BSD camps today.
I mention this, because CVS has a similar, though somewhat less profound, emergent property of "The One True HEAD Branch". By its nature, it encourages a single direction for all experimentation and all forward looking thought, denying nourishment to any contradictory lines of inquiry, by chopping off the roots. CVS is, in a nutshell, anti-research. It prevents people from going off 90 degrees from where everyone else is headed, and discovering new territory.
Perhaps you've heard of OpenBSD. It emerged because there was "One True HEAD Branch" in NetBSD (an early adopter of CVS, in Open Source-land), and several people felt strongly enough that the focus of the project should be secure systems research, that the resulting code directions were incompatible.
Tools issues are at the base of nearly any strong divide you can name in an Open Source community.
Linux currently has issue, where Linus is investigating the use of Larry McVoy's BitKeeper (Larry was smart, in that early on, he recognized the emergent properties tools choices force onto projects, and tried to design around the problem). It turns out that a single human CVS repository doesn't scale infinitely.
FreeBSD is in the throes of a "To use Perforce or not to use Perforce" decision. Perforce supports seperate lines of concurrent developement.
It fosters, as my former boss' boss, Ray Noorda, used to say, "coopetition": help each other make the best implementation according to their design, and then may the best design win.
Perforce lets this happen, but it also tends to balkanize developement, if not everyone is using the tool. There are complaints in FreeBSD that significant work is taking place in Perforce branches that aren't visible to normal CVS users. The Perforce users complain back that there would be no need for Perforce, if the develeopement were permitted in the main CVS tree -- along with the breakage that would entail. Both arguments have merit. Right now, there is a truce... more of an agreement to disagree, and not force the issue today, but a promise that the battle will be fought to the death at some later date.
For your project, a tool which supports multiple concurrent "One True HEAD Branches" seems like it fitys the bill (though as I wrote that, I still asked myself why, with so few people, it was an issue for you in the first place).
Whether the tool you pick is Perforce, Bitkeeper, or some other tool that can support that developement model is irrelevent.
What is relevent is that you understand that our tools shape the way we think about solving problems, and if you have already arrived at an approach that doesn't -- or *can't* -- fit into the shape dictated by CVS, then it's probably time to look at another tool.
Not matter what you do, I can guarantee you that layering another, less adequate, tool on top of an already inadequate tool, will not fix your problem.
I can also guarantee you that if you can't change your model to fit an existing tool, you're going to find yourself in the source code control tools business, instead of the business you intended to be in.
Probably, you should rethink whatever premise it is that's resulting in large, infrequently integrated patch sets. If it's just your release engineering department not wanting to do their work on a branch, well, that's tough. Branch tag for releases as a matter of policy, and move on. If on the other hand, it's something more profound, perhaps you need to rethink your assumptions in favor of what the tools can do, vs. what you would like them to be able to do.
Alternately, welcome to the source code control tool business.
-- Terry