While the algebra is somewhat procedural, the calculus is set-oriented, and they are fully equivalent.
and, uncoincidentally, the isomorphism extends further to machines that manipulate physical punch cards. You go on to say:
The idea is exactly not looking at records and operators, but describe what you want -- just leave the relational system set the procedures to get that in the most efficient way it can.
Right. And what Gray has pointed out is that Codd's work on the math and how to implement it doesn't really require computers, as such.
In an alternate timeline, there were no computers just lots of expensive punch-card machines and racks and racks of data stored on punch-cards. (Such was the economic value of all this data that the racks of cards were often stored with an almost military degree of jealous protection: the origin of the term "Data Base".)
Each card machine could perform a simple operation like "duplicate this card stack" or "pull out the cards that have a Q in column 3". The machines could be organized into a sort of assembly line for a particular computation, with technicians looking at a script on a clipboard and carrying trays of cards between machines, configuring each machine with the right parameters, running the cards through, then going to the next step. It was an expensive, labor-intensive process and the ad-hoc procedures used to write the scripts for the technicians were black-magic, often error prone.
Time-study super-genious, Alternate-Codd, studied the machines and the procedures used to operate them. He realized that they could be described by set math. He realized that if you let the managers define their "Card Searches" in very high-level, very mathy terms -- then there was a straightforward optimization problem to get from that "Search Specification" to set of "compiled instructions" for the technicians. The goals was produce a set of Compiled Instructions that would use the punch card machines in an optimal way -- saving time and money.
He studied the optimization problem and developed some techniques for it. Companies used his results by highering a "Compiler Pool" -- most often a group of women chosen from the secretarial pool for the accuracy of their work. When a new Card Search request came in, the search would be typed up and mimeographed, and handed to the head of the Compiler Pool. It typically took "the girls" about a day to compile a query but, every time, the scripts they wrote for the technicians produced the right answer, usually much faster than anyone thought possible.
In one office, though, in Rochester New York, there was a famous accident. The office used by the Compiler Pool had developed a problem with flies. One day, one was swatted and killed with the mimeograph master of a compiled query, leaving a mark that obscured some important numbers. Nobody noticed, the technicians dutifully followed the errant script, and by the next afternoon the company's entire collection of precious data was strune, unsorted, in a huge pile on the machine room floor. The company was bankrupt only 9 months later.
The company president demanded an explanation when the accident occured and much investigation followed, eventually revealing the fly and its consequences. This was, of course, the origin of the familiar phrase (known to every customer whose ever gotten a $500 bill for a month of telephonic service), "compiler bug".
> [why is hard to write a good revision > control system?]
Many reasons. Here are a few.
1) precision. If your mp3-player crashes -- big whoop. You'll fix it, or report a bug, or try a different one. If you run your project on revision control system XYZZY for a year, and then discover that it has corrupted 6 month old data beyond repair, now you are really screwed. There are many features in revision control systems that aren't critical -- bugs can just be fixed. But there's a core part of revctl that has to be very robust.
2) balancing art and science. I suspect that most casual uses of, say, CVS are just thinking about checking out trees, maybe updating them, maybe checking stuff in. When projects are large and busy, though, suddenly branching and merging and history auditting and all the "obscure" features are very important. The problem for the designers/authors of revision control systems is that for those obscure-but-important features: There Are No Right Answers. If you were to try to develop a purely mathematical theory of what those features should do, the fundamental theorem of the theory would be "it is impossible to implement them." In practice, the best you can do is to implement _approximations_ of what those features would ideally do. And worse, there are gazillions of different approximations to choose from. So there's a serious challenge there: to pick a subset of the possible that adds up to the most useful approximation of the impossible.
4) making wise implementation decisions, especially regarding time and space performance characteristics. Revision control systems ultimately wind up managing a _lot_ of data, and keeping that data around for a _long_ time. In an implementation, you have to make decisions about how to store that data, trading off factors such as the complexity of the implementation, the amount of storage space you'll use, and the cost of retrieving data. Over the lifetime of a deployed revctl system, you can expect factors like CPU speed and disk economics to evolve profoundly far. As basic, text-book software implementation tasks go -- revctl is a fairly challenging one.
5) distribution. In terms of what users are starting to demand, distribution is a comparatively new thing in revision control. Remember, it wasn't _that_ long ago that CVS didn't even support remote access to a central repository, nevermind distribution across mulitple repositories. Taking distributed operation into account, the mix of slow, medium and fast network connectivity in the world, the economics and politics of administration -- distribution amplifies the challenges of (1)..(4).
projects are the R&D lab of free software vend
on
Funding Open Source?
·
· Score: 1
Public projects are the de facto R&D lab of commercial free software vendors.
Unlike a "high on a hill" lab owned by some big company, our R&D is cheaper/faster/better -- but it ain't free. In my case, and many others, the funding is falls below the costs.
We need two things: _Will_ (self interested one could argue) from the vendors to pay the bills. _Mechanism_, to arrange that payment (not merely "paypal buttons" -- higher level mechanism, so that the vendors are assured technology transfer and have a legitimate claim to R&D tax credits).
There's exactly two legitimate bases for stock valuations: one is dividends, the other is a cycle of systematic buy-backs and new issues.
Absent either of those two options, what have you got? You've got someone saying to the market "Hey, loan us some money. We never intend to repay, but perhaps you can sell our note to someone else for a profit."
I _originally_ decided to write free software for a very simple reason: in order to join a community based on friendship, mutual support, and shared intellectual development, dedicated to improving it's larger environment through hacking (in the sense of "playful, forthright, responsible, and creative development and application of technical and engineering skill, insight, and ideas").
In high school, and then later in college, there were all the regular faces you'd see around the computer labs. There was a culture there, for a time, now largely gone, based on sharing ideas and resources, and being friendly. We learned from one another, we egged each other on to better and better achievements, and we made our campuses better even for people who were outside of the clique. We'd go out for Chinese food, order pizzas, and then drop by the basement of the guy who had a discarded rack-mount pdp-11 in his basement to see if we could still boot the thing. We'd show off our hacks to one another. We traded copies of papers and books. We weren't competing in a scarce job market. We weren't competing for "who gets the best press on/.". We weren't saddled with the impossible task of reconciling the supposed "business realities" of our non-hacker bosses with the essentially mathematical truths that under-pin the craft we were learning.
Around that time, software was becoming a big, mass-market commercial product for the first time. There was visicalc and scriptsit, for example. There were warnings from faculty members that pirating software was against the rules. And a little while after that, there were the early writings of and about RMS, and against that: the example of unipress emacs.
In those writings, hacker cultures were pretty well described. The fundamental contradiction between such human communities and proprietary licensing were clearly spelled out. Free software was a no brainer. It was simply the only civilized alternative.
Resume fodder. Fame. Power of volunteers. A few million bucks to line the pockets of RHAT execs. A general mean-spiritedness and intellectual dishonesty when projects compete. A shockingly naive and dangerous popular outlook on what good programming consists of. A commoditization of programmers to the point where they are formed into a worse-than-peasant-class. A stunningly uninformed and uncritical view of technology dominating/. and kerneltrap and 100 project mailing lists. An FSF whose mission is a jet-setting RMS and a completely unfunded, bottom of the page, also-ran "build a GNU-system" task....
The free software "community" these days is decadence. It has become divorced from human values. It's in a shameful state.
The free software movement originated out of the mourning of a single individual for a lost community. How ironic that it has evolved into a culture that actively resists the formation of community.
This is good for Red Hat. There are some obvious PR benefits to it, of course.... but I think it amounts to R&D they'll eventually capitalize on.
RHATs central servers -- not just for isos but also for updates -- are a vulnerability; a single point of failure six different ways from tuesday. (There's even another post in this/. topic about the servers allegedly being overloaded right now.)
Not nearly all, but a big chunk of the vulnerabilities can be fixed with P2P distribution. RHAT's bigger customers can be organized to help each other that way. When, for example, security emergency response times become critical, P2P will be a big boon.
If, suddenly, all distribution of RHAT software happened P2P -- subscriptions would still have value, and that value will grow over time. Immediately, it would have value as a source of secure hashes, delivered over multiple channels. Of course it would retain its support values -- and my hope/prediction is that in the future, Red Hat Network will increase in the degree to which it is a low-walled garden "community (of customers) website": tightening and enriching the feedback loop between customers and programmers.
I would say that that is question we should each ask of ourselves, and work towards in our lives. I would say that that answers are never simple, but the ideals not so hard to grasp. I would say that "The Place of Dead Roads" by William S Burroughs is, perhaps, his best work -- and certainly a milestone in American literature.
> Another way of looking at it is simply the > usual networking transaction that take > place in the real world. Imagine that you > are looking for a reliable contractor to > renovate your house. There are a number of > three-way transactions taking place > between you, a friend you trust, and a > contractor he trusts well enough to > recommend. The whole point of reputation > and networking is to allow a certain > amount of transitivity in trust > relationships.
If I'm looking for a contractor for a big job, sure -- I'll bring my friend whose worked with several over for wine and, in the course of the day, form my own nuanced judgement. I might treat the prospective contractors to a lunch or dinner to chat about nothing in particular and construction and quality. I'll bring them to my house and watch how they look at it. What part of this, exactly, do you want to reduce to a score on a web site?
How, in Affero's system, do you say "I didn't get along with that guy at all -- but knowing you as I do, I wonder if he might not be the right guy for your job?"
> Not to mention, if you haven't noticed that > every community that uses a publically > displayed "experience points" type system > slowly dies a redundant, boring death as people > continually spit out the same useless advice as > fast as possible to receive their precious > points. It seems to attract the bottom of > the barrel, perhaps because people who are > truly interested in the discussion don't need > the "incentive" and go to serious forums.
Oh no....you're so wrong. Henri's all on top of that "gaming the system stuff". Didn't you read the interview? He _says_so_ and that proves it's true.
Oh come on now, you're taking my points to
the extreme and pointing out their
breaking points:)
I'm simply thinking through the implications of what happens if Affero succeeds on their current path. It's you times 100s or 1000s of others.
Of *course* I wouldn't judge somebody
exclusively on some bad karma they got
back in 1999,
Timing of "bad karma" isn't the primary issue. The unrecorded context is. Haven't you ever been in a situation where the group dynamic included people trying (and succeeding) at making you "look bad"? I think the best way to judge, say, a potential employee is to sit down over a nice meal and talk with them. Then sit down with some paper or a whiteboard and talk with them. In programming, look at their code, then talk with them some more.
are you trying to tell me that if you had
one position to fill, and you had two
people applying, and one had a better
Affero profile than the other (which,
after a little investigation, proved well
founded), you wouldn't choose the person
with the better profile?
First, I don't believe that there is any such thing as a "well founded" Affero profile.
Second, yes -- I would not use Affero to judge candidates. I would try to get to know the candidates and their capabilities personally. If I still couldn't decide, or had doubts about the reasons for my intial decision -- I'd flip a coin.
We don't need to make ourselves less human and more robotic by reducing to a database table our highest values. We need the Johnson Family (a code of conduct at the turn of the century in the American west; good bums and theives; a Johnson is a good man to do business with; he honors his obligations; he isn't a snoopy, self-rightous person; he doesn't stand idly by when someone is drowning or trapped in a burning car; a Johson will give help when help is needed...)
Conversely, if I went and looked at his
Affero rating, and saw that he had
received some negative or
middle-of-the-road feedback, or that
compared to others on LinuxQuestions he
barely had any, I might be less inclined
to take him on.
And you think this is a _good_ thing?
Suppose someone gets a negative rating for reasons that are really stupid or that no longer apply. That kind of thing happens all the time and then, looking at the evidence N years down the road, it's impossible for 3rd parties to tell what happened. You're proposing that that kind of bad luck should be amplified and have a long term effect on a person's life -- apparently because you find it convenient or even compelling to simplify your evaluation task to just "Look at the number in column 4".
I have in my pocket a list of... um... _57_ communists within the federal government....
Human trust or reputation is usually developed one-and-one and in personal interactions. It is a _little bit_ transitive (A trusts B, B trusts C, therefore A trusts C) but there are many interesting exceptions. It is a _little bit_ like an incrementally adjusted "score" in a long term game, but again, there are many interesting exceptions where it changes with the wind. Trust and reputation, in their human sense, are mysteries.
A database about "trust" or "reputation" based on voting is something completely different. It has little or nothing in common with the human forms. It can not "change with the wind". Worse than being strictly transitive, it's a popularity contest (A "trusts" anonymous crowds of voters; an anonymous crowd of voters "trusts" C; therefore A "trusts" C). That's not trust -- that's an election for homecoming king and queen in a cliquish high school.
In short, systems such as Affero smack of an unscientific sociological experiment to redefine what trust and reputation mean. Worse, given its proposed connection to money and careers -- it's an experiment that, if it succeeds, forces everyone in the free software industry to play. In short, it is immoral.
(This isn't to say that it's fundamentally different from, say, HR blacklists and other private realizations of similar ideas.)
One of the key "properties" that Affero possesses is a _great_ thing: the paylist mechanism. You can make a list of people or organizations and describe how they "divide up a pie" -- and people can, in a single transaction, pay all the members of that list according to the proportions. That's a (potentially) incredibly useful tool. Think of it as "group paypal". For example, a software project or a group of musicians can use that to organize an on-line tip-jar without the hassles and legal overhead of forming a formal organization.
So, Affero, _please_ drop this obnoxious, culture-polluting notion of formalized "trust" and "reputation", surface the paylist mechanism, and let us use that as we see fit. We'll use _real_ trust and _real_ reputation to negotiate among ourselves how to structure the paylists.
Meanwhile: we really _do not need_ a monetized, playground popularity contest.
I think the reason is that, unlike 10 years
ago, many companies are now in the business of writing free software.
Not really. Not in the comprehensive way that was once the FSF agenda. Sure, companies doing development in fairly narrow (and not infrequently private or even proprietary) areas -- but no big R&D push comperable to the effort that FSF had going. Lot's of company-oriented projects that have the hearts and minds of volunteers, though. (And isn't that last point at least unseemly?)
The FSF is going where it's needed - providing legal support to ensure that existing free
software remains free, and providing hosting
services for volunteer-run projects.
Some of what the FSF is doing (you left out advocacy) is very important. I don't disagree about that. That's why it's a delicate criticism -- I also have a lot of respect for the FSF.
I'm not even sure that the Right Thing is for the FSF to change here -- only to raise the issue on/. to see what folks might have to say.
Time was when contributions to FSF funded programmers busy writing new free software. This appears to be far less the case, these days -- at a period of time when, 10 years ago, I would have predicted that FSF would now be doing more or less what RHAT does.
This is a delicate criticism, of course. It's not at all that where there money goes isn't important -- far from it.
But, hey, where's my "complete GNU system" (other than in arguments that various non-FSF distributions should be called GNU/Linux)?
I'll bet it tanked because the economy is so bad. Unemployment, particularly in tech sectors is very high. Consumer spending in general is way down.
In boom times, even a bad Star Trek movie is worth $7-$20 bucks -- for it's value as camp, if nothing else. Other posters have remarked that they are prioritizing -- seeing LOTR instead, for example. That's a symptom of thin wallets.
But, hey, the blockbuster isn't the future. Small independent films are. The way to make money from the franchise is to make it a, well, franchise. License independents to use the ST universe (but none of the hollywood characters). Give them budgets and a technical assist on effects. Be liberal enough to allow some R rated content. A flurry of films for a $1M or three combined with all that latent creativity in the world, early DVD collections of the best-of-breed: paradise! (Well, film-wise, anyway.)
> [arch isn't portable beyond unixen because > it's largely written in sh]
Just as a small clarification on a technical issue:
1) In some sense, yes, that's an obstacle.
2) It is very portable among solid Posix and nearly-Posix systems. It's not terribly useful as it stands on cygwin because (I've been told) `fork/exec' is very slow on cygwin.
3) Most importantly, though, and a bit unlike SVN, arch is designed to be implemented more than once. It's tiny enough to rewrite (say, in Python or Perl) in just a few man-months. It's based in part on the idea of standardizing repository formats, exchange formats, and so forth. In other words, from the point of view of whether or not to support finishing arch, you have to regard it not just as a particular implementation, but as a collection of standards that are effective, simple, and cheap and easy to (re)implement in many different contexts. It's a bit like designing a cataloging system for libraries -- you think bigger than just one implementation.
(Regarding other comments in this "thread", about "get a job", or "you're just trying to steal funding from svn", etc. Well, those aren't bad advice/concerns/objections to discuss -- but I don't think the blog format really supports that kind of discussion -- so I'm going to let them go without direct reply.)
I wasn't going to bother, but the previous comment mentioning arch has been modded up to 4, so I'll speak a tiny bit of my peace.
SVN is a huge and complex system that aims, for its 1.0 release, to be just a tiny bit more featureful than CVS. There's quite a large number of bugs. The complexity for repository administrators is pretty high. The developers are willfully postponing consideration of a lot of deep issues in revision control. If you follow the dev list closely... well, just follow the dev list closely.
arch is a tiny, simple system that aims, for its 1.0 release, to be way more featureful than CVS. Although I don't think its ready for deployment in large-scale situations, early adopters tell me that they enjoy using it. arch, unlike svn, is very well positioned to compete (with just a bit more development) with BitKeeper, ClearCase, and others. arch can do a hell of a lot for the commercial free software world with just a bit of investment.
And, I don't know how you should interpret this, but svn has a handful of paid developers -- arch has none and, in fact, I'm literally days away from homelessness.
Either your CEO had absolutely no knowledge and input on this decision -- or your CEO needs serious therapy.
Re:Sick of reviewers, critics, skeptics, guides, e
on
Taken?
·
· Score: 1
> 1) Does the story take you somewhere?
It certainly did: for about 3/4 of the series. What the heck are these aliens up to? How will society be impacted? What does it all _mean_?
> 2) Do you care about the outcome?
Sure: but that's where the series falls apart. It has a stupid, hopelessly vague answer to the "what the heck are these aliens up to" question. It's ending is designed to say "no impact on society at all". Nothing happened and every character (and the audience) who expressed concern over these events over the 40-some years of the plot is shown to have wasted their time.
I suppose the failure to emerge of clear, thoughtful pictures of what these aliens were all about is supposed to leave me with the imaginative freedom to Wonder in Awe at the Big Imponderables but this rehashed Close Encounters ending -- well, been there, done that, and it only took around 20 minutes last time.
> If you're entire dept is about to be
> outsourced then what good would an IT union do
> you? How would they stop the jobs from
> leaving?
Well, the longshoremen beefed up retirement benefits for everyone as well as protections for the outgoing job-classes. And, as I understand it, they got some authority over the newly created (tech related) jobs. So -- yeah -- the union did very well by a class of people being displaced by economic development.
Of course, unlike many "IT professionals", the longshoremen take their jobs very, very seriously.
Isn't it interesting that a comparison to 19th century factories, while obviously exaggerated, isn't completely and utterly ridiculous? After a century of progress, there should be _no_ comparison, yet there is.
Isn't it interesting that some execs make hundreds or more times their workers? If pay were equal, that'd be (by my envelope) about 10% fewer layoffs. So-called "deadwood" is an asset: pay them to take classes and run drills -- preparedness is value. Pay them to hang around with light hours and make the office more comfortable while they attend to a life outside the office -- aren't these things implied by "conservative values"?
The party line among execs is that their pay is justified by a "global competitive market" for their skills -- but really, how many of these folks are being actively recruited in any serious way? No -- they are an old boys club. Obscene stock grants and bonuses don't "align their motivations" -- they "isolate them from the rest of us".
All that said, one of the bigger problems in IT is the substitution of bodies for brains. Too many IT workers don't really know what they're doing -- but have positions of high consequence. I'm not sad to see them go -- I'm sad to see them hired in the first place.
One common pattern I've noticed is eager, young, generally nice-folks execs and upper managers who fret primarily about the role of the appropriate use of their "authority" -- and that tends to result in arbitrary and counterproductive exercises thereof. Another pattern is HR execs who write COE's (conditions of employment documents) that fill many pages, the gist of which is "we have arbitrary rights over you, you have no claims against us". In other words, from one way of looking at it, our jobs suck because everyone at every level is paranoid, untrusting, and isolated.
The best high-tech employers I've ever heard of were various coops -- most often, celebrity coops (coops of already famous hackers). We need more of those, and we need efforts to bring everyone up to speed with those, attitude-wise.
The most satisfied class of employees I've ever seen are non-tenure-track university employees, especially the unionized ones. Their pay sucks. They have no end of gripes. But their benefits are generally good, job security good, hours good, job satisfaction often good, work product often good, and they all live in and _help_to_create_ the best urban environments in the nation and drink plenty of good coffee and enjoy good affordable food.
making sure that all
music used either came with a free
license (gnu/bsd style)
Yes! EFF has published a music license in that style.
It seems like a "simple" bootstrapping problem: invest in some producers to record tracks under those terms, and attach them to an infrastructure that pays artists. Global Mobal Intelligence production. Roving recording techs, scavenging the land for the underappreciated.
I proposed this to affero (who has the needed low-level tech), but they didn't take me seriously. Maybe if others reinforced the idea to them?
Slashdot Mirror
He isn't grossly misrepresenting Codd's work.
You said it yourself:
While the algebra is somewhat procedural, the calculus is set-oriented, and they are fully equivalent.
and, uncoincidentally, the isomorphism extends further to machines that manipulate physical punch cards. You go on to say:
The idea is exactly not looking at records and operators, but describe what you want -- just leave the relational system set the procedures to get that in the most efficient way it can.
Right. And what Gray has pointed out is that Codd's work on the math and how to implement it doesn't really require computers, as such.
In an alternate timeline, there were no computers just lots of expensive punch-card machines and racks and racks of data stored on punch-cards.
(Such was the economic value of all this data that the racks of cards were often stored with an almost military degree of jealous protection: the origin of the term "Data Base".)
Each card machine could perform a simple operation like "duplicate this card stack" or "pull out the cards that have a Q in column 3". The machines could be organized into a sort of assembly line for a particular computation, with technicians looking at a script on a clipboard and carrying trays of cards between machines, configuring each machine with the right parameters, running the cards through, then going to the next step. It was an expensive, labor-intensive process and the ad-hoc procedures used to write the scripts for the technicians were black-magic, often error prone.
Time-study super-genious, Alternate-Codd, studied the machines and the procedures used to operate them. He realized that they could be described by set math. He realized that if you let the managers define their "Card Searches" in very high-level, very mathy terms -- then there was a straightforward optimization problem to get from that "Search Specification" to set of "compiled instructions" for the technicians. The goals was produce a set of Compiled Instructions that would use the punch card machines in an optimal way -- saving time and money.
He studied the optimization problem and developed some techniques for it. Companies used his results by highering a "Compiler Pool" -- most often a group of women chosen from the secretarial pool for the accuracy of their work. When a new Card Search request came in, the search would be typed up and mimeographed, and handed to the head of the Compiler Pool. It typically took "the girls" about a day to compile a query but, every time, the scripts they wrote for the technicians produced the right answer, usually much faster than anyone thought possible.
In one office, though, in Rochester New York, there was a famous accident. The office used by the Compiler Pool had developed a problem with flies. One day, one was swatted and killed with the mimeograph master of a compiled query, leaving a mark that obscured some important numbers. Nobody noticed, the technicians dutifully followed the errant script, and by the next afternoon the company's entire collection of precious data was strune, unsorted, in a huge pile on the machine room floor. The company was bankrupt only 9 months later.
The company president demanded an explanation when the accident occured and much investigation followed, eventually revealing the fly and its consequences. This was, of course, the origin of the familiar phrase (known to every customer whose ever gotten a $500 bill for a month of telephonic service), "compiler bug".
> [why is hard to write a good revision
> control system?]
Many reasons. Here are a few.
1) precision. If your mp3-player crashes -- big whoop. You'll fix it, or report a bug, or try a different one. If you run your project on revision control system XYZZY for a year, and then discover that it has corrupted 6 month old data beyond repair, now you are really screwed. There are many features in revision control systems that aren't critical -- bugs can just be fixed. But there's a core part of revctl that has to be very robust.
2) balancing art and science. I suspect that most casual uses of, say, CVS are just thinking about checking out trees, maybe updating them, maybe checking stuff in. When projects are large and busy, though, suddenly branching and merging and history auditting and all the "obscure" features are very important. The problem for the designers/authors of revision control systems is that for those obscure-but-important features: There Are No Right Answers. If you were to try to develop a purely mathematical theory of what those features should do, the fundamental theorem of the theory would be "it is impossible to implement them." In practice, the best you can do is to implement _approximations_ of what those features would ideally do. And worse, there are gazillions of different approximations to choose from. So there's a serious challenge there: to pick a subset of the possible that adds up to the most useful approximation of the impossible.
4) making wise implementation decisions, especially regarding time and space performance characteristics. Revision control systems ultimately wind up managing a _lot_ of data, and keeping that data around for a _long_ time. In an implementation, you have to make decisions about how to store that data, trading off factors such as the complexity of the implementation, the amount of storage space you'll use, and the cost of retrieving data. Over the lifetime of a deployed revctl system, you can expect factors like CPU speed and disk economics to evolve profoundly far. As basic, text-book software implementation tasks go -- revctl is a fairly challenging one.
5) distribution. In terms of what users are starting to demand, distribution is a comparatively new thing in revision control. Remember, it wasn't _that_ long ago that CVS didn't even support remote access to a central repository, nevermind distribution across mulitple repositories. Taking distributed operation into account, the mix of slow, medium and fast network connectivity in the world, the economics and politics of administration -- distribution amplifies the challenges of (1)..(4).
Public projects are the de facto R&D lab of commercial free software vendors.
Unlike a "high on a hill" lab owned by some big company, our R&D is cheaper/faster/better -- but it ain't free. In my case, and many others, the funding is falls below the costs.
We need two things: _Will_ (self interested one could argue) from the vendors to pay the bills. _Mechanism_, to arrange that payment (not merely "paypal buttons" -- higher level mechanism, so that the vendors are assured technology transfer and have a legitimate claim to R&D tax credits).
> If so, wouldn't bill get those billions without
> having to hand a few hundred million over to
> Uncle Sam
And won't he, most likely, dump a hell of a lot of that money into his family's philanthropic NPO?
I wonder how many small-town libraries will get a boost from this dividend.
(I hate him as an overrated hacker and citizen-politician, but, so far, respect him as a rich celebrity.)
There's exactly two legitimate bases for stock valuations: one is dividends, the other is a cycle of systematic buy-backs and new issues.
Absent either of those two options, what have you got? You've got someone saying to the market "Hey, loan us some money. We never intend to repay, but perhaps you can sell our note to someone else for a profit."
I _originally_ decided to write free software for a very simple
/.". We weren't saddled with the impossible task of reconciling
/. and kerneltrap and 100
reason: in order to join a community based on friendship, mutual
support, and shared intellectual development, dedicated to improving
it's larger environment through hacking (in the sense of "playful,
forthright, responsible, and creative development and application of
technical and engineering skill, insight, and ideas").
In high school, and then later in college, there were all the regular
faces you'd see around the computer labs. There was a culture there,
for a time, now largely gone, based on sharing ideas and resources,
and being friendly. We learned from one another, we egged each other
on to better and better achievements, and we made our campuses better
even for people who were outside of the clique. We'd go out for
Chinese food, order pizzas, and then drop by the basement of the guy
who had a discarded rack-mount pdp-11 in his basement to see if we
could still boot the thing. We'd show off our hacks to one another.
We traded copies of papers and books. We weren't competing in a
scarce job market. We weren't competing for "who gets the best press
on
the supposed "business realities" of our non-hacker bosses with the
essentially mathematical truths that under-pin the craft we were
learning.
Around that time, software was becoming a big, mass-market commercial
product for the first time. There was visicalc and scriptsit, for
example. There were warnings from faculty members that pirating
software was against the rules. And a little while after that, there
were the early writings of and about RMS, and against that: the
example of unipress emacs.
In those writings, hacker cultures were pretty well described. The
fundamental contradiction between such human communities and
proprietary licensing were clearly spelled out. Free software was a
no brainer. It was simply the only civilized alternative.
Resume fodder. Fame. Power of volunteers. A few million bucks to
line the pockets of RHAT execs. A general mean-spiritedness and
intellectual dishonesty when projects compete. A shockingly naive
and dangerous popular outlook on what good programming consists of.
A commoditization of programmers to the point where they are formed
into a worse-than-peasant-class. A stunningly uninformed and
uncritical view of technology dominating
project mailing lists. An FSF whose mission is a jet-setting RMS and
a completely unfunded, bottom of the page, also-ran "build a
GNU-system" task....
The free software "community" these days is decadence. It has become
divorced from human values. It's in a shameful state.
The free software movement originated out of the mourning of a single
individual for a lost community. How ironic that it has evolved into
a culture that actively resists the formation of community.
-t
This is good for Red Hat. There are some obvious PR benefits to it, of course.... but I think it amounts to R&D they'll eventually capitalize on.
RHATs central servers -- not just for isos but also for updates -- are a vulnerability; a single point of failure six different ways from tuesday. (There's even another post in this
Not nearly all, but a big chunk of the vulnerabilities can be fixed with P2P distribution. RHAT's bigger customers can be organized to help each other that way. When, for example, security emergency response times become critical, P2P will be a big boon.
If, suddenly, all distribution of RHAT software happened P2P -- subscriptions would still have value, and that value will grow over time. Immediately, it would have value as a source of secure hashes, delivered over multiple channels. Of course it would retain its support values -- and my hope/prediction is that in the future, Red Hat Network will increase in the degree to which it is a low-walled garden "community (of customers) website": tightening and enriching the feedback loop between customers and programmers.
-t
> Would you say, Tom, that you are a
> Johnson?
I would say that that is question we should each ask of ourselves, and work towards in our lives. I would say that that answers are never simple, but the ideals not so hard to grasp. I would say that "The Place of Dead Roads" by William S Burroughs is, perhaps, his best work -- and certainly a milestone in American literature.
-t
> Another way of looking at it is simply the
> usual networking transaction that take
> place in the real world. Imagine that you
> are looking for a reliable contractor to
> renovate your house. There are a number of
> three-way transactions taking place
> between you, a friend you trust, and a
> contractor he trusts well enough to
> recommend. The whole point of reputation
> and networking is to allow a certain
> amount of transitivity in trust
> relationships.
If I'm looking for a contractor for a big job, sure -- I'll bring my friend whose worked with several over for wine and, in the course of the day, form my own nuanced judgement. I might treat the prospective contractors to a lunch or dinner to chat about nothing in particular and construction and quality. I'll bring them to my house and watch how they look at it. What part of this, exactly, do you want to reduce to a score on a web site?
How, in Affero's system, do you say "I didn't get along with that guy at all -- but knowing you as I do, I wonder if he might not be the right guy for your job?"
> Not to mention, if you haven't noticed that
> every community that uses a publically
> displayed "experience points" type system
> slowly dies a redundant, boring death as people
> continually spit out the same useless advice as
> fast as possible to receive their precious
> points. It seems to attract the bottom of
> the barrel, perhaps because people who are
> truly interested in the discussion don't need
> the "incentive" and go to serious forums.
Oh no....you're so wrong. Henri's all on top of that "gaming the system stuff". Didn't you read the interview? He _says_so_ and that proves it's true.
Oh come on now, you're taking my points to :)
the extreme and pointing out their
breaking points
I'm simply thinking through the implications of what happens if Affero succeeds on their current path. It's you times 100s or 1000s of others.
Of *course* I wouldn't judge somebody
exclusively on some bad karma they got
back in 1999,
Timing of "bad karma" isn't the primary issue. The unrecorded context is. Haven't you ever been in a situation where the group dynamic included people trying (and succeeding) at making you "look bad"? I think the best way to judge, say, a potential employee is to sit down over a nice meal and talk with them. Then sit down with some paper or a whiteboard and talk with them. In programming, look at their code, then talk with them some more.
are you trying to tell me that if you had
one position to fill, and you had two
people applying, and one had a better
Affero profile than the other (which,
after a little investigation, proved well
founded), you wouldn't choose the person
with the better profile?
First, I don't believe that there is any such thing as a "well founded" Affero profile.
Second, yes -- I would not use Affero to judge candidates. I would try to get to know the candidates and their capabilities personally. If I still couldn't decide, or had doubts about the reasons for my intial decision -- I'd flip a coin.
We don't need to make ourselves less human and more robotic by reducing to a database table our highest values. We need the Johnson Family (a code of conduct at the turn of the century in the American west; good bums and theives; a Johnson is a good man to do business with; he honors his obligations; he isn't a snoopy, self-rightous person; he doesn't stand idly by when someone is drowning or trapped in a burning car; a Johson will give help when help is needed...)
-t
Conversely, if I went and looked at his
Affero rating, and saw that he had
received some negative or
middle-of-the-road feedback, or that
compared to others on LinuxQuestions he
barely had any, I might be less inclined
to take him on.
And you think this is a _good_ thing?
Suppose someone gets a negative rating for reasons that are really stupid or that no longer apply. That kind of thing happens all the time and then, looking at the evidence N years down the road, it's impossible for 3rd parties to tell what happened. You're proposing that that kind of bad luck should be amplified and have a long term effect on a person's life -- apparently because you find it convenient or even compelling to simplify your evaluation task to just "Look at the number in column 4".
I have in my pocket a list of
Human trust or reputation is usually developed one-and-one and in personal interactions. It is a _little bit_ transitive (A trusts B, B trusts C, therefore A trusts C) but there are many interesting exceptions. It is a _little bit_ like an incrementally adjusted "score" in a long term game, but again, there are many interesting exceptions where it changes with the wind. Trust and reputation, in their human sense, are mysteries.
A database about "trust" or "reputation" based on voting is something completely different. It has little or nothing in common with the human forms. It can not "change with the wind". Worse than being strictly transitive, it's a popularity contest (A "trusts" anonymous crowds of voters; an anonymous crowd of voters "trusts" C; therefore A "trusts" C). That's not trust -- that's an election for homecoming king and queen in a cliquish high school.
In short, systems such as Affero smack of an unscientific sociological experiment to redefine what trust and reputation mean. Worse, given its proposed connection to money and careers -- it's an experiment that, if it succeeds, forces everyone in the free software industry to play. In short, it is immoral.
(This isn't to say that it's fundamentally different from, say, HR blacklists and other private realizations of similar ideas.)
One of the key "properties" that Affero possesses is a _great_ thing: the paylist mechanism. You can make a list of people or organizations and describe how they "divide up a pie" -- and people can, in a single transaction, pay all the members of that list according to the proportions. That's a (potentially) incredibly useful tool. Think of it as "group paypal". For example, a software project or a group of musicians can use that to organize an on-line tip-jar without the hassles and legal overhead of forming a formal organization.
So, Affero, _please_ drop this obnoxious, culture-polluting notion of formalized "trust" and "reputation", surface the paylist mechanism, and let us use that as we see fit. We'll use _real_ trust and _real_ reputation to negotiate among ourselves how to structure the paylists.
Meanwhile: we really _do not need_ a monetized, playground popularity contest.
-t
I think the reason is that, unlike 10 years
/. to see what folks might have to say.
ago, many companies are now in the business of writing free software.
Not really. Not in the comprehensive way that was once the FSF agenda. Sure, companies doing development in fairly narrow (and not infrequently private or even proprietary) areas -- but no big R&D push comperable to the effort that FSF had going. Lot's of company-oriented projects that have the hearts and minds of volunteers, though.
(And isn't that last point at least unseemly?)
The FSF is going where it's needed - providing legal support to ensure that existing free
software remains free, and providing hosting
services for volunteer-run projects.
Some of what the FSF is doing (you left out advocacy) is very important. I don't disagree about that. That's why it's a delicate criticism -- I also have a lot of respect for the FSF.
I'm not even sure that the Right Thing is for the FSF to change here -- only to raise the issue on
-t
Time was when contributions to FSF funded programmers busy writing new free software. This appears to be far less the case, these days -- at a period of time when, 10 years ago, I would have predicted that FSF would now be doing more or less what RHAT does.
This is a delicate criticism, of course. It's not at all that where there money goes isn't important -- far from it.
But, hey, where's my "complete GNU system" (other than in arguments that various non-FSF distributions should be called GNU/Linux)?
-t
I'll bet it tanked because the economy is so bad. Unemployment, particularly in tech sectors is very high. Consumer spending in general is way down.
In boom times, even a bad Star Trek movie is worth $7-$20 bucks -- for it's value as camp, if nothing else. Other posters have remarked that they are prioritizing -- seeing LOTR instead, for example. That's a symptom of thin wallets.
But, hey, the blockbuster isn't the future. Small independent films are. The way to make money from the franchise is to make it a, well, franchise. License independents to use the ST universe (but none of the hollywood characters). Give them budgets and a technical assist on effects. Be liberal enough to allow some R rated content. A flurry of films for a $1M or three combined with all that latent creativity in the world, early DVD collections of the best-of-breed: paradise! (Well, film-wise, anyway.)
Salon has a bunch of good content. Maybe you agree that this story is good. Subscribe!
Can hubble resolve the garbage we left on the moon? Crackpots aside, that'd make some neat pictures.
> [arch isn't portable beyond unixen because
> it's largely written in sh]
Just as a small clarification on a technical issue:
1) In some sense, yes, that's an obstacle.
2) It is very portable among solid Posix and nearly-Posix systems. It's not terribly useful as it stands on cygwin because (I've been told) `fork/exec' is very slow on cygwin.
3) Most importantly, though, and a bit unlike SVN, arch is designed to be implemented more than once. It's tiny enough to rewrite (say, in Python or Perl) in just a few man-months. It's based in part on the idea of standardizing repository formats, exchange formats, and so forth. In other words, from the point of view of whether or not to support finishing arch, you have to regard it not just as a particular implementation, but as a collection of standards that are effective, simple, and cheap and easy to (re)implement in many different contexts. It's a bit like designing a cataloging system for libraries -- you think bigger than just one implementation.
(Regarding other comments in this "thread", about "get a job", or "you're just trying to steal funding from svn", etc. Well, those aren't bad advice/concerns/objections to discuss -- but I don't think the blog format really supports that kind of discussion -- so I'm going to let them go without direct reply.)
I wasn't going to bother, but the previous comment mentioning arch has been modded up to 4, so I'll speak a tiny bit of my peace.
... well, just follow the dev list closely.
SVN is a huge and complex system that aims, for its 1.0 release, to be just a tiny bit more featureful than CVS. There's quite a large number of bugs. The complexity for repository administrators is pretty high. The developers are willfully postponing consideration of a lot of deep issues in revision control. If you follow the dev list closely
arch is a tiny, simple system that aims, for its 1.0 release, to be way more featureful than CVS. Although I don't think its ready for deployment in large-scale situations, early adopters tell me that they enjoy using it. arch, unlike svn, is very well positioned to compete (with just a bit more development) with BitKeeper, ClearCase, and others. arch can do a hell of a lot for the commercial free software world with just a bit of investment.
And, I don't know how you should interpret this, but svn has a handful of paid developers -- arch has none and, in fact, I'm literally days away from homelessness.
Go figure.
Either your CEO had absolutely no knowledge and input on this decision -- or your CEO needs serious therapy.
> 1) Does the story take you somewhere?
It certainly did: for about 3/4 of the series. What the heck are these aliens up to? How will society be impacted? What does it all _mean_?
> 2) Do you care about the outcome?
Sure: but that's where the series falls apart. It has a stupid, hopelessly vague answer to the "what the heck are these aliens up to" question. It's ending is designed to say "no impact on society at all". Nothing happened and every character (and the audience) who expressed concern over these events over the 40-some years of the plot is shown to have wasted their time.
I suppose the failure to emerge of clear, thoughtful pictures of what these aliens were all about is supposed to leave me with the imaginative freedom to Wonder in Awe at the Big Imponderables but this rehashed Close Encounters ending -- well, been there, done that, and it only took around 20 minutes last time.
> If you're entire dept is about to be
> outsourced then what good would an IT union do
> you? How would they stop the jobs from
> leaving?
Well, the longshoremen beefed up retirement benefits for everyone as well as protections for the outgoing job-classes. And, as I understand it, they got some authority over the newly created (tech related) jobs. So -- yeah -- the union did very well by a class of people being displaced by economic development.
Of course, unlike many "IT professionals", the longshoremen take their jobs very, very seriously.
Isn't it interesting that a comparison to 19th century factories, while obviously exaggerated, isn't completely and utterly ridiculous? After a century of progress, there should be _no_ comparison, yet there is.
Isn't it interesting that some execs make hundreds or more times their workers? If pay were equal, that'd be (by my envelope) about 10% fewer layoffs. So-called "deadwood" is an asset: pay them to take classes and run drills -- preparedness is value. Pay them to hang around with light hours and make the office more comfortable while they attend to a life outside the office -- aren't these things implied by "conservative values"?
The party line among execs is that their pay is justified by a "global competitive market" for their skills -- but really, how many of these folks are being actively recruited in any serious way? No -- they are an old boys club. Obscene stock grants and bonuses don't "align their motivations" -- they "isolate them from the rest of us".
All that said, one of the bigger problems in IT is the substitution of bodies for brains. Too many IT workers don't really know what they're doing -- but have positions of high consequence. I'm not sad to see them go -- I'm sad to see them hired in the first place.
One common pattern I've noticed is eager, young, generally nice-folks execs and upper managers who fret primarily about the role of the appropriate use of their "authority" -- and that tends to result in arbitrary and counterproductive exercises thereof. Another pattern is HR execs who write COE's (conditions of employment documents) that fill many pages, the gist of which is "we have arbitrary rights over you, you have no claims against us". In other words, from one way of looking at it, our jobs suck because everyone at every level is paranoid, untrusting, and isolated.
The best high-tech employers I've ever heard of were various coops -- most often, celebrity coops (coops of already famous hackers). We need more of those, and we need efforts to bring everyone up to speed with those, attitude-wise.
The most satisfied class of employees I've ever seen are non-tenure-track university employees, especially the unionized ones. Their pay sucks. They have no end of gripes. But their benefits are generally good, job security good, hours good, job satisfaction often good, work product often good, and they all live in and _help_to_create_ the best urban environments in the nation and drink plenty of good coffee and enjoy good affordable food.
making sure that all
music used either came with a free
license (gnu/bsd style)
Yes! EFF has published a music license in that style.
It seems like a "simple" bootstrapping problem: invest in some producers to record tracks under those terms, and attach them to an infrastructure that pays artists. Global Mobal Intelligence production. Roving recording techs, scavenging the land for the underappreciated.
I proposed this to affero (who has the needed low-level tech), but they didn't take me seriously. Maybe if others reinforced the idea to them?
-t