Having returned to relatively socialist Canada from the (surprisingly still quite free market, despite the corporatism (i.e. business buying law) going on) U.S.A., I can only say...
<warning: rant>
Those who support taxation deserve to have their heads cleaved from thier bodies, in the most painful way possible, and their corpses recycled to nourish the plants that are harvested to produce the grains that feed the pigs who's processed flesh in the form of ham or bacon I'm occasionally given to consume.
The social stagnation and "nanny state" attitude here is so opressively overwhelming it boggles the mind: "We can't do that because it would take more tax dollars and cost us too much."
Fuck the socialist attitude: You'd like hot lunches at school for your kids (no shit: this is unheard of in a Canadian public school), get off your arses, get a deal struck between the school board and a local caterer, and have parents volounteer to distribute the food... best $1.25 a day I spent in the U.S.
But, nooooooo... we'd have to have 250 government bureaucrats overseeing the nutritional content of the food in such a program. And so, our kids eat cold sandwiches (except the lucky few, like my daughter, who's parents sacrifice to purchase a $30, sorry, $34.50 after tax, thermos for hot soup for her).
Socialized medicine? Can't save your kid's life for lack of the funds to purchase the experimental drugs because you've already spent them in the form of taxes that are supposed to pay for medical care.... "So sorry, your kid dies because after paying our administrators we certaintly can't afford any kind of experimental treatment."
Worse than the Nazis they are, those damn socialist parasites -- yes, yes, nothing can compare with the slaughter of six million innocent people in a grand short-lived murder spree, at least not in "horror per day" ratings. But, like thousands of paper cuts, socialist butchers take their human toll, slowly, over time, that, if left unchecked, would surely surpass the death toll of any genocide attempt. Like any proper parasite, they never destroy the entire productive host population, though.
</warning>
Bravo!, then, to those that oppose any moral basis for involuntary taxation (and the, "But look!, we gave you a road" (2000 miles away) argument doesn't wash -- it's rather like the guy who expects sex from his date because he bought her dinner: "rape" seams a fitting word in both cases).
And to those Americans who think Canada is a "kinder, gentler" society for all the social programs, I say, come and live here for a year, maybe get sick and need your tax-funded services. You'll find them surprisingly unavailable.
For myself, born here, I struggle against U.S. immigration hurdles (been there, got the LC, green card processing slowed by the INS, and had to return), but slowly resign to the life-sapping tax yoke. Yet, for my son, an American, born and raised, god-fucking-damit, I simultaneously yearn to keep him near, and hope for an American family to adopt him into the bosom of freedom that is his birthright.
Sure, the objections about the components being expensive, compared to PC-based equivalents, are noted. They apply strongest to the storage devices, which should really just be hard disks in servers somewhere at the home's headend.
The other devices are "living-room" stylish, and fit well in a media center. Well, maybe showed off a bit more, somewhat like my (rapidly aging) B&O Beosystem 5500.. The idea of a dedicated entertainment peripheral, capable of providing access to networked (locally or remotely) movies, music, and live TV and radio, is rapidly maturing: the "set top box" is coming of age. Whereas STBs were once rather awkward devices, necessary to provide access to proprietary or specialty cable signals and services, this range of devices is modular (thus accomodating "ugly duckling" proprieteray sources, if necessary), the notion of a "media receiver" is starting to make sense. One without a honkin' noisy PC fan, thank you.
I suppose those of us without dedicated "headends" for our servers can take heart in the stylish storage units that would also fit in well in a living room, though you will be paying for "style" over substance in that case. Me, I want all my video and audio (legally purchased), on one central server, with original media carefully archived.
Now, to do this right will require accomidation for terrestrial and satellite SD and HD transmissions, and time-shifting storage of same.
Re:Software Engineering is different in Purpose
on
Software Craftsmanship
·
· Score: 3, Interesting
As with many things, the software "engineering" vs. craftmanship dichotomy is not completely black and white.
Whereas engineering is about reproducable, and measurable processes that can be constrained within certain bounds, craftmanship is about being able to build things that serve a purpose.
To some degree a craftsman will delve into a standard repetoire of tricks and techniques to get a job done, reflecting the "engineering" aspect of the job. However, what makes a craft interesting is that no two assignments are alike, and the job-specific problems, and how they are solved separate the master from the novice, not mere knowledge of a larger repetoire of canned solutions to known problems.
Because programming is such a young discipline (as opposed, say, to building buildings, bridges, or even airplanes), there is a log of original craftmanship involved in most projects. When a design pattern is found to be useful, it is catalogued, communicated, and often finds generic implementation in some piece of code, or higher-level programming language -- application-specific languages, or languages "tuned" to be particularly useful for certain applications reflect "software engineering": we've solved this problem, this is the general approach, and here are the parameters within which this solution works. A design pattern, implemented, becomes a "rough in" of a piece of code.
What this means, of course, is that the repeatable stuff becomes engineered, leaving only the "finish work" to be crafted. Leading edge programmers pushing the envelope of what the "finish work" is are thus craftspersons, and commensurate with the original work they do, notoriously unable to provide time, complexity, and labour estimates: when the job is done, they will know how long it will take.
This, of course is frustrating to traditional management teams. For software is not like a house. The interesting stuff, and the stuff that sells as the next "killer app" is precisely the stuff that no one has yet produced, reducing it to a low-margin commodity, instead of the "hot" program it is. And this stuff is not engineered -- it is crafted.
Software patents and copyrights ensure artificially high value for what would otherwise be commodity software, restricting its proliferation until it is ubiquitous, and commensurately high salaries for "assembly-line software engineers". Without them, the high-margin areas would be those of the leading edge, crafted code -- protected by copyright and patent for a short duration, perhaps, to encourage progression of the art, and recoupment of development efforts.
Interestingly, some 95% of all code is not engineereed according to a simple blueprint, but custom-crafted, Microsoft Office sales duely noted. Even if you can buy all the pipe and fittings you need, a plumber to cut things to proper lengths is handy. If all commodity software were free, there would be plenty of employment for software craftspersons (on this, I agree with RMS). Software engineers, in the guise of assembly-line coders, would be relegated to the ranks to apprentice, or "do it yourselfer". Perhaps when this happens, true software engineering, that is the polishing of a custom crafted design into a generic cookie-cutter component, understandable and consumable by the apprentice, will properly refer to the master software craftsperson.
One aspect of that article that I definitely disagree with is the contention that technical debates cannot occur over email
I wholeheartedly agree with this sentiment, but, often, meeting dynamics start to encroach on such email exchanges, and the "Solve it now, we've wasted enough time!" rather than "solve it correctly" pressure this creates results in sub-optimal, short-term "solutions".
The "best" solution is the one that has the most support, in such situations, whether or not it is correct, robust, or scalable to future needs.
Of course, as we all know, the processor doesn't give a rat's ass how much support a "solution" has, but rather whether it is correct.
While email might be the perfect forum for long, complex, technical discussions, to solve difficult problems, with facts and avenues of research carefully preserved, articles like this one, and the "don't waste time on email" mentality they will engender in management as "the latest productivity thing", will derail such use of the medium. So, we are, once again, diverted to the "five minute fix" hell, that so makes meetings unproductive: if you can't make the quick fix work, you must be a bad programmer, no?
So, while I agree that email is an ideal medium for dealing with difficult problems, trying to use it for that purpose is likely going to invite sabbotage from those who do not understand the nuances of the problem, and what makes it difficult in the first place, as they get drawn into the discussion. This is espescially true as the design and programming vocabulary grows to accomodate maturation of the discipline: words like "generic", "refactor", "polymorphic", "singleton", "abstract", and "virtual" have very specific meanings in a modern design and OO programming context, and are ripe for misinterpretation by those who take them out of context: I've seen "generic" mistaken for "portable", "virtual" as pertaining to memory management (which it may or may not), and "abstract" misconstrued as "academic", with "polymorhic" and "refactor" raising fear of "too complicated" solutions.
There are simple problems and complex problems. And, complex problems do not have simple solutions, by definition. A growing trend in these days of "interchangable software engineers" is pressure to code to the level of understanding of the "least skilled programmer" to support this interchangability. The dynamics of large groups (and growing email audiences) increases these pressures. Sorry, but there is nothing that can make brain surgery a "cut by numbers" discipline, and there is nothing that can make complex problems simple.
So, while email may be perfect to let "hard core" problem-solvers collaborate, their efforts will be usurped, making it best to avoid the medium in favour of the classic midnight-programming sessions, when the hoi poloi have left to pursure their domestic lives, no doubt comfortably simple.
Re:Why do English people have disgusting teeth?
on
AOL's Mystro TV vs Tivo?
·
· Score: 0, Offtopic
...america is full of nothing more than the off-spring of scum that couldnt make it in there home lands.
I thought that was 'strailia. Oh wait! Thats where all the people who were not wanted in their homelands were sent.
British teeth... American lardasses... Canadian..., er, um, hmm, nothing more offensive than "bumps on logs" comes to mind. It's the quiet ones you have to watch, though, ya know.
Perhaps it was something on the news about dentists being restricted from using them, or hydrogen peroxide bleaching products, or some such, on teeth, that got me confused.
... IIRC, it is illegal to market tooth-whitening products in England (though, I may be mistaken about this).
Perhaps there's a correlation?
Now, if only I could get Caffienated Diet Mountain Dew in Canada I might be a happier hacker... mutter, mutter, grumble, socialist, grumble, kvetch, communist, mutter, complain, fascist, grumble, mutter, curse... geez, I miss the U.S.A.! War-mongering Dubya, and all!
I haven't coded for an Alpha Micro in years, and recently convinced the copyright holder on SPY (I guess one is a success if someone writes a clone program -- in this case, "TheSPY") to release it to the public domain. Believe it or not, there's a lot of businesses that still run on such machines, and surprisingly well (though they've moved on to 680x0 varients, AMOS remains pretty much as it has been).
Most of my work these days is embedded (TMX320Cx0, MIPS), Linux, or BSD-based. At home I run GNU/Linux on an Athlon XP1600+ with 100+ GB disk and 1/2 GB DDR RAM, and an old P200 clunker with a whopping 80 MB RAM. With the telecom bust in the U.S., I returned to Ontario from Texas (damn I miss that place - big houses and lotsa' guns), and accepted work with ATI.
I too junked a lot of old stuff in my last three moves (Montreal to Chicago, Chicago to Dallas, Dallas to Toronto): a perfecrly working Multisync EGA monitor, a bunch of S100 and SS50 cards (remember the SWTPC?), bunches of MFM drives, printers and so on, as well as some 20+ year old 9 track 1600 BPI tapes: sorry, can't provide any copies of the SPAM (System Programming for Alpha Micros) PASCAL-ripoff compiler I wrote).
With the move back to Toronto, I gave up my beautiful ADSL service and am stuck with dialup for a while: do I get a non-winmodem PCI modem for the Athlon? or jury rig an ethernet crossover cable to the P200 using it as a firewall, with it's ISA modem? Decisions, decisions. As I added structured wiring to my Dallas, house, I threw in all the routers, firewalls, satellite multiswitches, etc. when I sold it.
20 years ago was 1983, and the AM100 was released in 1976, IIRC.
Actually, the idea of a microprogrammed PDP-11 in a microcomputer form-factor (for those days) would not have been much of a stretch of the imagination: the PDP-11 was a real machine, and micros were already here, vis. the Altair (January, 1975). The issue was only one of the complexity of the instruction set.
The subsequent Alpha Micro machines (AM100/L, AM1000, AM2000, etc.) represented a move from the PDP-11 instruction set to the mass-market 68000 and derivatives. The cool thing was that the operating system (AMOS: Alpha Micro Operating System, what else), appeared the same to high-level language programs, and application migration was a slam dunk -- no small feat for those days where code portability was generally a non-issue.
They always used top-quality hardware: CDC disk drives (10 MB Hawk, 80 MB Phoenix), and later SCSI drives and controllers: never IDE.
While the company still exists in some form, they always targeted niche vertical markets and never became a dominent force: they didn't make "PeeCees" but rather higher-end machines, by comparison. Of course, AMOS functionality stagnated around the capabilities of a cross between PCDOS 1.0 and RSTS (though multi-tasking and multi-user), and their limited-hierarchy file systems (two level: by project and programmer, hence "project-programmer" number, or PPN, a DEC idea) and file name limitiations (six character name and three character extentions, upper-case only) were a bit of a joke. But, you could write blindingly fast business applications for them in AlphaBasic (complete with ISAM extentions). (I, of course, stuck to PDP-11 and 68k assembler coding for that platform, with a SPY program as my claim to fame (or not): it permitted the monitoring of terminal I/O on a different terminal (even a different screen type, with translation)).
I've often thought of designing an AMOS compatibility layer, and porting AlphaBasic to a more modern platform: there's a surprising amount of business applications still running on AlphaMicros.
Barnes and Noble has gotten quite a bit of coin from me instead of Amazon because of Bezoz's silly patents, and my commensurate boycott of his business.
I always make sure I let the B&N people know that their "patent behavior", relative to Amazon, is a deciding factor in my chosing to patronize them instead of their competition. Usually, it's some clerk who wouldn't know a patent if they infringed upon one who says, "that's nice", but on occasion a more senior B&N staffer has asked me to elaborate and take note of my input.
Do my lowly few hundred dollars of purchases a year make that much of a difference in B&N's policy? Not bloody likely. But, it costs me nothing to make my position clear, and there is always the slightest chance it might get others (store personel, managers, other customers) to pause and think.
Knuth, Donald E, "The Art of Computer Programming"
on
An IMDb for Books
·
· Score: 1
At present, I appear to be the first to recommend this series of books, but I'm sure not to be the last.
Having worked with both Linux and BSD TCP/IP stacks, and at the kernel level in general (in both, BSD more so), I'd really like to know if he as addressed BSD at all, and if so, how it compares to other free operating systems.
If you're serious, I could come up with something. There's a bit of an attempt at cross-browser "web cams" with "picture in picture" javascript here, but (a) Javascript is not my real forte, (b) the code has not been kept up to date to accomodate real recent non-standard browsers, and (c) most of the cams are probably dead by now [Jennycam and Kellycam seam to be live]. It represents an toy exercise to rapidly produce something in a language I really don't know. Generally, I'd offer C or C++ examples.
With regard to the hardware side of networking, you can look here: that's what I did for my house in Dallas.
I amgainfully employed at the moment, so any interest would have to be serious and financially worth my while. What kind of code would you like to see?
Asking someone to write a bit of code is more something I'd do to a junior programmer, to see if they can cut it at all, because of the small size of the exercise. For senior posts, I'd hope to hear them describe how to solve a problem, being specific about the technologies involved; a demonstration of the breadth of knowledge and problem-solving ability that they'd need to lead on a project.
Having been in the 'biz' since 1976, in data communications, embedded systems, automated test systems, automated software quality assurance, and most recently graphics; employing everything from various assembly languages, to Java (with a particular liking for C++), I would never interview a programmer without a small programming test. And, I have a greater regard for potential employers that insist that I produce some code in "real-time" during the interview. Having to produce substantial examples of "real code" is a problem, because often, as other posters have noted, such code belongs to previous or current employers. The few times I have been asked to do that, prior to an interview, I explained the situation, suggested several programming tasks that would be representative of skill, say 500-1000 lines of C or C++, and suggested that I deliver a solution in a day or two. We'd agree to some varient of one of the tasks I'd suggest (parser for a small language, state driven automaton, cross-browser friendly Javascript, source code pretty-printer, etc.) and I'd deliver, intentionally under time pressure. When willing, I'd deliver incrementally more sophisticated solutions, so my development and refinement process could be examined, but this requires a significant investment of time on the part of the prospective employer (surprisingly, the better ones make the investment). But, I still think, that the in-interview programming exercise permits gleaning much of the same qualities with far less review effort -- the task is necessarily simpler, but the stress and pressure to perform are higher.
The "in interview" programming task doesn't have to be complex: order all the zeros in an integer array at the beginning, or sort an array -- something that can be completed in 10-20 minutes, tops.
The junior programmer will, of course, take the approach he or she knows, and may be able to talk about the complexity of the algorithm. That, and correctness, is all you should expect.
The senior programmer will start with the same, and then proceed to (a) analyze the solution for best, worst, and average case behavior, for running time and memory use, as appropriate; (b) suggest alternatives with their pros and cons; (c) explore the posibilities of making the algorithm generic; (d) identify any traits that might affect implementation. In particular, if there are nested tests in the implementation, the experienced programmer will consider optimization for the order in which the tests are done, noting that branches can be expensive.
Usually, one thinks all these "extra" steps "take time" and are thus expensive and to be avoided. However, the experienced programmer will make a big dent in considering those issues in the same time as the junior programmer struggles to solve the basic problem -- often concurrently while the solution he or she chose to present is still being illustrated.
Of course, the senior programmer will also be expected to "speak to" design methodologies and software engineering best practices, be comfortable with a variety of programming languages, and can demonstrate an ability to pick up a new language without difficulty (I "relearn" Perl or Tcl everytime they're the right tool for the job).
But, the bottom line is, a designer who can't code or understand code can't, without help, produce a running program. They might be of value in some shop, perhaps, but I've never encountered a place where designers (who may be using some modelling system, like Rational Rose, that can crank out state and event-driven code from a meta-description) aren't expected to deal with compiler errors and warnings on their own.
This seems like a pointless argument -- anything you've lived through, Mr 113 years lived through as well and the previous 70-odd years. Those 70 years included two world wars, the first atomic bomb, the invention of the airplane, widespread industrialization, etc etc etc... etc. He's got you beat.
Obviously, I didn't get my point across (though, my rapid response and plethora of typos may have something to do with this).
My point was not that I had lived through greater societal change. Obviously not. But, rather that the societal changes I (and others of "my generation") have gone through rank "up there" with the transition from a non-electrical to an electified society. To repeat: the transition from a non-wired (i.e., non-ubiquitious internet-connected to internet-connected) society has about as much socio-technological impact, relative to the status quo, as did the internal combustion engine, electrification, steam engine, invention of steel, and control of fire.
Yes, obviously, if you are to add up such disruptive changes, a longer life suggests increased exposure to more such techno-social changes. And, relative to the first one you experience, successive ones might pale in comparison.
But, society is sensitive not to aggregate changes over time, but rather relative changes: once electrification becomes widespread, it is no longer disruptive. Some would suggest that these relative disruptive changes are becoming more frequent and more disruptive as we approach a "technological singularity". I don't know that I buy into this apocalyptic singularity argument, but the pace of change does appear to be increasing, and opportunity for disruptive change in any given interval increasing in likelihood as well.
Certainly, someone born 100+ years ago would not have imagined our world in their youth. But, I maintain that this is true for someone born 40, or even 20 years ago. For those born in the early 1980's, would you have imagined laws like the DMCA in your early teens? That real ownership of non-weaponry entertainment hardware would be so regulated (or attempt to be so regulated)?
It may well have been possible for you to have had a computer all of your life. Even the internet, nascent as it may have been, may well predate you.
Perhaps, but as someone born in 1961, who's first access to a computer was a timesharing system (HP2000, BASIC and all) was in 1973, and who built his own computer around 1980, I can attest that, for a middle-aged person like me, the world certainly changed from being "analog" to "mostly digital".
The best social example is the Internet. Do you remember scouring the newspapers for job ads? I do. (And they only got printed on Wednesays.) I would argue that the implications of connectivity are no less impressive than electicity: I now shop, bank, communicate, research entirely almost entirely online. As I child I would do research for projects in a physical library. I can't imagine doing that now, and I doubt my two year old son ever will.
When he was born he had no *electricity* and no one in his family had ever seen an automobile. Geronimo had only been captured three years previously and was not only still alive, but a comparitively young man.
My father grew up without electicity or automobiles (though they existed). I still maintain that his transition (abandoning horses for transportation in favour of automobiles, and starting to get electrical appliances) is less disruptive than one where you no longer have to go places to get things.
The world he was born in to was one someone born 500 years before would have recongnized. The world you were born into is one that that hypothetical person couldn't possibly even have conceived of.
I would argue that this wouldn't be that far a stretch for the world into which I was born in 1961: no CD players, portable phones (we had CB radios, though -- not the same), consumer video players (never mind DVDs), not even calculators. Clocks had hands. Once the "digital revolution" had taken hold, it was easy to imagine these things, yes (O.K. we can digitize audio, video is the next hurdle, etc.), but an analog mindset did not lend itself to that kind of extrapolation: analog video recording existed, of course, but certainly not at consumer prices.
Remember, this was a world that had yet to see the supposed MPAA-destroying effects of consumer video recorders, and the motion-picture and recording industries were safe in their monopolies based on expensive production equipment.
You are talking differences in quantity. I am talking differences in quality.
I'd argue that both exist, and one should not be so quick to discount the relationship between them: better quality of two-way wireless communication has had significant social implications (i.e. anything good or bad w.r.t. cell phones) -- it isn't just a "quantity" (better, newer phone) issue.
There is no essential difference in type or quality of life today than there was 40 years ago when I first entered school. We live the same way now, with mostly the same things, as we did then. Electricity, phones, central heating, planes, automobiles, movies, TV, hydrogen bombs, etc.
I'd argue that we do a lot of things differently -- seeking employment, conducting business, etc.
While the tone of the interview was harsh toward ol' Billy Gee, his responses make business sense:
It is not profitable to fix bugs...
... at least that's what Microsoft's purported customer feedback indicates.
If anything, bug fixes, service packs, and other ancilliary releases represent an expense for Microsoft -- as much a part of P.R. than anything: convincing people that they take quality seriously, and that the next release will be "better", and so worth buying.
Apparently, people believe this since the perception that newer releases are less buggy persists.
How much would you spend to have a bug fixed? $10? $100?, or more like the $2000 to $20000 it actually costs (once overhead is taken into account)? Probably not anywhere close to $2000. You might even think the software vendor has an obligation to fix the bug. Nope. Nada. You accepted the lack of a warrenty, remember? Enough people accept it that Microsoft does not have to provide one. Their software is good enough for enough people to keep them profitable. Tough noogies.
Of course, if you're capable of examining and correcting bugs, given the source code (and, sometimes, even if you don't have it, though that's generally a tough slog, reserved for the most stubborn of us), you might not have $2000, but you may have the skill to invest your time to solve the problem. Heck, if you're gonna find and fix it for yourself anyway, might as well share your fix for some egoboo. For those of us with those kind of skills, closed-source software is, indeed, a poor value proposition.
Richard Stallman has pointed out that free software will not put the maintenance programmer out of work, since not everyone has the skills to fix bugs in the code they use -- one can always subscribe to a software support service, and, for certain enterprise products such subscriptions are du regeur. With open source code (and I use the distinction because I'm focusing on the ecomonic attributes of same, and not the social philosophy of it being free, though it may very well be), it may be easier for the individual to hire a maintenance programmer. Someone who's business relies on bug-free code will surely do so, and I think many have realised the folly of tying themselves to the suppport promises of closed-source providers, like Microsoft -- the expression "...hook, line, and sinker" come to mind.
It is ironic that perhaps RMS's argument for the livelihood available for maintenance programmers is weakened by the popularity of the free software movement itself: so many programmers will provide fixes for free that only difficult bugs or esoteric modifications (with little market demand) will justify payment.
I have used, in my time, Clearcase (which I rather liked despite the high price tag and apparent inefficiency repository-side), CVS, and most recently Perforce. For all the complaining about CVS lacking sophistication, it does get 95% of the job of source code control done. But, none of these address the root problem, and it's unfair to pick on one for not addressing it, implying that the others do a better job.
Inconsistent checkins of code, even code in different files, can break builds, unit, and integration tests. Consider the development process:
You check out a read-only version of the top of the development tree, that builds clean, and passes all the tests. Great. You get a write checkout on the stuff you want to change. Even if others don't touch those files (which can be difficult to enforce for some kinds of files, like headers of unique enumerations that everyone updates), you can still break things.
When you test build, you test build with your stuff changed, and everything else frozen. There is no guarantee that when you check in your changes, the break will build because something else on which your code depends got changed. Like a header file. I suppose you could get a write lock on all the files on which your code depends, but that still isn't good enough.
Consider a processing sequence where two function in two code files get called. One of them is supposed to increment some global "the sequence was run" counter. Both do. Oops. Builds fine, fails regression testing.
Short of locking the entire source tree when one developer changes something, you can't avoid this in general. Oh sure, you can resync all the files you didn't change, and run a build and regression test before checking your change in, but, lo, you'd have to lock the entire source tree during that time (or at least see if it changed again after your build and test, and repeat the process if it did, possibly indefinately). Serializing an otherwise parallel development process that way is murder on productivity: even if you run all the sanity builds at night, you now have a one day turnaround just to test build all changes, and hope they make it into the source repository. Kinda sucks, when you just changed a few lines.
Any automated solution will have to rely on serialization of source tree access, at some level. If the project can be broken down into independent components, serialization within a component can be relatively painless, with somewhat less frequent serialization across components (so called "integration" which the nightly build strives to avoid because it happens all the time). Experience shows that, unless you want to plan "integration" phases, this defeats a large benefit of the nightly build process, though, it is not unreasonable for very large projects, with clearly independent parts.
So, what's the solution?
The same, it's always been: divide and conquer.
While "integration" phases are to be shunned, and "repository serialization" kills productivity, one can take a statistical approach: instead of verifying everything before a checkin to a frozen repository, you design your project to try to isolate the effects of implementation changes from one another. Early on, this may be difficult as interfaces are still being tweaked, but you have less code then, and builds happen quickly. This is a large part of what a project architect is supposed to do.
If done correctly, a local delta built with a recent snapshot of the source repository is not likely to break the build and unit test of a more recent snapshot if it builds and passes regression tests against the somewhat older snapshot. This isn't foolproof, of course, but a proper design will have the necessary isolation: an implementation change in one area, or the addition of a new interface should be oblivious to your code.
Now, if interfaces need to change, or new features are to be added that have to be coordinated among developers (i.e. someone adds a feature and someone else writes code to use it), then you need greater coordination among all those that might be affected. Such work can take place on a side branch, and merged to the main development tree only when it is internally consistent. Again, this is generally the responsibility of the common lead programmer of those implementing the changes that need to be coordinated (perhaps the project architect, but in large projects, that kind of detail can be delegated).
Where trouble brews is when such a synchronized change has to take place across development teams: it usually is more effective if one person handles the integration of the new feature and code that uses it. Because the feature user has the need, it may be him or her. However, review of code to be added to a base for which another team is responsible should, of course, rest with that team: "You code didn't have this which I needed, so here's the patch, wanna check it out?" Yes, this can cause political friction, but in a mature development team, that won't happen. When communication between teams is minimal, hostile, or non-existent, and such functionality is to be added, is when builds break, and regression tests fail -- and the finger pointing begins.
It's a long way to Algeria or Istanbul from Washington DC., but it's a lot closer to either of those places from Versailles or Bonn., and if a "real" war breaks out, we won't be talking about Iraq anymore.
Flak falling a little close to your back yard, is it?
Sorry to be flip -- I certainly see your point. The question is how strongly does the relative proximity of Europe to the Middle East compared to the U.S.A. and the good point you raise affect the positions of France and Germany in the face of damning evidence (which has, as of yet, not been presented).
If damning evidence of Iraq's violations were to be produced, I doubt that France and Germany could continue to protest a resolution authorizing a U.S. attack -- that kind of "ass covering" would be a bit too obvious under those circumstances: they'd either anger Iraq by not vetoing the resolution, or anger the U.S., which would be hell bent on proceeding anyway.
I can imagine the U.S. taking the following position: "Support the resolution and we will defend your interests against growing instability when we attack anyway, or we won't help defend your interests due to instability when we attack anyway. But, we will attack.... anyway."
Shitty position to be in: disagree and we won't help you... agree and we might help you.
Sucks to not be the U.S. these days, in terms of military muscle, but, as Lord Elrond might put it, their "... list of allies grows thin."
...but if the US offers satellite photos of stuff leaving before UN inspectors come, it could be said that the US should be able to say, "they are lying to our faces, and here's the proof".
Yes, of course. But so far, it does not appear that they have made a convincing case for this to the U.N. Security Council. While France and Germany are threatening to veto any new resolutions authorizing the use of force against Iraq, pending "proof", I do not get the impression that they exactly like Iraq, and are acting impartially.
With regard to the UN, and those opposed to the use of force, force is already justified and authorize by the existing UN resolution signed by Iraq at the close of the First Gulf War. Iraq agreed to the terms, including unrestricted inspections by UN Weapons Inspectors, and he has failed to abide by the agreement. No further justification is required.
The UN's inaction serves only to undermine their effectiveness as a stabilizing force throughout the world. The dog has no teeth.
While I generally agree that non-conformance to the resolution Iraq signed at the end of the Gulf War justifies use of force, I'd think it should be for the U.N. Weapons Inspectors to
determine if their access is unrestricted or not, and not the U.S.
Now, while such non-conformance existed in the past, the present situation appears to (a) be an attempt (or at least the appearance of same) to correct this non-conformance, and (b) investigation by said inspectors to determine conformance. So far, the inspectors' verdict appears to be "We don't know, yet."
While I am no friend of Iraq's regime, particularly given their history, and see the U.S.'s role in acting as "executioner" as fair, if unsavory; I do not think they should be "judge and jury" as well -- some impartial justification for force should be present to legitimize it.
Just because the jury is deliberating for a long time does not mean you get to hang the accused, though you can take all measures short of that to reduce any threat he may present (i.e. a buildup and massing of force is reasonable under the circumstances).
Bush may indeed be due his pound of flesh, but not with the premature spilling of civillian blood.
Sadly, I don't think it's possible to combine the UNTIL and VARYING clauses (as in... VARYING GIRL FROM FIRST_GIRL TO LAST_GIRL.), but it's been a while since I coded in that abortion of a language.
And this is different from .tpc.int *HOW*?
on
U.S. Endorses ENUM
·
· Score: 2, Interesting
You know,.tpc.int.
"The Phone Company"
For those who don't know (and are too lazy to check here, this is a free service that maps fax numbers to email addresses, so, if you know a fax number, you can send a properly mime-formatted fax (or plain text, it works), to them via a.tpc.int email address: it gets routed to a local internet to fax gateway (presumably a local call away from the destination fax machine), and thence to the desired destination.
Being free, coverage is not perfect, of course, and there are limits to how much each gateway will accept (per origin, hour, day, week, etc.) but the system works surprisingly well!
Yes, fax machines are not phones, but the concept obviously extends there.
Slashdot Mirror
Or not, depending on your, er, "preferences".
<warning: rant>
Those who support taxation deserve to have their heads cleaved from thier bodies, in the most painful way possible, and their corpses recycled to nourish the plants that are harvested to produce the grains that feed the pigs who's processed flesh in the form of ham or bacon I'm occasionally given to consume.
The social stagnation and "nanny state" attitude here is so opressively overwhelming it boggles the mind: "We can't do that because it would take more tax dollars and cost us too much."
Fuck the socialist attitude: You'd like hot lunches at school for your kids (no shit: this is unheard of in a Canadian public school), get off your arses, get a deal struck between the school board and a local caterer, and have parents volounteer to distribute the food... best $1.25 a day I spent in the U.S.
But, nooooooo... we'd have to have 250 government bureaucrats overseeing the nutritional content of the food in such a program. And so, our kids eat cold sandwiches (except the lucky few, like my daughter, who's parents sacrifice to purchase a $30, sorry, $34.50 after tax, thermos for hot soup for her).
Socialized medicine? Can't save your kid's life for lack of the funds to purchase the experimental drugs because you've already spent them in the form of taxes that are supposed to pay for medical care.... "So sorry, your kid dies because after paying our administrators we certaintly can't afford any kind of experimental treatment."
Worse than the Nazis they are, those damn socialist parasites -- yes, yes, nothing can compare with the slaughter of six million innocent people in a grand short-lived murder spree, at least not in "horror per day" ratings. But, like thousands of paper cuts, socialist butchers take their human toll, slowly, over time, that, if left unchecked, would surely surpass the death toll of any genocide attempt. Like any proper parasite, they never destroy the entire productive host population, though.
</warning>
Bravo!, then, to those that oppose any moral basis for involuntary taxation (and the, "But look!, we gave you a road" (2000 miles away) argument doesn't wash -- it's rather like the guy who expects sex from his date because he bought her dinner: "rape" seams a fitting word in both cases).
And to those Americans who think Canada is a "kinder, gentler" society for all the social programs, I say, come and live here for a year, maybe get sick and need your tax-funded services. You'll find them surprisingly unavailable.
For myself, born here, I struggle against U.S. immigration hurdles (been there, got the LC, green card processing slowed by the INS, and had to return), but slowly resign to the life-sapping tax yoke. Yet, for my son, an American, born and raised, god-fucking-damit, I simultaneously yearn to keep him near, and hope for an American family to adopt him into the bosom of freedom that is his birthright.
Sure, the objections about the components being expensive, compared to PC-based equivalents, are noted. They apply strongest to the storage devices, which should really just be hard disks in servers somewhere at the home's headend.
The other devices are "living-room" stylish, and fit well in a media center. Well, maybe showed off a bit more, somewhat like my (rapidly aging) B&O Beosystem 5500.. The idea of a dedicated entertainment peripheral, capable of providing access to networked (locally or remotely) movies, music, and live TV and radio, is rapidly maturing: the "set top box" is coming of age. Whereas STBs were once rather awkward devices, necessary to provide access to proprietary or specialty cable signals and services, this range of devices is modular (thus accomodating "ugly duckling" proprieteray sources, if necessary), the notion of a "media receiver" is starting to make sense. One without a honkin' noisy PC fan, thank you.
I suppose those of us without dedicated "headends" for our servers can take heart in the stylish storage units that would also fit in well in a living room, though you will be paying for "style" over substance in that case. Me, I want all my video and audio (legally purchased), on one central server, with original media carefully archived.
Now, to do this right will require accomidation for terrestrial and satellite SD and HD transmissions, and time-shifting storage of same.
Whereas engineering is about reproducable, and measurable processes that can be constrained within certain bounds, craftmanship is about being able to build things that serve a purpose.
To some degree a craftsman will delve into a standard repetoire of tricks and techniques to get a job done, reflecting the "engineering" aspect of the job. However, what makes a craft interesting is that no two assignments are alike, and the job-specific problems, and how they are solved separate the master from the novice, not mere knowledge of a larger repetoire of canned solutions to known problems.
Because programming is such a young discipline (as opposed, say, to building buildings, bridges, or even airplanes), there is a log of original craftmanship involved in most projects. When a design pattern is found to be useful, it is catalogued, communicated, and often finds generic implementation in some piece of code, or higher-level programming language -- application-specific languages, or languages "tuned" to be particularly useful for certain applications reflect "software engineering": we've solved this problem, this is the general approach, and here are the parameters within which this solution works. A design pattern, implemented, becomes a "rough in" of a piece of code.
What this means, of course, is that the repeatable stuff becomes engineered, leaving only the "finish work" to be crafted. Leading edge programmers pushing the envelope of what the "finish work" is are thus craftspersons, and commensurate with the original work they do, notoriously unable to provide time, complexity, and labour estimates: when the job is done, they will know how long it will take.
This, of course is frustrating to traditional management teams. For software is not like a house. The interesting stuff, and the stuff that sells as the next "killer app" is precisely the stuff that no one has yet produced, reducing it to a low-margin commodity, instead of the "hot" program it is. And this stuff is not engineered -- it is crafted.
Software patents and copyrights ensure artificially high value for what would otherwise be commodity software, restricting its proliferation until it is ubiquitous, and commensurately high salaries for "assembly-line software engineers". Without them, the high-margin areas would be those of the leading edge, crafted code -- protected by copyright and patent for a short duration, perhaps, to encourage progression of the art, and recoupment of development efforts.
Interestingly, some 95% of all code is not engineereed according to a simple blueprint, but custom-crafted, Microsoft Office sales duely noted. Even if you can buy all the pipe and fittings you need, a plumber to cut things to proper lengths is handy. If all commodity software were free, there would be plenty of employment for software craftspersons (on this, I agree with RMS). Software engineers, in the guise of assembly-line coders, would be relegated to the ranks to apprentice, or "do it yourselfer". Perhaps when this happens, true software engineering, that is the polishing of a custom crafted design into a generic cookie-cutter component, understandable and consumable by the apprentice, will properly refer to the master software craftsperson.
I wholeheartedly agree with this sentiment, but, often, meeting dynamics start to encroach on such email exchanges, and the "Solve it now, we've wasted enough time!" rather than "solve it correctly" pressure this creates results in sub-optimal, short-term "solutions".
The "best" solution is the one that has the most support, in such situations, whether or not it is correct, robust, or scalable to future needs.
Of course, as we all know, the processor doesn't give a rat's ass how much support a "solution" has, but rather whether it is correct.
While email might be the perfect forum for long, complex, technical discussions, to solve difficult problems, with facts and avenues of research carefully preserved, articles like this one, and the "don't waste time on email" mentality they will engender in management as "the latest productivity thing", will derail such use of the medium. So, we are, once again, diverted to the "five minute fix" hell, that so makes meetings unproductive: if you can't make the quick fix work, you must be a bad programmer, no?
So, while I agree that email is an ideal medium for dealing with difficult problems, trying to use it for that purpose is likely going to invite sabbotage from those who do not understand the nuances of the problem, and what makes it difficult in the first place, as they get drawn into the discussion. This is espescially true as the design and programming vocabulary grows to accomodate maturation of the discipline: words like "generic", "refactor", "polymorphic", "singleton", "abstract", and "virtual" have very specific meanings in a modern design and OO programming context, and are ripe for misinterpretation by those who take them out of context: I've seen "generic" mistaken for "portable", "virtual" as pertaining to memory management (which it may or may not), and "abstract" misconstrued as "academic", with "polymorhic" and "refactor" raising fear of "too complicated" solutions.
There are simple problems and complex problems. And, complex problems do not have simple solutions, by definition. A growing trend in these days of "interchangable software engineers" is pressure to code to the level of understanding of the "least skilled programmer" to support this interchangability. The dynamics of large groups (and growing email audiences) increases these pressures. Sorry, but there is nothing that can make brain surgery a "cut by numbers" discipline, and there is nothing that can make complex problems simple.
So, while email may be perfect to let "hard core" problem-solvers collaborate, their efforts will be usurped, making it best to avoid the medium in favour of the classic midnight-programming sessions, when the hoi poloi have left to pursure their domestic lives, no doubt comfortably simple.
I thought that was 'strailia. Oh wait! Thats where all the people who were not wanted in their homelands were sent.
British teeth... American lardasses... Canadian..., er, um, hmm, nothing more offensive than "bumps on logs" comes to mind. It's the quiet ones you have to watch, though, ya know.
Perhaps it was something on the news about dentists being restricted from using them, or hydrogen peroxide bleaching products, or some such, on teeth, that got me confused.
Perhaps there's a correlation?
Now, if only I could get Caffienated Diet Mountain Dew in Canada I might be a happier hacker... mutter, mutter, grumble, socialist, grumble, kvetch, communist, mutter, complain, fascist, grumble, mutter, curse... geez, I miss the U.S.A.! War-mongering Dubya, and all!
I haven't coded for an Alpha Micro in years, and recently convinced the copyright holder on SPY (I guess one is a success if someone writes a clone program -- in this case, "TheSPY") to release it to the public domain. Believe it or not, there's a lot of businesses that still run on such machines, and surprisingly well (though they've moved on to 680x0 varients, AMOS remains pretty much as it has been).
Most of my work these days is embedded (TMX320Cx0, MIPS), Linux, or BSD-based. At home I run GNU/Linux on an Athlon XP1600+ with 100+ GB disk and 1/2 GB DDR RAM, and an old P200 clunker with a whopping 80 MB RAM. With the telecom bust in the U.S., I returned to Ontario from Texas (damn I miss that place - big houses and lotsa' guns), and accepted work with ATI.
I too junked a lot of old stuff in my last three moves (Montreal to Chicago, Chicago to Dallas, Dallas to Toronto): a perfecrly working Multisync EGA monitor, a bunch of S100 and SS50 cards (remember the SWTPC?), bunches of MFM drives, printers and so on, as well as some 20+ year old 9 track 1600 BPI tapes: sorry, can't provide any copies of the SPAM (System Programming for Alpha Micros) PASCAL-ripoff compiler I wrote).
With the move back to Toronto, I gave up my beautiful ADSL service and am stuck with dialup for a while: do I get a non-winmodem PCI modem for the Athlon? or jury rig an ethernet crossover cable to the P200 using it as a firewall, with it's ISA modem? Decisions, decisions. As I added structured wiring to my Dallas, house, I threw in all the routers, firewalls, satellite multiswitches, etc. when I sold it.
Wouldn't have had to.
20 years ago was 1983, and the AM100 was released in 1976, IIRC.
Actually, the idea of a microprogrammed PDP-11 in a microcomputer form-factor (for those days) would not have been much of a stretch of the imagination: the PDP-11 was a real machine, and micros were already here, vis. the Altair (January, 1975). The issue was only one of the complexity of the instruction set.
The subsequent Alpha Micro machines (AM100/L, AM1000, AM2000, etc.) represented a move from the PDP-11 instruction set to the mass-market 68000 and derivatives. The cool thing was that the operating system (AMOS: Alpha Micro Operating System, what else), appeared the same to high-level language programs, and application migration was a slam dunk -- no small feat for those days where code portability was generally a non-issue.
They always used top-quality hardware: CDC disk drives (10 MB Hawk, 80 MB Phoenix), and later SCSI drives and controllers: never IDE.
While the company still exists in some form, they always targeted niche vertical markets and never became a dominent force: they didn't make "PeeCees" but rather higher-end machines, by comparison. Of course, AMOS functionality stagnated around the capabilities of a cross between PCDOS 1.0 and RSTS (though multi-tasking and multi-user), and their limited-hierarchy file systems (two level: by project and programmer, hence "project-programmer" number, or PPN, a DEC idea) and file name limitiations (six character name and three character extentions, upper-case only) were a bit of a joke. But, you could write blindingly fast business applications for them in AlphaBasic (complete with ISAM extentions). (I, of course, stuck to PDP-11 and 68k assembler coding for that platform, with a SPY program as my claim to fame (or not): it permitted the monitoring of terminal I/O on a different terminal (even a different screen type, with translation)).
I've often thought of designing an AMOS compatibility layer, and porting AlphaBasic to a more modern platform: there's a surprising amount of business applications still running on AlphaMicros.
I always make sure I let the B&N people know that their "patent behavior", relative to Amazon, is a deciding factor in my chosing to patronize them instead of their competition. Usually, it's some clerk who wouldn't know a patent if they infringed upon one who says, "that's nice", but on occasion a more senior B&N staffer has asked me to elaborate and take note of my input.
Do my lowly few hundred dollars of purchases a year make that much of a difference in B&N's policy? Not bloody likely. But, it costs me nothing to make my position clear, and there is always the slightest chance it might get others (store personel, managers, other customers) to pause and think.
At present, I appear to be the first to recommend this series of books, but I'm sure not to be the last.
Having worked with both Linux and BSD TCP/IP stacks, and at the kernel level in general (in both, BSD more so), I'd really like to know if he as addressed BSD at all, and if so, how it compares to other free operating systems.
With regard to the hardware side of networking, you can look here: that's what I did for my house in Dallas.
I amgainfully employed at the moment, so any interest would have to be serious and financially worth my while. What kind of code would you like to see?
Having been in the 'biz' since 1976, in data communications, embedded systems, automated test systems, automated software quality assurance, and most recently graphics; employing everything from various assembly languages, to Java (with a particular liking for C++), I would never interview a programmer without a small programming test. And, I have a greater regard for potential employers that insist that I produce some code in "real-time" during the interview. Having to produce substantial examples of "real code" is a problem, because often, as other posters have noted, such code belongs to previous or current employers. The few times I have been asked to do that, prior to an interview, I explained the situation, suggested several programming tasks that would be representative of skill, say 500-1000 lines of C or C++, and suggested that I deliver a solution in a day or two. We'd agree to some varient of one of the tasks I'd suggest (parser for a small language, state driven automaton, cross-browser friendly Javascript, source code pretty-printer, etc.) and I'd deliver, intentionally under time pressure. When willing, I'd deliver incrementally more sophisticated solutions, so my development and refinement process could be examined, but this requires a significant investment of time on the part of the prospective employer (surprisingly, the better ones make the investment). But, I still think, that the in-interview programming exercise permits gleaning much of the same qualities with far less review effort -- the task is necessarily simpler, but the stress and pressure to perform are higher.
The "in interview" programming task doesn't have to be complex: order all the zeros in an integer array at the beginning, or sort an array -- something that can be completed in 10-20 minutes, tops.
The junior programmer will, of course, take the approach he or she knows, and may be able to talk about the complexity of the algorithm. That, and correctness, is all you should expect.
The senior programmer will start with the same, and then proceed to (a) analyze the solution for best, worst, and average case behavior, for running time and memory use, as appropriate; (b) suggest alternatives with their pros and cons; (c) explore the posibilities of making the algorithm generic; (d) identify any traits that might affect implementation. In particular, if there are nested tests in the implementation, the experienced programmer will consider optimization for the order in which the tests are done, noting that branches can be expensive.
Usually, one thinks all these "extra" steps "take time" and are thus expensive and to be avoided. However, the experienced programmer will make a big dent in considering those issues in the same time as the junior programmer struggles to solve the basic problem -- often concurrently while the solution he or she chose to present is still being illustrated.
Of course, the senior programmer will also be expected to "speak to" design methodologies and software engineering best practices, be comfortable with a variety of programming languages, and can demonstrate an ability to pick up a new language without difficulty (I "relearn" Perl or Tcl everytime they're the right tool for the job).
But, the bottom line is, a designer who can't code or understand code can't, without help, produce a running program. They might be of value in some shop, perhaps, but I've never encountered a place where designers (who may be using some modelling system, like Rational Rose, that can crank out state and event-driven code from a meta-description) aren't expected to deal with compiler errors and warnings on their own.
Obviously, I didn't get my point across (though, my rapid response and plethora of typos may have something to do with this).
My point was not that I had lived through greater societal change. Obviously not. But, rather that the societal changes I (and others of "my generation") have gone through rank "up there" with the transition from a non-electrical to an electified society. To repeat: the transition from a non-wired (i.e., non-ubiquitious internet-connected to internet-connected) society has about as much socio-technological impact, relative to the status quo, as did the internal combustion engine, electrification, steam engine, invention of steel, and control of fire.
Yes, obviously, if you are to add up such disruptive changes, a longer life suggests increased exposure to more such techno-social changes. And, relative to the first one you experience, successive ones might pale in comparison.
But, society is sensitive not to aggregate changes over time, but rather relative changes: once electrification becomes widespread, it is no longer disruptive. Some would suggest that these relative disruptive changes are becoming more frequent and more disruptive as we approach a "technological singularity". I don't know that I buy into this apocalyptic singularity argument, but the pace of change does appear to be increasing, and opportunity for disruptive change in any given interval increasing in likelihood as well.
Certainly, someone born 100+ years ago would not have imagined our world in their youth. But, I maintain that this is true for someone born 40, or even 20 years ago. For those born in the early 1980's, would you have imagined laws like the DMCA in your early teens? That real ownership of non-weaponry entertainment hardware would be so regulated (or attempt to be so regulated)?
Perhaps, but as someone born in 1961, who's first access to a computer was a timesharing system (HP2000, BASIC and all) was in 1973, and who built his own computer around 1980, I can attest that, for a middle-aged person like me, the world certainly changed from being "analog" to "mostly digital".
The best social example is the Internet. Do you remember scouring the newspapers for job ads? I do. (And they only got printed on Wednesays.) I would argue that the implications of connectivity are no less impressive than electicity: I now shop, bank, communicate, research entirely almost entirely online. As I child I would do research for projects in a physical library. I can't imagine doing that now, and I doubt my two year old son ever will.
When he was born he had no *electricity* and no one in his family had ever seen an automobile. Geronimo had only been captured three years previously and was not only still alive, but a comparitively young man.
My father grew up without electicity or automobiles (though they existed). I still maintain that his transition (abandoning horses for transportation in favour of automobiles, and starting to get electrical appliances) is less disruptive than one where you no longer have to go places to get things.
The world he was born in to was one someone born 500 years before would have recongnized. The world you were born into is one that that hypothetical person couldn't possibly even have conceived of.
I would argue that this wouldn't be that far a stretch for the world into which I was born in 1961: no CD players, portable phones (we had CB radios, though -- not the same), consumer video players (never mind DVDs), not even calculators. Clocks had hands. Once the "digital revolution" had taken hold, it was easy to imagine these things, yes (O.K. we can digitize audio, video is the next hurdle, etc.), but an analog mindset did not lend itself to that kind of extrapolation: analog video recording existed, of course, but certainly not at consumer prices.
Remember, this was a world that had yet to see the supposed MPAA-destroying effects of consumer video recorders, and the motion-picture and recording industries were safe in their monopolies based on expensive production equipment.
You are talking differences in quantity. I am talking differences in quality.
I'd argue that both exist, and one should not be so quick to discount the relationship between them: better quality of two-way wireless communication has had significant social implications (i.e. anything good or bad w.r.t. cell phones) -- it isn't just a "quantity" (better, newer phone) issue.
There is no essential difference in type or quality of life today than there was 40 years ago when I first entered school. We live the same way now, with mostly the same things, as we did then. Electricity, phones, central heating, planes, automobiles, movies, TV, hydrogen bombs, etc.
I'd argue that we do a lot of things differently -- seeking employment, conducting business, etc.
I wonder how many CTOs hand an "Oh crap!" experience this morning, and not the usual kind.
It is not profitable to fix bugs...
If anything, bug fixes, service packs, and other ancilliary releases represent an expense for Microsoft -- as much a part of P.R. than anything: convincing people that they take quality seriously, and that the next release will be "better", and so worth buying.
Apparently, people believe this since the perception that newer releases are less buggy persists.
How much would you spend to have a bug fixed? $10? $100?, or more like the $2000 to $20000 it actually costs (once overhead is taken into account)? Probably not anywhere close to $2000. You might even think the software vendor has an obligation to fix the bug. Nope. Nada. You accepted the lack of a warrenty, remember? Enough people accept it that Microsoft does not have to provide one. Their software is good enough for enough people to keep them profitable. Tough noogies.
Of course, if you're capable of examining and correcting bugs, given the source code (and, sometimes, even if you don't have it, though that's generally a tough slog, reserved for the most stubborn of us), you might not have $2000, but you may have the skill to invest your time to solve the problem. Heck, if you're gonna find and fix it for yourself anyway, might as well share your fix for some egoboo. For those of us with those kind of skills, closed-source software is, indeed, a poor value proposition.
Richard Stallman has pointed out that free software will not put the maintenance programmer out of work, since not everyone has the skills to fix bugs in the code they use -- one can always subscribe to a software support service, and, for certain enterprise products such subscriptions are du regeur. With open source code (and I use the distinction because I'm focusing on the ecomonic attributes of same, and not the social philosophy of it being free, though it may very well be), it may be easier for the individual to hire a maintenance programmer. Someone who's business relies on bug-free code will surely do so, and I think many have realised the folly of tying themselves to the suppport promises of closed-source providers, like Microsoft -- the expression "...hook, line, and sinker" come to mind.
It is ironic that perhaps RMS's argument for the livelihood available for maintenance programmers is weakened by the popularity of the free software movement itself: so many programmers will provide fixes for free that only difficult bugs or esoteric modifications (with little market demand) will justify payment.
I have used, in my time, Clearcase (which I rather liked despite the high price tag and apparent inefficiency repository-side), CVS, and most recently Perforce. For all the complaining about CVS lacking sophistication, it does get 95% of the job of source code control done. But, none of these address the root problem, and it's unfair to pick on one for not addressing it, implying that the others do a better job.
Inconsistent checkins of code, even code in different files, can break builds, unit, and integration tests. Consider the development process:
You check out a read-only version of the top of the development tree, that builds clean, and passes all the tests. Great. You get a write checkout on the stuff you want to change. Even if others don't touch those files (which can be difficult to enforce for some kinds of files, like headers of unique enumerations that everyone updates), you can still break things.
When you test build, you test build with your stuff changed, and everything else frozen. There is no guarantee that when you check in your changes, the break will build because something else on which your code depends got changed. Like a header file. I suppose you could get a write lock on all the files on which your code depends, but that still isn't good enough.
Consider a processing sequence where two function in two code files get called. One of them is supposed to increment some global "the sequence was run" counter. Both do. Oops. Builds fine, fails regression testing.
Short of locking the entire source tree when one developer changes something, you can't avoid this in general. Oh sure, you can resync all the files you didn't change, and run a build and regression test before checking your change in, but, lo, you'd have to lock the entire source tree during that time (or at least see if it changed again after your build and test, and repeat the process if it did, possibly indefinately). Serializing an otherwise parallel development process that way is murder on productivity: even if you run all the sanity builds at night, you now have a one day turnaround just to test build all changes, and hope they make it into the source repository. Kinda sucks, when you just changed a few lines.
Any automated solution will have to rely on serialization of source tree access, at some level. If the project can be broken down into independent components, serialization within a component can be relatively painless, with somewhat less frequent serialization across components (so called "integration" which the nightly build strives to avoid because it happens all the time). Experience shows that, unless you want to plan "integration" phases, this defeats a large benefit of the nightly build process, though, it is not unreasonable for very large projects, with clearly independent parts.
So, what's the solution?
The same, it's always been: divide and conquer.
While "integration" phases are to be shunned, and "repository serialization" kills productivity, one can take a statistical approach: instead of verifying everything before a checkin to a frozen repository, you design your project to try to isolate the effects of implementation changes from one another. Early on, this may be difficult as interfaces are still being tweaked, but you have less code then, and builds happen quickly. This is a large part of what a project architect is supposed to do.
If done correctly, a local delta built with a recent snapshot of the source repository is not likely to break the build and unit test of a more recent snapshot if it builds and passes regression tests against the somewhat older snapshot. This isn't foolproof, of course, but a proper design will have the necessary isolation: an implementation change in one area, or the addition of a new interface should be oblivious to your code.
Now, if interfaces need to change, or new features are to be added that have to be coordinated among developers (i.e. someone adds a feature and someone else writes code to use it), then you need greater coordination among all those that might be affected. Such work can take place on a side branch, and merged to the main development tree only when it is internally consistent. Again, this is generally the responsibility of the common lead programmer of those implementing the changes that need to be coordinated (perhaps the project architect, but in large projects, that kind of detail can be delegated).
Where trouble brews is when such a synchronized change has to take place across development teams: it usually is more effective if one person handles the integration of the new feature and code that uses it. Because the feature user has the need, it may be him or her. However, review of code to be added to a base for which another team is responsible should, of course, rest with that team: "You code didn't have this which I needed, so here's the patch, wanna check it out?" Yes, this can cause political friction, but in a mature development team, that won't happen. When communication between teams is minimal, hostile, or non-existent, and such functionality is to be added, is when builds break, and regression tests fail -- and the finger pointing begins.
Flak falling a little close to your back yard, is it?
Sorry to be flip -- I certainly see your point. The question is how strongly does the relative proximity of Europe to the Middle East compared to the U.S.A. and the good point you raise affect the positions of France and Germany in the face of damning evidence (which has, as of yet, not been presented).
If damning evidence of Iraq's violations were to be produced, I doubt that France and Germany could continue to protest a resolution authorizing a U.S. attack -- that kind of "ass covering" would be a bit too obvious under those circumstances: they'd either anger Iraq by not vetoing the resolution, or anger the U.S., which would be hell bent on proceeding anyway.
I can imagine the U.S. taking the following position: "Support the resolution and we will defend your interests against growing instability when we attack anyway, or we won't help defend your interests due to instability when we attack anyway. But, we will attack.... anyway."
Shitty position to be in: disagree and we won't help you... agree and we might help you.
Sucks to not be the U.S. these days, in terms of military muscle, but, as Lord Elrond might put it, their "... list of allies grows thin."
Yes, of course. But so far, it does not appear that they have made a convincing case for this to the U.N. Security Council. While France and Germany are threatening to veto any new resolutions authorizing the use of force against Iraq, pending "proof", I do not get the impression that they exactly like Iraq, and are acting impartially.
The UN's inaction serves only to undermine their effectiveness as a stabilizing force throughout the world. The dog has no teeth.
While I generally agree that non-conformance to the resolution Iraq signed at the end of the Gulf War justifies use of force, I'd think it should be for the U.N. Weapons Inspectors to determine if their access is unrestricted or not, and not the U.S.
Now, while such non-conformance existed in the past, the present situation appears to (a) be an attempt (or at least the appearance of same) to correct this non-conformance, and (b) investigation by said inspectors to determine conformance. So far, the inspectors' verdict appears to be "We don't know, yet."
While I am no friend of Iraq's regime, particularly given their history, and see the U.S.'s role in acting as "executioner" as fair, if unsavory; I do not think they should be "judge and jury" as well -- some impartial justification for force should be present to legitimize it.
Just because the jury is deliberating for a long time does not mean you get to hang the accused, though you can take all measures short of that to reduce any threat he may present (i.e. a buildup and massing of force is reasonable under the circumstances).
Bush may indeed be due his pound of flesh, but not with the premature spilling of civillian blood.
Sadly, I don't think it's possible to combine the UNTIL and VARYING clauses (as in ... VARYING GIRL FROM FIRST_GIRL TO LAST_GIRL.), but it's been a while since I coded in that abortion of a language.
"The Phone Company"
For those who don't know (and are too lazy to check here, this is a free service that maps fax numbers to email addresses, so, if you know a fax number, you can send a properly mime-formatted fax (or plain text, it works), to them via a .tpc.int email address: it gets routed to a local internet to fax gateway (presumably a local call away from the destination fax machine), and thence to the desired destination.
Being free, coverage is not perfect, of course, and there are limits to how much each gateway will accept (per origin, hour, day, week, etc.) but the system works surprisingly well!
Yes, fax machines are not phones, but the concept obviously extends there.