It's hard for me to know how seriously to take this when in it's not at all clear to me
whether Satchell is genuinely in the running or if he and John Dvorak are just playing "Howard Stern for President!"
Hmmm... I remember when Pat Paulson (he of the Smothers Brothers show) was "running" for President. I can see why you might think that this is all a gag to get some attention and to act as a carrier for some of my ideas.
I won't speak for John, he is all too capable (and willing!) to speak for himself.
For my part, I'm serious about serving on the Technical Committee. If I was trying to pull a stunt, the ideal way would be to get a series of articles (paid, of course) in one of the magazines and write my head off. (And I'm ashamed to admit I didn't think of it first.)
As for buying a more up-to-date Macintosh, I don't have any need for it right now. The only thing I use the Mac for is running PageMaker and Illustrator for the few contracts requiring desktop publishing that still come my way. When I have a need for a newer Mac, I'll get one. Until then, I will do just fine with what I have.
The answer, that informal resolution will be speedier than formal
litigation leaves much to be desired. If a formal court order holds no weight, why would M$ listen to some little TRC? Were are the
teeth?
I direct your attention to a part of my answer to question six:
More importantly and implied in the PFJ is that the TC's six-month report [to the Plaintiffs] would be able to show any pattern of tendency toward
non-compliance and edge-skating, a defect in the 1995 decree that made micro-infractions, to coin a term, almost impossible to track.
Just because the resolution is informal and fast doesn't mean that Microsoft wouldn't have to take heat for the act. It just means that Joe Programmer doesn't have to wade through a court fight in order to learn how to interface with some arcane corner of Windows XP in order to get his product out the door.
Yes, it can be done. It can even be done decently with an extra $1000 or so in recording hardware. But at best it represents a
significant degradation in sound quality + a lot of work to get what should be freely available in the first place.
BZZZZZT! $1000 is the wrong answer. (No complaint, though about the second sentence in your answer.)
The Echo Gina24 is a sound card I used that cost me only $500, and the audio quality is professional quality. Echo Digital Audio has other products that may be less expensive but sport similar performance specifications. (Do you really need 8 outputs at the same time? I didn't think so.) At $249 MSRP for the Mia (which means you can prolly find it for a bit less if you look) you can get A/D that surpasses most sound cards that come with PCs today.
When I measured the performance of the Echo Gina24, I was impressed with its 127 dBFS noise floor and 73 dB total harmonic distortion when excited with a 23-tone test signal. (The THD measurement may well have been measuring the performance of the UTC/TRW A1 transformer I was using to balance the signal for injection into the Echo Gina24, which uses balanced inputs.) The real test, though, was with live recording. The Echo Gina24 did as good a job, to my ears, as my Technics 1500US tape deck running at 15 ips recording a classical string quartet from my board and a pair of ATM-31 microphones mounted in a shock-absorbing stereo brace. Better if you consider the tape deck has a 60 dB noise floor.
(BONUS: Linux drivers -- in source -- are supposed to be available in January.)
We have a foot of snow; how will IT work here?
on
This is IT?
·
· Score: 2
We have highways closed, chain controls, and a request to not travel if we don't have to. I would think twice before taking my Jeep out.
The reason that Dollar Rent-A-Car is asking for thumbprints is because they no longer trust customers to take proper care of their cars and to honor their contracts. How many times have you ridden with a person who is driving aggressively who says, "What do I care, it's a rental"? Not to mention rental cars that are driven to Mexico and sold there.
Trust is a two-way street. I don't know about you, but I am starting to get the idea that the customer is just as likely to be victimized as the vendor. I would be tempted to require exactly the same forms of identification from the clerk helping me that the clerk demands of me. I know why they want a driver's license and credit card: proof that I have passed some state's minimum exam for driving, and proof of payment capability. When they ask for a thumbprint, though, I'd be tempted to whip out my own fingerprint card and request they fill in their full name, current address, and fingerprint. That way, if there is a service problem I can identify the clerk completely. (It could also help to show law enforcement that I am the authorized contract-holder of a rental car by demonstrating that I obtained the contract with a bona-fide agent of the rent-a-car company.)
When the National ID card is instituted, I'm going to ask to see the card of the clerks. Trust is a two-way street.
I'll be brief with the hurdles you will have to overcome:
Certification: Part 68 certification applies to the entire device, hardware and software, and also applies to any modification made on the device, hardware and software, that can affect the transmitter. International certification is even trickier, and requires that the manufacturer have some standing with each country, although there are now some procedures to streamline the process (CTR-21 comes to mind). In all cases, certification must also be "owned by the manufacturer" -- and the GPL is specifically designed to have software NOT be owned by a single entity.
Stories around the campfire: It's fine to talk about "standards", but be aware that the ITU-T standards are written in such a way that people who are not part of the inner circle will have significantly more difficulty creating working code. Standards only mandate the WHAT, not the HOW, and significant interactions between two ends are not described in the Standards. The fact is, modem design is a bit of a black art because you have to know signal processing, but you also have to know the quirks of the telephone system over which you operate. This is particularly true of echo-cancelling modulation methods such as V.34 and V.90. Getting that information is expensive. Very expensive.
Patents: V.34 and V.90 modulation and demodulation have a number of patents currently active that would need to be dealt with. The problem here is that the companies holding those patents aren't going to provide RF licensing -- in the current economy the patents are significant sources of revenue and the owners aren't about to throw revenue away. You can't get around them.
Testing: Proper testing of modem code is not trivial. I did it for magazines, for companies, and for end-users, and it's damn hard and not cheap. Proper testing would include both lab testing and field trials, with lots of parameter capture so the designer can see how a given connection fails.
Lack Of Interface Standards: each HST modem product has a unique interface board, with absolutely no documentation available from the manufacturers (even when they want to give it out, which they don't) and completely different operation. Let me list the areas of differences: control interface; audio information coding; codec interface; sample rate setting (absolutely required for V.90); hook control; ring detect (I know one board that uses the audio path for this); impedance setting (complex versus fixed, 600 ohm versus 900 ohm, hybrid balance equalization); line monitoring for fax PNG detection while on-hook. There's more, but I can't think of them all.
Motorola holds the base patents on host signal processing, and I'm not sure how the Open Source community can get around those patents. Given Motorola's hard times, I doubt anyone will convince them to provide a royalty-free license to the patent -- especially as they have a soft-modem product in the race. (But then again, they concentrate in the Windows marketplace, so a Linux license could happen...maybe...if the moon is right.)
Then there is the CPU intensive nature of HSP modems. Depending on the quality of modem you are trying to do, CPU horsepower requirements are huge. A bare-bones V.34 implementation requires around 40 MHz of a Pentium-class CPU, while a robust bells-and-whistles version needs something like 90-95 MHz. Don't expect a 486 to handle the load. To be as good as possible on as many platforms as possible, the signal processing code would have to use integer arithmetic instead of floating-point, because the floating-point performance of x86 class processors varies quite a bit from chip type to chip type.
Can it be done? Yes. Can it be done to the expectations of the Linux community? I don't think so, unless one of the big boys (Motorola, Connexent, Nortel, USRobotics) decides to weigh into the market and provide already-developed code and an interface.
...down the drain. Remember when the NCC was the biggest show going, when they were able to completely fill McCormick Place in Chicago, and then dwindled down to 20, count'em 20 tables before the NCC show organizers saw the handwriting on the wall and converted the NCC back to a research-only show?
The Computer Dealers Exposition (that's what COMDEX stands for, boys and girls) outgrew its original charter almost a decade ago -- how many dealers make the trip in? Damn few that I know. Today, it's the press and the companies themselves that make up the bulk of the show, along with employees of the Fortune 5000 companies that are still making enough money to keep the travel budget stuffed.
Speaking of the press, have you noticed that a lot of magazine and newsletter titles have closed in the past 12 months? Have you noticed that the amount of computer-trade ink has fallen off tremendously? For example, we just lost SmartPartner Magazine today, according to reports.
I know quite a number of the members of the press who have decided to forgo the annual pilgrimage to Las Vegas, either because they don't have jobs/assignments or because they want no part of a large, concentrated crowd of people at something that is uniquely United States.
One benefit to the Death Of COMDEX is the end of the maniac development cycle that requires companies to "show something" according to a calendar set by someone else. We may well see all software companies release software when it's ready, not when the booth bimbos hit the floor.
And that would be an improvement.
Re:Buffer Overflows, Kernel Patches, & Fucking Tro
on
PDF Virus Spotted
·
· Score: 2
BTW, does your favorite OS distribute fixes that can patch the currently executing kernel in memory without taking the system down, in the event of a kernel bug?
Oh, you shouldn't hoist yourself that far above the rim of the foxhole, you're such a tempting target...
By the way, the answer to your question is that there are several operating systems that let you fix problems without bringing the whole machine to its knees. My very first OS, IBM System/360 MVT, let you change all sorts of stuff "on the fly," including supvervisor call modules -- all you needed to do was down the services affecting the change. Most of the reboots were due to running critical utilities that required that OS MVT be shut down completely to performanc regular maintanence, such as -- wait for it -- disk pack defragmentation.
There were a number of embedded systems in which the majority of the services were disk-resident, being loaded and run on request or on demand, depending on the complexity of the system. Even device drivers (except the hard disk and the console) were loadable modules.
Which leads to the answer that most of you were expecting, but were wondering when I would get to it. Linux has moved to loadable modules for many, many kernel functions, and I expect that the trend will continue rather than abate. The original move to kernel modules was to relieve the strain of building very, very large monolithic kernels for workstation and server environments. The current trend is to let package distributors include everything under the sun, and let the user (or the system, when it is smart enough) load the right module on demand.
I look forward to the day when the only thing that is part of the base kernel is...the console and the disk driver.
Dynamic PDF stuff is *necessary* for those of us writing workflow applications...
Buzzzzzzzzzz! WRONG ANSWER.
Before you reflexively hit the "reply" button, consider that I implemented just this sort of complex form application with lots of dynamic calculation and database interaction, and I don't get even CLOSE to PDF until it's time for the user to print the document...then my web site sends the PDF document (sans attachments, active scripting, whatever) to the Web browser for printing.
Isn't Excel usually the choice for this sort of thing?
There is a saying among old telecom people: "If the telephone company were to sell sushi, they would advertise it as 'Cold, Dead Fish.'"
SBC has once again proven this cold adage with its silence about the switchover from Virtual Circuit/Virtual Path routing of DSL to PPP Aggregation. Nothing on the SBC web site. Nothing from the "customer service" people. Nothing from the ISP, as they are in the dark as much as the customers. As the first northern Nevada customer of DSL (Nevada Bell) I'm facing this changeover and am not happy about it.
The bottom line is that something has to change. The fact is, DSL provisioning is a crock bordering on kludge. To understand this assertion, let's take a look at the overall block diagram for DSL provision:
The DSLAMs connect to an Asynchronous Transfer Mode (ATM) network. In bridging mode (what I and many others in SBC-land who use an independent ISP have today) the data from the DSLAM port makes its way to the ISP using VC/VP channels that are nailed up. Once the circuit is nailed up, the number of CPU cycles required to switch 56-byte packets is very small indeed.
The independent ISP offering DSL connectivity needs a circuit into the ATM network, which for all practical purposes means getting at least a DS3 and an appropriate ATM switch/router. Assuming 40 megabits/s per DS3, you can handle 104 users of 384/128 DSL service, or 27 users of 1.5/384 service, at a time. With 10x oversubscription (low rate) that's 1000 and 270 users. With 50x oversubscription, that's 5200 users. Or is it?
ATM network was designed to handle relatively few channels at high speed. To this end, the address fields in ATM packets are short. With some horsing around, you can get about 1000 circuits per ATM link (and that DS3 counts as an ATM link). That means you cannot use a single channel for all customers. The actual ceiling is lower when you take into account routing problems, with a lower limit of about 250 channels.
The net result is that if you are an ISP you have to have multiple DS3 channels when your user base grows above a certain level. At $5K/month a pop, this limits the ability of the ISPs to control costs per port, which would tend to keep prices high. This is bad for the customer because it keeps prices high, it's bad for the ISP because it keeps costs high, and it's not all that swift for the ILEC...
Ever wonder why it takes so long to provision a bridging DSL circuit? One of the things I found out is that provisioning a single circuit requires an amazing amount of ATM network programming...in a process that is frankly broken. In the old days, BD (before DSL), the number of times the ATM network needed to be configured in a month could be counted on the fingers of one hand, and that hand could have taken a trip through a thresher or combine and still do the job. With the deployment of DSL, the fragility of the tools used to nail up circuits in the ATM network were exposed. There was a time when I could tell that Nevada Bell made another DSL sale: my DSL would stop working. The delay isn't in making the connections, it's finding open channels in every single link to use for the connection. Extensive bookkeeping.
So SBC decided to move to Point-to-Point Protocol Terminated Aggregation, replacing the VP/VC architecture that is currently in use.
So why didn't Ms. Semilof publish all this information? I wanted to know, and called her. She said that SBC wasn't forthcoming with information to give their side of the story. When I tried the usual press channels, I too got stonewalled. It took a call to a good buddy to get the information I need to generate the information showned above. Yep, once again SBC proves that the telephone companies don't know how to market.
Let's look at some of the hot-button items that other people have mentioned in this discussion.
Static IPs: The availability of a fixed IP address depends on how each particular ISP wants to handle things. If the ISP wishes to manage all aspects of authentication, Internet presence, and bandwidth control in the manner they do today, they can use L2TP tunneling over ATM to exchange traffic from user to ISP. The ISP's RADIUS server can serve up "sticky" IPs to emulate the static IP addresses many of us enjoy. It would be up to the customer to keep the PPPoE circuit alive if the customer is running servers at the CPE end of the circuit; not hard, but something on the list of things to do.
MTU problems: PPPoE has a nasty habit of forcing a smaller MSS than anyone expects, because of the packet overhead of PPPoE itself. This has been dealt with in many places, and the solutions are pretty well known.
Performance hits: Well, yes. Adding layers of protocol will cause slowdowns. There is another [active] router in the way, too. Expect ping times to go up. (Sorry, gamers, if you really want good ping time you will be forced to a T1 type solution.) Throughput will be affected, too, although I don't know by how much.
ISP concerns: In the current situation, it's a real hassle to switch from one ISP to another. When I switched away from NBI to my current provider, the process took 7 days, 1 day of which my DSL was completely out. With the changeover to PPPoE, though, the only thing a customer has to do is change the PPPoE login sequence. The ISP never knows the customer is going away until s/he calls to close out the bill. I discount the cost problems associated with the switchover, although most ISPs are running such razor-thin margins that the couple of thousands of dollars this will cost them in new equipment will hurt, hurt, hurt. (The gain is that the ISP can increase the oversubscription rate and thus lower running costs, which makes that couple of thousand in equipment plus technician time an investment.) Another concern is the lost of VPN business, as PPPoE lets an enterprise participate so that telecommuters can log in directlywith the company during the day to work (bypassing the ISP), then log into the ISP at night to play.
Not that it makes much difference, but there are two Robert X. Cringley people in the world. Cram (no, I'm not going to use his real name) wrote the column for InfoWorld for years, then broke away from IW and IDG and took the name to new heights.
Meanwhile, back at InfoWorld, another member of the staff has picked up the monikor and writes it.
That doesn't invalidate your statement, though, that his infamy is due more to who he knows than what he knows -- but the PBS Cringe does know quite a bit on his own. (I used to work with him.)
Not quite. Here is a quote from the page you pointed to:
Session Four:
Taxonomy of OSSD (Nakakoji and Yamamoto). PDF of PowerPoint Slides.
Now, I find I can open this session just fine from a browser in Linux -- no CrushingLicenseWare required.
Now, I have prepared PowerPoint presentations from time to time, and when you shut off all the automation, it's not a bad way to throw something together for a client, and PDF the Notes pages means I can have THEM copy off the notes before I arrive. One time, when the damn projector wouldn't work, I was able (because I prepared transparencies just in case) to grab the ubiquitous overhead projector and make my presentation with no delay. The other presenters were so woebegone because the only thing they had was their laptops, and hadn't sent anything ahead.
There's more to presentations then how you present them, IMHO.
The Internet was pretty well served by the Internet Society, and the engineering details by the Internet Engineering Task Force. Why did the United States government decide THEY had to pick an agency, when the Internet Society is the place that represents ALL the people?
That, of course, meant that the Internet Name Task Force (INTF) (to pick a name) would not be beholden to US trademark law...
The near-violent opposition to
building Yucca Mountain is a result of how the public perceives risk
I hope you read the entire paper that you linked to, because there is an interesting tidbit that I caught immediately.
In the paper, there was a discussion about the seismic activity in Nevada. Now, Californians may scoff at us Neighbors to the East when we talk about earthquakes, but we have 'em. I live at Lake Tahoe, and felt two good-size jolts Saturday just after midnight. The epicenter was less than 15 miles away. That was an interesting wake-up call in and of itself, even though there was no damage.
What caught my eye, though, was that we have a number of active faults in the State of Nevada. Both North and South. So the NIMBY isn't all based on irrational fears.
The paper you linked to pointed this out.
Now, that said, I would be willing as a citizen of the State of Nevada to vote to have the Yucca Mountain storage site opened...as long as the entire Department of Energy, from the top boss to the janitors, were willing to relocate on top of the waste dump site and form a new town. I figure if the watchdogs has a pony in the race they would do a better job than if they stayed put in WashDC.
Did the Coca-Karma story ever make it to the front page of Slashdot? (Using "Search" turned up nothing.)
Should it?
I personally found it a very, very disturbing read, particularly in light of the court cases that affect the Internet that are turning up in the Federal courts.
Portions of my comments will seem redundant,
but I think that there is enough new material for
the entire essay to be useful. I'll see how the
moderators feel about that, of course.:)
My experience extends over three decades, and
I'm here to say that product implementation
reviews are indeed real, in academic and
industrial enviornments.
First off, the review cycle is more than just
reviews of the code -- the best projects had
reviews at every major milestone. This was
especially true of those milestones that required
the ball be handed off to the next group to work
on the project.
Some reviews are major deals: marketing
definition review, product design review,
and development assignment review. Some reviews
are relatively minor, but just as important:
detailed design reviews of hardware and software,
post-implementation reviews ditto, and
integration reviews. The difference is the number
of people involved. Major reviews required a
fairly large conference room, and in the instance
of development assignment the companies I worked
for would book a large ballroom to hold all the
people involved in the project. (Smaller projects
took over the lunchroom.) The other reviews were
two- and three-people affairs: peer review and
critique would have you handing over notes and
source to a peer, and the two of you plus the
supervisor (task lead, group lead, whatever) would
go over the results. Integration reviews may
involve as many as five to ten people, depending
on the level and diversity of the elements being
integrated.
Then there were the bug-track reviews...
By the way, in one small company the peer
reviews were very informal -- sometimes the review would be done over a cup of coffee during a break, especially when the patch was small and localized...but the review was done because it saved so much grief down the road. Especially grief from The Boss.
There was another part to reviews in the small company that was lacking in the large companies I worked for: documentation reviews. Part of the job at the small company was that any change to the code required changes to the corresponding interface, control block, and other design documentation. No change was allowed to go through without the documentation changes being included in the change report. It was the only way for eight programmers to be able to provide maintenance support for 19 man-years of assembler code AND be able to also develop new products.
The best review system? The one that let people learn about and fix mistakes with the minimum of fuss. At ALL levels. One of the first things I learned was that promoting the people who made the fewest mistakes was a recipe for disaster, because it penalized people for being aggressive with implementation so that the company could satisfy customers. Granted, sloppy programming should be frowned on, but the whole point of the review system was to let the system catch any mistakes so each person didn't have to waste time going through code sixteen jillion times to try to find that "last bug". Better to let a new pair of eyes catch it quickly.
When you analyse all the "systems" of developing programs that have been promoted over the past five decades, it comes down to having multiple eyeballs catch the silly stuff and the tricky mistakes, and to not allow sloppy stuff to even enter the stream. For if you know that your code will be seen by others, you take pains to not only get it right but also to get it pretty.
This last, to me, is one of the benefits of OSS development -- you will be judged by a LOT of people.:)
(Before you ask, I've not submitted a bug report yet. I am waiting to get mod privs again so I can better document the problem)
I dread using Opera when Slashdot decides to give me moderator points. Every time that happens, I have to go back to Netscape for a time.
The problem: the little "moderate" drop-down lists start appearing at random in the page when there is a large article and I have mod privs.
It's as though Opera can't handle a very large number of small screen objects. Netscape and (shudder) IE handle the situation just fine.
That isn't a bad-enough thing to make me kick Opera off my system. It's a bad-enough thing that I don't kick off The Competition.
BSD folks do evangalize, don't kid yourself
on
USENIX Reports
·
· Score: 2
But serriously BSD folks dont' hate anything,nor compete, we just love unix.... WE don't hate windows... hate is such a
negative things to do.... dwell on possitive stuff
I have one word for you: BULL
When I was writing my book, Linux IP Stacks Commentary for Coriolis, I took pre-publication copies of the book to the THINK conference and let people there paw through them. Let me summarize the reactions I got, by "class":
Admitted Windows Fanatics (AWFs): "I don't understand any of this. Where is the Visual Basic?"
Macintosh Evangalists: well, they didn't say anything -- they were too busy reading and in most cases taking notes. One of them got violent when someone tried to pry the spiral-bound book out of his hands. Fortunately I was able to satisfy the curiosity of the newcomer with another copy that I had held back for just such an eventuality.
Sun advocates: "Hey, this doesn't look anything like the W. Richard Stevens books." (The pre-publication proofs didn't have the dedication in the front, so at that time no one was aware that we authors had a double dedication: To Jon Postel, Primary Mover and Shaker, and to W. Richard Stevens, the guy "who illustrated TCP/IP" for all of us.)
BSD mavans: "Hey, why are you writing this crap about Linux? BSD is way cooler [I refuse to spell this last word the way the BSDfolk tend to say it] and needs more press!" When I point out that the Stevens books already document the NET3 implementation, which I understood to be the core of the BSD stack, they replied "well, we need more bookshelf space devoted to BSD."
There were other, less-easily catagorized responses, which is why this doesn't add up to 100.:)
"We just love UNIX"? Then why is the ONLY hate mail I've received about the book (aside from regular demands to write a second edition covering the 2.4.0 stack) come from *BSD folk? Why does the only mail that contains the word "traitor" come from people who profess allegiance to the Little Red Devil? NOT ONE MEMBER of the fruit group, not one member of the Gremlins-for-Gates parade, not one member of the three-letter-word SUN fans, not one member of the Amiga/BeOS niche-dwellers have written a discouraging word.
(And the really, really funny postscript to all this: I'm bring up a NetBSD box here for some consulting work, because the client insists on it. No rationale based on fact. I'm not kicking, mind you, because NetBSD will do the job.)
I guess I'm showing my age when I say what I'm about to say.
Remember when the United States Congress lowered the speed limits "to save gas"? When the standard top speed for the Interstates was lowered from 70 mph to 55 mph? And how long (and how many tickets and revenue) it took for the people to make their displeasure known and to get the speed limits raised to something reasonable?
Oh, the rationale for doing it was great. The fuel consumption difference between a "standard" car running at 70 mph and running at 55 mph was significant, and the traffic safety "experts" also predicted that traffic deaths would go down when the speed limit went down.
The "standard" car has for the most part been consigned to the junkyard or the crusher, and the cars on the road have better gas milage and design so that the difference isn't all that great. Further, when the speed limit was raised from 55 to 65, the actual results confounded the "experts" by not going up, and in some places traffic deaths and injuries went down.
What about the problem with "rubbing," where trucks and cars are going at different speeds? Well, in Nevada and California I don't see any difference in speed between autos and trucks, and I don't see the NHP and CHP pulling speeding trucks over, either. I guess the *HP prefer lower traffic deaths to slavish adherence to bad traffic laws.
OK, so I'm currently keeping the lights on by bean-counting and picking up the odd free-lance writing job. So I stop coding for a while. I'm enjoying the vacation, a little bit.
My experience trying to find a technical job? I chase down openings, only to be told that the openings have been pulled "because of the economy." Some companies like talking to us older people, some prefer kids out of school. So be it.
I'm in Nevada, and want no part of the California lifestyle or expense.
I'm a little surprised and a lot concerned that people seem to have forgotten the main reason Stallman holds the views he does. Check some of his earliest stuff and you will see it.
Stallman wants to be able to fix the software he is using when it breaks, and add things the original author missed.
Simple, isn't it?
Next level: how much software have you had to abandon because the author(s) and publisher (a) went out of business and (b) the source wasn't made available? You then had to move on to something else, go through another learning curve, maybe even spend a lot of time converting old data to the new format. That takes time, brothers and sisters, and time is money. And that's where the word "trust" really comes in: are you willing to bet your livelihood that WhizPublisher and BowToProgrammer will be around in the future?
Then there is the other aspect of "trust," that the publisher and the author(s) will continue to maintain the software, fix the bugs you find, and extend the functionality in ways that are useful to you. A couple of examples will serve to illustrate my point:
EXAMPLE 1: Remember troff, the typesetting program developed for Unix? It was a great piece of work, and did things incredibly well. Unfortunately the author died, so much of the incredible work had to be scrapped because no one else could begin to understand the code (not even typesetter manufacturers -- I watched one guy at Varityper try). Now, if the source had been released widely (fat chance, being a bastard child of a utility regulated by the FCC) there might have been enough of a brain trust developed to fully understand the workings of the original program. Instead, some people wrote a work-alike that serves us today, but loses some really nifty code.
EXAMPLE 2: Microsoft WORD has an interesting history, being the first massed-marketed pieces of software whose beta was bound into a mass-market magazine. (PC World, for those who care about such trivia.) Since that time it has become a definition of bloat, yet there are features professional writers have requested of Microsoft that have not been included. Because Microsoft does not make the source available, there is no way for the technically-minded professional writer to add any of those features that would REALLY make life easier. One of those features, a phrase dictionary, is one reason the legal profession sticks with WordPerfect.
We trust vendors to "do the right thing" but they are under no obligation to do so. Those who say "if you don't like it, go write your own" should be aware that the entry cost for writing a word-processor package is very, very high. Indeed, one reason for the Open Source Movement in general and the GNU Public License (not Virus) in particular is to lower the cost of entry by building a collaborative effort to accomplish a task. Divide and Succeed.
And so we now get to the bottom of why Microsoft and Stallman are at odds. Microsoft wants to hold your productivity hostage, so that THEY can release stuff under THEIR terms and to THEIR schedule. Microsoft has no significant competition in a number of markets, so competition won't keep them in line. (Remember the anti-trust suit?) The ONLY significant competition currently in place is GPLed software, because Microsoft can't "embrace and innovate" something that requires they show their cards for all to see.
The BSD and similar licenses are flawed in that Microsoft can "embrace and innovate" to the point that the original code is lost in the jungle of proprietary extensions that Microsoft would add.
By the way, Microsoft isn't the only company that plays the grab-and-obfuscate game, only the most obvious one.
What Microsoft fears most is that other corporations are beginning to "get it," that the large proprietary corporate model is not the only model for ensuring viable support for software products. The distributed development model, specifically OSS protected by the GPL, provides the same advantages as the corporate (or centralized) development model without the "bottleneck effect" of corporate management prejudice and the cost of "buying" 30,000 programmers.
And what about all those programmers? Banished to the bread lines? Guess again. Some of the most lucrative programming is in applications for specific industries. Corporations are looking to combine off-the-shelf components in ways that improve corporate productivity, and are willing to spend the bucks to make that happen. Look at the insurance industry. Look at the food-supply industry. Banking. Finance. Even waste management.
Want to work on something a little more generic? Try embedded-systems programming. There are still microwave oven controllers to be programmed, not to mention metal-forming presses and the like. Who do you think programs the firewall appliances we use on our cable and DSL feeds? Who do you think creates the new gambling machines now showing up in Vegas and Atlantic City? Even my furnace has a microprocessor in it.
And not to worry, e-commerce isn't dead, it was just overblown. There are lots of jobs there.
So stop crying about loss of jobs for programmers with the GPL. If anything, it will increase the number of programming jobs because the tools will be cheap enough to lower the barrier of cost of entry.
THAT is the blessing of the GPL: it lowers the cost of entry into computing for a number of industries.
Like the development of UNIX at AT&T Bell Labs, the FORTRAN development project was done "under the radar," a common enough practice in the '50s and '60s...even the '70s. Projects lasted long enough and required enough resources and money that small productivity projects were easily buried by low and middle management, and more often than not the productivity improvements helped managers bring projects in on time and within budget.
Where do you think a number of our useful tools came from? Many of them got their start as skunk works projects. DDT, as part of Automatic Electric's development of the computer-based switch. LEXX and YACC from UNIX, which made application-specific language much, much easier. And how about the TECO and VI editors?
The only reason that productivity improvements can't be buried these days is that people now schedule with the tools that we already have, and that doesn't leave much room for hiding stuff. Also, the marketing cycle is much, much reduced.
Slashdot Mirror
Hmmm... I remember when Pat Paulson (he of the Smothers Brothers show) was "running" for President. I can see why you might think that this is all a gag to get some attention and to act as a carrier for some of my ideas.
I won't speak for John, he is all too capable (and willing!) to speak for himself.
For my part, I'm serious about serving on the Technical Committee. If I was trying to pull a stunt, the ideal way would be to get a series of articles (paid, of course) in one of the magazines and write my head off. (And I'm ashamed to admit I didn't think of it first.)
As for buying a more up-to-date Macintosh, I don't have any need for it right now. The only thing I use the Mac for is running PageMaker and Illustrator for the few contracts requiring desktop publishing that still come my way. When I have a need for a newer Mac, I'll get one. Until then, I will do just fine with what I have.
I direct your attention to a part of my answer to question six:
Just because the resolution is informal and fast doesn't mean that Microsoft wouldn't have to take heat for the act. It just means that Joe Programmer doesn't have to wade through a court fight in order to learn how to interface with some arcane corner of Windows XP in order to get his product out the door.
Yes, it can be done. It can even be done decently with an extra $1000 or so in recording hardware. But at best it represents a significant degradation in sound quality + a lot of work to get what should be freely available in the first place.
BZZZZZT! $1000 is the wrong answer. (No complaint, though about the second sentence in your answer.)
The Echo Gina24 is a sound card I used that cost me only $500, and the audio quality is professional quality. Echo Digital Audio has other products that may be less expensive but sport similar performance specifications. (Do you really need 8 outputs at the same time? I didn't think so.) At $249 MSRP for the Mia (which means you can prolly find it for a bit less if you look) you can get A/D that surpasses most sound cards that come with PCs today.
When I measured the performance of the Echo Gina24, I was impressed with its 127 dBFS noise floor and 73 dB total harmonic distortion when excited with a 23-tone test signal. (The THD measurement may well have been measuring the performance of the UTC/TRW A1 transformer I was using to balance the signal for injection into the Echo Gina24, which uses balanced inputs.) The real test, though, was with live recording. The Echo Gina24 did as good a job, to my ears, as my Technics 1500US tape deck running at 15 ips recording a classical string quartet from my board and a pair of ATM-31 microphones mounted in a shock-absorbing stereo brace. Better if you consider the tape deck has a 60 dB noise floor.
(BONUS: Linux drivers -- in source -- are supposed to be available in January.)
We have highways closed, chain controls, and a request to not travel if we don't have to. I would think twice before taking my Jeep out.
How would "Ginger" play here? Not at all?
The reason that Dollar Rent-A-Car is asking for thumbprints is because they no longer trust customers to take proper care of their cars and to honor their contracts. How many times have you ridden with a person who is driving aggressively who says, "What do I care, it's a rental"? Not to mention rental cars that are driven to Mexico and sold there.
Trust is a two-way street. I don't know about you, but I am starting to get the idea that the customer is just as likely to be victimized as the vendor. I would be tempted to require exactly the same forms of identification from the clerk helping me that the clerk demands of me. I know why they want a driver's license and credit card: proof that I have passed some state's minimum exam for driving, and proof of payment capability. When they ask for a thumbprint, though, I'd be tempted to whip out my own fingerprint card and request they fill in their full name, current address, and fingerprint. That way, if there is a service problem I can identify the clerk completely. (It could also help to show law enforcement that I am the authorized contract-holder of a rental car by demonstrating that I obtained the contract with a bona-fide agent of the rent-a-car company.)
When the National ID card is instituted, I'm going to ask to see the card of the clerks. Trust is a two-way street.
I'll be brief with the hurdles you will have to overcome:
Motorola holds the base patents on host signal processing, and I'm not sure how the Open Source community can get around those patents. Given Motorola's hard times, I doubt anyone will convince them to provide a royalty-free license to the patent -- especially as they have a soft-modem product in the race. (But then again, they concentrate in the Windows marketplace, so a Linux license could happen...maybe...if the moon is right.)
Then there is the CPU intensive nature of HSP modems. Depending on the quality of modem you are trying to do, CPU horsepower requirements are huge. A bare-bones V.34 implementation requires around 40 MHz of a Pentium-class CPU, while a robust bells-and-whistles version needs something like 90-95 MHz. Don't expect a 486 to handle the load. To be as good as possible on as many platforms as possible, the signal processing code would have to use integer arithmetic instead of floating-point, because the floating-point performance of x86 class processors varies quite a bit from chip type to chip type.
Can it be done? Yes. Can it be done to the expectations of the Linux community? I don't think so, unless one of the big boys (Motorola, Connexent, Nortel, USRobotics) decides to weigh into the market and provide already-developed code and an interface.
...down the drain. Remember when the NCC was the biggest show going, when they were able to completely fill McCormick Place in Chicago, and then dwindled down to 20, count'em 20 tables before the NCC show organizers saw the handwriting on the wall and converted the NCC back to a research-only show?
The Computer Dealers Exposition (that's what COMDEX stands for, boys and girls) outgrew its original charter almost a decade ago -- how many dealers make the trip in? Damn few that I know. Today, it's the press and the companies themselves that make up the bulk of the show, along with employees of the Fortune 5000 companies that are still making enough money to keep the travel budget stuffed.
Speaking of the press, have you noticed that a lot of magazine and newsletter titles have closed in the past 12 months? Have you noticed that the amount of computer-trade ink has fallen off tremendously? For example, we just lost SmartPartner Magazine today, according to reports.
I know quite a number of the members of the press who have decided to forgo the annual pilgrimage to Las Vegas, either because they don't have jobs/assignments or because they want no part of a large, concentrated crowd of people at something that is uniquely United States.
One benefit to the Death Of COMDEX is the end of the maniac development cycle that requires companies to "show something" according to a calendar set by someone else. We may well see all software companies release software when it's ready, not when the booth bimbos hit the floor.
And that would be an improvement.
Oh, you shouldn't hoist yourself that far above the rim of the foxhole, you're such a tempting target...
By the way, the answer to your question is that there are several operating systems that let you fix problems without bringing the whole machine to its knees. My very first OS, IBM System/360 MVT, let you change all sorts of stuff "on the fly," including supvervisor call modules -- all you needed to do was down the services affecting the change. Most of the reboots were due to running critical utilities that required that OS MVT be shut down completely to performanc regular maintanence, such as -- wait for it -- disk pack defragmentation.
There were a number of embedded systems in which the majority of the services were disk-resident, being loaded and run on request or on demand, depending on the complexity of the system. Even device drivers (except the hard disk and the console) were loadable modules.
Which leads to the answer that most of you were expecting, but were wondering when I would get to it. Linux has moved to loadable modules for many, many kernel functions, and I expect that the trend will continue rather than abate. The original move to kernel modules was to relieve the strain of building very, very large monolithic kernels for workstation and server environments. The current trend is to let package distributors include everything under the sun, and let the user (or the system, when it is smart enough) load the right module on demand.
I look forward to the day when the only thing that is part of the base kernel is...the console and the disk driver.
Buzzzzzzzzzz! WRONG ANSWER.
Before you reflexively hit the "reply" button, consider that I implemented just this sort of complex form application with lots of dynamic calculation and database interaction, and I don't get even CLOSE to PDF until it's time for the user to print the document...then my web site sends the PDF document (sans attachments, active scripting, whatever) to the Web browser for printing.
Isn't Excel usually the choice for this sort of thing?
There is a saying among old telecom people: "If the telephone company were to sell sushi, they would advertise it as 'Cold, Dead Fish.'"
SBC has once again proven this cold adage with its silence about the switchover from Virtual Circuit/Virtual Path routing of DSL to PPP Aggregation. Nothing on the SBC web site. Nothing from the "customer service" people. Nothing from the ISP, as they are in the dark as much as the customers. As the first northern Nevada customer of DSL (Nevada Bell) I'm facing this changeover and am not happy about it.
The bottom line is that something has to change. The fact is, DSL provisioning is a crock bordering on kludge. To understand this assertion, let's take a look at the overall block diagram for DSL provision:
The DSLAMs connect to an Asynchronous Transfer Mode (ATM) network. In bridging mode (what I and many others in SBC-land who use an independent ISP have today) the data from the DSLAM port makes its way to the ISP using VC/VP channels that are nailed up. Once the circuit is nailed up, the number of CPU cycles required to switch 56-byte packets is very small indeed.
The independent ISP offering DSL connectivity needs a circuit into the ATM network, which for all practical purposes means getting at least a DS3 and an appropriate ATM switch/router. Assuming 40 megabits/s per DS3, you can handle 104 users of 384/128 DSL service, or 27 users of 1.5/384 service, at a time. With 10x oversubscription (low rate) that's 1000 and 270 users. With 50x oversubscription, that's 5200 users. Or is it?
ATM network was designed to handle relatively few channels at high speed. To this end, the address fields in ATM packets are short. With some horsing around, you can get about 1000 circuits per ATM link (and that DS3 counts as an ATM link). That means you cannot use a single channel for all customers. The actual ceiling is lower when you take into account routing problems, with a lower limit of about 250 channels.
The net result is that if you are an ISP you have to have multiple DS3 channels when your user base grows above a certain level. At $5K/month a pop, this limits the ability of the ISPs to control costs per port, which would tend to keep prices high. This is bad for the customer because it keeps prices high, it's bad for the ISP because it keeps costs high, and it's not all that swift for the ILEC...
Ever wonder why it takes so long to provision a bridging DSL circuit? One of the things I found out is that provisioning a single circuit requires an amazing amount of ATM network programming...in a process that is frankly broken. In the old days, BD (before DSL), the number of times the ATM network needed to be configured in a month could be counted on the fingers of one hand, and that hand could have taken a trip through a thresher or combine and still do the job. With the deployment of DSL, the fragility of the tools used to nail up circuits in the ATM network were exposed. There was a time when I could tell that Nevada Bell made another DSL sale: my DSL would stop working. The delay isn't in making the connections, it's finding open channels in every single link to use for the connection. Extensive bookkeeping.
So SBC decided to move to Point-to-Point Protocol Terminated Aggregation, replacing the VP/VC architecture that is currently in use.
So why didn't Ms. Semilof publish all this information? I wanted to know, and called her. She said that SBC wasn't forthcoming with information to give their side of the story. When I tried the usual press channels, I too got stonewalled. It took a call to a good buddy to get the information I need to generate the information showned above. Yep, once again SBC proves that the telephone companies don't know how to market.
Let's look at some of the hot-button items that other people have mentioned in this discussion.
Static IPs: The availability of a fixed IP address depends on how each particular ISP wants to handle things. If the ISP wishes to manage all aspects of authentication, Internet presence, and bandwidth control in the manner they do today, they can use L2TP tunneling over ATM to exchange traffic from user to ISP. The ISP's RADIUS server can serve up "sticky" IPs to emulate the static IP addresses many of us enjoy. It would be up to the customer to keep the PPPoE circuit alive if the customer is running servers at the CPE end of the circuit; not hard, but something on the list of things to do.
MTU problems: PPPoE has a nasty habit of forcing a smaller MSS than anyone expects, because of the packet overhead of PPPoE itself. This has been dealt with in many places, and the solutions are pretty well known.
Performance hits: Well, yes. Adding layers of protocol will cause slowdowns. There is another [active] router in the way, too. Expect ping times to go up. (Sorry, gamers, if you really want good ping time you will be forced to a T1 type solution.) Throughput will be affected, too, although I don't know by how much.
ISP concerns: In the current situation, it's a real hassle to switch from one ISP to another. When I switched away from NBI to my current provider, the process took 7 days, 1 day of which my DSL was completely out. With the changeover to PPPoE, though, the only thing a customer has to do is change the PPPoE login sequence. The ISP never knows the customer is going away until s/he calls to close out the bill. I discount the cost problems associated with the switchover, although most ISPs are running such razor-thin margins that the couple of thousands of dollars this will cost them in new equipment will hurt, hurt, hurt. (The gain is that the ISP can increase the oversubscription rate and thus lower running costs, which makes that couple of thousand in equipment plus technician time an investment.) Another concern is the lost of VPN business, as PPPoE lets an enterprise participate so that telecommuters can log in directlywith the company during the day to work (bypassing the ISP), then log into the ISP at night to play.
Not that it makes much difference, but there are two Robert X. Cringley people in the world. Cram (no, I'm not going to use his real name) wrote the column for InfoWorld for years, then broke away from IW and IDG and took the name to new heights.
Meanwhile, back at InfoWorld, another member of the staff has picked up the monikor and writes it.
That doesn't invalidate your statement, though, that his infamy is due more to who he knows than what he knows -- but the PBS Cringe does know quite a bit on his own. (I used to work with him.)
Not quite. Here is a quote from the page you pointed to:
Now, I find I can open this session just fine from a browser in Linux -- no CrushingLicenseWare required.
Now, I have prepared PowerPoint presentations from time to time, and when you shut off all the automation, it's not a bad way to throw something together for a client, and PDF the Notes pages means I can have THEM copy off the notes before I arrive. One time, when the damn projector wouldn't work, I was able (because I prepared transparencies just in case) to grab the ubiquitous overhead projector and make my presentation with no delay. The other presenters were so woebegone because the only thing they had was their laptops, and hadn't sent anything ahead.
There's more to presentations then how you present them, IMHO.
KSpline
The Internet was pretty well served by the Internet Society, and the engineering details by the Internet Engineering Task Force. Why did the United States government decide THEY had to pick an agency, when the Internet Society is the place that represents ALL the people?
That, of course, meant that the Internet Name Task Force (INTF) (to pick a name) would not be beholden to US trademark law...
I hope you read the entire paper that you linked to, because there is an interesting tidbit that I caught immediately.
In the paper, there was a discussion about the seismic activity in Nevada. Now, Californians may scoff at us Neighbors to the East when we talk about earthquakes, but we have 'em. I live at Lake Tahoe, and felt two good-size jolts Saturday just after midnight. The epicenter was less than 15 miles away. That was an interesting wake-up call in and of itself, even though there was no damage.
What caught my eye, though, was that we have a number of active faults in the State of Nevada. Both North and South. So the NIMBY isn't all based on irrational fears.
The paper you linked to pointed this out.
Now, that said, I would be willing as a citizen of the State of Nevada to vote to have the Yucca Mountain storage site opened...as long as the entire Department of Energy, from the top boss to the janitors, were willing to relocate on top of the waste dump site and form a new town. I figure if the watchdogs has a pony in the race they would do a better job than if they stayed put in WashDC.
Did the Coca-Karma story ever make it to the front page of Slashdot? (Using "Search" turned up nothing.)
Should it?
I personally found it a very, very disturbing read, particularly in light of the court cases that affect the Internet that are turning up in the Federal courts.
Portions of my comments will seem redundant, but I think that there is enough new material for the entire essay to be useful. I'll see how the moderators feel about that, of course. :)
My experience extends over three decades, and I'm here to say that product implementation reviews are indeed real, in academic and industrial enviornments.
First off, the review cycle is more than just reviews of the code -- the best projects had reviews at every major milestone. This was especially true of those milestones that required the ball be handed off to the next group to work on the project.
Some reviews are major deals: marketing definition review, product design review, and development assignment review. Some reviews are relatively minor, but just as important: detailed design reviews of hardware and software, post-implementation reviews ditto, and integration reviews. The difference is the number of people involved. Major reviews required a fairly large conference room, and in the instance of development assignment the companies I worked for would book a large ballroom to hold all the people involved in the project. (Smaller projects took over the lunchroom.) The other reviews were two- and three-people affairs: peer review and critique would have you handing over notes and source to a peer, and the two of you plus the supervisor (task lead, group lead, whatever) would go over the results. Integration reviews may involve as many as five to ten people, depending on the level and diversity of the elements being integrated.
Then there were the bug-track reviews...
By the way, in one small company the peer reviews were very informal -- sometimes the review would be done over a cup of coffee during a break, especially when the patch was small and localized...but the review was done because it saved so much grief down the road. Especially grief from The Boss.
There was another part to reviews in the small company that was lacking in the large companies I worked for: documentation reviews. Part of the job at the small company was that any change to the code required changes to the corresponding interface, control block, and other design documentation. No change was allowed to go through without the documentation changes being included in the change report. It was the only way for eight programmers to be able to provide maintenance support for 19 man-years of assembler code AND be able to also develop new products.
The best review system? The one that let people learn about and fix mistakes with the minimum of fuss. At ALL levels. One of the first things I learned was that promoting the people who made the fewest mistakes was a recipe for disaster, because it penalized people for being aggressive with implementation so that the company could satisfy customers. Granted, sloppy programming should be frowned on, but the whole point of the review system was to let the system catch any mistakes so each person didn't have to waste time going through code sixteen jillion times to try to find that "last bug". Better to let a new pair of eyes catch it quickly.
When you analyse all the "systems" of developing programs that have been promoted over the past five decades, it comes down to having multiple eyeballs catch the silly stuff and the tricky mistakes, and to not allow sloppy stuff to even enter the stream. For if you know that your code will be seen by others, you take pains to not only get it right but also to get it pretty.
This last, to me, is one of the benefits of OSS development -- you will be judged by a LOT of people. :)
Don't you mean "put the system default config file in /etc/<pgmname>/default.conf and the user-definable overrides in $HOME/.<pgmname>.conf?
(Before you ask, I've not submitted a bug report yet. I am waiting to get mod privs again so I can better document the problem)
I dread using Opera when Slashdot decides to give me moderator points. Every time that happens, I have to go back to Netscape for a time.
The problem: the little "moderate" drop-down lists start appearing at random in the page when there is a large article and I have mod privs.
It's as though Opera can't handle a very large number of small screen objects. Netscape and (shudder) IE handle the situation just fine.
That isn't a bad-enough thing to make me kick Opera off my system. It's a bad-enough thing that I don't kick off The Competition.
I have one word for you: BULL
When I was writing my book, Linux IP Stacks Commentary for Coriolis, I took pre-publication copies of the book to the THINK conference and let people there paw through them. Let me summarize the reactions I got, by "class":
Admitted Windows Fanatics (AWFs): "I don't understand any of this. Where is the Visual Basic?"
Macintosh Evangalists: well, they didn't say anything -- they were too busy reading and in most cases taking notes. One of them got violent when someone tried to pry the spiral-bound book out of his hands. Fortunately I was able to satisfy the curiosity of the newcomer with another copy that I had held back for just such an eventuality.
Sun advocates: "Hey, this doesn't look anything like the W. Richard Stevens books." (The pre-publication proofs didn't have the dedication in the front, so at that time no one was aware that we authors had a double dedication: To Jon Postel, Primary Mover and Shaker, and to W. Richard Stevens, the guy "who illustrated TCP/IP" for all of us.)
BSD mavans: "Hey, why are you writing this crap about Linux? BSD is way cooler [I refuse to spell this last word the way the BSDfolk tend to say it] and needs more press!" When I point out that the Stevens books already document the NET3 implementation, which I understood to be the core of the BSD stack, they replied "well, we need more bookshelf space devoted to BSD."
There were other, less-easily catagorized responses, which is why this doesn't add up to 100. :)
"We just love UNIX"? Then why is the ONLY hate mail I've received about the book (aside from regular demands to write a second edition covering the 2.4.0 stack) come from *BSD folk? Why does the only mail that contains the word "traitor" come from people who profess allegiance to the Little Red Devil? NOT ONE MEMBER of the fruit group, not one member of the Gremlins-for-Gates parade, not one member of the three-letter-word SUN fans, not one member of the Amiga/BeOS niche-dwellers have written a discouraging word.
(And the really, really funny postscript to all this: I'm bring up a NetBSD box here for some consulting work, because the client insists on it. No rationale based on fact. I'm not kicking, mind you, because NetBSD will do the job.)
And what do you propose to have the program do if printf() fails? Print an error message to stdout? ;^)
Answer A: dump core and quit
Answer B: somehow generate a kernel panic
Answer C: print an error to stderr, you dolt!
Answer D: use syslog to record the error
Answer E: avoid using *printf for the security risk that it is.
I guess I'm showing my age when I say what I'm about to say.
Remember when the United States Congress lowered the speed limits "to save gas"? When the standard top speed for the Interstates was lowered from 70 mph to 55 mph? And how long (and how many tickets and revenue) it took for the people to make their displeasure known and to get the speed limits raised to something reasonable?
Oh, the rationale for doing it was great. The fuel consumption difference between a "standard" car running at 70 mph and running at 55 mph was significant, and the traffic safety "experts" also predicted that traffic deaths would go down when the speed limit went down.
The "standard" car has for the most part been consigned to the junkyard or the crusher, and the cars on the road have better gas milage and design so that the difference isn't all that great. Further, when the speed limit was raised from 55 to 65, the actual results confounded the "experts" by not going up, and in some places traffic deaths and injuries went down.
What about the problem with "rubbing," where trucks and cars are going at different speeds? Well, in Nevada and California I don't see any difference in speed between autos and trucks, and I don't see the NHP and CHP pulling speeding trucks over, either. I guess the *HP prefer lower traffic deaths to slavish adherence to bad traffic laws.
OK, so I'm currently keeping the lights on by bean-counting and picking up the odd free-lance writing job. So I stop coding for a while. I'm enjoying the vacation, a little bit.
My experience trying to find a technical job? I chase down openings, only to be told that the openings have been pulled "because of the economy." Some companies like talking to us older people, some prefer kids out of school. So be it.
I'm in Nevada, and want no part of the California lifestyle or expense.
Just my pair-o-pennies(tm)
I'm a little surprised and a lot concerned that people seem to have forgotten the main reason Stallman holds the views he does. Check some of his earliest stuff and you will see it.
Simple, isn't it?
Next level: how much software have you had to abandon because the author(s) and publisher (a) went out of business and (b) the source wasn't made available? You then had to move on to something else, go through another learning curve, maybe even spend a lot of time converting old data to the new format. That takes time, brothers and sisters, and time is money. And that's where the word "trust" really comes in: are you willing to bet your livelihood that WhizPublisher and BowToProgrammer will be around in the future?
Then there is the other aspect of "trust," that the publisher and the author(s) will continue to maintain the software, fix the bugs you find, and extend the functionality in ways that are useful to you. A couple of examples will serve to illustrate my point:
EXAMPLE 1: Remember troff, the typesetting program developed for Unix? It was a great piece of work, and did things incredibly well. Unfortunately the author died, so much of the incredible work had to be scrapped because no one else could begin to understand the code (not even typesetter manufacturers -- I watched one guy at Varityper try). Now, if the source had been released widely (fat chance, being a bastard child of a utility regulated by the FCC) there might have been enough of a brain trust developed to fully understand the workings of the original program. Instead, some people wrote a work-alike that serves us today, but loses some really nifty code.
EXAMPLE 2: Microsoft WORD has an interesting history, being the first massed-marketed pieces of software whose beta was bound into a mass-market magazine. (PC World, for those who care about such trivia.) Since that time it has become a definition of bloat, yet there are features professional writers have requested of Microsoft that have not been included. Because Microsoft does not make the source available, there is no way for the technically-minded professional writer to add any of those features that would REALLY make life easier. One of those features, a phrase dictionary, is one reason the legal profession sticks with WordPerfect.
We trust vendors to "do the right thing" but they are under no obligation to do so. Those who say "if you don't like it, go write your own" should be aware that the entry cost for writing a word-processor package is very, very high. Indeed, one reason for the Open Source Movement in general and the GNU Public License (not Virus) in particular is to lower the cost of entry by building a collaborative effort to accomplish a task. Divide and Succeed.
And so we now get to the bottom of why Microsoft and Stallman are at odds. Microsoft wants to hold your productivity hostage, so that THEY can release stuff under THEIR terms and to THEIR schedule. Microsoft has no significant competition in a number of markets, so competition won't keep them in line. (Remember the anti-trust suit?) The ONLY significant competition currently in place is GPLed software, because Microsoft can't "embrace and innovate" something that requires they show their cards for all to see.
The BSD and similar licenses are flawed in that Microsoft can "embrace and innovate" to the point that the original code is lost in the jungle of proprietary extensions that Microsoft would add.
By the way, Microsoft isn't the only company that plays the grab-and-obfuscate game, only the most obvious one.
What Microsoft fears most is that other corporations are beginning to "get it," that the large proprietary corporate model is not the only model for ensuring viable support for software products. The distributed development model, specifically OSS protected by the GPL, provides the same advantages as the corporate (or centralized) development model without the "bottleneck effect" of corporate management prejudice and the cost of "buying" 30,000 programmers.
And what about all those programmers? Banished to the bread lines? Guess again. Some of the most lucrative programming is in applications for specific industries. Corporations are looking to combine off-the-shelf components in ways that improve corporate productivity, and are willing to spend the bucks to make that happen. Look at the insurance industry. Look at the food-supply industry. Banking. Finance. Even waste management.
Want to work on something a little more generic? Try embedded-systems programming. There are still microwave oven controllers to be programmed, not to mention metal-forming presses and the like. Who do you think programs the firewall appliances we use on our cable and DSL feeds? Who do you think creates the new gambling machines now showing up in Vegas and Atlantic City? Even my furnace has a microprocessor in it.
And not to worry, e-commerce isn't dead, it was just overblown. There are lots of jobs there.
So stop crying about loss of jobs for programmers with the GPL. If anything, it will increase the number of programming jobs because the tools will be cheap enough to lower the barrier of cost of entry.
THAT is the blessing of the GPL: it lowers the cost of entry into computing for a number of industries.
Like the development of UNIX at AT&T Bell Labs, the FORTRAN development project was done "under the radar," a common enough practice in the '50s and '60s...even the '70s. Projects lasted long enough and required enough resources and money that small productivity projects were easily buried by low and middle management, and more often than not the productivity improvements helped managers bring projects in on time and within budget.
Where do you think a number of our useful tools came from? Many of them got their start as skunk works projects. DDT, as part of Automatic Electric's development of the computer-based switch. LEXX and YACC from UNIX, which made application-specific language much, much easier. And how about the TECO and VI editors?
The only reason that productivity improvements can't be buried these days is that people now schedule with the tools that we already have, and that doesn't leave much room for hiding stuff. Also, the marketing cycle is much, much reduced.