In particular, specific workers willing to work for very low wages.
I know of one company that thought they could hire good programmers for $40,000 per year. They advertised for months, and were complaining about the IT worker shortage. Then they went to a recruiter. The recruiter calmly told them that a) the skill set they were advertising was very specialised and would cost them $120,000 per year, and b) if they relaxed their requirement for a particular object-orient language to simply requiring that the employee know object-oriented programming, they could get an employee for around $70-$90K/year. After a big gulp, they said "Okay." Three days later both open positions were filled.
There was no shortage of workers, just a shortage of workers willing to work for a ridiculously low wage. That is true of most open positions out there.
Question: If I can write 500 lines of working, fully debugged code in a single 8 hour day, and the industry average is 40 lines of (fully debugged and working) code in an 8 hour day, should I be paid the same as the just-starting-out code monkey who can barely plunk out 40 lines of code in a 16 hour day?
Serious question, that. Because while I'm older than the 20-somethings and can't work 16 hour days on a regular basis anymore (my health suffers), I'm definitely no slacker. If you look at the current project I'm on, there may have been an entire team working on the product, often working 14 hour days, but I bet that I personally wrote close to 50% of the lines of code in the product.
So SHOULD I be paid the same as some twenty-something college dropout slacker who knows nothing and thinks he knows everything? I don't think so. Luckily my employer agrees.
Actually, I just configured Samba by hand. I've been editing smb.conf files since 1996, and am perfectly capable of doing it by hand.
As for upgrading to a.0, my system at home is deliberately configured so I can blow away the root partition, install a new distribution, and be back up and running with minimal hassle. So I'll upgrade or re-install or whatever I want to do, thank you, and if it doesn't work, I'll blow it away and install something that does. Heck, I occasionally even blow Linux away and run FreeBSD (gasp, agh, hack!).
Obviously you did not try to upgrade your system from Red Hat 6.2 to Red Hat 7.0, only to find that 'startx' no longer worked and all attempts at configuring 'X' failed.
Obviously you did not try to configure your Samba server after you installed Red Hat 7.0 (from scratch, after giving up on the upgrade) and found that a) the Samba configurator has disappeared from Linuxconf, and b) the Samba configurator menu item on the 'foot' menu starts up a Netscape browser pointed at http://home.netscape.com rather than doing anything sensible.
Copyright law requires no notices. You cannot reproduce a piece of software you get in the mail and redistribute it without the author's permission, regardless of whether you asked for the software or not.
On the other hand, you are well within your rights as a consumer to sell that single disk you got in the mail to anybody you wish (presuming you made no copies). You never agreed to any license, after all. Unless you're in a UCITA state, in which case being born constitutes agreement with any and all licenses that anybody wants to arbitrarily hold you to:-}.
George W. Bush never met a campaign contributor he didn't like, and as governor of Texas has had no problems signing laws that say corporations have more property rights than consumers. It is likely that George W. Bush would side with DC here, because "well, DC paid lots of money to develop this thing so it's theirs".
Check out The Leasing of America for a more extended rant on how recent changes in the law take away individual's property rights in favor of giving special rights to special interests.
Here in Phoenix, I live across from Papago Park (several square miles of ravines and hills) and can ride my mountain bike out the door to go mountain biking along great trails any time I wish. When I considered moving to the Silicon Valley, I found an apartment complex that was fairly close to the job I was considering, but it was miles and hours of driving to get anywhere that I could mountain bike or rollerblade.
As for clubs and bars, I don't do'em, so I don't care how many of them San Jose has. All I know is that everything I see about living in the Silicon Valley says it sucks. The politics here in Arizona are bizarre, and the sprawl is no fun either, but if you choose where you live carefully, it's a helluva lot more livable than the Silicon Valley as it currently stands.
SF doesn't suck as far as livability goes, but that's a different world from the Silicon Valley, even if it IS only a couple hours away from San Jose (if the traffic is light:-).
One thing to beware of is your choice of management books. There's a lot of "fad" books out there that purport to tell techies how to become good managers of technical projects. I've seen a good programmer thrash ridiculously from fad to fad as he tried to manage a technical project, depending upon which book he'd last read. The fact of the matter is that management is a messy seat-of-the-pants operation in many respects, and us techies, with our logical, orderly "there is one correct answer" orientation, are generally ill-suited for management.
This doesn't mean that the skills cannot be learned. If you're interested in management, watch your own managers closely. Look at the good ones, and the bad ones. See what techniques the good ones use for organizing projects, managing difficult people, managing non-difficult people, etc. Then expect there to be a lengthy learning curve as you move upward from team leader to project architect to product manager. For most techies, it takes several years to become a good manager, because it takes that long to be able to accustom yourself to a job that is chaotic, disorderly, and the utter antithesis of everything that you've done previously. It takes that long to come up with effective strategies for dealing with management issues such as effectively marshalling the available resources to put people to work where they are most effective, effectively lobby upper management for the resources you need in order to attain the goals you want, interact with marketing to find out what features the product needs, with sales so that they know what product is coming down the pike and how they will have to sell this product, with IT to get computers for the guys, etc... it's not an easy job, and I'm somewhat wary of moving in that direction myself, but if you know what you're getting into and have adequately prepared yourself, it can be a load of fun.
There is something to be said for creating a product from scratch -- defining its feature set in a competitive matrix, deciding its basic architecture, figuring out how to allocate the available resources in the most effective manner to actually get the product created, decide what language or languages will be used to meet the various criteria, etc. You will not (usually) do this as an ordinary techie in most companies. You'll need to be at least a team leader to be able to do this -- and that's a management position, bucko.
It's not always the best place in the world to be, but it's not the death penalty you make it out to be either. A team leader's job is every bit as exciting as a techie's job. Figuring out what everybody needs to be working on is every bit as exciting as figuring out what sorting algorithm you need to use for a particular set of data, it's just a different set of excitement, that's all.
I know that most folks here shudder at the thought, but the deal is not the financial commitment. The deal is that once they have your money, they have no need or desire to provide you with a reasonable level of service. Health clubs have been doing this for years. Most people go to a health club for a few months then quit going, so health clubs sign people up for 1 year contracts. The problem is that once you sign that contract, that's the last you'll see of the professional trainers etc. that were promised. Instead, what you get are apathetic people who hide if you need help figuring out a piece of equipment, "trainers" who are just high school football players moonlighting for extra cash, etc. They figure that since they'll never see you after three months from now, it isn't any use trying to be helpful anyhow. Hiring competent trainers etc. would just be wasted expense with no bottom line advantage.
My basic conclusion, after all this, is that I have one answer to the one-year contract: "If I sign this, what incentive do you have to treat me right?". The best health club I ever belonged to had no contracts (it was a month-by-month deal) and had a level of service unmatched by anywhere I've been since, although, alas, it was also expensive.
If everybody ran 'portsentry' and had no open ports listening on the Internet, things would be much better. Script kiddies could not know whether there was no computer at that address or if it was instead running 'portsentry' ('portsentry' tosses that host into ipchains so that no ACK is even sent), and thus would not be able to exploit the undesirable denial-of-service possibilities of 'portsentry'.
I am waiting for a distribution to come set up that way out-of-box... yeah, right.
Seriously. "Classic" Unix was based upon a component approach. Components were independently reusable, useful in their own right, and could be chained together in various fashions to create larger programs.
When TCP/IP came along, though, this approach was abandoned to great extent. And when Unix GUI programming came along, it was totally abandoned -- there's no such thing as an "X" component.
And finally, Microsoft did the world a grande disservice by deciding that no, threads of execution did not need to be firewalled off from each other so that stray pointers could not crash the entire system, let's run them all in the same memory space! Multi-threaded programs are now the norm, and are a maintenance nightmare. Components in a multi-threaded program can no longer be tested in abstraction, they must be tested amidst the object environment that they were designed for. Successfully writing a component in a multi-threaded program is not just a case of writing some routines to process a stdin and stdout file handle, you now must know about the stuff in the global shared object depository, and how to arbitrate access to them.
A project I'm working on started out as a Windows-style multi-threaded program. It swiftly became obvious to me, however, when my office-mate (an excellent programmer) could not understand my architecture, that the chances of less-than-stellar programmers ever coming into the project and contributing were next to nil. Thus the project was re-written as a Unix-style program rather than a Windows-style program. While newcomers to the project need to have various services running before their programs will work, the startup learning time is greatly reduced, and their components can be written in isolation without me worrying that their component is going to break *MY* component. And on modern systems, this isn't even slow. Granted, sometimes we have 10 processes running (a plumbing nightmare!), but user response is still quite snappy.
Threads: Just Say No.
-E
Bombing obscure third world country
on
Lawsuits Suck
·
· Score: 2
You forget. The Brits did indeed do exactly that. Remember the Falkland Island War with Argentina, where Maggie "Brass Balls" Thatcher sent in the Royal Navy after the Argentines seized a few sheep in the middle of nowhere?!
Of course, that sucked up so much of the budget that they had to retire the Vulcan bombers for lack of funds to upkeep them...
Some projects need more of the kind of design work you're talking about than others. For example, an accounting system XML interface is going to need specifications, sure, but there's no shortage of programmers (outsourced or no) who understand accounting systems enough to do it in their sleep, good spec or no.
Python is one of the languages that's often mentioned as being faster to program in than C or C++. It is. I can write about the same # of lines of code per hour whether it is in "C" or Python, but my typical Python routine is about 20 lines long, while the equivalent "C" routine is about 80 lines long. But that does not, of course, reduce the design overhead, meaning that there really isn't that significant a savings in overall project time. It does, however, make things more efficient when you're trying to do something that's never been done before, and you're having to constantly build prototypes to see whether a possible design will work or not, and what the components would need to be for that design.... even if the final project must be in "C" due to other considerations, it might be worthwhile to prototype some things in Python, Perl, or even/bin/sh just to see whether it would work or not. But that's something to be done only for things where nobody has ever done it before and thus the "right" design is a mystery that must be discovered via both trial-and-error and analysis of the problem (and you may not know the full scope of the problem until you try sample solutions -- some problems are difficult that way!).
For most projects, I would say that choice of language is irrelevant to the ship date (though I would prefer a language like Java or Python that takes care of memory allocation/memory leaks and dangling pointers for me... I *HATE* memory leaks and dangling pointers!). It is, after all, perfectly possible to write object-oriented code in plain old "C"...
One thing to bear in mind is that a lot of design problems can be resolved simply by having the appropriate architecture. For example, a Unix-style architecture of "many small tools chained together" can be done quite well by specifying what functionality the product needs, specifying what those "many small tools" will be that implement that functionality, what they will do, and what their inputs and outputs will be. Then you can pretty much draw pictures of the rest of the project, with black boxes with the names of the "many small tools" scattered hither and fro, plus you can assign myriad junior programmers to the black boxes (or at least the ones that do not interface with internals of other black boxes, sigh, which is the downside of trying to emulate the Unix-style architecture using C++ classes or other such object-oriented techniques).
Unfortunately, here's what happens in real life:
You're a designer. You've laid out this neat architecture. You've documented it out the yazoo. Management says "That's nice, where's the program?".
So you start writing the black boxes, one by one. They get done. They're tested, one by one, according to the test plan. They work. Management says "That's nice, where's the program? I don't see any pretty GUI graphics on the screen!".
You start chaining the black boxes together to create the back end services for the GUI. Ten days later management, in frustration, fires you and hires a new project manager. The new project manager comes in, sees the project nearly completed, and assigns a programmer to finish chaining the black boxes together, something that takes another five days. Meanwhile he assigns another programmer to whip up a quick prototype GUI in TCL/TK.
Management says "Ooh, pretty pictures, we ship tomorrow!". The new project manager smiles, accepts his 25% bonus for delivery, tells the GUI programmer to tar up the halfway-working project and release it as version 1.0 (complete with the half-assed prototype TCL/TK GUI), then sets the team to work on version 1.1, the finished version that actually works.
And that is how the real world works. Sad but true. Pointy-haired bosses don't want specifications. They don't want software engineering. They don't understand all this stuff about design for maintainability. They just want pretty pictures on the screen that look like they're doing something (even if they're not), and if they don't see pretty pictures, they don't believe that work is being done.
Try telling a pointy-haired boss that the GUI is the easy part and that you need to put your experienced people on the back-end stuff and hire a newcomer to the company to do the GUI. I dare you. He'll look at you like you have horns growing out of your head. So what ends up is that the most experienced programmer in the company gets assigned to whip up the GUI and yeah, he can do it in 4 weeks (as vs some newcomer to the project who'd take 8 weeks), but that's 4 weeks further behind that the back end code (that does the actual work) gets.... meaning no net savings in time. But pointy haired bosses think that the pictures on the screen are the only thing that counts, and have no conception that there must be code behind the pictures to actually do things... and thus projects get written bass-ackwards all the time (i.e., pretty pictures drawn with GUI Designer tool to impress boss, then programmers charged with writing code to implement all the buttons and widgets... despite the fact that no functional analysis has been done on what the product needs to do, and no analysis has been done on proper architecture for the back end).
So it goes in the real world. If you ever interview me for a job, be sure to ask me "What is your dream?". My answer will be "to some day, some how, work for some company that manages sofware projects effectively and efficiently." Alas, I'm starting to think it's going to remain a dream for the foreseeable future... well-managed software development, outside of a few very specialized niches like aeronautic software, is virtually unknown. Otherwise Microsoft would be out of business, because there's no way that their buggy bloatware could compete with well-designed software delivered in a timely, efficient manner by well-managed companies... Microsoft is very lucky in that their competition has been folks like Digital Research, Borland, Corel, SCO, Netscape, and Novell, all of which began as effective companies but which degenerated over time to producing the same kind of buggy ill-designed bloatware as Microsoft.
I think it also depends on the project itself. If it is a project in a well-defined, well-known area, you are safe, because it is easy to write a good, comprehensive specification. If you're doing something that has never been done before, you will write the specification... then as the project goes along, realise that you didn't know about part N, meaning you then specify part N, then as you go along you realise you didn't know ab out part M, meaning you then specify part M, etc.... such an interative specify-prototype-specify-prototype cycle is normal when you're trying to do something that's never been done before (if somebody knew how to do it, they would have already done it!), and outsourcing that is pretty much impossible unless you also send your chief architect and the project manager to oversee the development on-site.
If, on the other hand, it is Yet Another Accounting System Front End, yeah, outsource it... okay, so this one is done in XML rather than using Curses, big friggin' deal, an accounting system front end is an accounting system front end...
Most root kits don't touch the library path. They merely start up a daemon on some high port (usually a hacked version of 'ssh' that accepts connections only from the correct person) and then replace 'ps', 'ls', 'netstat', and a few other tools of note to make it hard to detect that a new daemon is running. Oh, and toss some code into/etc/rc.d/rc.sysinit that pretends to be starting normal services such as rpc.statd (grin). If you are running Red Hat 6.2, that file should be 13679 bytes long... if it is longer, YOU HAVE BEEN HACKED.
Unfortunately, no current Linux distribution comes with intrusion detection tools installed, running, or even mentioned in the documentation. They should. Especially given Linux's lousy record in this area (yes, problems are fixed quickly, but there are so MANY of them...).
'Nuff said. Every root kit in existence has hacked versions of 'netstat', 'ps', and 'top' so you can't see the ports open.
There are some tools to detect that 'netstat' and 'ps' are no longer reporting the same stuff as what's being reported in/proc, but these tools do not come with the typical Linux distribution and could easily be hacked themselves if they became common. I won't mention particular tools 'cause I don't want to give the kiddies an idea what they're facing when they go against my system:-}.
I'll admit it -- I got rooted. I'd set up wuftpd and *thought* I'd restricted it so that I could only get to it from within my vpn. Unfortunately, next time I upgraded my Red Hat to the latest, I forgot to make sure that my firewall rules were still intact. Whoops! So last wuftpd exploit that came about, BLAMMO. [Note: Red Hat 6.2 came out when? The last wuftpd exploit came out when? You do the time line:-). ]
What scares me is the number of remote exploits that have been found over the years in Linux-based utilities, and the difficulty of securing current Linux distributions in the face of all of these potential exploits. I have come to the conclusion that Linux is safe on the Internet only when configured as a single-purpose device with all other software removed. Thus I have an old Cyrix P150 now serving as a firewall doing nothing but IP masquerading and (internal) name resolution (it is not listening on the external network). The only service port open is OpenSSH. I have the thing wired to detect and counter all sorts of attacks, but I'm not going to go into that because one of those programs opens me up to a rather insidious Denial of Service attack that's harder to trace than the typical ping flood or smurf.
Does that make me secure? No. If it wasn't for the need to run CIPE, I would dump Linux on my firewall and run OpenBSD there.
BTW, if anybody wants a root kit, I saved the one the script kiddies left for me:-). Very interesting work. Obviously a derivative of one that I encountered in 1997 or so, but with some interesting twists. I especially liked the sweet little hack of 'ssh' that sits on a high port and gives instant root access to the attacker connecting to that port with the right private key. There's a couple of things I would do, if I were the author of this kit, to make it harder to detect though... I won't go into details here though, for obvious reasons. In any event, this particular kit is easily detectable by anybody who routinely examines the contents of their/var/log directory... and if you type 'locate t0rn' you'll see some files that 'ls' says don't exist... 'nuff said. If you're running Linux and you're connected to the Internet, you'd best go check 'locate' results now:-).
For patents, if you wait more than six years you can lose the right to collect damages FOR THAT PARTICULAR INFRINGEMENT. This does not eliminate your right to pursue damages for other infringing applications, or otherwise affect the validity of the patent.
The U.N. Charter, which the United States willingly signed (and crafted, even!), says that the U.S. owes $x amount of dollars for U.N. operations. The United States, in complete defiance of a treaty which it signed, has refused to fork over more than a BILLION dollars that they are required (by law!) to fork over.
So I guess you're talking about a billion "shove it!" messages that the United States has given the U.N...
Their goal is not to keep computer geeks from sharing DeCSS. They know that this will happen. Their goal is to prevent a commercial company from releasing a commercial product utilizing the algorithms within DeCSS.
This is not a new strategy. The U.S. Government used this strategy for many years to slow the adoption of personal encryption products, and it worked. For example, the persecution of Phil Zimmerman was specifically designed to slow the adoption of his PGP software as the standard mechanism for private EMAIL, and it worked -- how many people today send private encrypted EMAIL? Almost nobody, outside of a few dozen subscribers to the Cypherpunks mailing list. Sure, you and I can send encrypted EMAIL between each other (or could if I'd ever bothered generating a key:-), but how many ordinary everyday people could do that using the ordinary software that came with their computer?
My feeling is that this case will be found in favor of the DVDCCA, because regardless of the Constitution of the United States, the next President will be as much a corporate puppet as the majority of congressmen are. People hold hope that the Supremes might rule different. They certainly may. And the horse could learn to talk too. Recent rulings by the Supremes show that anything you get out of them is a crapshoot, meaning that even if they accept a case such as MPAA vs. 2600, there's a good chance they will decide that the economic health of the United States is more important than the Constitution (after all, they've ruled that RICO is constitutional, even though it violates at least two of the Bill of Rights).
I have no solutions. I am not enamored of revolution. The so-called "leaders" of revolutions tend to be rather unsavory power-hungry types who are worse than the dictators that they replace, and besides, most people are affluent enough that they don't mind that they now live in a corporate dictatorship rather than in a free country (not that the United States has ever been particularly free -- just ask union organizers of the 1930's, or civil rights workers of the 1950's, about how "free" the United States ever was). After all, this corporate dictatorship has proven far better at providing mind-numbing entertainment and consumer goods than the earlier power cliques that ruled this country, such as, e.g., the military/industrial clique in the 1950's (thus the "Red Scare"). Certainly that messy thing called "democracy" is far inferior to this nice, safe corporate state? After all, the planes DO run on time, right? (okay, so that one went over your head, it was about Mussolini -- despite his boasting that fascism made the trains run on time, by all acounts Italian trains were off-schedule just as regularly during his fascist rule as they were before it... Italians have never been known for efficiency, fascist or not:-).
1) Driving record: If it is a job that involves driving, I agree that a driving record check is a Good Idea(tm). Otherwise, it's nonsense.
2) Credit record: My credit record is my personal business. Furthermore, it's of dubious legality to use credit record for hiring purposes (that is not one of the enumerated purposes in the Fair Credit Reporting Act). I refuse to work for companies that knowingly and willfully violate the law, though the fact that Microsoft still has employees tells me that my attitude is not universal.
3) Criminal record: May be a worthwhile check for certain positions (I certainly don't want a bookkeeper who was convicted of theft!), but for others, I don't want to know if this hot programmer I want to hire got arrested for pot when he was in college. (Generic "I" here, putting myself into the hiring manager's shoes). The job of engineering management is the job of accumulating and managing talent. Sometimes that talent comes with baggage, but the engineering manager's job is to deal with that baggage and get good work out of the talent.
Interviewing neighbors: I'd much rather run the guy past a dozen employees, take him to lunch, etc. to find out whether he will get along with people. Somebody might fake it for a 40 minute interview, but he's not going to fake it for a 4 hour interview with a dozen people. Nobody's that good, except maybe a few vintage KGB employees:-}.
Medical record: It is of dubious legality to ask for medical records except under certain very limited circumstances (such as when a job requires a large amount of physical labor, or where poor health could present a safety hazard, such as for airline pilots or truck drivers). Under federal law, it is illegal to discriminate against the handicapped for employment purposes, and asking for medical records could be construed as a mechanism for violating the law. I refuse to work for companies that knowingly and willfully violate the law.
Drug tests: I don't want to know whether this hot talent I want to hire does a little pot in his spare time. An engineering manager's job is to accumulate and use talent, and if the guy has talent, and shows that he has the ability to contribute in a positive manner, I want him on my team. What he does on his own time is his own business. If he comes to work stoned that's a different story.
Finally, regarding the amount of risk a company is exposing itself to: There are two kinds of companies in this world -- companies that are interested in Cover Your Ass, and companies that are interested in Getting Things Done. Your logic is the logic of companies interested in CYA. Personally, I don't like working for such companies, because the best things happen when a company dares to take risks in order to Make Things Happen. One of those risks is the engineering talent that it takes to Make Things Happen, which tends to be high-strung and difficult to manage. But that's the job of an engineering manager to manage those people and get the incredible results out of them that they're capable of doing. Sometimes that requires overlooking a few character flaws like, say, occasional pot use (or bad body odor, something that afflicts a key engineer at one company I deal with:-). But you can't Change The World without taking risks, and all Cover Your Ass has ever managed to do was generate paperwork and flat profits (see: Unisys for an example, which went from being the #2 company in the computer business to being an also-ran services business).
It depends upon the state. In "civilized" states like NJ, PA, and CA, non-compete clauses that have the effect of rendering you unemployable in your normal profession are null and void. On the other hand, in states such as Texas (hi, George W.!), the courts have ruled the other way repeatedly. In Texas, "the bidness of guvmen't is bidness" (i.e., they believe that government is in the business of ruling in favor of business every time it's possible), which is their way of attracting businesses to Texas ("Come to Texas and polute without fear!"). Ironically, such policies also tend to drive talent out of Texas to more progressive states, which is why Texas is an also-ran in the computer business (okay, they have a couple of good computer assemblers in Dell and Compaq, but all the REAL innovation is being done in places like the Silicon Valley).
In other words, by saying "the bidness of guvmen't is bidness", Texas has actually hurt any chance it ever had of being big-time in the computer biz! (Forget about Austin's "Silicon Gulch", that's just more assembly plants, the amount of R&D being done there is miniscule compared to the "real" centers of the computer industry).
One thing I'm interested in, if I'm going into a startup-type situation, is whether these guys are well-managed, and are going to be able to actually pay my paycheck for long enough to get the product out the door (I *HATE* leaving a project in midstream!). Thus the following questions seem relevant: 1) How much cash do you have on hand? 2) What's your burn rate? 3) When do you expect to be profitable? 4) What's your plan for attaining profitability?
I know that if I were running a business, I sure as hell wouldn't want to give out that info without having an NDA in hand -- if Barnes and Noble were trying to put me out of business, them knowing that I have 12 months of cash on hand means that they know they only have to cut their prices to unprofitability for 12 months and 1 day in order to put me out of business (and they will, believe me, those brick-and-mortar places are absolutely appalled by the dot.com crowd that has the AUDACITY to believe that they can break into the market that these brick-and-mortar places have monopolized in the "real world"!).
Slashdot Mirror
I know of one company that thought they could hire good programmers for $40,000 per year. They advertised for months, and were complaining about the IT worker shortage. Then they went to a recruiter. The recruiter calmly told them that a) the skill set they were advertising was very specialised and would cost them $120,000 per year, and b) if they relaxed their requirement for a particular object-orient language to simply requiring that the employee know object-oriented programming, they could get an employee for around $70-$90K/year. After a big gulp, they said "Okay." Three days later both open positions were filled.
There was no shortage of workers, just a shortage of workers willing to work for a ridiculously low wage. That is true of most open positions out there.
-E
Serious question, that. Because while I'm older than the 20-somethings and can't work 16 hour days on a regular basis anymore (my health suffers), I'm definitely no slacker. If you look at the current project I'm on, there may have been an entire team working on the product, often working 14 hour days, but I bet that I personally wrote close to 50% of the lines of code in the product.
So SHOULD I be paid the same as some twenty-something college dropout slacker who knows nothing and thinks he knows everything? I don't think so. Luckily my employer agrees.
-E
As for upgrading to a .0, my system at home is deliberately configured so I can blow away the root partition, install a new distribution, and be back up and running with minimal hassle. So I'll upgrade or re-install or whatever I want to do, thank you, and if it doesn't work, I'll blow it away and install something that does. Heck, I occasionally even blow Linux away and run FreeBSD (gasp, agh, hack!).
-E
Obviously you did not try to configure your Samba server after you installed Red Hat 7.0 (from scratch, after giving up on the upgrade) and found that a) the Samba configurator has disappeared from Linuxconf, and b) the Samba configurator menu item on the 'foot' menu starts up a Netscape browser pointed at http://home.netscape.com rather than doing anything sensible.
'Nuff said. I'm disappointed.
-E
On the other hand, you are well within your rights as a consumer to sell that single disk you got in the mail to anybody you wish (presuming you made no copies). You never agreed to any license, after all. Unless you're in a UCITA state, in which case being born constitutes agreement with any and all licenses that anybody wants to arbitrarily hold you to :-}.
-E
Check out The Leasing of America for a more extended rant on how recent changes in the law take away individual's property rights in favor of giving special rights to special interests.
-E
As for clubs and bars, I don't do'em, so I don't care how many of them San Jose has. All I know is that everything I see about living in the Silicon Valley says it sucks. The politics here in Arizona are bizarre, and the sprawl is no fun either, but if you choose where you live carefully, it's a helluva lot more livable than the Silicon Valley as it currently stands.
SF doesn't suck as far as livability goes, but that's a different world from the Silicon Valley, even if it IS only a couple hours away from San Jose (if the traffic is light :-).
-E
This doesn't mean that the skills cannot be learned. If you're interested in management, watch your own managers closely. Look at the good ones, and the bad ones. See what techniques the good ones use for organizing projects, managing difficult people, managing non-difficult people, etc. Then expect there to be a lengthy learning curve as you move upward from team leader to project architect to product manager. For most techies, it takes several years to become a good manager, because it takes that long to be able to accustom yourself to a job that is chaotic, disorderly, and the utter antithesis of everything that you've done previously. It takes that long to come up with effective strategies for dealing with management issues such as effectively marshalling the available resources to put people to work where they are most effective, effectively lobby upper management for the resources you need in order to attain the goals you want, interact with marketing to find out what features the product needs, with sales so that they know what product is coming down the pike and how they will have to sell this product, with IT to get computers for the guys, etc... it's not an easy job, and I'm somewhat wary of moving in that direction myself, but if you know what you're getting into and have adequately prepared yourself, it can be a load of fun.
-E
It's not always the best place in the world to be, but it's not the death penalty you make it out to be either. A team leader's job is every bit as exciting as a techie's job. Figuring out what everybody needs to be working on is every bit as exciting as figuring out what sorting algorithm you need to use for a particular set of data, it's just a different set of excitement, that's all.
-E
My basic conclusion, after all this, is that I have one answer to the one-year contract: "If I sign this, what incentive do you have to treat me right?". The best health club I ever belonged to had no contracts (it was a month-by-month deal) and had a level of service unmatched by anywhere I've been since, although, alas, it was also expensive.
-E
I am waiting for a distribution to come set up that way out-of-box... yeah, right.
-E
When TCP/IP came along, though, this approach was abandoned to great extent. And when Unix GUI programming came along, it was totally abandoned -- there's no such thing as an "X" component.
And finally, Microsoft did the world a grande disservice by deciding that no, threads of execution did not need to be firewalled off from each other so that stray pointers could not crash the entire system, let's run them all in the same memory space! Multi-threaded programs are now the norm, and are a maintenance nightmare. Components in a multi-threaded program can no longer be tested in abstraction, they must be tested amidst the object environment that they were designed for. Successfully writing a component in a multi-threaded program is not just a case of writing some routines to process a stdin and stdout file handle, you now must know about the stuff in the global shared object depository, and how to arbitrate access to them.
A project I'm working on started out as a Windows-style multi-threaded program. It swiftly became obvious to me, however, when my office-mate (an excellent programmer) could not understand my architecture, that the chances of less-than-stellar programmers ever coming into the project and contributing were next to nil. Thus the project was re-written as a Unix-style program rather than a Windows-style program. While newcomers to the project need to have various services running before their programs will work, the startup learning time is greatly reduced, and their components can be written in isolation without me worrying that their component is going to break *MY* component. And on modern systems, this isn't even slow. Granted, sometimes we have 10 processes running (a plumbing nightmare!), but user response is still quite snappy.
Threads: Just Say No.
-E
Of course, that sucked up so much of the budget that they had to retire the Vulcan bombers for lack of funds to upkeep them...
-E
Python is one of the languages that's often mentioned as being faster to program in than C or C++. It is. I can write about the same # of lines of code per hour whether it is in "C" or Python, but my typical Python routine is about 20 lines long, while the equivalent "C" routine is about 80 lines long. But that does not, of course, reduce the design overhead, meaning that there really isn't that significant a savings in overall project time. It does, however, make things more efficient when you're trying to do something that's never been done before, and you're having to constantly build prototypes to see whether a possible design will work or not, and what the components would need to be for that design.... even if the final project must be in "C" due to other considerations, it might be worthwhile to prototype some things in Python, Perl, or even /bin/sh just to see whether it would work or not. But that's something to be done only for things where nobody has ever done it before and thus the "right" design is a mystery that must be discovered via both trial-and-error and analysis of the problem (and you may not know the full scope of the problem until you try sample solutions -- some problems are difficult that way!).
For most projects, I would say that choice of language is irrelevant to the ship date (though I would prefer a language like Java or Python that takes care of memory allocation/memory leaks and dangling pointers for me... I *HATE* memory leaks and dangling pointers!). It is, after all, perfectly possible to write object-oriented code in plain old "C"...
-E
Unfortunately, here's what happens in real life:
You're a designer. You've laid out this neat architecture. You've documented it out the yazoo. Management says "That's nice, where's the program?".
So you start writing the black boxes, one by one. They get done. They're tested, one by one, according to the test plan. They work. Management says "That's nice, where's the program? I don't see any pretty GUI graphics on the screen!".
You start chaining the black boxes together to create the back end services for the GUI. Ten days later management, in frustration, fires you and hires a new project manager. The new project manager comes in, sees the project nearly completed, and assigns a programmer to finish chaining the black boxes together, something that takes another five days. Meanwhile he assigns another programmer to whip up a quick prototype GUI in TCL/TK.
Management says "Ooh, pretty pictures, we ship tomorrow!". The new project manager smiles, accepts his 25% bonus for delivery, tells the GUI programmer to tar up the halfway-working project and release it as version 1.0 (complete with the half-assed prototype TCL/TK GUI), then sets the team to work on version 1.1, the finished version that actually works.
And that is how the real world works. Sad but true. Pointy-haired bosses don't want specifications. They don't want software engineering. They don't understand all this stuff about design for maintainability. They just want pretty pictures on the screen that look like they're doing something (even if they're not), and if they don't see pretty pictures, they don't believe that work is being done.
Try telling a pointy-haired boss that the GUI is the easy part and that you need to put your experienced people on the back-end stuff and hire a newcomer to the company to do the GUI. I dare you. He'll look at you like you have horns growing out of your head. So what ends up is that the most experienced programmer in the company gets assigned to whip up the GUI and yeah, he can do it in 4 weeks (as vs some newcomer to the project who'd take 8 weeks), but that's 4 weeks further behind that the back end code (that does the actual work) gets.... meaning no net savings in time. But pointy haired bosses think that the pictures on the screen are the only thing that counts, and have no conception that there must be code behind the pictures to actually do things... and thus projects get written bass-ackwards all the time (i.e., pretty pictures drawn with GUI Designer tool to impress boss, then programmers charged with writing code to implement all the buttons and widgets... despite the fact that no functional analysis has been done on what the product needs to do, and no analysis has been done on proper architecture for the back end).
So it goes in the real world. If you ever interview me for a job, be sure to ask me "What is your dream?". My answer will be "to some day, some how, work for some company that manages sofware projects effectively and efficiently." Alas, I'm starting to think it's going to remain a dream for the foreseeable future... well-managed software development, outside of a few very specialized niches like aeronautic software, is virtually unknown. Otherwise Microsoft would be out of business, because there's no way that their buggy bloatware could compete with well-designed software delivered in a timely, efficient manner by well-managed companies... Microsoft is very lucky in that their competition has been folks like Digital Research, Borland, Corel, SCO, Netscape, and Novell, all of which began as effective companies but which degenerated over time to producing the same kind of buggy ill-designed bloatware as Microsoft.
-E
If, on the other hand, it is Yet Another Accounting System Front End, yeah, outsource it... okay, so this one is done in XML rather than using Curses, big friggin' deal, an accounting system front end is an accounting system front end...
-E
Unfortunately, no current Linux distribution comes with intrusion detection tools installed, running, or even mentioned in the documentation. They should. Especially given Linux's lousy record in this area (yes, problems are fixed quickly, but there are so MANY of them...).
-E
There are some tools to detect that 'netstat' and 'ps' are no longer reporting the same stuff as what's being reported in /proc, but these tools do not come with the typical Linux distribution and could easily be hacked themselves if they became common. I won't mention particular tools 'cause I don't want to give the kiddies an idea what they're facing when they go against my system :-}.
-E
What scares me is the number of remote exploits that have been found over the years in Linux-based utilities, and the difficulty of securing current Linux distributions in the face of all of these potential exploits. I have come to the conclusion that Linux is safe on the Internet only when configured as a single-purpose device with all other software removed. Thus I have an old Cyrix P150 now serving as a firewall doing nothing but IP masquerading and (internal) name resolution (it is not listening on the external network). The only service port open is OpenSSH. I have the thing wired to detect and counter all sorts of attacks, but I'm not going to go into that because one of those programs opens me up to a rather insidious Denial of Service attack that's harder to trace than the typical ping flood or smurf.
Does that make me secure? No. If it wasn't for the need to run CIPE, I would dump Linux on my firewall and run OpenBSD there.
BTW, if anybody wants a root kit, I saved the one the script kiddies left for me :-). Very interesting work. Obviously a derivative of one that I encountered in 1997 or so, but with some interesting twists. I especially liked the sweet little hack of 'ssh' that sits on a high port and gives instant root access to the attacker connecting to that port with the right private key. There's a couple of things I would do, if I were the author of this kit, to make it harder to detect though... I won't go into details here though, for obvious reasons. In any event, this particular kit is easily detectable by anybody who routinely examines the contents of their /var/log directory... and if you type 'locate t0rn' you'll see some files that 'ls' says don't exist... 'nuff said. If you're running Linux and you're connected to the Internet, you'd best go check 'locate' results now :-).
-E
Read the law:
http://www4.law.cornell.edu/uscode/ 35/ch29.html
-E
So I guess you're talking about a billion "shove it!" messages that the United States has given the U.N...
This is not a new strategy. The U.S. Government used this strategy for many years to slow the adoption of personal encryption products, and it worked. For example, the persecution of Phil Zimmerman was specifically designed to slow the adoption of his PGP software as the standard mechanism for private EMAIL, and it worked -- how many people today send private encrypted EMAIL? Almost nobody, outside of a few dozen subscribers to the Cypherpunks mailing list. Sure, you and I can send encrypted EMAIL between each other (or could if I'd ever bothered generating a key :-), but how many ordinary everyday people could do that using the ordinary software that came with their computer?
My feeling is that this case will be found in favor of the DVDCCA, because regardless of the Constitution of the United States, the next President will be as much a corporate puppet as the majority of congressmen are. People hold hope that the Supremes might rule different. They certainly may. And the horse could learn to talk too. Recent rulings by the Supremes show that anything you get out of them is a crapshoot, meaning that even if they accept a case such as MPAA vs. 2600, there's a good chance they will decide that the economic health of the United States is more important than the Constitution (after all, they've ruled that RICO is constitutional, even though it violates at least two of the Bill of Rights).
I have no solutions. I am not enamored of revolution. The so-called "leaders" of revolutions tend to be rather unsavory power-hungry types who are worse than the dictators that they replace, and besides, most people are affluent enough that they don't mind that they now live in a corporate dictatorship rather than in a free country (not that the United States has ever been particularly free -- just ask union organizers of the 1930's, or civil rights workers of the 1950's, about how "free" the United States ever was). After all, this corporate dictatorship has proven far better at providing mind-numbing entertainment and consumer goods than the earlier power cliques that ruled this country, such as, e.g., the military/industrial clique in the 1950's (thus the "Red Scare"). Certainly that messy thing called "democracy" is far inferior to this nice, safe corporate state? After all, the planes DO run on time, right? (okay, so that one went over your head, it was about Mussolini -- despite his boasting that fascism made the trains run on time, by all acounts Italian trains were off-schedule just as regularly during his fascist rule as they were before it... Italians have never been known for efficiency, fascist or not :-).
-E
2) Credit record: My credit record is my personal business. Furthermore, it's of dubious legality to use credit record for hiring purposes (that is not one of the enumerated purposes in the Fair Credit Reporting Act). I refuse to work for companies that knowingly and willfully violate the law, though the fact that Microsoft still has employees tells me that my attitude is not universal.
3) Criminal record: May be a worthwhile check for certain positions (I certainly don't want a bookkeeper who was convicted of theft!), but for others, I don't want to know if this hot programmer I want to hire got arrested for pot when he was in college. (Generic "I" here, putting myself into the hiring manager's shoes). The job of engineering management is the job of accumulating and managing talent. Sometimes that talent comes with baggage, but the engineering manager's job is to deal with that baggage and get good work out of the talent.
Interviewing neighbors: I'd much rather run the guy past a dozen employees, take him to lunch, etc. to find out whether he will get along with people. Somebody might fake it for a 40 minute interview, but he's not going to fake it for a 4 hour interview with a dozen people. Nobody's that good, except maybe a few vintage KGB employees :-}.
Medical record: It is of dubious legality to ask for medical records except under certain very limited circumstances (such as when a job requires a large amount of physical labor, or where poor health could present a safety hazard, such as for airline pilots or truck drivers). Under federal law, it is illegal to discriminate against the handicapped for employment purposes, and asking for medical records could be construed as a mechanism for violating the law. I refuse to work for companies that knowingly and willfully violate the law.
Drug tests: I don't want to know whether this hot talent I want to hire does a little pot in his spare time. An engineering manager's job is to accumulate and use talent, and if the guy has talent, and shows that he has the ability to contribute in a positive manner, I want him on my team. What he does on his own time is his own business. If he comes to work stoned that's a different story.
Finally, regarding the amount of risk a company is exposing itself to: There are two kinds of companies in this world -- companies that are interested in Cover Your Ass, and companies that are interested in Getting Things Done. Your logic is the logic of companies interested in CYA. Personally, I don't like working for such companies, because the best things happen when a company dares to take risks in order to Make Things Happen. One of those risks is the engineering talent that it takes to Make Things Happen, which tends to be high-strung and difficult to manage. But that's the job of an engineering manager to manage those people and get the incredible results out of them that they're capable of doing. Sometimes that requires overlooking a few character flaws like, say, occasional pot use (or bad body odor, something that afflicts a key engineer at one company I deal with :-). But you can't Change The World without taking risks, and all Cover Your Ass has ever managed to do was generate paperwork and flat profits (see: Unisys for an example, which went from being the #2 company in the computer business to being an also-ran services business).
_E
In other words, by saying "the bidness of guvmen't is bidness", Texas has actually hurt any chance it ever had of being big-time in the computer biz! (Forget about Austin's "Silicon Gulch", that's just more assembly plants, the amount of R&D being done there is miniscule compared to the "real" centers of the computer industry).
-E
I know that if I were running a business, I sure as hell wouldn't want to give out that info without having an NDA in hand -- if Barnes and Noble were trying to put me out of business, them knowing that I have 12 months of cash on hand means that they know they only have to cut their prices to unprofitability for 12 months and 1 day in order to put me out of business (and they will, believe me, those brick-and-mortar places are absolutely appalled by the dot.com crowd that has the AUDACITY to believe that they can break into the market that these brick-and-mortar places have monopolized in the "real world"!).
-E