Suppose you have a software package, and the CD KEY is used to allow you to install the software. Presumably, it takes some encrypted form and mutates it into a useful version. Alternately, such a code might be used to alter program logic to affect software behavior -- whatever. The point here is that the CD KEY is a protection mechanism at the client end.
Like the rest of the/. majority, I too find the DCMA an example of knee-jerk legislation produced by the uninformed and easily lobbied. But in this, suppose you even agree with it...
According to Tim Jung's post the gripe expressed was that the bnetd.org server does not do CD KEY checking. My point -- it shouldn't have to.
It appears that the design of this product is such that invalid CD KEY prevents people from stealing battle.net server resources. Apparently, that is working; good for Blizzard.
As I understand it, people aren't forging false CD KEYs and inappropriately using battle.net server's resources -- doing so would make the case more plausible. Yet in this case, it would an individual service hijacking player who should be the focus of legal attention.
So what was designed and built by Blizzard is something that actually says "show me your receipt and I'll let you use our systems." Rather than forge CD KEYs to do something illegal like steal Blizzard's service, the user community has provided their own resources, built their own software, and opted not to check for a "receipt" to use those services. Technically, it's not duplicated Blizzard's server then either, since it's a subset.
True, this does let people try an approximation. However, it isn't the actual golden master -- by definition it's build with low confidence, and possibly broken with missing features. Blizzard wasn't passing out free copies of a production game, it passed out something else with the expectations of comments.
About the only real complaint Blizzard has is that they aren't getting as much beta feedback as they could had they expanded the beta base. However, if Blizzard's servers are locked out via a CD KEY except to only a few, then they weren't going after that data because they wouldn't be getting that data anyhow -- so there's no loss, other than potential they forgot to go after. That was a business mistake.
Blizzard's true error then is not designing the software to require something only their servers could provide.
However, I can tell you as a software consumer, if I purchase a product that depends on someone's website being up and around, I get jittery about them going out of business or no longer supporting it and wouldn't make the purchase.
I suspect if Blizzard kindly asked for it, anonymous beta testers would happily provide feedback. Feedback that would make the game much better, improving overall sales. Blizzard actually has a very positive opportunity here, if they can get past the shortsightedness.
Went to Walt Disney World at the end of last year, and managed to get substantial face time with a really nice animator. She recommended we pop over to Disney's digital theater and watch Monster's Inc.
Coming from someone who made movies for a living, she seemed pretty qualified to notice the difference.
Frankly, I'd have to agree. In the opening Pixar demo, I could easily see details that just weren't visible on standard film stock. The bird's had scratches on their beaks from pecking; the wire they sat on was branded; everything looked very crisp and bright.
Convinced I was just being more observant this time around, I made a point to see the movie again in a non-digital theater. My observations on the digital showing were correct. The animator was right.
The funny part was when, as I was buying my ticket, I asked the person at the ticket booth what they thought of the digital show. The answer was "it looks the same to me."
That got me wondering -- if you don't know what to look for, are you going to be able to appreciate it?
Unfortunately, I'm not a big stereo buff, and when my musician friend took me to a local store to pick a home theater system, I couldn't tell the difference between the really high end stuff and mid-range. Perhaps this is due to my hearing not being as acute as his? Now my vision is much better.
Could it be that the average eyesight is not that great, or could it be that the average viewer isn't looking for extra details but does notice the absence of extensive film damage and splicing?
Can I take someone else's picture, enlarge it -- extrapolating pixels via these new fractal toolkits -- and post that? At this point, information is being added. Hmm... a better derative work?
What if I find a business that makes and sells professional thumbnails. Can I zoom it as well? Or do I not have to, because the it's already fair use by virture of being thumbnail size?
---
I lay claims to blank.gif which holds one transparent pixel. Anyone who wants to make a smaller thumbnail of that, feel free.
There are several problems that stem from the behavior you're asking about. Let's explore them.
The primary purpose of a version control system is to... store revision history! (surprise.) The secondary purpose is to provide chronological associations between files. (for instance, this documentation goes with that version of the software) What happens is the non-initiated miss the purpose of the tool and view it as a central dumping grounds for unrelated "stuff."
If you're just trying to share temporary artifacts, stick them in a public folder on your network, publish them on the intranet, don't pollute a project's repository with unrelated and transient materials just because you've got write access.
Basically, if you can't tell what you have in a repository (and know why it's there), you've got a problem on your hands.
I hesitate to reveal how many times I've had to clean up repositories that had superfluous files that didn't belong to the project or the repository in question, had versions spread across separate files, had no commented revision history or other identifying features, or where it was just being used as a backup.
Let's face it - commercial version control systems are expensive. I once worked for a place where everyone had to get a license for the client just to get non-project related materials. The side effect was that this particular tool didn't have decent security, and it allowed everyone to access the source code by virtue of having rights to the repository. I've yet to get a decent explanation why the HR department needs access source code.
Adding insult to injury, non-programmers usually don't "get it" when it comes to version control. As a result, things would mysteriously disappear. Turns out a non-developer was being 'helpful' by cleaning up stuff that didn't look "important." Thank god for backups.
The version control system is supposed to help with change control, not make you a victim of your officemates' good intentions.
Speaking of polluting repositories, or in this case, excessive growth, a lot of version control systems are not that efficient when it comes to storing binary data... such as a Word document. We'd often have people check in change after change after change to such documents, and the repository would get enormous. Doing standard checkouts on the project would take friggin' forever.
Ironically, developer documentation (which was written in LaTeX, HTML, and plain ASCII text files) worked just fine. Wonder why... perhaps the developers knew how the tool operated and took advantage of that fact? I think so. Sure, they stored graphics in it, either as PostScript or multiple JPEG/GIF/PNGs - but those changed so little, it wasn't noticed.
So, just as we've established a version control system shouldn't be used as file junk yard, we should also take note that there *are* specific tools for managing intra-documentation changes. It takes relatively little effort to use similar tags across two different toolsets, and thus keep everything in synch.
Finally, and perhaps the worse offense, is management thinking that version control is a communication tool. I'm not making this up, but I've been in meetings where management put a memo in version control and lashed at the staff for not reading it. I like to say that version control is like the national archives, you can get anything you want, if you know it's there. It is NOT the Borg Collective; it isn't a broadcast medium, and it isn't a substitution for communication - no matter when you checked it in.
Yes, CVS can be "abused" in the manner you're describing, but only for a short time. Eventually you'll run into technical limitations, strange CM policies that appear to have nothing to do with CM, and you'll be scratching your head asking "what the hell am I looking at?"
Excellent point; poorly worded on my part. In general, your statement ought to be true about all version number schemes inside a repository. (Cederqvist, section 4.3)
Labels are our friends. Though, I've actually heard people using phrases like "We're modifying the 1.19.3.4.7.x branch today." That doesn't convey a lot of meaning.
However, based on real world practices, people tend to use revision numbers as version numbers. They shouldn't. And there is a difference between the two. Your point illustrates that well; thank you for raising it. I'd like to think Sun didn't tweak their internal revision numbers to mirror product version numbers.
Where I was going was, if numbers are going to be used to convey repository structure, it should be hack free. If revision numbers are going to be used to convey information, the user should have control over what gets used. The reserved use (which personally I like), in CVS's case came from [Cederqvist section 13]. PVCS is pretty darn good about giving the right level of control for those who want to twiddle numbers directly.
I'm simply saying it's up to the person running the repository to decide -- ideally they should have a clue of what works well.
I've done SCM for a number of years, professionally evaluated version control product, and helped edit an Anti-Pattern book on the subject. It seems, at least to me, that the majority of version control systems out there have the basis covered when it comes to check-in, check-out, branching, and labeling. The standard features, if you will.
However, most of the reasons that I've seen companies change version control systems is because of completely different reasons. Here are a few that come to mind:
- A version control system must be fast. I worked at one company where we tried to use Visual SourceSafe over a WAN; it took HOURS to share code. A good VCS should transmit the minimal amount of data.
- A version control system must provide security. All too often management uses the SCM repository as kind of a shared directory (BAD, BAD, BAD) -- and people who have no need to see or modify the code, do... implicitly.
- A version control system should provide extensive auditing and notification capabilities that can be discretely turned on and off. Allow logging the positive, the negative, and letting people know when particular operations happen to a set of files. In once case we attempted to get PVCS to automate scripts on a change to send mail to the PM. Checking in a directory flooded inboxes, since it could audit collections of code.
- There MUST be a recovery mechanism. Ever try to recover a lost SourceSafe password? Yikes. (Gaining re-entry is possible, back stuff up, change your password, do a diff. Copy pattern into the admin record with hex editor. Login as admin with new password. Change admin password....this worked at least twice for me.)
- Again, there MUST be a recovery mechanism. I love RCS, SCCS, and PVCS for their file-related mechanisms. Why? I've had SCM systems go down hard when the database got munged. Yes, you can recover from a backup, but a lot of work gets lost. With an open file format, you can at least hand fix localized problems.
- That said, good version control systems should allow you to check in collections of files as atomic units, move files and directories, and operate on projects as a whole. Anytime I have twiddle with a repository, thereby breaking past history, something is seriously wrong with the VCS system model.
- Good systems must have an IMPORT / EXPORT capability that PRESERVES HISTORY. The less I feel locked into a solution, the more likely I'll be to try it out. Porting between system is usually painful.
- SCM systems must conform to how the CM manager wants to run things, not the other way around. Let's face it, users can and will make mistakes, and that's okay. Mistakes should be fixable. I'll never use StarTeam because it was too easy for users to check in accidentally branches that couldn't be removed. Tech support argued that version control should reflect the history of the product, where I maintain (and still do) that it should reflect the intended history. If I want to include user errors, that should be my policy, not the tools. My users should be able to reflect upon the project history and know why things changed. Period. You don't use a hack to undo a mistake.
- Branching notation should be clear and to the point. CVS has it's magic numbers, StarTeam has god awful views. Let me choose the numbering scheme, don't play games with odd/even numbering. Version numbers should not be overloaded to carry additional meta-information by the product.
- A good SCM tool should remember tag history. Suppose I accidently move or delete a tag, now I want to put it back. Suppose I want to see where it's been. This case is rare, but anyone who's had a user twiddle with the wrong tags feels this pain as sharp and deep.
- More ADMINISTRATIVE control. My big beef with CVS is when I have to twiddle with the repository structures and permissions directly to accomplish what I want done. No. No. No. There should be a tool (that audit's change) for standard operations.
- An admin should have the ability to define, enforce, and audit user permissions that should be applied cross dimensionally against repository, commands, and elements within the repository.
- Data should be stored in a manner that can be parsed by custom tools. It allows me to write extensions and automation.
- Nothing should be possible in a GUI that is not possible from the command line. The inverse holds true as well. Everything should be automation friendly. Early versions of PVCS pissed me off for this reason. As a SCM manager, I've used both, and I'll take a command line over a GUI any day. My novice users want a GUI, my advanced ones usually revert back to command lines (and integrate it with their editors).
- There must be readable 2 and 3 way diffs.
- A good SCM tool will be able to produce reports, or at least make it possible to export information that can produce reports.
- A good SCM tool should know how to handle binary files efficiently, rather than just storing the whole copy.
- A good SCM system should not put a limitation on comments.
- A good version control system should not try to "do it all" (CCC/Harvest) and do none of it well. When GUI's pop up off screen, or you have to artificially create packages for simple files, something's wrong. Which leads into...
SCM systems should operate the way the users of that system do.
There is a BIG difference between how commercial houses run things verses OpenSource projects.
Commercial groups usually have a smaller set of developers, they are known in advance, and commonly use the locking model. OpenSource models tend to use concurrency a lot more, and operate on the applying diff's procedure. (Yes, I know, exceptions are out there.)
Thus, some tools that feel more natural in some environments get quickly rejected in others. I've yet to see someone produce a readable guide about version control abstracted at a high level bringing all the terminology together. (Incidentally, I'm about to release one; email me for a draft.)
The overall problem in tends to be that people look on the side of the box for features, rather than asking if the features are even applicable for what they're doing.
Worse yet, proper SCM often gets sidestepped in commercial world. Ask: Do you want branching? You get, is it a feature?...yes! Now ask: Do you know when it's appropriate to branch, how to do the branch efficiently, how to graft branches back to the root, or how to physically do it... and you find out this is where a lot of bad CM happens. It isn't fun to inherit a screwed up repository.
The most common downfall of SCM, as I've seen in the commercial world, is a failure of the those running it (quite often over-tasked infrastructure people) failing to understand the product being built with the tool, failure by team leads to communicate repository structure, failure by management as they use the SCM tool as a substitute for communication, and failure by the developers who don't know how to use the tool and when to use the appropriate features.
My problem is that books that act like do-it-all toaster ovens are usually very incomplete in their depth. I have a number of printed resources that fall into this category on my reference shelves.
Let's use your CVS example and assume that I've been using PVCS successfully for a decade.
I want to make the switch from PVCS to CVS. So, I bought the reference card, the reference book, the O'Reily book, and an OpenSource book that covers CVS.
First thing these things tell me to do is seek out "the Cederqvist." Let's furthermore assume I get past this and realize it's the bible of CVS. I may run into another problem... how do I read a TeX file, a PS file, or such. So, let's assume I get past _that_ and have HTML, Text, or PDF. (There is implicit knowledge needed to perform a primitive level of fundamental tasks.)
Going straight to CVS's Cederqvist v1.11.1p1 -- section 1.1 tells us it's a version control system and it can record the history of our source files. This statement assumes we already know what we're looking at, have an idea of what the software does, and we're trying to learn the commands to it.
Back out a level... why would I want version control? What real world reason would make me want to use it? Many colleges don't address that, as many students don't work in teams for credit. They tend to encounter version control the moment they get assigned to a development team, and never having to do it before, they view it as overhead.
A good manual should show parallels to real world problems and solutions, in addition to documenting every featured option.
It's not until you get bitten in the butt by your own actions or those of your co-workers, that you start to see value in it. It's not until you use version control to identify and resolve a really hideous bug that you get an awe and sense of appreciation of it. It's not until you have to produce a production level patch that you get a sincere respect for it. And it's not until you start doing parallel development that you realize how much you should have had this back at day one.
By section 1.3.2 we see some examples -- we're shown the solution without knowing the problem it's designed to solve.
By section 2, on page 7, we're instantly in the guts of how the repository works. Details that never need be known -- unless CVS has limitations that we have to compensate for manually. Much later we learn this is the case. This goes on for pages and pages.
I'm glad the information is covered, but is this was a _user_ is looking for when he picks up a all-text 166 page manual and hits page 7?
As life goes on, we learn about tags and stickiness. We still are left to extrapolate why we need them. Life would come together in a snap if someone said "users of PVCS and SourceSafe may recognize sticky tags as static labels; the reason we use _these_ terms instead are...."
But just because you know what a tool does, or how to invoke commands doesn't mean you're using it right. There are at least five different kinds of branching I can come up with off the top of my head, depending on what goal you're trying to accomplish.
Anyone who's inherited a version control system and seen a branch of a branch of a branch of a branch of a branch and no one could justify why knows what I'm talking about.
Just as the argument is made that "because you learned the language doesn't mean you know how to program" extends to configuration management, too. "Just cause you know how to do CVS doesn't mean you know how to do CM." And this equally applied to using autoconf, make, rpm, LaTeX documentation, etc.
There are right ways, wrong ways, and the effective way. Let's be honest here, our admired gurus are gurus because they know not just how to play by the unwritten rules, but also when and how to break them.
What I really want to see is a book that doesn't discuss the tool, but discusses the real world best OpenSource practices, and uses the real tools we use as examples to teach it.
There are a lot of programmers out there who don't have the minimum set of knowledge to perform the admin part of steps, but do have the technical know how to write solid code.
> I very much doubt that. The former is generally easier than the latter.
I've written a number of various utilities and applications for the public domain. Some shareware was successful enough it still results in checks in the mail, some applications I personally witnessed in use by over 300 people each day over the course of four years, and many others have just faded away with time and platform changes. On the commercial front, I've written a lot of flagship products, directed development efforts, and been highly involved in QA and SCM. I like to think I can code my way out of a paper bag.
Naturally to do all those things, I've needed to know various languages, compilers, bug tracking tools, version control systems, build automation, and documentation. I like to think I've successfully been involved with much of the software lifecycle.
But, when I first dipped my foot in the Linux pool, I was trying desperately to map my prior experience from PC to Linux.
I knew Microsoft and Borland's C++, but couldn't get certain parts of the STL to work with gcc. Oh, that part was broken (it's hence been fixed).
I knew SourceSafe and PVCS inside and out and had been the CM manager of 70 people. Just mapping the terminology from those products to RCS/SCCS/CVS was a small barrier of its own when I first started. Things didn't help when the some standard CM tasks required implementation knowledge of CVS and tweaking the repository directly.
In corporate environments, we had access to the version control system directly; we were immediately responsible for the code. There was no need to generate patches for submission, or apply them.
In cases where the software wasn't designed to be portable, people never took that into account. The general philosophy had to change for Linux.
Tired of Microsoft's or Borland's make? Use OpusMake. Want to build an installation package?
Use InstallSheild or another varient. Hard core debugging? Soft/ICE. Powerful tracing? Any NuMega product. Documentation? Word. PageMaker. FrameMaker.
But assuming I've got GNU Make, autoconf, RPM, gdb, LaTex, and a number other things under my belt -- everything has to be done in a way that's acceptable and receptive to the community.
The point I'm going with is this: there's a lot of untapped talent out there, because of the transitional Rosetta stone is kept too close to our chest.
We share our code, but not our process and techniques. We assume that just because people haven't cut their teeth on Linux, know GNU utilities inside and out, and know how to do things the way we do that they are neophytes.
That needs to change.
If the Linux and OpenSource community wants to tap the knowledge and talent of the commercial world, we need to not just provide software tools and grass movement marketing, but we need to provide the intellectual resources as well.
What I really want to see is a book that assumes you know how to sling code, but addresses the specifics on how to become part of the coding community.
I've seen lots of lists that say:
0. Get the latest version of the code from CVS.
1. Read and understand the code.
2. Make changes.
3. Send your patches to the maintainer.
4. Hope they get accepted.
There are a lot of programmers out there who don't have the minimum set of knowledge to perform the admin part of steps, but do have the technical know how to write solid code.
How many people have code but don't know how to set up a good makefile, but could if a decent template were explained? How many people would like to have configure scripts, but aren't sure how the magic works? How many people aren't sure how to put their code in CVS or upload it to SourceForge? How many people want to know how to build packages, whether by RPM or some other means? How many people don't know what questions users need answered in documentation, nor how to put it in a man/info page?
Simply making a breadth, but shallow, offering consisting of nicely printed man pages that are indexed hasn't helped much. It'd be nice if someone took a simple project and followed it end-to-end.
(At serious risk to my inbox, if enough contributors send me suggestions, tidbits, or the process as _they_ see it, I'll make a decent effort and putting something together.)
To me, at least, the OpenSource seems to be the
magic solution to the getting all three of:
Better, Faster, Cheaper.
For the most part, if I'm interested in substance and functionality over glitz, OpenSource projects have what I want -- with the added benefit that if it isn't precisely what I want, I can fix that.
If there's a problem, it usually gets noticed and fixed sooner. Authors take pride in their work, as their very name and reputation is attached.
And amazingly enough, all this comes at a very low price tag.
That doesn't say that OpenSource comes at no cost. The economics are slightly different. To be a consumer in this market, I have to have about the same amount of knowledge in my head about how my computer worked when I was running DOS back in the '80s. I recognize my computer is not a do-all appliance with pre-canned solutions I have to accept or not use. I can mold it to my will... and surprisingly with relatively little effort. OpenSource lets me venture into the realm of the unexplored if I so choose, or I can stay well within my comfort zone.
On the flip side, to be a contributor, I recognize I may never get rich directly from my contributions. However, I can get noticed. I can get famous. I can get appreciated. I can be worth more to my employer, whether from experience or name recognition.
It's personally rewarding, providing personal growth, a sense of community, and is fun to boot. I've yet to get this experience out off a sealed package off the shelf.
If you're the type of person who find yourself doing a View Source when you visit an interesting website, then you've got enough of a streak of curiosity to survive consuming OpenSource.
With familiarity and tmie, it's easy to contribute. Contributions don't have to be just code. They can be suggesting ideas, reporting bugs, play testing, or even proof reading.
Don't the ISP providers themselves purchase a hunk of bandwidth and IP ranges that they then partition and redistribute, offering themselves as middleman for support and value-added services?
The real test here is going to be time, and whether or not IBM decides to stand behind this instance of Linux for a substancial period of time..
What this does buy the linux community is the fact that Linux has support by a big name, rich company. IT managers should feel more comfortable with this knowledge.
In the past I've seen IT departments lean toward Microsoft in their solutions, even knowing the product was defective, because they honestly thought they could get individual attention and support.
IBM certainly knows how to deliver better support than Microsoft, especially since IBM will come on site.
Does anyone remember when Microsoft reported that Quartdeck's product QEMM would no longer work with the next version of windows.
And it didn't.
Unless you renamed QEMM.SYS to something else, like QEMM386.SYS, then it worked again.
Microsoft is again relying on dirty tricks to wear the user down and not innovation as encouragement.
All this is going to do is make clients lie about who they are. This taints the statistics and hampers other systems that require this information for providing features.
The interesting news is that if you click on the other MSN links they provide on the "you can't access this site" page, such as oh... advertising... then suddenly it works.
Has anyone tried MSN with their latest browser and see if it, and only it, really renders "correctly?" Heck, if Microsoft wanted to limit their audience, why not invent a whole different set of tags? Embrace and extend... but not too much that it attracts legal attention.
The general public needs to learn the difference between vandalism and terrorism and stop piggybacking on the media's hot word of the day.
Both acts are jammed packed with emotion, but one is more localized than the other in its duration and impact. Until people get hurt/killed or massive outages, or serious damage happens to largely shared resources, we need to stop placing defacement of web pages in the same category as recent events motivated by religious/political differences.
Unfortunately, people are teaching that programming is a matter of drag'n'drop IDEs, connecting components, and using class libraries.
However, who writes the IDEs, the editors, the class libraries, the components? How do you build a new language or a new operating system? How do you make a device driver or whip out microcode?
Computer Science, as I remember it, was learning how to problem solve and evaluate solutions by understanding their trade-offs. There was advanced data structures, algorithms, analysis, and math involved. When you had that under your belt, then you started learning the art.
Students need to understand what the machine is doing under the hood, how machine language is represented by assembly language, and how high level statements perform groups of operations. It gives them an appreciation and a better understanding of why things work the way they do -- and it helps them seek better solutions. You also learn when breaking the rules is the right thing to do.
A language like Pascal which is solidly has structure that must be followed is a fine example of learning how to take mental concepts and map them into executable code when there are langauge constraints. Eventually one learns that different programming langauges are better at expressing and addressing certain kinds of problems more efficiently than others.
Programmers should be expected to know how to deal with pointers and languages without garbage collection. Eventually some task bumps into them. Knowing about proper resource management can help optimize solutions.
In short, it's all about building blocks before taking short cuts.
Java has a steep learning curve to master its extensive library, and it babys developers in things they ought to understand already. Never being exposed to lower level constuctions, especially early on, is not something I would consider as being beneficial in the long run.
I decided to give it a try, and my keyboard usage has droped way down. I really like rolling one's hand over the mouse buttons to move forward and back, not to mention the quick gestures to minimize or close.
I use a screen with a lot of realestate, so keeping mouse movements to a minimum via not having to hit small targets is a good thing. Besides, you can always use it the old fashioned way.
I hope before this trend diversifies (and M$ claims to innovate it several years from now, while poo-pooing it for the short run), that someone sets about putting together some standard gestures so our environments will act similar.
Slashdot Mirror
Alphabetic Collection for Reducing Or Numbing Your Memory
Suppose you have a software package, and the CD KEY is used to allow you to install the software. Presumably, it takes some encrypted form and mutates it into a useful version. Alternately, such a code might be used to alter program logic to affect software behavior -- whatever. The point here is that the CD KEY is a protection mechanism at the client end.
Like the rest of the /. majority, I too find the DCMA an example of knee-jerk legislation produced by the uninformed and easily lobbied. But in this, suppose you even agree with it...
According to Tim Jung's post the gripe expressed was that the bnetd.org server does not do CD KEY checking. My point -- it shouldn't have to.
It appears that the design of this product is such that invalid CD KEY prevents people from stealing battle.net server resources. Apparently, that is working; good for Blizzard.
As I understand it, people aren't forging false CD KEYs and inappropriately using battle.net server's resources -- doing so would make the case more plausible. Yet in this case, it would an individual service hijacking player who should be the focus of legal attention.
So what was designed and built by Blizzard is something that actually says "show me your receipt and I'll let you use our systems." Rather than forge CD KEYs to do something illegal like steal Blizzard's service, the user community has provided their own resources, built their own software, and opted not to check for a "receipt" to use those services. Technically, it's not duplicated Blizzard's server then either, since it's a subset.
True, this does let people try an approximation. However, it isn't the actual golden master -- by definition it's build with low confidence, and possibly broken with missing features. Blizzard wasn't passing out free copies of a production game, it passed out something else with the expectations of comments.
About the only real complaint Blizzard has is that they aren't getting as much beta feedback as they could had they expanded the beta base. However, if Blizzard's servers are locked out via a CD KEY except to only a few, then they weren't going after that data because they wouldn't be getting that data anyhow -- so there's no loss, other than potential they forgot to go after. That was a business mistake.
Blizzard's true error then is not designing the software to require something only their servers could provide.
However, I can tell you as a software consumer, if I purchase a product that depends on someone's website being up and around, I get jittery about them going out of business or no longer supporting it and wouldn't make the purchase.
I suspect if Blizzard kindly asked for it, anonymous beta testers would happily provide feedback. Feedback that would make the game much better, improving overall sales. Blizzard actually has a very positive opportunity here, if they can get past the shortsightedness.
Went to Walt Disney World at the end of last year, and managed to get substantial face time with a really nice animator. She recommended we pop over to Disney's digital theater and watch Monster's Inc.
Coming from someone who made movies for a living, she seemed pretty qualified to notice the difference.
Frankly, I'd have to agree. In the opening Pixar demo, I could easily see details that just weren't visible on standard film stock. The bird's had scratches on their beaks from pecking; the wire they sat on was branded; everything looked very crisp and bright.
Convinced I was just being more observant this time around, I made a point to see the movie again in a non-digital theater. My observations on the digital showing were correct. The animator was right.
The funny part was when, as I was buying my ticket, I asked the person at the ticket booth what they thought of the digital show. The answer was "it looks the same to me."
That got me wondering -- if you don't know what to look for, are you going to be able to appreciate it?
Unfortunately, I'm not a big stereo buff, and when my musician friend took me to a local store to pick a home theater system, I couldn't tell the difference between the really high end stuff and mid-range. Perhaps this is due to my hearing not being as acute as his? Now my vision is much better.
Could it be that the average eyesight is not that great, or could it be that the average viewer isn't looking for extra details but does notice the absence of extensive film damage and splicing?
Can I take someone else's picture, enlarge it -- extrapolating pixels via these new fractal toolkits -- and post that? At this point, information is being added. Hmm... a better derative work?
What if I find a business that makes and sells professional thumbnails. Can I zoom it as well? Or do I not have to, because the it's already fair use by virture of being thumbnail size?
---
I lay claims to blank.gif which holds one transparent pixel. Anyone who wants to make a smaller thumbnail of that, feel free.
There are several problems that stem from the behavior you're asking about. Let's explore them.
The primary purpose of a version control system is to... store revision history! (surprise.) The secondary purpose is to provide chronological associations between files. (for instance, this documentation goes with that version of the software) What happens is the non-initiated miss the purpose of the tool and view it as a central dumping grounds for unrelated "stuff."
If you're just trying to share temporary artifacts, stick them in a public folder on your network, publish them on the intranet, don't pollute a project's repository with unrelated and transient materials just because you've got write access.
Basically, if you can't tell what you have in a repository (and know why it's there), you've got a problem on your hands.
I hesitate to reveal how many times I've had to clean up repositories that had superfluous files that didn't belong to the project or the repository in question, had versions spread across separate files, had no commented revision history or other identifying features, or where it was just being used as a backup.
Let's face it - commercial version control systems are expensive. I once worked for a place where everyone had to get a license for the client just to get non-project related materials. The side effect was that this particular tool didn't have decent security, and it allowed everyone to access the source code by virtue of having rights to the repository. I've yet to get a decent explanation why the HR department needs access source code.
Adding insult to injury, non-programmers usually don't "get it" when it comes to version control. As a result, things would mysteriously disappear. Turns out a non-developer was being 'helpful' by cleaning up stuff that didn't look "important." Thank god for backups.
The version control system is supposed to help with change control, not make you a victim of your officemates' good intentions.
Speaking of polluting repositories, or in this case, excessive growth, a lot of version control systems are not that efficient when it comes to storing binary data... such as a Word document. We'd often have people check in change after change after change to such documents, and the repository would get enormous. Doing standard checkouts on the project would take friggin' forever.
Ironically, developer documentation (which was written in LaTeX, HTML, and plain ASCII text files) worked just fine. Wonder why... perhaps the developers knew how the tool operated and took advantage of that fact? I think so. Sure, they stored graphics in it, either as PostScript or multiple JPEG/GIF/PNGs - but those changed so little, it wasn't noticed.
So, just as we've established a version control system shouldn't be used as file junk yard, we should also take note that there *are* specific tools for managing intra-documentation changes. It takes relatively little effort to use similar tags across two different toolsets, and thus keep everything in synch.
Finally, and perhaps the worse offense, is management thinking that version control is a communication tool. I'm not making this up, but I've been in meetings where management put a memo in version control and lashed at the staff for not reading it. I like to say that version control is like the national archives, you can get anything you want, if you know it's there. It is NOT the Borg Collective; it isn't a broadcast medium, and it isn't a substitution for communication - no matter when you checked it in.
Yes, CVS can be "abused" in the manner you're describing, but only for a short time. Eventually you'll run into technical limitations, strange CM policies that appear to have nothing to do with CM, and you'll be scratching your head asking "what the hell am I looking at?"
Hope this helped!
Excellent point; poorly worded on my part. In general, your statement ought to be true about all version number schemes inside a repository. (Cederqvist, section 4.3)
Labels are our friends. Though, I've actually heard people using phrases like "We're modifying the 1.19.3.4.7.x branch today." That doesn't convey a lot of meaning.
However, based on real world practices, people tend to use revision numbers as version numbers. They shouldn't. And there is a difference between the two. Your point illustrates that well; thank you for raising it. I'd like to think Sun didn't tweak their internal revision numbers to mirror product version numbers.
Where I was going was, if numbers are going to be used to convey repository structure, it should be hack free. If revision numbers are going to be used to convey information, the user should have control over what gets used. The reserved use (which personally I like), in CVS's case came from [Cederqvist section 13]. PVCS is pretty darn good about giving the right level of control for those who want to twiddle numbers directly.
I'm simply saying it's up to the person running the repository to decide -- ideally they should have a clue of what works well.
I've done SCM for a number of years, professionally evaluated version control product, and helped edit an Anti-Pattern book on the subject. It seems, at least to me, that the majority of version control systems out there have the basis covered when it comes to check-in, check-out, branching, and labeling. The standard features, if you will.
...this worked at least twice for me.)
However, most of the reasons that I've seen companies change version control systems is because of completely different reasons. Here are a few that come to mind:
- A version control system must be fast. I worked at one company where we tried to use Visual SourceSafe over a WAN; it took HOURS to share code. A good VCS should transmit the minimal amount of data.
- A version control system must provide security. All too often management uses the SCM repository as kind of a shared directory (BAD, BAD, BAD) -- and people who have no need to see or modify the code, do... implicitly.
- A version control system should provide extensive auditing and notification capabilities that can be discretely turned on and off. Allow logging the positive, the negative, and letting people know when particular operations happen to a set of files. In once case we attempted to get PVCS to automate scripts on a change to send mail to the PM. Checking in a directory flooded inboxes, since it could audit collections of code.
- There MUST be a recovery mechanism. Ever try to recover a lost SourceSafe password? Yikes. (Gaining re-entry is possible, back stuff up, change your password, do a diff. Copy pattern into the admin record with hex editor. Login as admin with new password. Change admin password.
- Again, there MUST be a recovery mechanism. I love RCS, SCCS, and PVCS for their file-related mechanisms. Why? I've had SCM systems go down hard when the database got munged. Yes, you can recover from a backup, but a lot of work gets lost. With an open file format, you can at least hand fix localized problems.
- That said, good version control systems should allow you to check in collections of files as atomic units, move files and directories, and operate on projects as a whole. Anytime I have twiddle with a repository, thereby breaking past history, something is seriously wrong with the VCS system model.
- Good systems must have an IMPORT / EXPORT capability that PRESERVES HISTORY. The less I feel locked into a solution, the more likely I'll be to try it out. Porting between system is usually painful.
- SCM systems must conform to how the CM manager wants to run things, not the other way around. Let's face it, users can and will make mistakes, and that's okay. Mistakes should be fixable. I'll never use StarTeam because it was too easy for users to check in accidentally branches that couldn't be removed. Tech support argued that version control should reflect the history of the product, where I maintain (and still do) that it should reflect the intended history. If I want to include user errors, that should be my policy, not the tools. My users should be able to reflect upon the project history and know why things changed. Period. You don't use a hack to undo a mistake.
- Branching notation should be clear and to the point. CVS has it's magic numbers, StarTeam has god awful views. Let me choose the numbering scheme, don't play games with odd/even numbering. Version numbers should not be overloaded to carry additional meta-information by the product.
- A good SCM tool should remember tag history. Suppose I accidently move or delete a tag, now I want to put it back. Suppose I want to see where it's been. This case is rare, but anyone who's had a user twiddle with the wrong tags feels this pain as sharp and deep.
- More ADMINISTRATIVE control. My big beef with CVS is when I have to twiddle with the repository structures and permissions directly to accomplish what I want done. No. No. No. There should be a tool (that audit's change) for standard operations.
- An admin should have the ability to define, enforce, and audit user permissions that should be applied cross dimensionally against repository, commands, and elements within the repository.
- Data should be stored in a manner that can be parsed by custom tools. It allows me to write extensions and automation.
- Nothing should be possible in a GUI that is not possible from the command line. The inverse holds true as well. Everything should be automation friendly. Early versions of PVCS pissed me off for this reason. As a SCM manager, I've used both, and I'll take a command line over a GUI any day. My novice users want a GUI, my advanced ones usually revert back to command lines (and integrate it with their editors).
- There must be readable 2 and 3 way diffs.
- A good SCM tool will be able to produce reports, or at least make it possible to export information that can produce reports.
- A good SCM tool should know how to handle binary files efficiently, rather than just storing the whole copy.
- A good SCM system should not put a limitation on comments.
- A good version control system should not try to "do it all" (CCC/Harvest) and do none of it well. When GUI's pop up off screen, or you have to artificially create packages for simple files, something's wrong. Which leads into...
SCM systems should operate the way the users of that system do.
There is a BIG difference between how commercial houses run things verses OpenSource projects.
Commercial groups usually have a smaller set of developers, they are known in advance, and commonly use the locking model. OpenSource models tend to use concurrency a lot more, and operate on the applying diff's procedure. (Yes, I know, exceptions are out there.)
Thus, some tools that feel more natural in some environments get quickly rejected in others. I've yet to see someone produce a readable guide about version control abstracted at a high level bringing all the terminology together. (Incidentally, I'm about to release one; email me for a draft.)
The overall problem in tends to be that people look on the side of the box for features, rather than asking if the features are even applicable for what they're doing.
Worse yet, proper SCM often gets sidestepped in commercial world. Ask: Do you want branching? You get, is it a feature?...yes! Now ask: Do you know when it's appropriate to branch, how to do the branch efficiently, how to graft branches back to the root, or how to physically do it... and you find out this is where a lot of bad CM happens. It isn't fun to inherit a screwed up repository.
The most common downfall of SCM, as I've seen in the commercial world, is a failure of the those running it (quite often over-tasked infrastructure people) failing to understand the product being built with the tool, failure by team leads to communicate repository structure, failure by management as they use the SCM tool as a substitute for communication, and failure by the developers who don't know how to use the tool and when to use the appropriate features.
Actually, that was the book I was refering to. :)
It's got a fairly good CVS overview, then goes into a bit about OpenSource, and then hops to advanced CVS stuff.
Still, there's a gap -- what's the RIGHT way to use a tool. Or, assuming I now know CVS, how could this apply to SourceForge?
Show me a project, show me how you made a patch, show me how you submitted it.
My problem is that books that act like do-it-all toaster ovens are usually very incomplete in their depth. I have a number of printed resources that fall into this category on my reference shelves.
Let's use your CVS example and assume that I've been using PVCS successfully for a decade.
I want to make the switch from PVCS to CVS. So, I bought the reference card, the reference book, the O'Reily book, and an OpenSource book that covers CVS.
First thing these things tell me to do is seek out "the Cederqvist." Let's furthermore assume I get past this and realize it's the bible of CVS. I may run into another problem... how do I read a TeX file, a PS file, or such. So, let's assume I get past _that_ and have HTML, Text, or PDF. (There is implicit knowledge needed to perform a primitive level of fundamental tasks.)
Going straight to CVS's Cederqvist v1.11.1p1 -- section 1.1 tells us it's a version control system and it can record the history of our source files. This statement assumes we already know what we're looking at, have an idea of what the software does, and we're trying to learn the commands to it.
Back out a level... why would I want version control? What real world reason would make me want to use it? Many colleges don't address that, as many students don't work in teams for credit. They tend to encounter version control the moment they get assigned to a development team, and never having to do it before, they view it as overhead.
A good manual should show parallels to real world problems and solutions, in addition to documenting every featured option.
It's not until you get bitten in the butt by your own actions or those of your co-workers, that you start to see value in it. It's not until you use version control to identify and resolve a really hideous bug that you get an awe and sense of appreciation of it. It's not until you have to produce a production level patch that you get a sincere respect for it. And it's not until you start doing parallel development that you realize how much you should have had this back at day one.
By section 1.3.2 we see some examples -- we're shown the solution without knowing the problem it's designed to solve.
By section 2, on page 7, we're instantly in the guts of how the repository works. Details that never need be known -- unless CVS has limitations that we have to compensate for manually. Much later we learn this is the case. This goes on for pages and pages.
I'm glad the information is covered, but is this was a _user_ is looking for when he picks up a all-text 166 page manual and hits page 7?
As life goes on, we learn about tags and stickiness. We still are left to extrapolate why we need them. Life would come together in a snap if someone said "users of PVCS and SourceSafe may recognize sticky tags as static labels; the reason we use _these_ terms instead are...."
But just because you know what a tool does, or how to invoke commands doesn't mean you're using it right. There are at least five different kinds of branching I can come up with off the top of my head, depending on what goal you're trying to accomplish.
Anyone who's inherited a version control system and seen a branch of a branch of a branch of a branch of a branch and no one could justify why knows what I'm talking about.
Just as the argument is made that "because you learned the language doesn't mean you know how to program" extends to configuration management, too. "Just cause you know how to do CVS doesn't mean you know how to do CM." And this equally applied to using autoconf, make, rpm, LaTeX documentation, etc.
There are right ways, wrong ways, and the effective way. Let's be honest here, our admired gurus are gurus because they know not just how to play by the unwritten rules, but also when and how to break them.
What I really want to see is a book that doesn't discuss the tool, but discusses the real world best OpenSource practices, and uses the real tools we use as examples to teach it.
> I very much doubt that. The former is generally easier than the latter.
I've written a number of various utilities and applications for the public domain. Some shareware was successful enough it still results in checks in the mail, some applications I personally witnessed in use by over 300 people each day over the course of four years, and many others have just faded away with time and platform changes. On the commercial front, I've written a lot of flagship products, directed development efforts, and been highly involved in QA and SCM. I like to think I can code my way out of a paper bag.
Naturally to do all those things, I've needed to know various languages, compilers, bug tracking tools, version control systems, build automation, and documentation. I like to think I've successfully been involved with much of the software lifecycle.
But, when I first dipped my foot in the Linux pool, I was trying desperately to map my prior experience from PC to Linux.
I knew Microsoft and Borland's C++, but couldn't get certain parts of the STL to work with gcc. Oh, that part was broken (it's hence been fixed).
I knew SourceSafe and PVCS inside and out and had been the CM manager of 70 people. Just mapping the terminology from those products to RCS/SCCS/CVS was a small barrier of its own when I first started. Things didn't help when the some standard CM tasks required implementation knowledge of CVS and tweaking the repository directly.
In corporate environments, we had access to the version control system directly; we were immediately responsible for the code. There was no need to generate patches for submission, or apply them.
In cases where the software wasn't designed to be portable, people never took that into account. The general philosophy had to change for Linux.
Tired of Microsoft's or Borland's make? Use OpusMake. Want to build an installation package? Use InstallSheild or another varient. Hard core debugging? Soft/ICE. Powerful tracing? Any NuMega product. Documentation? Word. PageMaker. FrameMaker.
But assuming I've got GNU Make, autoconf, RPM, gdb, LaTex, and a number other things under my belt -- everything has to be done in a way that's acceptable and receptive to the community.
The point I'm going with is this: there's a lot of untapped talent out there, because of the transitional Rosetta stone is kept too close to our chest.
We share our code, but not our process and techniques. We assume that just because people haven't cut their teeth on Linux, know GNU utilities inside and out, and know how to do things the way we do that they are neophytes. That needs to change.
If the Linux and OpenSource community wants to tap the knowledge and talent of the commercial world, we need to not just provide software tools and grass movement marketing, but we need to provide the intellectual resources as well.
What I really want to see is a book that assumes you know how to sling code, but addresses the specifics on how to become part of the coding community.
I've seen lots of lists that say:
0. Get the latest version of the code from CVS.
1. Read and understand the code.
2. Make changes.
3. Send your patches to the maintainer.
4. Hope they get accepted.
There are a lot of programmers out there who don't have the minimum set of knowledge to perform the admin part of steps, but do have the technical know how to write solid code.
How many people have code but don't know how to set up a good makefile, but could if a decent template were explained? How many people would like to have configure scripts, but aren't sure how the magic works? How many people aren't sure how to put their code in CVS or upload it to SourceForge? How many people want to know how to build packages, whether by RPM or some other means? How many people don't know what questions users need answered in documentation, nor how to put it in a man/info page?
Simply making a breadth, but shallow, offering consisting of nicely printed man pages that are indexed hasn't helped much. It'd be nice if someone took a simple project and followed it end-to-end.
(At serious risk to my inbox, if enough contributors send me suggestions, tidbits, or the process as _they_ see it, I'll make a decent effort and putting something together.)
Cut'n'Paste is evil. Real computer science students should know how to use wizards to write their redundant code.
Actually, if you think about it, Wil's perspective on things might actually be the best commentary for the /. audience.
He'd know first hand what would truly interest the geek within. I doubt the other actor's would be able to do so.
How long before the first Linux port?
For the most part, if I'm interested in substance and functionality over glitz, OpenSource projects have what I want -- with the added benefit that if it isn't precisely what I want, I can fix that. If there's a problem, it usually gets noticed and fixed sooner. Authors take pride in their work, as their very name and reputation is attached. And amazingly enough, all this comes at a very low price tag.
That doesn't say that OpenSource comes at no cost. The economics are slightly different. To be a consumer in this market, I have to have about the same amount of knowledge in my head about how my computer worked when I was running DOS back in the '80s. I recognize my computer is not a do-all appliance with pre-canned solutions I have to accept or not use. I can mold it to my will... and surprisingly with relatively little effort. OpenSource lets me venture into the realm of the unexplored if I so choose, or I can stay well within my comfort zone.
On the flip side, to be a contributor, I recognize I may never get rich directly from my contributions. However, I can get noticed. I can get famous. I can get appreciated. I can be worth more to my employer, whether from experience or name recognition.
It's personally rewarding, providing personal growth, a sense of community, and is fun to boot. I've yet to get this experience out off a sealed package off the shelf.
If you're the type of person who find yourself doing a View Source when you visit an interesting website, then you've got enough of a streak of curiosity to survive consuming OpenSource.
With familiarity and tmie, it's easy to contribute. Contributions don't have to be just code. They can be suggesting ideas, reporting bugs, play testing, or even proof reading.
So let me get this right... chewing gum in class will go on my permanent record afterall?
With a little luck, this amazing set of insight ought to spill over to user home pages as well.
Don't the ISP providers themselves purchase a hunk of bandwidth and IP ranges that they then partition and redistribute, offering themselves as middleman for support and value-added services?
What this does buy the linux community is the fact that Linux has support by a big name, rich company. IT managers should feel more comfortable with this knowledge.
In the past I've seen IT departments lean toward Microsoft in their solutions, even knowing the product was defective, because they honestly thought they could get individual attention and support.
IBM certainly knows how to deliver better support than Microsoft, especially since IBM will come on site.
.FED.US and .GOV, managed by GSA, are being contracted to SAIC.
In short, they live.
Does anyone remember when Microsoft reported that Quartdeck's product QEMM would no longer work with the next version of windows.
And it didn't.
Unless you renamed QEMM.SYS to something else, like QEMM386.SYS, then it worked again.
Microsoft is again relying on dirty tricks to wear the user down and not innovation as encouragement.
All this is going to do is make clients lie about who they are. This taints the statistics and hampers other systems that require this information for providing features.
The interesting news is that if you click on the other MSN links they provide on the "you can't access this site" page, such as oh... advertising... then suddenly it works.
Has anyone tried MSN with their latest browser and see if it, and only it, really renders "correctly?" Heck, if Microsoft wanted to limit their audience, why not invent a whole different set of tags? Embrace and extend... but not too much that it attracts legal attention.
The general public needs to learn the difference between vandalism and terrorism and stop piggybacking on the media's hot word of the day.
Both acts are jammed packed with emotion, but one is more localized than the other in its duration and impact. Until people get hurt/killed or massive outages, or serious damage happens to largely shared resources, we need to stop placing defacement of web pages in the same category as recent events motivated by religious/political differences.
Unfortunately, people are teaching that programming is a matter of drag'n'drop IDEs, connecting components, and using class libraries.
However, who writes the IDEs, the editors, the class libraries, the components? How do you build a new language or a new operating system? How do you make a device driver or whip out microcode?
Computer Science, as I remember it, was learning how to problem solve and evaluate solutions by understanding their trade-offs. There was advanced data structures, algorithms, analysis, and math involved. When you had that under your belt, then you started learning the art.
Students need to understand what the machine is doing under the hood, how machine language is represented by assembly language, and how high level statements perform groups of operations. It gives them an appreciation and a better understanding of why things work the way they do -- and it helps them seek better solutions. You also learn when breaking the rules is the right thing to do.
A language like Pascal which is solidly has structure that must be followed is a fine example of learning how to take mental concepts and map them into executable code when there are langauge constraints. Eventually one learns that different programming langauges are better at expressing and addressing certain kinds of problems more efficiently than others.
Programmers should be expected to know how to deal with pointers and languages without garbage collection. Eventually some task bumps into them. Knowing about proper resource management can help optimize solutions.
In short, it's all about building blocks before taking short cuts.
Java has a steep learning curve to master its extensive library, and it babys developers in things they ought to understand already. Never being exposed to lower level constuctions, especially early on, is not something I would consider as being beneficial in the long run.
I decided to give it a try, and my keyboard usage has droped way down. I really like rolling one's hand over the mouse buttons to move forward and back, not to mention the quick gestures to minimize or close.
I use a screen with a lot of realestate, so keeping mouse movements to a minimum via not having to hit small targets is a good thing. Besides, you can always use it the old fashioned way.
I hope before this trend diversifies (and M$ claims to innovate it several years from now, while poo-pooing it for the short run), that someone sets about putting together some standard gestures so our environments will act similar.