I think you underestimate just how much tape is in today's cartridges. There are 150 meters of tape in a DDS4 cartridge, for example (or is it 180? Doesn't matter, still a lot). That's about 750 feet of tape for the metrically impaired, crammed into a tiny cartridge barely larger than the mini-cassettes occasionally used to record meetings. This tape is ultra-thin and very tightly spooled in order to cram it all into that teeny cartridge. The whole point of tape is storage density -- fitting the most data into the smallest space for the least per-byte cost -- and there's just no room there to slide heads inbetween leaves.
Tape drive manufacturers are raising capacities via a variety of methods. They are coming up with thinner tape materials so that they can cram more tape into a cartridge (I understand there will be a DDS5 that crams over 200 meters of tape into a tiny 4mm tape cartridge!). They are coming up with new heads that either store data more densely linearly, or that store data more densely vertically (i.e. put more tracks on a tape). They've also been playing with the speed at which data is recorded, and perhaps varying that to adjust to tape quality etc. There are also experiments ongoing with multiple heads and serpentine tapes, though I haven't heard that this is buying anything (easier to have a smaller cartridge and multiple simple drives rather than big complex cartridges and one complex drive). Having seen these guys do so many "impossible" things (they said that DDS4 was impossible!), I've given up on figuring out where it's all going to end, but I do know that traditional tape drives are nowhere near their limits as far as speed and capacity go.
Seagate and HP just introduced their LTO technology that holds 100gb native. Tandberg's SLR-100 holds 50gb native, as does the Exabyte Mammoth II (or does the Mammoth II have 66gb? I'm away from my office, alas, so don't have the specs in front of me). Granted, we're talking about $3,000 tape drives here, in an era where 83gb hard drives cost half as much. But (shrug) fast tape storage devices have always been more expensive than the hard drives they back up, at least in recent memory (I understand it was different back in the 60's).
I've been looking at the data sheets on some of the big enterprise-class storage systems. We're talking about boxes that have 5 to 15 drives, and attach via fibre channel loop to multiple servers that need to be backed up, and that have hundreds of tapes that they manage via robotics. Yes, I'm working on enhancing the Linux 'mtx' tape library control software to drive these things, though I'll never be able to personally see or test one:-}. There are some interesting challenges to handle with fibre-attached storage, specifically, the one of "who has the robotic arm now?!", but none that are unsolvable. I am confident that no matter how big hard drives get, we'll be able to back them up -- albeit for a price!
Didn't they used to say that you couldn't make a silicon chip with a less than 1micron feature size because the wavelength of light was too wide to properly expose the die? (Note to newbies -- a silicon chip of that era was basically photo-etched, i.e. a mask was made that was the inverse of the features on the chip, the chip was painted with resist, resist is exposed to light and then after the mask and light are removed an etchant eats away the unexposed portions in order to form features).
Of course, we know what happened after that -- they quit using visual light, and started using shorter-wavelength beams.
A friend of mine says "Is tape storage on the way out? It's not keeping up with disk storage!".
Seagate and HP just introduced a tape drive with 100gb (UNCOMPRESSED) capacity, and they say that they can take that same technology to 250gb native. These LTO drives do this by having oodles of tracks on a tape so that a stretch of tape may have hundreds of tracks in parallel, and by using new tape materials that allow them to make the tape thinner so they can pack more tape into a cartridge. People said linear tape was dead, that helical scan would always be faster and higher capacity, but it appears that conventional wisdom is foiled again...
I don't know what hard drives are going to be like five years from now, but I do know they're not going to stall, capacity-wise, due to some "inherent" limit. Too many smart people are looking for ways to bypass those limits, either by using some other technology altogether (hmm... photo-sensitive materials??) or by figuring some way around the "limit" using clever application of the underlying physics.
It's the economy, stupid. The United States worships money. Most citizens of the United States worship money. The United States is the world's wealthiest country, especially for geeks (who are especially well paid in the Internet sector). Thus we stay.
Not to mention that we look overseas, and we see similar problems overseas to what we're fighting here, such as the UK's "Official Secrets Act" and the UK's draconian libel laws (where you are judged guilty of libel unless you can prove beyond a reasonable doubt that you have the facts on your side), or Australia's Internet censorship laws, or the telephone monopoly in Germany that is hindering Germans from getting online... 'nuff said.
And finally, there is the language barrier. Most Americans have never bothered learning another language. Why should they, when the United States is so big and powerful? This means that most Americans could only move to other English-speaking countries, most of which haven't had much of a high tech industry. Other high-tech powerhouses such as Germany are of little interest to Americans, because we (gasp) don't speak the language...
PostgreSQL's query speed is reasonable, within 10-20% of Oracle's and "close enough" to MySQL's. Postgres's insert speed is hideous. I benchmark it as less than 1/3rd of MySQL's speeds on inserts.
Much of Postgres's reputation for slow speed stems from attempts to use it as a CGI back end database. PostgreSQL, like Oracle, takes a long time to open and close connections. This is because PostgreSQL spawns off an entirely new process for each connection, complete with checking the user permissions etc., while MySQL spawns a thread, which is considerably faster to do but potentially less reliable if a thread dies due to a bug in the RDBMS (ask Microsoft what happens when a thread dies without releasing any locks that it has! Ever wonder why Windows dies so often?!).
In short, if you want to use PostGreSQL as a web back end, use a persistent connection -- do NOT open and close the database for each CGI transaction!
Failover generally relies upon transaction logs and when machine A fails, uses machine A's transaction logs to bring machine B up to date. The result is that machine B is current as of the data that machine A failed.
Replication generally does not take place on as current a basis. Replication can be done with any currently-existing RDBMS simply by adding a "last changed" timestamp to each record, and then occasionally querying out all records before a certain timestamp and sending those records to the remote server. Replication thus ensures that you have a snapshot of the data at some point in time, but not necessarily an up-to-date version of that data.
Those differences are why replication can be done by third-party software, while "real" standby requires specific support at the RDBMS level. I have done replication with technology as crude as dBase II by explicitly programming it into my applications. Standby, on the other hand, is a different issue.
Finally: For small businesses, none of these particularly matter. Small businesses don't have the money for big replication servers and such. They rely on an older version of replication: they have a paper copy of everything that goes into the computer, and make nightly backups (small businesses, unlike large businesses, don't run 24/7 and thus the RDBMS is stable at that time of night, they don't need the ability to do "hot" backups). If the database crashes and eats their data, they restore it from tape, then manually type in any transactions that weren't on the tape (using their paper copies). PostGreSQL is already "there" as far as small businesses are concerned, from a price/feature standpoint. PostGreSQL's only real issue is performance, especially performance when adding records, which is pathetically slow (using transactions helps, in that at least you don't get a sync for each "insert" but rather a single set of syncs at the "end transaction" time, but it's still less than 1/3rd the speed of MySQL even if you turned off the syncs altogether and ran it in the dangerous "async" mode). However, most small businesses don't need to add 200,000 records in a short period of time... I can add 200,000 records in little over 3 minutes with PostGreSQL on modest hardware, which is pretty pathetic, but far beyond the needs of a small business.
How about: SCO's top management is arrogant, has their head stuck up their rear, their service sucks, their product is full of bugs and is a nightmare to support....
When Linux became mature enough to compete with SCO OpenServer, I dumped SCO OpenServer in a hearbeat. I was tired of bugs that SCO refused to fix, the yearly price increases, the yearly re-shuffling of the product line so that any quote I did for my customers had to be totally re-written (as vs. just update the pricing) for SCO's latest "well, we didn't like the way we'd split up Unix last time, we have a DIFFERENT split this year!" trick... and the unreliability. God, the unreliability! We still have OpenServer at the office. The NFS is flakey. The SCSI tape driver locks up every other night (or did until we moved the nightly backup to the Linux box). The print spooler has locked up semi-randomly for the past ten years, and SCO has never managed to make it work right. Getting any free software to compile on OpenServer is a pain in the rear because it is totally non-standard. Etc. etc. etc.
In the past SCO has skated over all of this because, as buggy as they are, they were still less buggy than Microsoft products. But most of us who were forced to use SCO Unix in an earlier life find Linux (or FreeBSD) to be such a relief that singing "ding dong, the witch is dead!" is a natural reaction to seeing SCO in trouble.
You have the right idea. The point is to get good people, not to get the "buzzword compliant". The Dallas Cowboys, during their heyday, had the theory of "draft talent, not position." That is, draft the best people, regardless of whether they were "buzzword compliant" (i.e., had the exact skill set that the Cowboys needed at that particular point in time). This kept them on top of the NFL for close to fifteen years because while some players may have been "out of position", if they were good at their job they could adjust quickly with the proper input from the coaching staff (management and co-workers) -- and if they weren't, the coaching staff could tell within a short period of time and can them before they did any damage.
As for VB apps and $45k or more for new hires, it depends on what part of the country you're in. In the Silicon Valley that would be starvation wages:-). In Shreveport, Louisiana, that would be more than the CEO of the company. I do know that one of our recent new hires (well, "recent" == "last June") said that most of his new-grad friends got a job for between $40k and $45K per year, this being in Phoenix. But they were COBOL/data processing types going out into the cusp of the Y2K-fix job market too... I doubt they'd have gotten that much for doing VB!
One thing I have discovered, BTW, is that there seems to be little correlation between high college grades and "hacker talent". Most hard core geeky types apparently prefer to be hacking on their computers rather than studying:-}. But you wouldn't know this from the recruiting practices of many major companies (such as Microsoft), most of which go almost entirely upon grades for their pre-screening of new grads.
The point is that any seriously geeky person who has been exposed to Perl and Perl-like languages can write Perl code within hours, and GOOD Perl code within days -- like any seriously geeky person, I pick up new computer languages the way that women seem to pick up shoes at the shopping mall:-) (not to mention that any seriously geeky person has SOME experience with Perl -- why do you think I use PHP3 and Python:-). And you would not give someone like me the time of day because my prior experience has been the (very Perl-like) PHP3 and (somewhat Perl-like) Python. You want the exact match, and refuse to accept otherwise well-skilled people who could do the job (and do it in Perl), especially if they like poking humorous fun at Perl I presume. ("Q: What's the difference between a Perl programmer and a COBOL programmer? A: 30 years.").
I'm not looking for a job, BTW, so don't even look for my resume. I'm quite happy with Phoenix AZ and I'm quite happy with my co-workers, who in my opinion are doing a damned good job even when I disagree with some of their decisions. I'll point out that your "must jell well with the other people you are working with" in reality translates to "must be like me". Of course, I must admit that I'm no different... when I'm making hiring recommendations, I'm looking for people who are somewhat offbeat but in a positive way, ability to quote Monty Python optional, and I'm looking for people who I feel can learn anything quickly, even if they don't have the exact skill set for the job. Gosh, people like me:-). But the point is that I realize this, and you, apparently, don't, somehow believing that everybody must be just like you in order to get along. I do believe that there is a value in a diverse workplace. I might not be on the same wavelength as the ex-Air Force officer down the hall (I'm somewhat liberal, he's a staunch Jerry Falwell Republican, I'm the eccentric professor in wrinkled clothing, he's spit and polish etc.), but I do believe he brings something to the company of value, and I don't bother trying to convert him to supporting Al Gore (grin).
Not to mention that Multics really didn't have a "kernel space". It had certain instructions that would only run in the lowest ring, and of course the kernel ran in the lowest ring, but the kernel wasn't the only thing running in the lowest ring, some of the kernel functionality was actually implemented in the processor's hardware and microcode, and a lot of the I/O processing was done by the front end processors (which is what made implementing Emacs on Multics such a ball of hair -- the FNP's weren't originally designed to do character-at-a-time I/O).
The easiest way to get a password in Multics was the old "trojan terminal" trick. Multics was usually accessed via crowded terminal rooms, and there was often a waiting list to get on (remote access back then was very expensive and few Multics installations had any remote access). Log in, run your trojan (which put up a fake login prompt), walk away. Someone else jumps on your "open" terminal, tries their personid, projectid, and password, gets 'login incorrect' message (at which point your program surreptuously exits and logs out, having saved the data to a file somewhere), and then they get the "real" login prompt. Classic, simple, almost undetectable!
Of course, that wasn't the holy grail. The holy grail was getting one of the operators' passwords, or somehow executing commands as an operator to create a ring0 gate for you (basically same as creating a suid root/bin/sh). I'm trying to remember whether it was Multics that someone tried the "smart terminal" attack on, or whether we'd already moved to Unix by that time. The TVI912 terminal would transmit the contents of its screen to the remote system when you sent ESC-7. So send a clear screen, the commands to be executed, and then ESC-7 as the payload of a Unix "write" command (or Multics equivalent -- still trying to remember whether Multics had an equivalent, darn it!), and guess what happens? (Oh, make sure to clear the screen again after you've sent the payload!). Of course, after the first time, the operators remembered to turn off messages ("biff n" on Unix):-).
I've written web shopping carts -- in Python. I've written web inventory management system front ends -- in PHP3. And like any other geek worth his name, I can learn a new computer language within a matter of weeks (though I already do know a LITTLE Perl -- why do you think I use Python and PHP3:-)?
But it seems to me that you wouldn't consider me for a second, because I don't have EXACTLY the skill set that you want. Nevermind that with my history, anybody with a dullard's amount of brains would figure that I could swiftly move in and do the job. A dullard's amount of brains don't appear to be in the requirements document for personnel departments:-{.
(Note -- I am NOT looking for a job, I am quite happy with my current one... I was merely noting what I saw as the biggest problem facing job seekers: inflexible employers who want a particular set of 'easy to define' skills, rather than valuing 'hard to measure' skills like flexibility, intelligence, and productivity).
Caldera's big problem, in my opinion, is that in the past they haven't settled on one game plan and stuck with it. Instead, they've veered all over the road, in the process wasting millions of dollars on licensing and development fees for commercial product ports that were swiftly discontinued when they switched directions yet again.
On the other hand, their upcoming products are quite solid (I've seen the beta versions, and even the beta versions are more stable than the typical Linux distribution), and they do have the top VAR program in the Linux biz. Chances are if you buy a solution that's based on Linux, it's probably based on Caldera's Linux. The problem is that 99% of the time, you don't know that it's Caldera's Linux -- or even Linux, for that matter. All you know is that you bought a "Document Imaging And Storage Solution". Thus Caldera's low profile.
We'll have to see whether Caldera has finally settled on a strategy and will stick to it. I think their current strategy is a good one... but then, so was their 1997-vintage "Linux for Business" strategy, which doesn't seem to have turned into a pot of gold.
I agree. The way the DCMA reads, Haselton's work violates the DCMA.
There's only one problem: There's another law which applies too, and this law is the supreme law of the land. It's called the Constitution of the United States of America, and it has an amendment (the 1st Amendment), which the Supremes have held explicitly protects "critical speech" that makes "fair use" of copyrighted material. What this means is that, in the end, the parts of the DMCA that consist of government inhibition of free speech will be thrown out.
The problem is that it will take years of appeals before the illegal portions of the DMCA are thrown out, and it will cost hundreds of thousands of dollars in court costs. In the meantime, software companies will continue to use tactics of intimidation and threats to prevent critical speech, much as McDonalds did with their McLibel lawsuit against Greenpeace activists.
And the next problem is that, after this law is thrown out, the companies involved will buy yet ANOTHER law that removes people's right to engage in critical speech, and the whole thing starts over again. And so it goes in the United States of Self Delusion, where we delude ourselves that we live in a free country when in actuality we are ruled by those who spend millions of dollars to buy laws that benefit themselves at the cost of the rest of us.
Strange, for a "joke", it manages to run our entire corporation ( Enhanced Software Technologies ). Even the marketing people have KDE desktops, and they are DEFINITELY non-technical people.
Linux may be a "joke" as a home user desktop, but as a corporate desktop it works, it is low maintenance (the users cannot trash their system no matter how hard they try, and all user-changable files are mounted off of the NFS server so that all user files are backed up every night without any special software other than plain old BRU), and the users have a pre-defined desktop with easy-to-use icons for all the software they need to run. And any user can log in to any machine on campus and get his own desktop -- no "roaming profiles" needed!
Upsides: Low maintenance. Easy to swap out dead machines without disrupting user's work (he can just go to another machine, or I can slide in a backup machine, he logs in, and is back to his desktop).
Downsides: User can't install games that he brings from home. Hmm, is that really a downside? (grin).
When I was a teacher, I had immunity from state prosecution -- AS LONG AS I WAS ACTING IN ACCORDANCE WITH SCHOOL DISTRICT POLICIES AND PROCEDURES.
The latter clause is what allows police officers etc. to get away with murder (literally) -- as long as they are abiding by the policies and procedures regulating their job, you have recourse only against the hiring agency, not against the individual officer. If official Goon Squad policy is to get one of those bogus overly-broad search warrants for all "hacker" cases, then the Goon Squad can be held liable, but the individual offices are indemnified (except in cases of violation of the Constitition -- it doesn't matter whether said violation is official policy or not, doing it can result in you being individually sued).
So what you're saying is that even though he wrote this fairly large project single-handedly in C++, a) he does not know the language, and b) it takes more than one project to learn C++.
Sheesh, that's enough to make me want to learn Java instead:-).
Actually, in many cases Microsoft has used their market lead such that they really DO force product upon people. For example, most school districts already have site licenses with Microsoft that cover Microsoft operating systems. Yet every #%@#$% machine that they order already comes with a Microsoft operating system pre-installed and the cost added to the price of the machine -- and the vendors complain that they must do that, due to provisions of their contract with Microsoft!
So if you insist that Microsoft has not forced their product upon anybody: You're wrong. (Just ask any Linux user, who, until last year, was unable to buy a laptop without paying Microsoft for Windows -- if that wasn't Microsoft forcing their product upon people, I don't know what is!).
Note that many temps hope that, now that 'permatemping' is not going to be the case, Microsoft will hire them as permenant employees, with full benefits etc. In some cases that will actually happen, as line managers go to bat for workers who have made themselves indispensible to their operation. In some cases it won't, as permatemps leave and are replaced by other temps.
What this means is that the temps really WILL be temps. You won't have any more of this "permatemp" stuff being used to get out of paying benefits to long-time employees. For the permatemps who get hired full-time, it's a good deal. For others, it sucks. But either way, at least you're not in limbo-land, as you are if you're a "permatemp".
is more of what the user already has. This has always been the case.
Very few innovations have occured from listening to "what the user wants". Rather, innovation occurs when people with vision implement that vision. This doesn't mean pushing users out of the loop. The designers of the Macintosh, for example, were happy to torment hapless new hire secretaries and marketroids in order to test whether their vision would fly in the real world (that's why the original Mac only had one button, BTW -- they found that the hapless marketroids would get confused about whether to click the left button or the right button, not suprising considering that most marketroids are folks who failed as used car salesmen:-). But there was no big hoard of Apple customers standing around saying "we want an easy to use computer!". Rather, Apple's customers at the time (almost all Apple II users), were standing around saying "we want more gee-whiz-bang toys!".
Substituting market research amongst the company's customers for vision is a common sign that a company is going downhill. At DEC, for example, their marketing department surveyed their customers and said that their customers wanted more and bigger minicomputers, and DEC obliged them, while meanwhile ignoring those "microcomputer" thingies that DEC's customers sneered at as "toys". As a result, there is no more DEC...
That's something that I'd be curious to know too, but remember, the EST deal has not been finalized yet. It'd be premature to announce something about such a decision when some unusual event might call the deal off. A letter of intent is not the same thing as a finalized purchase.
In the meantime, EST *has* Open Sourced some code. CRU/ODBR has been Open Sourced and anybody could grab them and modify them to operate with the backup utility of their choice. A couple of encryption modules have been Open Sourced too. Go look at for a cryptographic-quality PRNG and a TwoFish encryption module for Python.
Disclaimers:
I am an employee of EST.
I am not an "authorized speaker" for EST.
Like all low-level software engineering types, management tells me things only after they've already released the press release. Thus I have no more inside knowledge of the EST/Atipa deal than you do.
Thus all contents of this message represent my own personal opinion, and not the opinion of EST and its management.
Using 'python' mode in Emacs, a 'tab' key takes you to the current default indentation level, while the 'backspace' key drops you back an indentation level (to, say, close an 'if' block). 'pass', 'continue', 'return', and 'raise' also decrement the current default indentation level, while block signifiers (e.g. "def", "class", "if", etc.) increment the current default indentation level.
All in all, the white space issue is one of the only things I dislike about Python, but not because it's a pain to keep track of white space (Emacs, and, I presume, 'vim' or [chuckle]vigor, do that for me). Rather, it is because it makes Python hard to embed in web pages the way you can do with PHP3 or 'eperl' or similar tools. The Python zealots say that this is a feature, that you should not mix program and display in the same file, you should instead use an approach similar to ZOPE's 'DTML' (which uses SHTML-like commands to embed the results of a Python object's execution into a web page). Personally, I believe they are too quick to deprecate the advantages of sometimes embedding short little server-side scripts into web pages.
Final comment: Despite my reference to "Python zealots", I personally avoid Perl like the plague. I will use PHP3 before I use Perl. Not because PHP3 is a great language (it isn't), but because Perl is a bloated, cryptic, messy language and proud of it. Perl is a language for dog people, i.e., people who like big, shaggy, messy critters that slobber all over the place, chew on everything, etc. and that require a lot of work to maintain. Python is a language for cat people, people who like neat, independent, self-contained critters that don't require a lot of maintenance. As you can tell from my.sig, I'm one of the latter:-).
Red Hat 6.1, aside from the stupid installer, actually wasn't bad from a quality perspective. Especially by contrast with Red Hat 6.0:-). (Hint: I filled Bugzilla with bugs on RH 6.0... amazing thing was, all of'em were fixed for 6.1! I never had such behavior from Red Hat before!).
I was unimpressed by Mandrake 7.0. It did not properly detect my sound card (Red Hat 6.1 did), and while the enhancements to KDE were appreciated, Red Hat's unenhanced KDE wasn't any harder to use once you dragged a few icons a'la Mandrake out onto the desktop. And Red Hat 6.1 comes with PostGreSQL support already pre-compiled into all the web languages (Python, Perl, PHP3), so that you can sit down and write database-enabled web applications without ever installing a single software package. (Hopefully Caldera 2.4 will do this with MySQL too). Mandrake 7.0 also doesn't come with OpenLDAP or pam_ldap.
In short, Mandrake 7.0 wasn't much better than Red Hat as a workstation, was worse than Red Hat as a server (the most common use for Linux, after all), and I just didn't have much use for it.
Slashdot Mirror
Tape drive manufacturers are raising capacities via a variety of methods. They are coming up with thinner tape materials so that they can cram more tape into a cartridge (I understand there will be a DDS5 that crams over 200 meters of tape into a tiny 4mm tape cartridge!). They are coming up with new heads that either store data more densely linearly, or that store data more densely vertically (i.e. put more tracks on a tape). They've also been playing with the speed at which data is recorded, and perhaps varying that to adjust to tape quality etc. There are also experiments ongoing with multiple heads and serpentine tapes, though I haven't heard that this is buying anything (easier to have a smaller cartridge and multiple simple drives rather than big complex cartridges and one complex drive). Having seen these guys do so many "impossible" things (they said that DDS4 was impossible!), I've given up on figuring out where it's all going to end, but I do know that traditional tape drives are nowhere near their limits as far as speed and capacity go.
-E
I've been looking at the data sheets on some of the big enterprise-class storage systems. We're talking about boxes that have 5 to 15 drives, and attach via fibre channel loop to multiple servers that need to be backed up, and that have hundreds of tapes that they manage via robotics. Yes, I'm working on enhancing the Linux 'mtx' tape library control software to drive these things, though I'll never be able to personally see or test one :-}. There are some interesting challenges to handle with fibre-attached storage, specifically, the one of "who has the robotic arm now?!", but none that are unsolvable. I am confident that no matter how big hard drives get, we'll be able to back them up -- albeit for a price!
-E
Of course, we know what happened after that -- they quit using visual light, and started using shorter-wavelength beams.
A friend of mine says "Is tape storage on the way out? It's not keeping up with disk storage!".
Seagate and HP just introduced a tape drive with 100gb (UNCOMPRESSED) capacity, and they say that they can take that same technology to 250gb native. These LTO drives do this by having oodles of tracks on a tape so that a stretch of tape may have hundreds of tracks in parallel, and by using new tape materials that allow them to make the tape thinner so they can pack more tape into a cartridge. People said linear tape was dead, that helical scan would always be faster and higher capacity, but it appears that conventional wisdom is foiled again...
I don't know what hard drives are going to be like five years from now, but I do know they're not going to stall, capacity-wise, due to some "inherent" limit. Too many smart people are looking for ways to bypass those limits, either by using some other technology altogether (hmm... photo-sensitive materials??) or by figuring some way around the "limit" using clever application of the underlying physics.
-E
Not to mention that we look overseas, and we see similar problems overseas to what we're fighting here, such as the UK's "Official Secrets Act" and the UK's draconian libel laws (where you are judged guilty of libel unless you can prove beyond a reasonable doubt that you have the facts on your side), or Australia's Internet censorship laws, or the telephone monopoly in Germany that is hindering Germans from getting online... 'nuff said.
And finally, there is the language barrier. Most Americans have never bothered learning another language. Why should they, when the United States is so big and powerful? This means that most Americans could only move to other English-speaking countries, most of which haven't had much of a high tech industry. Other high-tech powerhouses such as Germany are of little interest to Americans, because we (gasp) don't speak the language...
_E
Much of Postgres's reputation for slow speed stems from attempts to use it as a CGI back end database. PostgreSQL, like Oracle, takes a long time to open and close connections. This is because PostgreSQL spawns off an entirely new process for each connection, complete with checking the user permissions etc., while MySQL spawns a thread, which is considerably faster to do but potentially less reliable if a thread dies due to a bug in the RDBMS (ask Microsoft what happens when a thread dies without releasing any locks that it has! Ever wonder why Windows dies so often?!).
In short, if you want to use PostGreSQL as a web back end, use a persistent connection -- do NOT open and close the database for each CGI transaction!
-E
Replication generally does not take place on as current a basis. Replication can be done with any currently-existing RDBMS simply by adding a "last changed" timestamp to each record, and then occasionally querying out all records before a certain timestamp and sending those records to the remote server. Replication thus ensures that you have a snapshot of the data at some point in time, but not necessarily an up-to-date version of that data.
Those differences are why replication can be done by third-party software, while "real" standby requires specific support at the RDBMS level. I have done replication with technology as crude as dBase II by explicitly programming it into my applications. Standby, on the other hand, is a different issue.
Finally: For small businesses, none of these particularly matter. Small businesses don't have the money for big replication servers and such. They rely on an older version of replication: they have a paper copy of everything that goes into the computer, and make nightly backups (small businesses, unlike large businesses, don't run 24/7 and thus the RDBMS is stable at that time of night, they don't need the ability to do "hot" backups). If the database crashes and eats their data, they restore it from tape, then manually type in any transactions that weren't on the tape (using their paper copies). PostGreSQL is already "there" as far as small businesses are concerned, from a price/feature standpoint. PostGreSQL's only real issue is performance, especially performance when adding records, which is pathetically slow (using transactions helps, in that at least you don't get a sync for each "insert" but rather a single set of syncs at the "end transaction" time, but it's still less than 1/3rd the speed of MySQL even if you turned off the syncs altogether and ran it in the dangerous "async" mode). However, most small businesses don't need to add 200,000 records in a short period of time... I can add 200,000 records in little over 3 minutes with PostGreSQL on modest hardware, which is pretty pathetic, but far beyond the needs of a small business.
-E
When Linux became mature enough to compete with SCO OpenServer, I dumped SCO OpenServer in a hearbeat. I was tired of bugs that SCO refused to fix, the yearly price increases, the yearly re-shuffling of the product line so that any quote I did for my customers had to be totally re-written (as vs. just update the pricing) for SCO's latest "well, we didn't like the way we'd split up Unix last time, we have a DIFFERENT split this year!" trick... and the unreliability. God, the unreliability! We still have OpenServer at the office. The NFS is flakey. The SCSI tape driver locks up every other night (or did until we moved the nightly backup to the Linux box). The print spooler has locked up semi-randomly for the past ten years, and SCO has never managed to make it work right. Getting any free software to compile on OpenServer is a pain in the rear because it is totally non-standard. Etc. etc. etc.
In the past SCO has skated over all of this because, as buggy as they are, they were still less buggy than Microsoft products. But most of us who were forced to use SCO Unix in an earlier life find Linux (or FreeBSD) to be such a relief that singing "ding dong, the witch is dead!" is a natural reaction to seeing SCO in trouble.
-E
As for VB apps and $45k or more for new hires, it depends on what part of the country you're in. In the Silicon Valley that would be starvation wages :-). In Shreveport, Louisiana, that would be more than the CEO of the company. I do know that one of our recent new hires (well, "recent" == "last June") said that most of his new-grad friends got a job for between $40k and $45K per year, this being in Phoenix. But they were COBOL/data processing types going out into the cusp of the Y2K-fix job market too... I doubt they'd have gotten that much for doing VB!
One thing I have discovered, BTW, is that there seems to be little correlation between high college grades and "hacker talent". Most hard core geeky types apparently prefer to be hacking on their computers rather than studying :-}. But you wouldn't know this from the recruiting practices of many major companies (such as Microsoft), most of which go almost entirely upon grades for their pre-screening of new grads.
-E
I'm not looking for a job, BTW, so don't even look for my resume. I'm quite happy with Phoenix AZ and I'm quite happy with my co-workers, who in my opinion are doing a damned good job even when I disagree with some of their decisions. I'll point out that your "must jell well with the other people you are working with" in reality translates to "must be like me". Of course, I must admit that I'm no different... when I'm making hiring recommendations, I'm looking for people who are somewhat offbeat but in a positive way, ability to quote Monty Python optional, and I'm looking for people who I feel can learn anything quickly, even if they don't have the exact skill set for the job. Gosh, people like me :-). But the point is that I realize this, and you, apparently, don't, somehow believing that everybody must be just like you in order to get along. I do believe that there is a value in a diverse workplace. I might not be on the same wavelength as the ex-Air Force officer down the hall (I'm somewhat liberal, he's a staunch Jerry Falwell Republican, I'm the eccentric professor in wrinkled clothing, he's spit and polish etc.), but I do believe he brings something to the company of value, and I don't bother trying to convert him to supporting Al Gore (grin).
-E
The easiest way to get a password in Multics was the old "trojan terminal" trick. Multics was usually accessed via crowded terminal rooms, and there was often a waiting list to get on (remote access back then was very expensive and few Multics installations had any remote access). Log in, run your trojan (which put up a fake login prompt), walk away. Someone else jumps on your "open" terminal, tries their personid, projectid, and password, gets 'login incorrect' message (at which point your program surreptuously exits and logs out, having saved the data to a file somewhere), and then they get the "real" login prompt. Classic, simple, almost undetectable!
Of course, that wasn't the holy grail. The holy grail was getting one of the operators' passwords, or somehow executing commands as an operator to create a ring0 gate for you (basically same as creating a suid root /bin/sh). I'm trying to remember whether it was Multics that someone tried the "smart terminal" attack on, or whether we'd already moved to Unix by that time. The TVI912 terminal would transmit the contents of its screen to the remote system when you sent ESC-7. So send a clear screen, the commands to be executed, and then ESC-7 as the payload of a Unix "write" command (or Multics equivalent -- still trying to remember whether Multics had an equivalent, darn it!), and guess what happens? (Oh, make sure to clear the screen again after you've sent the payload!). Of course, after the first time, the operators remembered to turn off messages ("biff n" on Unix) :-).
-E
But it seems to me that you wouldn't consider me for a second, because I don't have EXACTLY the skill set that you want. Nevermind that with my history, anybody with a dullard's amount of brains would figure that I could swiftly move in and do the job. A dullard's amount of brains don't appear to be in the requirements document for personnel departments :-{.
(Note -- I am NOT looking for a job, I am quite happy with my current one... I was merely noting what I saw as the biggest problem facing job seekers: inflexible employers who want a particular set of 'easy to define' skills, rather than valuing 'hard to measure' skills like flexibility, intelligence, and productivity).
-E
On the other hand, their upcoming products are quite solid (I've seen the beta versions, and even the beta versions are more stable than the typical Linux distribution), and they do have the top VAR program in the Linux biz. Chances are if you buy a solution that's based on Linux, it's probably based on Caldera's Linux. The problem is that 99% of the time, you don't know that it's Caldera's Linux -- or even Linux, for that matter. All you know is that you bought a "Document Imaging And Storage Solution". Thus Caldera's low profile.
We'll have to see whether Caldera has finally settled on a strategy and will stick to it. I think their current strategy is a good one... but then, so was their 1997-vintage "Linux for Business" strategy, which doesn't seem to have turned into a pot of gold.
-E
There's only one problem: There's another law which applies too, and this law is the supreme law of the land. It's called the Constitution of the United States of America, and it has an amendment (the 1st Amendment), which the Supremes have held explicitly protects "critical speech" that makes "fair use" of copyrighted material. What this means is that, in the end, the parts of the DMCA that consist of government inhibition of free speech will be thrown out.
The problem is that it will take years of appeals before the illegal portions of the DMCA are thrown out, and it will cost hundreds of thousands of dollars in court costs. In the meantime, software companies will continue to use tactics of intimidation and threats to prevent critical speech, much as McDonalds did with their McLibel lawsuit against Greenpeace activists.
And the next problem is that, after this law is thrown out, the companies involved will buy yet ANOTHER law that removes people's right to engage in critical speech, and the whole thing starts over again. And so it goes in the United States of Self Delusion, where we delude ourselves that we live in a free country when in actuality we are ruled by those who spend millions of dollars to buy laws that benefit themselves at the cost of the rest of us.
-E
Linux may be a "joke" as a home user desktop, but as a corporate desktop it works, it is low maintenance (the users cannot trash their system no matter how hard they try, and all user-changable files are mounted off of the NFS server so that all user files are backed up every night without any special software other than plain old BRU), and the users have a pre-defined desktop with easy-to-use icons for all the software they need to run. And any user can log in to any machine on campus and get his own desktop -- no "roaming profiles" needed!
Upsides: Low maintenance. Easy to swap out dead machines without disrupting user's work (he can just go to another machine, or I can slide in a backup machine, he logs in, and is back to his desktop).
Downsides: User can't install games that he brings from home. Hmm, is that really a downside? (grin).
-E
The latter clause is what allows police officers etc. to get away with murder (literally) -- as long as they are abiding by the policies and procedures regulating their job, you have recourse only against the hiring agency, not against the individual officer. If official Goon Squad policy is to get one of those bogus overly-broad search warrants for all "hacker" cases, then the Goon Squad can be held liable, but the individual offices are indemnified (except in cases of violation of the Constitition -- it doesn't matter whether said violation is official policy or not, doing it can result in you being individually sued).
-E
Sheesh, that's enough to make me want to learn Java instead :-).
-E
So if you insist that Microsoft has not forced their product upon anybody: You're wrong. (Just ask any Linux user, who, until last year, was unable to buy a laptop without paying Microsoft for Windows -- if that wasn't Microsoft forcing their product upon people, I don't know what is!).
-E
What this means is that the temps really WILL be temps. You won't have any more of this "permatemp" stuff being used to get out of paying benefits to long-time employees. For the permatemps who get hired full-time, it's a good deal. For others, it sucks. But either way, at least you're not in limbo-land, as you are if you're a "permatemp".
-E
Very few innovations have occured from listening to "what the user wants". Rather, innovation occurs when people with vision implement that vision. This doesn't mean pushing users out of the loop. The designers of the Macintosh, for example, were happy to torment hapless new hire secretaries and marketroids in order to test whether their vision would fly in the real world (that's why the original Mac only had one button, BTW -- they found that the hapless marketroids would get confused about whether to click the left button or the right button, not suprising considering that most marketroids are folks who failed as used car salesmen :-). But there was no big hoard of Apple customers standing around saying "we want an easy to use computer!". Rather, Apple's customers at the time (almost all Apple II users), were standing around saying "we want more gee-whiz-bang toys!".
Substituting market research amongst the company's customers for vision is a common sign that a company is going downhill. At DEC, for example, their marketing department surveyed their customers and said that their customers wanted more and bigger minicomputers, and DEC obliged them, while meanwhile ignoring those "microcomputer" thingies that DEC's customers sneered at as "toys". As a result, there is no more DEC...
-E
In the meantime, EST *has* Open Sourced some code. CRU/ODBR has been Open Sourced and anybody could grab them and modify them to operate with the backup utility of their choice. A couple of encryption modules have been Open Sourced too. Go look at for a cryptographic-quality PRNG and a TwoFish encryption module for Python.
Disclaimers:
- I am an employee of EST.
- I am not an "authorized speaker" for EST.
- Like all low-level software engineering types, management tells me things only after they've already released the press release. Thus I have no more inside knowledge of the EST/Atipa deal than you do.
- Thus all contents of this message represent my own personal opinion, and not the opinion of EST and its management.
-EAll in all, the white space issue is one of the only things I dislike about Python, but not because it's a pain to keep track of white space (Emacs, and, I presume, 'vim' or [chuckle]vigor, do that for me). Rather, it is because it makes Python hard to embed in web pages the way you can do with PHP3 or 'eperl' or similar tools. The Python zealots say that this is a feature, that you should not mix program and display in the same file, you should instead use an approach similar to ZOPE's 'DTML' (which uses SHTML-like commands to embed the results of a Python object's execution into a web page). Personally, I believe they are too quick to deprecate the advantages of sometimes embedding short little server-side scripts into web pages.
Final comment: Despite my reference to "Python zealots", I personally avoid Perl like the plague. I will use PHP3 before I use Perl. Not because PHP3 is a great language (it isn't), but because Perl is a bloated, cryptic, messy language and proud of it. Perl is a language for dog people, i.e., people who like big, shaggy, messy critters that slobber all over the place, chew on everything, etc. and that require a lot of work to maintain. Python is a language for cat people, people who like neat, independent, self-contained critters that don't require a lot of maintenance. As you can tell from my .sig, I'm one of the latter :-).
_E
'Nuff said.
-E
I was unimpressed by Mandrake 7.0. It did not properly detect my sound card (Red Hat 6.1 did), and while the enhancements to KDE were appreciated, Red Hat's unenhanced KDE wasn't any harder to use once you dragged a few icons a'la Mandrake out onto the desktop. And Red Hat 6.1 comes with PostGreSQL support already pre-compiled into all the web languages (Python, Perl, PHP3), so that you can sit down and write database-enabled web applications without ever installing a single software package. (Hopefully Caldera 2.4 will do this with MySQL too). Mandrake 7.0 also doesn't come with OpenLDAP or pam_ldap.
In short, Mandrake 7.0 wasn't much better than Red Hat as a workstation, was worse than Red Hat as a server (the most common use for Linux, after all), and I just didn't have much use for it.
-E
You might call Piglet a snapshot of Rawhide. Or not.
-E
If the behavior would currently be illegal, wait a few months until BMG has time to rent a few congresscritters.
-E