SM57's are not generally used for studio recording because they are, frankly, crap. They are mostly used for live performances, where the fact that they are bullet-proof and extremely directional makes up for the fact that they have a lousy frequency response curve, and even there the top bands mostly use Beta-57's (which are hand-sorted SM-57's selected for better frequency response).
You can get a better notion of what mikes are currently preferred for home recording by going over to alt.music.4-track (which despite its name is about home recording of all kinds). It appears that various small and large diaphragm condenser mikes are preferred for most purposes, with vintage mikes such as the SM-57 relegated to those times when you want a vintage sound. Microphones like the Marshal MXL-2001 and the Oktava MC-012 are a bit more expensive than an SM-57 (going for around $200-$300 rather than under $100 like an SM-57), but considering that a band can spend $15,000 for a 3-day recording session at a "real" recording studio, that's hardly a major expense.
You have to remember that Texas is the most anti-employee state in the United States. Most Texas law is aimed at protecting employers from being responsible for their misconduct and at giving employers special rights at the expense of employees. Texas courts have held that employee contracts give employers the right to everything the employee does as a private citizen, even things that are done on private time and have no relationship to the employee's job, even employees' ideas that have never been set down in paper or expressed orally. See http://www.unixguru.com/ for a prime example.
If I were a free software author living in Texas, I most probably would not be able to take a job in the computer industry, because Texas law, the way the Texas courts intepret it, gives employees the rights even to Open Source software that you write in your spare time on your own equipment.
All that object-oriented stuff is yesterday's news, haven't you heard that the latest craze is this new concept called COMPONENT-ORIENTED PROGRAMMING?
Only one problem: It was invented at AT&T Bell Labs in the early 1970's, and implemented as a research testbed called "Unix".
Yeah, today's component-oriented programming uses structs and RPC rather than streams. But it's the same darned thing. In fact, I recently architected a commercial tape backup program as a series of what is basically Python scripts being run as remote commands via a specialized RPC server. It made things *MUCH* easier to test, because I could run them locally (on the tape server, without going through the RPC service) as individual commands with some test inputs and outputs, and thus verify correct operation prior to attempting to connect to them from the client.
If you get a chance, I hid a file called 'TECHFAQ' in the Docs directory on the BRU Professional CD that explains more about the Unix philosophy and how well it applies to The Real World (as vs. to your Microsoft-centric world of threads and sending structs via RPC). I explain the performance disadvantages (minimal), the reliability advantages (extreme), and otherwise talk about The Unix Way (I say I "hid" the file there because until now, I haven't told anybody outside the company that it was there, and it's otherwise buried in a mass of.html files:-).
BTW, this program was written in Python, and makes extensive use of Python's class system and introspection facilities (especially for the subclasses of the master "dbrec" class, many subclasses are about 10 lines long of dbms record definition and that's it). But that does not invalidate the Unix model, but merely extends it.
All child rearing is an exercise in brainwashing. Children are by nature savages that need civilizing to learn things like "share with other children" and "use words, not fists". Anybody who's ever dealt with a toddler (or with unsocialized children raised in dank inner city neighborhoods) knows better to romanticize children.
The only question is with which notions to brainwash them. My personal belief is that children should be brainwashed to think logically, to be inquisitive, and to be self-reliant. Thus my children would not be going to one of these "faith based" programs. However, for those parents with different values, who will raise their children to be narrow-minded religious zealots anyhow, what is the harm of allowing them to send their children to the brainwashing institution of their choice?
In the aftermath of Columbine, I went looking for bomb sites on the Internet. I also went looking for news articles about other school shooting incidents in the United States. Does that mean I meant to blow up a school? No. It means that I was curious about the allegations that the Internet had something to do with all the violence, and decided to see for myself rather than rely upon some talking head on TV to feed me some pre-digested pap.
It is sad that people like you would have expelled me from school for satisfying my curiousity about the real facts. But it doesn't surprise me. There have long been hypocrits more interested in condemning others than in living an upright and helping life, and long ago I learned that such people migrate to positions of power, since such positions allow them to impose their own particular warped believes upon others.
FOIA requests would not allow you to get personal data about children (that would violate the Privacy Act, which superceds the FOIA for personal data). However, the Electronic Privacy Information Center has already put in an FOIA request asking for all memos, directives, etc. involving the purchase and its purpose. To quote EPIC's FOIA request:
"We request copies of all records concerning the Department of
Defense's (DoD) communication with N2H2, Inc. or Roper Starch
Worldwide, the products 'Bess,' 'Class Clicks,' and the 'Roper
Youth Report,' and any similar activities pursued by DoD. This
request includes, but is not limited to: minutes of meetings with
N2H2 and Roper Starch representatives and others, notes,
correspondence, submissions, reports, memoranda, electronic mail,
and staff calendars and appointment books."
It actually never made it to court. I believe that several lawsuits were actually filed, but then the two parties decided to take it to binding arbitration rather than spend decades winding it through the courts. Anderson Consulting won in that they did not have to pay the $15 billion to Arthur Anderson that the partnership agreement said, but in exchange they had to give up the Anderson name. All in all, Anderson Consulting probably won here -- you can buy a lot of name recognition with $15 billion.
Err, no, the Accenture name change is a result of a lawsuit between Arthur Anderson Accounting and Anderson Consulting. One of the provisions of the settlement was that Anderson Consulting had to change their name. In exchange, they did not have to pay Arthur Anderson Accounting $15 billion dollars. It was the surprise settlement of the year 2000, the accounting firm was rubbing their hands together at how much they could soak the consulting firm for in exchange for the consulting firm being able to go free (the contract between the two said the consulting firm had to pay $15 billion, the consulting firm was saying that the accounting firm had violated that contract by starting their own IT consulting firm but the accounting firm said "maybe, but not $15 billion worth!"), and the arbitrator kicked them in the nuts, awarding the accounting firm $0 in damages. Zero. Zilch. None. But the consulting firm had to find a new name, because the arbitrator said "if you are no longer associated with Arthur Anderson, you cannot use their name."
The basic problem: Arthur Anderson Consulting was originally a spinoff of Arthur Anderson Accounting, with its principles being partners in the accounting firm but being IT people rather than accountants. That didn't work too well, because the consulting firm was much more profitable than the accounting firm, yet the partnership agreement said that all partners shared equally in the profits of the combined company. So the IT people wanted out. They did things that Arthur Anderson didn't like, like charge Arthur Anderson major bucks to maintain Arthur Anderson's IT infrastructure. So Arthur Anderson said "Fine, we'll start our own internal IT consulting outfit." So Anderson Consulting said "Wait, no, you have a contract with us." So Arthur Anderson said "You can't use our name anymore, and we're going to sue you for the $15 billion dollars that the contract says you have to pay us if you go your own way." So lawsuits flew, squabbles happened, and eventually they settled it via arbitration. Anderson Consulting owed no $$$ to Arthur Anderson, but in exchange had to change their name. And so it goes in the wonderful wacky world of big business. See this link for a story about the whole deal.
[Note: Details have been changed in order to protect the easily bored. Take nothing for granted, check all facts yourself, yada yada yada.]
The problem with Red Hat Linux -- and all current Linux distributions -- is that Linux is not an operating system. Linux is a kernel. Lots of people have thrown together a bunch of random tools on top of that kernel and sold it as "Linux" (it should probably be called GNU-MIT-BSD-Linux), but it remains a set of random tools tossed on top of that kernel. The problem with a bunch of random tools gathered from all over is that keeping them up-to-date and working well together becomes exponentially harder as the number of tools grow. That, amongst other reasons, is why many commercial software vendors choose to re-invent the wheel rather than use the many available Open Source software libraries such as OpenSSL and libgmp. My own bigmath module may suck compared to libgmp, but I can at least insure that it will continue to work with my application. I have no such assurance with libgmp (and libgmp is hairy enough to compile that I can't assure that old versions of libgmp will continue to work with new versions of the various operating systems we support -- how will it work on an IA-64, for example?).
The wonder is that Red Hat Linux/SuSE Linux/etc. continue to be usable. The fact that they have bugs is undeniable and unavoidable, given the fact that they are random grab-bags of Open Source software, rather than being an operating system. If you want an operating system, get FreeBSD. Of course, this does not assure bug-free operation either (FreeBSD has had some rather annoying spontaneous reboot problems as of late, that keep coming and going), but you'll probably be more stable.
I, of course, run Red Hat Linux 7.0 on my personal system. That's because I love playing with a bunch of unstable bleeding edge software, I'm a techie, it's my curse. That does not mean I would implement Red Hat 7.0 on a production system though.
A team I was on recently finished a project that was 90% written in Python. It was my experience that a) 90% of my time was spent working on the 10% of the code written in "C" (sigh!), and b) I could write about the same amount of Python code in a day as I could "C" code, but the Python code did 10 times more stuff. And a lot of stupid errors like memory leaks and buffer overflows are impossible in Python, so there goes half the reason why the wuftpd motto should be "Root access for all since 1995!". All in all, I don't think we could have completed a project of that scale if it had been written in "C" or C++... there wasn't enough of us, or enough time, to write 10 times more code.
The main reason we chose Python was because a) the runtime system was time-tested and well debugged on all our target platforms (say that about any JVM out there!), b) it already had good low-level access to the OS without having to do anything fancy, and c) it was easy to drop to low-level "C" code whenever it was absolutely necessary for performance (we have five new Python classes written in "C" to speed up particularly hairy operations, as well as some additional "C" helper programs). The only problem we experienced with Python was a conflict between Python threading and the GTK+ toolkit (accessed via PyGTK)... disabling threading in Python fixed that.
All in all, I'd recommend the experience -- it taught me that "C" is great for small programs, but for large programs a "real" language makes things *MUCH* easier. (And don't talk to me about C++, C++ pretends to be a real language but at its heart is still syntactic sugar on top of "C"). While I have some gripes about Python (like, I want variable declarations so that a tpyo does not create a new variable and make me tear out my hair for hours trying to figure out why my progrma does not work!), I will never again voluntarily use "C" or C++ for any large project. (Famous last words, karma says that my next project will be in C++:-).
If you don't know what needs programming, how do you know what you need to write? And how do you know that what you produce will be usable?
A genius programmer once showed me a mockup of a GUI for a tape backup product. Now, I had used tape backup products back in my sysadmin days, but was definitely an end user, not an expert on the subject. His screens were incomprehensible to poor sysadmin me. I shook my head and said "I don't know how to use that." He called me stupid and said it was intuitive. It took two senior programmers and two managers to convince him that his work of genius was not acceptable because nobody without his genius could understand it.
If they had just put this guy in a back room and told him to program the bloody thing, well, it would have wasted three months worth of time for an incomprehensible product. Sometimes it's important to get non-techie input into things -- or at least get the input of people who don't know anything at all about that kind of product (I knew very little about tape backup products, except "you stick a tape in, click a couple of buttons, and it does something useful").
When I was doing school administration software, the first thing I'd do when writing a new module was track down a couple of my pet school administrators, arrange a meeting with them, and go over the specs, proposed screen layouts, etc. to make sure that a) it met their needs, and b) that the screen layouts looked intuitive and reasonable to their non-techie eyes. One time I got a design torpedoed three days before I had to have working code turned in (state deadline). To say I was upset was an understatement -- that was the last time I did something without running it by the non-techies *EARLY* in the design process! (In case you're wondering -- I consumed mass quantities of coffee, worked for almost 72 hours straight, and hit the deadline, but I was extremely scared driving the final product to the office that I was going to crash into something because I was starting to see things that didn't exist by then).
I suspect that most of the problems that people have with non-techie input comes from lack of involvement with the end users at an early stage of the product design. Well, and non-techie managers attempting to tell you how to code (or managers who aren't in your direct line of command trying to tell you that they need buzzword X, Y, and Z... at that time, involve your own engineering manager to explain that features X, Y, and Z will be in version 2.0:-). But if your engineering manager is part of the problem rather than part of the solution, it's time to get another job -- not time to dismiss the importance of outside input.
What I have to say is that you are full of [BLEEP!]. Software engineering is Gant charts and schedules and such, of course, and those aren't much fun -- for the project leader. But if the project architect has done his job right, and if the project leads are doing their jobs right, and if they're allowing their underlings to do THEIR jobs right, it all works out quite well.
Here's the way it worked in the last project I worked on: I had a document describing how I wanted things to work. I had charts describing the pieces of the project and how they fit together, as big block diagrams. We as a team decided what information needed to be maintained, and a database schema that would maintain that information (okay, so I provided the initial scheme and chart, but the final result deviated in some significant ways from my original). Then team members chose pieces of the project (or were occasionally assigned pieces, as needed), and wrote up how their pieces worked and what components were needed to make their pieces work (we had a template to use for this, but there was plenty of freedom to stray outside the lines). Then we wrote it, and had a blast doing it. I remember the guy in the cubicle around the corner asking me how I wanted a certain component that was in his sandbox implemented. I shrugged, said "Don't ask me, you're the owner of that subsystem. Just document the inputs and outputs so I know how to call your component, and leave the document on my desk." (I read the document to make sure the component did what I needed, of course, but usually that wasn't a problem -- by that time we all pretty well knew what we were doing). He was, like, boggled. I overheard him later saying that he'd never worked on a project before where he had such latitude, and that it was the most fun he'd ever had in any job anywhere. Yes, there was a daily meeting to check the charts and check each other's progress to make sure that each member was working on the most timely component in his sandbox (because there WERE dependencies between our components, and thus ordering did matter), and yes, we did document everything's interfaces (we had a template), but mostly it was just plain fun. Helps to have good team members too, folks who know their business and don't need hand-holding... I wouldn't have said the above if I hadn't known that this guy had 6 years of programming experience and knew the ropes. But even the lesser programmers ended up having more fun than in the typical blah kind of project where they were basically told "do this this and this" and given no lattitude.
I've been a team co-leader and had to deal with those programmers who don't have CS degrees. There are a few, a very few, who figure out that they don't know anything and who take steps to remedy it, but most are legends in their own mind. There was one programmer, for example, who wanted to argue with the two most seniormost software engineers in the company and the project manager because we wanted a generic database access class and he felt that was too much work ("each of these classes I'm writing only need one line of SQL code per class! Why do you want me to go to all the trouble of writing a generic database access module?"). Now, the three of us combined had close to 40 years in the computer business and had been through enough failed projects to know what happens when you tie your code to one particular database (hint: what happens when you change databases? Which, BTW, we did, close to the end of the project, when the original database did not meet performance requirements, but that was no problem because we had the database access class!), but this arrogant guy with no CS degree thought he knew better than all of us. Brilliant guy, actually, but a legend in his own mind, and refused to listen to experience, and argued about anything and everything even if it was something he knew absolutely nothing about. Maybe one day he'll learn. But I doubt it.
And I have other examples. Example after example after example. But I don't feel like repeating myself.
Note that I'm not saying that ALL programmers without degrees are arrogant know-it-alls who know nothing about software engineering and refuse to listen to those of us with the experience to know better. Just that, in my experience, that's the majority of programmers without degrees. These jerks aren't going to learn software engineering, because they don't think it's important. They think that creating programs is a matter of sitting down and writing a program, and all that "software engineering" stuff is just a waste of time. And when the software engineers running the project ask them to do something because it's a good engineering practice (such as, e.g., abstracting out the database access into a seperate class to isolate the program from the underlying database), they throw a fit because a) they don't understand abstraction, and b) they think they know better than us. Then they go complain to our bosses that we're not listening to them (when it's actually the other way around -- we tell them why we want, say, an abstract database access class, and they refuse to believe that our reasons are important). Poor little geeks, upset because we want them to follow good engineering practice instead of letting them hack unreadable unmaintainable spaghetti code all day. Sob sob sob.
Okay, now that I've raised the flame quotient...
BTW: On how to make software that doesn't suck: My advice is componetize, componetize, componetize. If the pieces of the project are individually testable parts rather than being part of a huge monolithic program, you have a chance (BARELY a chance) of making the thing actually work. I say "BARELY a chance" because over 80% of projects end up failing. Sad, but true, software engineering today is taught the hard way -- through exposing programmers to failure at every opportunity -- rather than in a formal way that would avoid all that waste of time, effort, and money. So I guess you could say that the definition of a software engineer is: "A programmer who has suffered through enough failed projects to know better."
If you do not accept the GPL, then you have no right to modify or distribute the program. Has nothing to do with click-thrus. Click-thrus take rights away from those provided by copyright law, while GPL adds rights to those provided by copyright law (specifically, the right to modify and distribute the program). If you choose not to accept the GPL, you're stuck with what copyright law says -- which is that you cannot distribute the program.
'mtx', 'tapeinfo', etc. are called from within BRU Professional (via ye olde fork/exec). No more a violation of GPL than calling GNU 'ls' from within a shell script that installs your proprietary program.
I am the maintainer for mtx, the Linux/Unix tape library control program. One of the first things I did with 'mtx' when I took over its maintenance was strip out the pieces that did the actual controlling of the hardware into a library module 'mtxl.c'. However, each and every program that I have written since then that uses that module -- 'tapeinfo', 'loaderinfo', and 'scsitape' -- has been required to be published under the GPL, because 'mtxl.c' (as a bunch of GPL'ed code stripped out of an existing GPL'ed program) requires that all programs that use it be themselves GPL'ed.
The rule (well, the law, I should say) is that if the library is GPL'ed, then programs that use the library must be GPL'ed. If you don't agree to that, you have no right under copyright law to use the library, and can be sued for a $100,000 copyright violation for each instance of shipping a proprietary product that uses the library (so if you sold 100,000 copies of your program... whoa, can you count that high?!).
Note, however, that I can use 'tapeinfo', 'loaderinfo', and 'scsitape' from a proprietary product without the proprietary product itself being GPL'ed. What matters is that these are complete, useful programs. The fact that they can be called from shell scripts or Python scripts that are not themselves GPL'ed is irrelevant.
It is clear that if you create a program that uses GPL'ed code, you must release that program under the GPL.
But this is Unix. The Unix philisophy is "many small programs chained together". The Unix philosophy is of many small independent components, each of which is independently useful, glued together by an overarching "glue" program (often written in a scripting language, but not necessarily).
I think it's plenty clear that releasing independently-usable programs under the GPL satisfies all terms of the GPL, as well as adding to the large stock of GPL'ed software already out there. The operative phrase is INDEPENDENTLY USABLE. If it requires proprietary components in order to be useful, then it's not in compliance with the GPL. So if I create a new encryption program, let's called it, say, 'aescrypt', so that I can transfer encrypted passwords around my network by calling it from within my own proprietary programs, it is in compliance with the GPL as long as I can post it on Freshmeat and other people can download it and use it in their own scripts and programs. But if I made it require a special file or a special proprietary program in order to be useful, well, that's not in compliance with the GPL. Deciding exactly how independent a program must be in order to qualify as being a GPL'ed program is something that requires some thought. It's obvious that "aescrypt", for example, could be GPL'ed (we actually released it under the BSD license, but that's another story). But if we took the GNU "df" program and modified it to produce output that was easily parsed by shell scripts but that is not easily humanly readable, does the resulting program comply with the GPL? I say yes, because other shell scripts that need file system listings can use "sdf" ("shell df") and thus it is independently useful. But others may disagree.
RMS has covered this to a certain extent in his comments on calling GPL'ed CORBA components from proprietary programs. He's for it -- as long as the CORBA components are independently usable components (i.e., that don't require non-GPL'ed components in order to run). The goal is to increase the number of GPL'ed programs and components in the world so that he never has to use a proprietary program, not necessarily to squash all proprietary vendors (though he disapproves of proprietary vendors, obviously!) But I'm sure there's some possibilities in there that RMS is still thinking about.
One thing to bear in mind is that this is Unix. Unix was conceived under the principle of "many small programs chained together". There is no reason why the communications protocols involved in a chess game cannot be created that same way. If I can do it for a tape server, I don't see why it couldn't be done for a chess server. And if the program is many small programs chained together, then those small programs that happen to include GPL'ed code can be released as GPL'ed programs without compromising the closed-source nature of the rest of the system. Everybody wins. People who want more GPL'ed software get more GPL'ed software, you get to use that GPL'ed software yourself from your non-GPL'ed software, and you get a more reliable architecture to boot (since a Unix-style "many small programs chained together" system can be MUCH more easily tested than some big monolithic monstrosity -- each component can be tested independently to insure proper operation).
If you look under my name at Freshmeat, you'll see that I "officially" have three projects. Each of those projects is actually an Open Source program that was either adapted from an already-GPL'ed program for use in a closed source program, or was created as a component for a Closed Source program. Thus 'aescrypt', 'mtx', and 'ocotillo' all exist as stand-alone programs usable by other people, but also are used as components in our product to handle encryption and tape library management.
While RMS would have preferred that we open sourced the whole application, the fact that we have released independently-usable programs as a result of our work is enough to satisfy the GPL and stave off a little of the grumbling. That is also why RMS says it's okay to call GPL'ed CORBA components from proprietary programs -- every little piece that's GPL'ed helps further his goal of being able to do everything with free software. The requirement is that the GPL'ed component be a complete, independently usable program or component -- this gives RMS something that he can personally run as part of his totally-free system. Just releasing a few unusable fragments of code (or a CORBA component that requires proprietary components in order to be useful) won't do the job.
Regarding network protocols, I wouldn't use 'ssh' or 'openssh' anyhow. Investigate 'openssl', and write your own protocol based upon it. I could not use OpenSSL for the closed source project that I worked on because of the RSA patent (which is now expired so it's not a problem for you, back then it WAS a problem) so I wrote my own Diffie-Hellman based protocol, but nobody should have to go through that hassle nowdays.
The only "great" teacher I had in a computer science course was my Graphics instructor, Dennis M. This was a guy who wasn't supposed to be a professor at the university because he'd gotten his doctorate there (it was against university policy to hire its own), but because he brought in $2M in grant money each year, they broke the rules for him. But computer graphics really isn't like anything else in the computer biz -- it's almost entirely applied analytic geometry, i.e., it's pretty much a math class. He made it understandable when the graphics instructor I'd had the previous semester hadn't had a clue how to teach the material (I dropped the previous instructor's class 2 weeks in because it was obvious I wasn't going to learn anything from that instructor -- the university charged the same for signing up for 18 hours as for signing up for 12, so I usually over-subscribed and dropped the lamer teachers' courses as soon as it became obvious).
My first-year computer science TA was pretty good too. He immediately saw that I was wasting my time with the little lamer programs in that required class, and set me up with something more challenging.
In high school, I can't think of many good instructors that I had. They were mostly dedicated and sincere enough, but when there's 35 kids in the class, there's limits to what you can do. Probably the best was my freshman English and sophomore Ethics instructor (same guy). This was at a Catholic school and he'd been at a Jesuit seminary for a while before deciding that wasn't what he wanted to do with his life, then he'd spent time working as a counsellor at drug treatment programs, then he decided to teach. It still amazes me that they let him teach what he taught -- for example, in one unit, talking about the ethics of having sex, including frank talk about masturbation, birth control and sexually transmitted disease, at a CATHOLIC SCHOOL? He was constantly challenging kids to think, and was a prime rebuttal to the theory that a religious viewpoint upon life was incompatible with an intellectual life. While I am no longer a practicing Catholic, I must admit that experiencing Jesuit thought first-hand made me respect the Catholic church a lot more than some of those blatantly anti-intellectual religions out there (see the footer on my home page for what I think of the Christian Coalition and its ilk:-).
Oh, regarding that "timeless wisdom etched in stone" bit -- probably the best thing this guy taught was that much of what's tossed out as "timeless wisdom etched in stone" is no more etched in stone than anything else. I guess this was under the philosophy of "toss out a morsel of timeless wisdom and you've taught a man a morsel, but teach a man to think, and you've put him on the road to wisdom".
In the old days, the major backbone NOC's kept a list of open trouble tickets available on the public Internet. So if you're doing a traceroute through Dallas and find that the Atlanta-Dallas route in the UUNET backbone is flapping (thus keeping all of your Shreveport customers from being able to reach any web site on the East Coast), you could actually go to noc.uu.net and find out whether they knew about it. If they knew about it, great. If not, you called up your local ISP, they contacted UUNET, and it got reported and fixed.
Today, if something goes down, you have no idea whether anybody knows about it or not. None of the backbone NOC's post trouble tickets to the open Internet anymore. Apparently they don't want anybody to know how lousy their service is. The sad thing is that by keeping these secret, they've caused a thousand-fold escalation in the number of phone calls coming in saying "Hey, did you know your route between Dallas and Atlanta is flapping?". Aside from convincing the rest of us that they have something to hide, of course -- but if you're part of an oligarchy that has collectively decided (illegal cartel?) to screw the customer, there isn't much I can do about you deciding to be a deceitful scumbag (well, I could create a new backbone, but that isn't exactly cost-effective).
I see. So in this company, service is what a stallion does to a mare.
Which makes it just like 99.999999% of other ISP's. I do wish that people knew the meaning of the term "customer service", but must admit that it will not happen within my lifetime -- it's too easy to make money nowadays by being a complete asshole jerk. Just advertise like hell, make sure that potential competitors can't get into the market by using monopolistic practices such as exclusive contracts, and voila, you have a company like @Home. No need to have customer service -- in fact, the harder you make it for your customers to get service, the better, because then you don't have to pretend to care.
If a competing ISP could get into my local cable drop, I'd switch ISP's in a minute. But by signing monopolistic exclusive contracts with local cable providers, @Home can continue providing lousy service while not giving a damn.
I remember when you could go straight to the NOC's web site and find out what tickets were open. That headed off a lot of geeks calling in with "did you know you had a routing loop between router-xyz.dallas.net and router-zzzy.dallas.net?" You looked at the NOC's ticket list, said to yourself "Oh, they already know about that", and went your way. Today you can't do that, because the national service providers don't want you to know how crappy their service is. The sad thing is that this attempt at decieving us has convinced us that they have something to hide.
Oh well. I guess the days when producing a good product at a good price in a friendly manner was the key to success are long gone. Today the goal appears to produce the shoddiest product for the highest price while providing the crappiest service -- then advertise the hell out of it, while using monopolistic tactics to drive the guys who do believe in producing good products out of business. Sort of like Microsoft did to folks like Digital Research, Quarterdeck (remember DesqView?), and (soon) Apple.
Don't assume that the Pentagon is full of war mongers. These people studied military history and continue to study it in real life. They know that war is hell (as William Tecumseh Sherman so pithily stated), and they generally advise to *NOT* send in the troops if there is any alternative at all. It was Clinton who decided to send in the military in Serbia, not the Pentagon, whose main influence was getting Clinton to allow them to target infrastructure with high altitude flights (fewer losses that way) rather than shove American military aircraft and soldiers into a meatgrinder war.
I've known a lot of retired military. They think this way. They're not war mongers -- they know that friends and subordinants will die if the country goes to war. They are prepared to pay that price, but not lightly, and not on a whim, and they certainly aren't going to advise going to war when there's an alternative.
Slashdot Mirror
You can get a better notion of what mikes are currently preferred for home recording by going over to alt.music.4-track (which despite its name is about home recording of all kinds). It appears that various small and large diaphragm condenser mikes are preferred for most purposes, with vintage mikes such as the SM-57 relegated to those times when you want a vintage sound. Microphones like the Marshal MXL-2001 and the Oktava MC-012 are a bit more expensive than an SM-57 (going for around $200-$300 rather than under $100 like an SM-57), but considering that a band can spend $15,000 for a 3-day recording session at a "real" recording studio, that's hardly a major expense.
-E
If I were a free software author living in Texas, I most probably would not be able to take a job in the computer industry, because Texas law, the way the Texas courts intepret it, gives employees the rights even to Open Source software that you write in your spare time on your own equipment.
-E
Only one problem: It was invented at AT&T Bell Labs in the early 1970's, and implemented as a research testbed called "Unix".
Yeah, today's component-oriented programming uses structs and RPC rather than streams. But it's the same darned thing. In fact, I recently architected a commercial tape backup program as a series of what is basically Python scripts being run as remote commands via a specialized RPC server. It made things *MUCH* easier to test, because I could run them locally (on the tape server, without going through the RPC service) as individual commands with some test inputs and outputs, and thus verify correct operation prior to attempting to connect to them from the client.
If you get a chance, I hid a file called 'TECHFAQ' in the Docs directory on the BRU Professional CD that explains more about the Unix philosophy and how well it applies to The Real World (as vs. to your Microsoft-centric world of threads and sending structs via RPC). I explain the performance disadvantages (minimal), the reliability advantages (extreme), and otherwise talk about The Unix Way (I say I "hid" the file there because until now, I haven't told anybody outside the company that it was there, and it's otherwise buried in a mass of .html files :-).
BTW, this program was written in Python, and makes extensive use of Python's class system and introspection facilities (especially for the subclasses of the master "dbrec" class, many subclasses are about 10 lines long of dbms record definition and that's it). But that does not invalidate the Unix model, but merely extends it.
-E
The only question is with which notions to brainwash them. My personal belief is that children should be brainwashed to think logically, to be inquisitive, and to be self-reliant. Thus my children would not be going to one of these "faith based" programs. However, for those parents with different values, who will raise their children to be narrow-minded religious zealots anyhow, what is the harm of allowing them to send their children to the brainwashing institution of their choice?
-E
It is sad that people like you would have expelled me from school for satisfying my curiousity about the real facts. But it doesn't surprise me. There have long been hypocrits more interested in condemning others than in living an upright and helping life, and long ago I learned that such people migrate to positions of power, since such positions allow them to impose their own particular warped believes upon others.
-E
"We request copies of all records concerning the Department of Defense's (DoD) communication with N2H2, Inc. or Roper Starch Worldwide, the products 'Bess,' 'Class Clicks,' and the 'Roper Youth Report,' and any similar activities pursued by DoD. This request includes, but is not limited to: minutes of meetings with N2H2 and Roper Starch representatives and others, notes, correspondence, submissions, reports, memoranda, electronic mail, and staff calendars and appointment books."
-E
-E
-E
[Note: Details have been changed in order to protect the easily bored. Take nothing for granted, check all facts yourself, yada yada yada.]
-E
The wonder is that Red Hat Linux/SuSE Linux/etc. continue to be usable. The fact that they have bugs is undeniable and unavoidable, given the fact that they are random grab-bags of Open Source software, rather than being an operating system. If you want an operating system, get FreeBSD. Of course, this does not assure bug-free operation either (FreeBSD has had some rather annoying spontaneous reboot problems as of late, that keep coming and going), but you'll probably be more stable.
I, of course, run Red Hat Linux 7.0 on my personal system. That's because I love playing with a bunch of unstable bleeding edge software, I'm a techie, it's my curse. That does not mean I would implement Red Hat 7.0 on a production system though.
-Eric
The main reason we chose Python was because a) the runtime system was time-tested and well debugged on all our target platforms (say that about any JVM out there!), b) it already had good low-level access to the OS without having to do anything fancy, and c) it was easy to drop to low-level "C" code whenever it was absolutely necessary for performance (we have five new Python classes written in "C" to speed up particularly hairy operations, as well as some additional "C" helper programs). The only problem we experienced with Python was a conflict between Python threading and the GTK+ toolkit (accessed via PyGTK)... disabling threading in Python fixed that.
All in all, I'd recommend the experience -- it taught me that "C" is great for small programs, but for large programs a "real" language makes things *MUCH* easier. (And don't talk to me about C++, C++ pretends to be a real language but at its heart is still syntactic sugar on top of "C"). While I have some gripes about Python (like, I want variable declarations so that a tpyo does not create a new variable and make me tear out my hair for hours trying to figure out why my progrma does not work!), I will never again voluntarily use "C" or C++ for any large project. (Famous last words, karma says that my next project will be in C++ :-).
-E
A genius programmer once showed me a mockup of a GUI for a tape backup product. Now, I had used tape backup products back in my sysadmin days, but was definitely an end user, not an expert on the subject. His screens were incomprehensible to poor sysadmin me. I shook my head and said "I don't know how to use that." He called me stupid and said it was intuitive. It took two senior programmers and two managers to convince him that his work of genius was not acceptable because nobody without his genius could understand it.
If they had just put this guy in a back room and told him to program the bloody thing, well, it would have wasted three months worth of time for an incomprehensible product. Sometimes it's important to get non-techie input into things -- or at least get the input of people who don't know anything at all about that kind of product (I knew very little about tape backup products, except "you stick a tape in, click a couple of buttons, and it does something useful").
When I was doing school administration software, the first thing I'd do when writing a new module was track down a couple of my pet school administrators, arrange a meeting with them, and go over the specs, proposed screen layouts, etc. to make sure that a) it met their needs, and b) that the screen layouts looked intuitive and reasonable to their non-techie eyes. One time I got a design torpedoed three days before I had to have working code turned in (state deadline). To say I was upset was an understatement -- that was the last time I did something without running it by the non-techies *EARLY* in the design process! (In case you're wondering -- I consumed mass quantities of coffee, worked for almost 72 hours straight, and hit the deadline, but I was extremely scared driving the final product to the office that I was going to crash into something because I was starting to see things that didn't exist by then).
I suspect that most of the problems that people have with non-techie input comes from lack of involvement with the end users at an early stage of the product design. Well, and non-techie managers attempting to tell you how to code (or managers who aren't in your direct line of command trying to tell you that they need buzzword X, Y, and Z... at that time, involve your own engineering manager to explain that features X, Y, and Z will be in version 2.0 :-). But if your engineering manager is part of the problem rather than part of the solution, it's time to get another job -- not time to dismiss the importance of outside input.
-E
Here's the way it worked in the last project I worked on: I had a document describing how I wanted things to work. I had charts describing the pieces of the project and how they fit together, as big block diagrams. We as a team decided what information needed to be maintained, and a database schema that would maintain that information (okay, so I provided the initial scheme and chart, but the final result deviated in some significant ways from my original). Then team members chose pieces of the project (or were occasionally assigned pieces, as needed), and wrote up how their pieces worked and what components were needed to make their pieces work (we had a template to use for this, but there was plenty of freedom to stray outside the lines). Then we wrote it, and had a blast doing it. I remember the guy in the cubicle around the corner asking me how I wanted a certain component that was in his sandbox implemented. I shrugged, said "Don't ask me, you're the owner of that subsystem. Just document the inputs and outputs so I know how to call your component, and leave the document on my desk." (I read the document to make sure the component did what I needed, of course, but usually that wasn't a problem -- by that time we all pretty well knew what we were doing). He was, like, boggled. I overheard him later saying that he'd never worked on a project before where he had such latitude, and that it was the most fun he'd ever had in any job anywhere. Yes, there was a daily meeting to check the charts and check each other's progress to make sure that each member was working on the most timely component in his sandbox (because there WERE dependencies between our components, and thus ordering did matter), and yes, we did document everything's interfaces (we had a template), but mostly it was just plain fun. Helps to have good team members too, folks who know their business and don't need hand-holding... I wouldn't have said the above if I hadn't known that this guy had 6 years of programming experience and knew the ropes. But even the lesser programmers ended up having more fun than in the typical blah kind of project where they were basically told "do this this and this" and given no lattitude.
-E
And I have other examples. Example after example after example. But I don't feel like repeating myself.
Note that I'm not saying that ALL programmers without degrees are arrogant know-it-alls who know nothing about software engineering and refuse to listen to those of us with the experience to know better. Just that, in my experience, that's the majority of programmers without degrees. These jerks aren't going to learn software engineering, because they don't think it's important. They think that creating programs is a matter of sitting down and writing a program, and all that "software engineering" stuff is just a waste of time. And when the software engineers running the project ask them to do something because it's a good engineering practice (such as, e.g., abstracting out the database access into a seperate class to isolate the program from the underlying database), they throw a fit because a) they don't understand abstraction, and b) they think they know better than us. Then they go complain to our bosses that we're not listening to them (when it's actually the other way around -- we tell them why we want, say, an abstract database access class, and they refuse to believe that our reasons are important). Poor little geeks, upset because we want them to follow good engineering practice instead of letting them hack unreadable unmaintainable spaghetti code all day. Sob sob sob.
Okay, now that I've raised the flame quotient...
BTW: On how to make software that doesn't suck: My advice is componetize, componetize, componetize. If the pieces of the project are individually testable parts rather than being part of a huge monolithic program, you have a chance (BARELY a chance) of making the thing actually work. I say "BARELY a chance" because over 80% of projects end up failing. Sad, but true, software engineering today is taught the hard way -- through exposing programmers to failure at every opportunity -- rather than in a formal way that would avoid all that waste of time, effort, and money. So I guess you could say that the definition of a software engineer is: "A programmer who has suffered through enough failed projects to know better."
-E
-E
'mtx', 'tapeinfo', etc. are called from within BRU Professional (via ye olde fork/exec). No more a violation of GPL than calling GNU 'ls' from within a shell script that installs your proprietary program.
The rule (well, the law, I should say) is that if the library is GPL'ed, then programs that use the library must be GPL'ed. If you don't agree to that, you have no right under copyright law to use the library, and can be sued for a $100,000 copyright violation for each instance of shipping a proprietary product that uses the library (so if you sold 100,000 copies of your program... whoa, can you count that high?!). Note, however, that I can use 'tapeinfo', 'loaderinfo', and 'scsitape' from a proprietary product without the proprietary product itself being GPL'ed. What matters is that these are complete, useful programs. The fact that they can be called from shell scripts or Python scripts that are not themselves GPL'ed is irrelevant.
-E
But this is Unix. The Unix philisophy is "many small programs chained together". The Unix philosophy is of many small independent components, each of which is independently useful, glued together by an overarching "glue" program (often written in a scripting language, but not necessarily).
I think it's plenty clear that releasing independently-usable programs under the GPL satisfies all terms of the GPL, as well as adding to the large stock of GPL'ed software already out there. The operative phrase is INDEPENDENTLY USABLE. If it requires proprietary components in order to be useful, then it's not in compliance with the GPL. So if I create a new encryption program, let's called it, say, 'aescrypt', so that I can transfer encrypted passwords around my network by calling it from within my own proprietary programs, it is in compliance with the GPL as long as I can post it on Freshmeat and other people can download it and use it in their own scripts and programs. But if I made it require a special file or a special proprietary program in order to be useful, well, that's not in compliance with the GPL. Deciding exactly how independent a program must be in order to qualify as being a GPL'ed program is something that requires some thought. It's obvious that "aescrypt", for example, could be GPL'ed (we actually released it under the BSD license, but that's another story). But if we took the GNU "df" program and modified it to produce output that was easily parsed by shell scripts but that is not easily humanly readable, does the resulting program comply with the GPL? I say yes, because other shell scripts that need file system listings can use "sdf" ("shell df") and thus it is independently useful. But others may disagree.
RMS has covered this to a certain extent in his comments on calling GPL'ed CORBA components from proprietary programs. He's for it -- as long as the CORBA components are independently usable components (i.e., that don't require non-GPL'ed components in order to run). The goal is to increase the number of GPL'ed programs and components in the world so that he never has to use a proprietary program, not necessarily to squash all proprietary vendors (though he disapproves of proprietary vendors, obviously!) But I'm sure there's some possibilities in there that RMS is still thinking about.
-E
-E
While RMS would have preferred that we open sourced the whole application, the fact that we have released independently-usable programs as a result of our work is enough to satisfy the GPL and stave off a little of the grumbling. That is also why RMS says it's okay to call GPL'ed CORBA components from proprietary programs -- every little piece that's GPL'ed helps further his goal of being able to do everything with free software. The requirement is that the GPL'ed component be a complete, independently usable program or component -- this gives RMS something that he can personally run as part of his totally-free system. Just releasing a few unusable fragments of code (or a CORBA component that requires proprietary components in order to be useful) won't do the job.
Regarding network protocols, I wouldn't use 'ssh' or 'openssh' anyhow. Investigate 'openssl', and write your own protocol based upon it. I could not use OpenSSL for the closed source project that I worked on because of the RSA patent (which is now expired so it's not a problem for you, back then it WAS a problem) so I wrote my own Diffie-Hellman based protocol, but nobody should have to go through that hassle nowdays.
-E
My first-year computer science TA was pretty good too. He immediately saw that I was wasting my time with the little lamer programs in that required class, and set me up with something more challenging.
In high school, I can't think of many good instructors that I had. They were mostly dedicated and sincere enough, but when there's 35 kids in the class, there's limits to what you can do. Probably the best was my freshman English and sophomore Ethics instructor (same guy). This was at a Catholic school and he'd been at a Jesuit seminary for a while before deciding that wasn't what he wanted to do with his life, then he'd spent time working as a counsellor at drug treatment programs, then he decided to teach. It still amazes me that they let him teach what he taught -- for example, in one unit, talking about the ethics of having sex, including frank talk about masturbation, birth control and sexually transmitted disease, at a CATHOLIC SCHOOL? He was constantly challenging kids to think, and was a prime rebuttal to the theory that a religious viewpoint upon life was incompatible with an intellectual life. While I am no longer a practicing Catholic, I must admit that experiencing Jesuit thought first-hand made me respect the Catholic church a lot more than some of those blatantly anti-intellectual religions out there (see the footer on my home page for what I think of the Christian Coalition and its ilk :-).
Oh, regarding that "timeless wisdom etched in stone" bit -- probably the best thing this guy taught was that much of what's tossed out as "timeless wisdom etched in stone" is no more etched in stone than anything else. I guess this was under the philosophy of "toss out a morsel of timeless wisdom and you've taught a man a morsel, but teach a man to think, and you've put him on the road to wisdom".
-E
Today, if something goes down, you have no idea whether anybody knows about it or not. None of the backbone NOC's post trouble tickets to the open Internet anymore. Apparently they don't want anybody to know how lousy their service is. The sad thing is that by keeping these secret, they've caused a thousand-fold escalation in the number of phone calls coming in saying "Hey, did you know your route between Dallas and Atlanta is flapping?". Aside from convincing the rest of us that they have something to hide, of course -- but if you're part of an oligarchy that has collectively decided (illegal cartel?) to screw the customer, there isn't much I can do about you deciding to be a deceitful scumbag (well, I could create a new backbone, but that isn't exactly cost-effective).
-E
Which makes it just like 99.999999% of other ISP's. I do wish that people knew the meaning of the term "customer service", but must admit that it will not happen within my lifetime -- it's too easy to make money nowadays by being a complete asshole jerk. Just advertise like hell, make sure that potential competitors can't get into the market by using monopolistic practices such as exclusive contracts, and voila, you have a company like @Home. No need to have customer service -- in fact, the harder you make it for your customers to get service, the better, because then you don't have to pretend to care.
If a competing ISP could get into my local cable drop, I'd switch ISP's in a minute. But by signing monopolistic exclusive contracts with local cable providers, @Home can continue providing lousy service while not giving a damn.
I remember when you could go straight to the NOC's web site and find out what tickets were open. That headed off a lot of geeks calling in with "did you know you had a routing loop between router-xyz.dallas.net and router-zzzy.dallas.net?" You looked at the NOC's ticket list, said to yourself "Oh, they already know about that", and went your way. Today you can't do that, because the national service providers don't want you to know how crappy their service is. The sad thing is that this attempt at decieving us has convinced us that they have something to hide.
Oh well. I guess the days when producing a good product at a good price in a friendly manner was the key to success are long gone. Today the goal appears to produce the shoddiest product for the highest price while providing the crappiest service -- then advertise the hell out of it, while using monopolistic tactics to drive the guys who do believe in producing good products out of business. Sort of like Microsoft did to folks like Digital Research, Quarterdeck (remember DesqView?), and (soon) Apple.
-E
The migration still may happen. The new RAQ most probably was already designed and was in pre-production prior to Sun buying Cobalt.
-E
I've known a lot of retired military. They think this way. They're not war mongers -- they know that friends and subordinants will die if the country goes to war. They are prepared to pay that price, but not lightly, and not on a whim, and they certainly aren't going to advise going to war when there's an alternative.
-E