What's scary is that many people who were among the first Linux converts have been out in the workforce long enough to actually be the boss-- which helps Linux acceptance tremendously and will only get better in the future.
Also, as in any case where one needs to convince one's boss of the "right" thing to do there are a few things to keep in mind:
Bosses get the final decision No matter how much you might wish to do things otherwise, your boss does get final say in what happens-- even if he/she is wrong. Overriding your bosses final decision with your own is unprofessional and reduces your credibility the next time. (see below for more discussion)
Bosses need a high-level view Don't try to convince your nontechnical boss that Linux is better because of the way it works internally. Speak in terms of high-level views-- e.g. it's more reliable, it scales better, it's easier to manage, etc. Present this first and when they want more detail give it out in layers of progressively more information. E.g. it's more reliable because <insert feature appropriate to the discussion here>. If they still want more detail (rare) then you can start talking internals.
Know thy enemy Your opinions will count for a lot more if you know both sides of the issue. Damning testimony about the horrors of Exchange means a lot more coming from someone who's actually worked with it than someone who only knows sendmail. Study both the advantages of competing products as well as their disadvantages-- you'll be able to answer tough questions better this way.
Be patient Maybe it didn't work out this time-- try to find out why and on your own time research the areas where your solution was seen to be deficient. This may not be for technical reasons, but that doesn't automatically make them less valid. What can you do to assuage your boss's fears next time? You may need to learn some nontechnical skills to accomplish this, such as budgetting, business management, vendor relations, etc. It'll make you a more valuable employee and your opinions will be more respeceted next time.
Be accomidating Most reasonable supervisors will let their staff work on thier own "pet projects" if they can be assured that it's not taking them away from the business priorities. See if your boss will let you set up an old scrap PC with Linux as a test system. Assure him that it won't interfere with your work and BE SURE IT DOESN'T This will mean dropping the test system work when real work needs to be done. You can show him just how useful Linux is by pointing out how you and your buddies have been pounding on it for months with no trouble whereas this "other server" has been nothing but problems in the interim.
In short, "smuggling" is a bad idea-- unless your boss is completely closed-minded. (In this case, maybe it's time to dust off the resume and look for someplace with better bosses.) If you can convince your boss that it's better to go with an Open Source solution, maybe he'll be able to convince other bosses and it'll spread company-wide. This would eliminate the "non-standard" argument we've all heard so often.
Your supervisor is there to make decisions-- let him/her do it.
BE CAREFUL-- a company I used to work for used viral techniques for automatically installing/updating antivirus software and quickly gave up on the idea. It's too easy to "spread" to a system where you don't want to have the fix applied.
A better solution is to run it as a non-viral application as part of the user's network login.
If you're dead-set on using viral techniques make sure that the application checks a central server for a blacklist of systems to refrain from infecting, and a whitelist of network addresses to ONLY infect. This will allow you to control its spread. Also-- be sure to include a self-destruct/undo capability triggered by this same server, and include an unambigious string that is easy to add to your virus scanners should it "get away" from you.
Again, it's really better to avoid doing this at all. Been there.
Unfortunately, there are plenty of people out there who find sending "direct mail" (aka spam) a perfectly acceptable form of product marketing. Many of them work for otherwise reputable companies.
This is a good time to find out if YOUR company sends those nasty "direct mails" out to people. If not your company, how about companies you do business with? Many places won't care what one person thinks, but when they start to see thousands, or (if you're so lucky to work for a larger company) millions of dollars in lost revenues because of their spam they might start to listen.
Techies like us have more influence on buying decisions and corporate policy than most people realize. Let's use it!
Let's consider the options on whether to believe this. I figure there are two options:
Option one, Lucas decides to release the DVD version of Episode 1. By doing this, he goes back on several years of announcing there would be no DVD version until the series was complete. In addition, he decides not to make a general announcement but instead leaks the information to one distributor, forgoing the chance to make a big deal of the fact that this will indeed be the first Star Wars DVD released.
Option two, Suncoast messed up by announcing something that doesn't really exist, which happens all the time
Seriously, in all likelihood this is just a misunderstanding based on a mistake made at Suncoast.
Maybe I should just break down and replace my 8-year old drives, but in the meantime software RAID-5 is an economical way to weather the frequent drive failures.
Unfortunately, it does not seem to be included in the pre3 kernel. Anyone know what's going on with this?
You're not the only one-- I'm running this on a fairly beefy box and it still takes a LONG time (as in several days) to complete a single work unit. In order for the daily stats to be useful, it seems like one ought to be able to finish more than one work unit per day.
It's my hope that this is what they mean by: we will have the opportunity to improve some other aspects of client operation. In particular, we plan to add more configurable checkpointing and a better display of progress in their announcement.
As to the speed of the whole search-- that would depend as much on the size of the search space as on the speed of the client. Clearly we are looking at a real small search space if it were 25% searched in only a few days.
I know they never counted my seven days' work since it's all still sitting in my buff-out.ogr file. I'm using the dnetc v2.8007-458-CTR-00020606 for Linux (Linux 2.2.12-20) client-- perhaps it's client-specific?
Talk about a complete lack of research-- these guys just made up something that sounded good. According to Kirk McKusick, current copyright holder of the BSD Daemon, the term 'daemon' comes directly from the mythological creatures of the same name responsible for taking care of mundane tasks.
For more detail, see Webster's dictionary, in this case we are looking at variant 2, "an attendant power or spirit". Whether daemons are evil as in "demon" variant 1 depends on whether they are working or not. Some days sendmail definately qualifies as the latter.
Consider also RedHat, which has been around for a much shorter period of time. Their Bug reporting system reports a total of about 1640 new, reopened, and assigned bugs with 140 bugs new this week. If Redhat had the same user base as windows, their bug system would likely report similar numbers.
Time and experience with the new OS will be the true test of its stability. Just think of how the bug counts will grow once it's been released to the rampaging mobs!
The AOL idea sounds like a pretty good deal-- my only concern would be how to change the dialup number. Is this something the user can control, or does the AOL software try to remove this "burden" by making it not user-selectable?
Also, does AOL have a list of dialup numbers and locations posted so that the numbers could be copied down ahead of time?
It seems unlikely that this person would be able to get decent cellular coverage out in the middle of nowhere. They seem contented with dialling up from the motels they encounter along the way.
With that said, be aware that some places do not use normal analog phone lines. The digital lines they use may fry your modem. I'm willing to bet that the cheapo places along the planned route will present no problems, but it might be wise to call ahead where possible.
Also, it would be worthwhile to bring along an external modem as a fallback for the PCMCIA modem. I've found PCMCIA modems to be rather fragile when plugged into things they ought not to have been plugged into, whereas my USR Courier has taken all kinds of abuse without complaint.
I find it hard to believe that Yahoo wasn't set up to cope with the denial-of-service attacks I've seen described so far. I'm sure that everyone who works on a web site with more than 10-20 million hits/day has dealt with these attacks.
For example, for the venerable SYN flood attack all one needs to due is tune the kernel to cope with it. SYN floods happen to most large sites on a daily basis.
The connect-to-port-80-and-hold attack is hard for a multiprocessing server like apache to deal with since it has to fork() for each connection. For a multithreaded server it's no problem at all-- it just needs a large pool of threads at its disposal. Each open connection takes up a thread until it times out, but thread creation takes up minimal resources. These connections are not always logged with the IP address in the web server, though perhaps they ought to be.
A worse problem, and perhaps this is what happened, is if an actual GET takes place. In this case the thread has to do something other than merely exist. Each IP address is dutifully logged, making it possible to track down the participants in the attack. (Of course this leads into the other thread here on whether people who are not malicious, but whose systems were hijacked, should be liable.)
Does anyone know exactly what kind of attack this was? Was it directed at the Yahoo site and the routers just melted, or was it directed at the routers themselves? (E.g. bogus routing messages flooding the routers with false updates or other routing-level attacks.)
I'd hate to see Yahoo's networking bill for this month.
In the days of 200MB hard drives, Western Digital was king. They made solid, inexpensive, high-performance drives.
About the time of the 500MB hard drive, they started cheapening things up. Cache sizes were reduced, and while everyone else was looking towards a screaming 5400RPM, Western Digital stuck at 3600.
This seemed to peak about the time of the 1.2/1.6GB drives. These had a tiny, tiny cache and performed abysmally, despite the WD propaganda about how their 128K cache was somehow better than everyone else's 512K cache. The post-install failure rate from my experience was on the order of 20-30%, with an early-life failure rate of about 30-40%, based on about 200 sold.
About this time, Seagate was making a 1.0GB low-profile drive that was rock-solid. Of about 500 sold, I saw two go bad. I haven't gone back to Western Digital since.
When talking about drive reliability for a particular manufacturer, it's important to give a timeframe. Different manufacturers have been good at different times, and who is great one year might suck the next.
Yes, these can be used just like real Tarot cards. Don't know how to use Tarot cards? I'd suggest starting with the alt.tarot FAQ, just like any good Internet junkie would.
Lots of people are going to need to decide whether they are going to pony up a minumum of $1,100.00 to buy shares in VA. Be sure to follow their instructions and READ THE PROSPECTUS before you agree to buy the shares.
And to protect myself from the lawyers, I need to tell you that I am not offering financial or legal advice. I'm just some schmuck who has thoughts to share. All are offered as-is with no warranty, etc. etc.
The S-1 Filing for the company is available online. Note that they also have a number of S-1/A filings online.
Here are some thoughts on the company:
Revenues
Thankfully, VA has a fairly good revenue stream ( 1998: $5,556,000.00 1999: $17,710,000.00 ) however, when one looks at the cost of revenues it also goes up, and in fact goes up disproportionately. ( 1998: $4,494,000.00 1999: $17,766,000.00 ).
This means that while VA had a pretty good gross margin in 1998, they actually went negative for 1999. Not a good trend.
The "gross margin" they mean here is how much they earned or lost by producing their product. A company can never be profitable until the gross margin is positive. When the gross margin is negative, the company is losing money on each unit sold. When the gross margin is positive and the company sells enough units they will make a profit, what being in business is ultimately about.
One has to wonder what happened that the gross margin went from $1,062,000.00 in 1998 to -$56,000 in 1999. Why did the cost of revenues go up so much?
Speculative Limitations
Deutsche Banc Alex requires you to send funds within three days of the IPO to cover your positions. Additionally, they take 10 days to wait for your check to clear. You may not transfer the shares to any other broker until your check has cleared. Note that they do not appear to offer online trading, and only have a single non-800 number listed to trade shares. They will only accept market orders (e.g. sell at any price) for the first day. All this for the low, low commission of $53.
Selected Risks
History of losses
The prospectus says it best:
We have a history of losses and expect to continue to incur net losses for the foreseeable future.
We incurred losses of $14.5 million in fiscal 1999 primarily due to expansion of our operations, and we had an accumulated deficit of $29.9 million as of October 29, 1999. We expect to continue to incur significant product development, sales and marketing and administrative expenses, particularly as a result of expanding our direct sales force. In addition, we are investing considerable resources in our professional services organization and our Internet operations. We do not expect to generate sufficient revenues to achieve profitability and, therefore, we expect to continue to incur net losses for at least the foreseeable future. If we do achieve profitability, we may not be able to sustain it.
No plans to make money into the forseeable future? Ouch. Now you know one reason why IPOs are considered risky. If their cost of revenues (which does not include administrative, sales, marketing, etc. costs as far as I know) does not come down, they'll be unable to make money even if they "generate sufficient revenues".
Synnex Dependency
We rely on Synnex as our single source contract manufacturer. If Synnex is unable to meet our manufacturing needs or our relationship terminates, we may lose revenues and damage our customer relationships.
So VA's server business (which in an earlier risk was mentioned to be 59% of their fiscal 1998 revenues and 88% of their revenues in the quarter ending October 29 1999) is completely tied to Synnex. Who's Synnex? Are they a stable company? Any risks associated with Synnex would naturally be inherited by VA due to this single-supplier arrangement.
Irritating Developers
If the Linux developer community fails to support us or reacts negatively to our business strategy, our business will be harmed.
The third parties in the Linux developer community, upon whom we rely to develop and maintain a majority of our software, may not continue to support us, our product promotions or our corporate or operating decisions. If we lose the support of these third parties, we would be forced to rely to a significantly greater extent on our own development efforts, which would require us to hire additional developers and increase our development expenses and could adversely impact product release schedules. In addition, negative reactions of third parties in the Linux developer community could harm our reputation, diminish our brand and result in lower net revenues.
Hmmm... they must read Slashdot as well.;-> I personally don't think this is a significant risk, but yes, it's there.
And speaking of irritating the developers, how about this little tidbit:
Intellectual Property
We may not be able to use intellectual property to protect ourselves from competition.
Our systems consist primarily of commodity hardware components in combination with the Linux operating system. While we have developed some proprietary techniques and expertise, most of our activities and systems are not protectable as proprietary intellectual property and may be used by competitors, harming our market share and product revenues. To protect our intellectual property, we generally enter into confidentiality or license agreements with our employees, consultants and corporate partners. We have also recently commenced a patent program and to date have filed one patent application. In general, however, we have taken only limited steps to protect our intellectual property. Accordingly, we may be unable to use intellectual property to prevent other companies from competing with us. In addition, we may be unable to prevent third parties from developing techniques that are similar or superior to our technology, or from designing around our copyrights, patents and trade secrets.
This is to be expected from any Open Source company. Hopefully the GPL will be deemed enforceable in a court of law which will limit the ability of competitors to compete unless they too assume this risk.
And yes, the doubts on enforceability of the General Public Licence were also listed as a risk.
Dilution
You will experience immediate and substantial dilution in the book value of your shares.
The initial public offering price is substantially higher than the book value per share of our outstanding common stock immediately after the offering. Accordingly, if you purchase common stock in the offering, youwill incur immediate dilution of approximately $10.41, assuming an initial public offering price of $12.00 per share, in the book value per share of our common stock from the price you pay for our common stock. For additional information on dilution of the book value of your shares, see "Dilution."
It's pretty common to have significant dilution as part of an IPO, but the magnitude of this dilution is enough to give one pause. Keep in mind that you'd be paying $11-13 for something only worth approximately $1.59.
Of course, if you're just in the mood to gamble, this is as good as any. However, this could be a great opportunity to take a look at a company's financials and really try to decode them. You'll find that it's not that much harder than picking through some ugly perl script once you know how to do it, and it can be much more profitable...;->
Any other thoughts on the soundness of this company?
Unfortunately, it is not easy to do a "proper" installation on a Win32 system. (Which, curiously enough, are the source of most of the complaints about SSH1 servers.) The DataFellows SSH2 Win32 client simply refuses to connect to an SSH1 server. I'll admit that it has been many months since I tried, so it's possible that they've since come to their senses.
Don't even get me started about wishing for a better scp client. (The only one I know of requires CygWin-- which is too large for many users to download.)
A great many people install just ssh2, assuming that since it's newer it will connect properly to all existing ssh servers. These people usually get a nasty surprise and start complaining that the ssh servers are "broken". I'm forced to agree. ("Broken as designed" comes to mind...)
It's also a toss-up whether a binary distribution was built "properly" or not. Of course, something as critical as ssh really ought to be built from the sources, but laziness can be a great motivator.
BTW, I agree that the SSH2 version is a better protocol-- I just wish DataFellows had implemented it so that the upgrade could be more trouble-free.
Actually, OpenSSH and the original ssh are equally affected by US laws against exporting cryptography. The difference is that the OpenBSD people are not located in the US, so they don't need to worry about exporting ssh. If RedHat weren't a US company you could already download ssh RPMs from them without filling out any forms.
Of course, you can already find RPMs for ssh from other non-US sites. Try rpmfind.net.
There seems to be a bit of confusion about exactly what this software offers over the standard SSH. Hopefully I can help clear it up a bit.
Licensing
SSH1 comes with a license which is rather ambiguous about commercial use. The most common interpretation is that it's OK to use it commercially so long as one isn't making a profit directly off it. (e.g. charging people for the software.) SSH2 is much clearer-- in order to use SSH2 in a business you must use the closed-source, $400-a-server version from DataFellows.
Here is the vague portion of the SSH1 license:
Companies are permitted to use this program as long as it is not used for revenue-generating purposes. For example, an Internet service provider is allowed to install this program on their systems and permit clients to use SSH to connect; however, actively distributing SSH to clients for the purpose of providing added value requires separate licensing.
Compatibility
SSH2 clients cannot talk to SSH1 servers. This was by design in an attempt to drive people to upgrade to the new protocol. SSH1 clients are able to talk to SSH2 servers.
Patents
The IDEA (default) algorithm is patented and requires a license to use commercially. The RSA algorithm is also patented, but that patent has either expired or is about to expire. If one can find a copy of "rsaref", formerly offered freely from RSA's FTP site, then one can use it instead of the internal RSA algorithm to work around this little hurdle.
One reason there is demand for another implementation of the SSH protocol is so that people in small businesses can continue to use SSH while still maintaining access to the source code and also staying $400/server closer to being profitable.
Given the incompatibility of the clients, upgrading from SSH1 to SSH2 requires a flag day upon which day every client and server must be simultaneously upgraded to SSH2. Trying to upgrade in stages results in those with SSH2 unable to connect to SSH1 servers. It is possible to install both versions of the client, but the user will have to be the one "failing over" to the other version. Irritating at best, costly and time-consuming at worst.
No, actually you can stop chewing on that foot. Much of the client is still closed-source. Here are the reasons they give (on the same page linked from above):
Why is distributed.net still closed-source?
Although we are providing all of the code linked on this page for public perusal, it is still necessary to keep select portions of the codebase unavailable for general distribution. Indeed, this is an aspect of our operations that we would very much like to be able to eliminate. However, there are several motivating arguments against open-source development with the current clients:
there exist people who would want to modify the client to purposely report unchecked blocks as being completed for the purposes of raising their statistics.
others may want to ruin the project for everyone by intentionally opening the possibility of bypassing the solution key.
the project could additionally be spoiled by attempting to overwhelm the keyservers by falsely submitting fake solutions or fake completions.
although unlikely, it is possible that home-made binaries contain coding mistakes or compilation errors. Admittedly, binary-only clients released by distributed.net could also contain errors, but the chances of such an error remaining hidden for long are virtually zero, and once such an error is discovered by us, we can confidently exclude blocks reported by specific binary versions of the client that are known to be defective.
Thankfully, they realize that client-side security is no security at all, and appear to be working on a server-side authentication method.
I admit, it would be very nice to have the complete code-- especially for people experimenting on bizarre high-end hardware. At one time I was very interested in building an HP-PA 2.0 version of the client, but alas the source was not to be had. I also had some PowerPC 620 system running AIX which could have been used-- note the distinct lack of any AIX clients this time.
Here's to hoping that either:
People stop vandalizing useful projects, rendering the need for security obsolete. (Hey, I can dream!)
or...
They get some good, solid server-side security set up soon.
This one is pretty scary. Normally after all the uproar dies down and the claims are read it's not too bad. This one really is.
Claim 1
1. A method for running an application as an X-Client so as to enable the application to be displayed with an X-Windows manager, the method comprising the steps of:
launching a "WINDOWS/NT" session;
I.e. starting a copy of Win98 inside VMware
invoking an application from within the "WINDOWS/NT" session;
I.e. starting up MS-Word
monitoring output messages that are sent from the application;
I.e. X-windows is constantly reading your mouse position
determining that one of the monitored output messages is a graphical user interface command;
I.e. you've just clicked your mouse and dragged it over your typo
and when the monitored output message is a graphical user interface command, enabling an X-Windows manager program to act on the command, and informing the "WINDOWS/NT" device driver of results of the command that was acted on by the X-Windows manager program, wherein the enabling step includes converting the graphical user interface command from a "WINDOWS/NT" format into a format that is recognized by X-Windows manager program to enable the X-Windows manager program to act on the command.
I.e. MS-Word now realizes that you've highlighted a selection of text.
I have to say of all the dubious patents we've seen floating by recently, this one takes the cake. They just patented running Windows apps. inside X-Windows. Neato.
However, if you don't launch an application from within Windows you're OK. And since IE is part of the operating system and not an application, you can freely browse the web in VMware without violating their patent.;->
The Ex-Mozilla site has a self-maintaining list of people who have fled Netscape. Ironically, there is also a My Netscape Network channel which lists the most recently changed entries on Ex-Mozilla.
I had to laugh at some of the postings. The "expertise" requirements in some cases were absurd. One place wanted 23 years of ABAP/4 expertise. ABAP/4 wasn't even a pipe dream 23 years ago.
Reminds me of one of my buddies who went to a job interview in 1992 where they wanted someone with 10 years of NT experience. I bet they were looking for a LONG time...
Sun's internal disks indeed only work with Sun SCSI cards. However, Sun SCSI cards will work with other disks, and Sun's external disks work with other SCSI cards. Sorry if I wasn't clear.
Slashdot Mirror
What's scary is that many people who were among the first Linux converts have been out in the workforce long enough to actually be the boss-- which helps Linux acceptance tremendously and will only get better in the future.
Also, as in any case where one needs to convince one's boss of the "right" thing to do there are a few things to keep in mind:
No matter how much you might wish to do things otherwise, your boss does get final say in what happens-- even if he/she is wrong. Overriding your bosses final decision with your own is unprofessional and reduces your credibility the next time. (see below for more discussion)
Don't try to convince your nontechnical boss that Linux is better because of the way it works internally. Speak in terms of high-level views-- e.g. it's more reliable, it scales better, it's easier to manage, etc. Present this first and when they want more detail give it out in layers of progressively more information. E.g. it's more reliable because <insert feature appropriate to the discussion here>. If they still want more detail (rare) then you can start talking internals.
Your opinions will count for a lot more if you know both sides of the issue. Damning testimony about the horrors of Exchange means a lot more coming from someone who's actually worked with it than someone who only knows sendmail. Study both the advantages of competing products as well as their disadvantages-- you'll be able to answer tough questions better this way.
Maybe it didn't work out this time-- try to find out why and on your own time research the areas where your solution was seen to be deficient. This may not be for technical reasons, but that doesn't automatically make them less valid. What can you do to assuage your boss's fears next time? You may need to learn some nontechnical skills to accomplish this, such as budgetting, business management, vendor relations, etc. It'll make you a more valuable employee and your opinions will be more respeceted next time.
Most reasonable supervisors will let their staff work on thier own "pet projects" if they can be assured that it's not taking them away from the business priorities. See if your boss will let you set up an old scrap PC with Linux as a test system. Assure him that it won't interfere with your work and BE SURE IT DOESN'T This will mean dropping the test system work when real work needs to be done. You can show him just how useful Linux is by pointing out how you and your buddies have been pounding on it for months with no trouble whereas this "other server" has been nothing but problems in the interim.
In short, "smuggling" is a bad idea-- unless your boss is completely closed-minded. (In this case, maybe it's time to dust off the resume and look for someplace with better bosses.) If you can convince your boss that it's better to go with an Open Source solution, maybe he'll be able to convince other bosses and it'll spread company-wide. This would eliminate the "non-standard" argument we've all heard so often.
Your supervisor is there to make decisions-- let him/her do it.
A new variant is already making the rounds. Does anyone know the best way to configure sendmail to reject ALL Visual Basic attachments?
The new variant uses a subject of "fwd: Joke"
BE CAREFUL-- a company I used to work for used viral techniques for automatically installing/updating antivirus software and quickly gave up on the idea. It's too easy to "spread" to a system where you don't want to have the fix applied.
A better solution is to run it as a non-viral application as part of the user's network login.
If you're dead-set on using viral techniques make sure that the application checks a central server for a blacklist of systems to refrain from infecting, and a whitelist of network addresses to ONLY infect. This will allow you to control its spread. Also-- be sure to include a self-destruct/undo capability triggered by this same server, and include an unambigious string that is easy to add to your virus scanners should it "get away" from you.
Again, it's really better to avoid doing this at all. Been there.
Unfortunately, there are plenty of people out there who find sending "direct mail" (aka spam) a perfectly acceptable form of product marketing. Many of them work for otherwise reputable companies.
This is a good time to find out if YOUR company sends those nasty "direct mails" out to people. If not your company, how about companies you do business with? Many places won't care what one person thinks, but when they start to see thousands, or (if you're so lucky to work for a larger company) millions of dollars in lost revenues because of their spam they might start to listen.
Techies like us have more influence on buying decisions and corporate policy than most people realize. Let's use it!
Let's consider the options on whether to believe this. I figure there are two options:
Option one, Lucas decides to release the DVD version of Episode 1. By doing this, he goes back on several years of announcing there would be no DVD version until the series was complete. In addition, he decides not to make a general announcement but instead leaks the information to one distributor, forgoing the chance to make a big deal of the fact that this will indeed be the first Star Wars DVD released.
Option two, Suncoast messed up by announcing something that doesn't really exist, which happens all the time
Seriously, in all likelihood this is just a misunderstanding based on a mistake made at Suncoast.
Maybe I should just break down and replace my 8-year old drives, but in the meantime software RAID-5 is an economical way to weather the frequent drive failures.
Unfortunately, it does not seem to be included in the pre3 kernel. Anyone know what's going on with this?
All the more reason to keep using text-based mailreaders
The best examples of this tracking are like this:
<IMG SRC="http://www.doubleclick.net/images/hidden-cgi/ pixel.gif?you@your-mail.com">
Where they send a 1x1 transparent image-- you'll never even see it unless you 'view source', and of course by then it's too late.
Gotta love fetchmail + pine! You get to see the source every time, before it can hurt you.
You're not the only one-- I'm running this on a fairly beefy box and it still takes a LONG time (as in several days) to complete a single work unit. In order for the daily stats to be useful, it seems like one ought to be able to finish more than one work unit per day.
It's my hope that this is what they mean by: we will have the opportunity to improve some other aspects of client operation. In particular, we plan to add more configurable checkpointing and a better display of progress in their announcement.
As to the speed of the whole search-- that would depend as much on the size of the search space as on the speed of the client. Clearly we are looking at a real small search space if it were 25% searched in only a few days.
I know they never counted my seven days' work since it's all still sitting in my buff-out.ogr file. I'm using the dnetc v2.8007-458-CTR-00020606 for Linux (Linux 2.2.12-20) client-- perhaps it's client-specific?
Talk about a complete lack of research-- these guys just made up something that sounded good. According to Kirk McKusick, current copyright holder of the BSD Daemon, the term 'daemon' comes directly from the mythological creatures of the same name responsible for taking care of mundane tasks.
For more detail, see Webster's dictionary, in this case we are looking at variant 2, "an attendant power or spirit". Whether daemons are evil as in "demon" variant 1 depends on whether they are working or not. Some days sendmail definately qualifies as the latter.
Consider also RedHat, which has been around for a much shorter period of time. Their Bug reporting system reports a total of about 1640 new, reopened, and assigned bugs with 140 bugs new this week. If Redhat had the same user base as windows, their bug system would likely report similar numbers.
Time and experience with the new OS will be the true test of its stability. Just think of how the bug counts will grow once it's been released to the rampaging mobs!
The AOL idea sounds like a pretty good deal-- my only concern would be how to change the dialup number. Is this something the user can control, or does the AOL software try to remove this "burden" by making it not user-selectable?
Also, does AOL have a list of dialup numbers and locations posted so that the numbers could be copied down ahead of time?
It seems unlikely that this person would be able to get decent cellular coverage out in the middle of nowhere. They seem contented with dialling up from the motels they encounter along the way.
With that said, be aware that some places do not use normal analog phone lines. The digital lines they use may fry your modem. I'm willing to bet that the cheapo places along the planned route will present no problems, but it might be wise to call ahead where possible.
Also, it would be worthwhile to bring along an external modem as a fallback for the PCMCIA modem. I've found PCMCIA modems to be rather fragile when plugged into things they ought not to have been plugged into, whereas my USR Courier has taken all kinds of abuse without complaint.
I find it hard to believe that Yahoo wasn't set up to cope with the denial-of-service attacks I've seen described so far. I'm sure that everyone who works on a web site with more than 10-20 million hits/day has dealt with these attacks.
For example, for the venerable SYN flood attack all one needs to due is tune the kernel to cope with it. SYN floods happen to most large sites on a daily basis.
The connect-to-port-80-and-hold attack is hard for a multiprocessing server like apache to deal with since it has to fork() for each connection. For a multithreaded server it's no problem at all-- it just needs a large pool of threads at its disposal. Each open connection takes up a thread until it times out, but thread creation takes up minimal resources. These connections are not always logged with the IP address in the web server, though perhaps they ought to be.A worse problem, and perhaps this is what happened, is if an actual GET takes place. In this case the thread has to do something other than merely exist. Each IP address is dutifully logged, making it possible to track down the participants in the attack. (Of course this leads into the other thread here on whether people who are not malicious, but whose systems were hijacked, should be liable.)
Does anyone know exactly what kind of attack this was? Was it directed at the Yahoo site and the routers just melted, or was it directed at the routers themselves? (E.g. bogus routing messages flooding the routers with false updates or other routing-level attacks.)
I'd hate to see Yahoo's networking bill for this month.
In the days of 200MB hard drives, Western Digital was king. They made solid, inexpensive, high-performance drives.
About the time of the 500MB hard drive, they started cheapening things up. Cache sizes were reduced, and while everyone else was looking towards a screaming 5400RPM, Western Digital stuck at 3600.
This seemed to peak about the time of the 1.2/1.6GB drives. These had a tiny, tiny cache and performed abysmally, despite the WD propaganda about how their 128K cache was somehow better than everyone else's 512K cache. The post-install failure rate from my experience was on the order of 20-30%, with an early-life failure rate of about 30-40%, based on about 200 sold.
About this time, Seagate was making a 1.0GB low-profile drive that was rock-solid. Of about 500 sold, I saw two go bad. I haven't gone back to Western Digital since.
When talking about drive reliability for a particular manufacturer, it's important to give a timeframe. Different manufacturers have been good at different times, and who is great one year might suck the next.
And of course the best way for a geek to read tarot is with a deck custom-built with him in mind.
My favorite cards:
Yes, these can be used just like real Tarot cards. Don't know how to use Tarot cards? I'd suggest starting with the alt.tarot FAQ, just like any good Internet junkie would.
Unfortunately, their voice mailbox is full.
Lots of people are going to need to decide whether they are going to pony up a minumum of $1,100.00 to buy shares in VA. Be sure to follow their instructions and READ THE PROSPECTUS before you agree to buy the shares.
And to protect myself from the lawyers, I need to tell you that I am not offering financial or legal advice. I'm just some schmuck who has thoughts to share. All are offered as-is with no warranty, etc. etc.
The S-1 Filing for the company is available online. Note that they also have a number of S-1/A filings online.
Here are some thoughts on the company:
Thankfully, VA has a fairly good revenue stream ( 1998: $5,556,000.00 1999: $17,710,000.00 ) however, when one looks at the cost of revenues it also goes up, and in fact goes up disproportionately. ( 1998: $4,494,000.00 1999: $17,766,000.00 ).
This means that while VA had a pretty good gross margin in 1998, they actually went negative for 1999. Not a good trend.
The "gross margin" they mean here is how much they earned or lost by producing their product. A company can never be profitable until the gross margin is positive. When the gross margin is negative, the company is losing money on each unit sold. When the gross margin is positive and the company sells enough units they will make a profit, what being in business is ultimately about.
One has to wonder what happened that the gross margin went from $1,062,000.00 in 1998 to -$56,000 in 1999. Why did the cost of revenues go up so much?
Deutsche Banc Alex requires you to send funds within three days of the IPO to cover your positions. Additionally, they take 10 days to wait for your check to clear. You may not transfer the shares to any other broker until your check has cleared. Note that they do not appear to offer online trading, and only have a single non-800 number listed to trade shares. They will only accept market orders (e.g. sell at any price) for the first day. All this for the low, low commission of $53.
The prospectus says it best:
We have a history of losses and expect to continue to incur net losses for the foreseeable future.
We incurred losses of $14.5 million in fiscal 1999 primarily due to expansion of our operations, and we had an accumulated deficit of $29.9 million as of October 29, 1999. We expect to continue to incur significant product development, sales and marketing and administrative expenses, particularly as a result of expanding our direct sales force. In addition, we are investing considerable resources in our professional services organization and our Internet operations. We do not expect to generate sufficient revenues to achieve profitability and, therefore, we expect to continue to incur net losses for at least the foreseeable future. If we do achieve profitability, we may not be able to sustain it.
No plans to make money into the forseeable future? Ouch. Now you know one reason why IPOs are considered risky. If their cost of revenues (which does not include administrative, sales, marketing, etc. costs as far as I know) does not come down, they'll be unable to make money even if they "generate sufficient revenues".
We rely on Synnex as our single source contract manufacturer. If Synnex is unable to meet our manufacturing needs or our relationship terminates, we may lose revenues and damage our customer relationships.
So VA's server business (which in an earlier risk was mentioned to be 59% of their fiscal 1998 revenues and 88% of their revenues in the quarter ending October 29 1999) is completely tied to Synnex. Who's Synnex? Are they a stable company? Any risks associated with Synnex would naturally be inherited by VA due to this single-supplier arrangement.
If the Linux developer community fails to support us or reacts negatively to our business strategy, our business will be harmed.
The third parties in the Linux developer community, upon whom we rely to develop and maintain a majority of our software, may not continue to support us, our product promotions or our corporate or operating decisions. If we lose the support of these third parties, we would be forced to rely to a significantly greater extent on our own development efforts, which would require us to hire additional developers and increase our development expenses and could adversely impact product release schedules. In addition, negative reactions of third parties in the Linux developer community could harm our reputation, diminish our brand and result in lower net revenues.
Hmmm... they must read Slashdot as well. ;-> I personally don't think this is a significant risk, but yes, it's there.
And speaking of irritating the developers, how about this little tidbit:
We may not be able to use intellectual property to protect ourselves from competition.
Our systems consist primarily of commodity hardware components in combination with the Linux operating system. While we have developed some proprietary techniques and expertise, most of our activities and systems are not protectable as proprietary intellectual property and may be used by competitors, harming our market share and product revenues. To protect our intellectual property, we generally enter into confidentiality or license agreements with our employees, consultants and corporate partners. We have also recently commenced a patent program and to date have filed one patent application. In general, however, we have taken only limited steps to protect our intellectual property. Accordingly, we may be unable to use intellectual property to prevent other companies from competing with us. In addition, we may be unable to prevent third parties from developing techniques that are similar or superior to our technology, or from designing around our copyrights, patents and trade secrets.
This is to be expected from any Open Source company. Hopefully the GPL will be deemed enforceable in a court of law which will limit the ability of competitors to compete unless they too assume this risk.
And yes, the doubts on enforceability of the General Public Licence were also listed as a risk.
You will experience immediate and substantial dilution in the book value of your shares.
The initial public offering price is substantially higher than the book value per share of our outstanding common stock immediately after the offering. Accordingly, if you purchase common stock in the offering, youwill incur immediate dilution of approximately $10.41, assuming an initial public offering price of $12.00 per share, in the book value per share of our common stock from the price you pay for our common stock. For additional information on dilution of the book value of your shares, see "Dilution."
It's pretty common to have significant dilution as part of an IPO, but the magnitude of this dilution is enough to give one pause. Keep in mind that you'd be paying $11-13 for something only worth approximately $1.59.
Of course, if you're just in the mood to gamble, this is as good as any. However, this could be a great opportunity to take a look at a company's financials and really try to decode them. You'll find that it's not that much harder than picking through some ugly perl script once you know how to do it, and it can be much more profitable... ;->
Any other thoughts on the soundness of this company?
Unfortunately, it is not easy to do a "proper" installation on a Win32 system. (Which, curiously enough, are the source of most of the complaints about SSH1 servers.) The DataFellows SSH2 Win32 client simply refuses to connect to an SSH1 server. I'll admit that it has been many months since I tried, so it's possible that they've since come to their senses.
Don't even get me started about wishing for a better scp client. (The only one I know of requires CygWin-- which is too large for many users to download.)
A great many people install just ssh2, assuming that since it's newer it will connect properly to all existing ssh servers. These people usually get a nasty surprise and start complaining that the ssh servers are "broken". I'm forced to agree. ("Broken as designed" comes to mind...)
It's also a toss-up whether a binary distribution was built "properly" or not. Of course, something as critical as ssh really ought to be built from the sources, but laziness can be a great motivator.
BTW, I agree that the SSH2 version is a better protocol-- I just wish DataFellows had implemented it so that the upgrade could be more trouble-free.
Actually, OpenSSH and the original ssh are equally affected by US laws against exporting cryptography. The difference is that the OpenBSD people are not located in the US, so they don't need to worry about exporting ssh. If RedHat weren't a US company you could already download ssh RPMs from them without filling out any forms.
Of course, you can already find RPMs for ssh from other non-US sites. Try rpmfind.net.
There seems to be a bit of confusion about exactly what this software offers over the standard SSH. Hopefully I can help clear it up a bit.
SSH1 comes with a license which is rather ambiguous about commercial use. The most common interpretation is that it's OK to use it commercially so long as one isn't making a profit directly off it. (e.g. charging people for the software.) SSH2 is much clearer-- in order to use SSH2 in a business you must use the closed-source, $400-a-server version from DataFellows.
Here is the vague portion of the SSH1 license:
Companies are permitted to use this program as long as it is not used for revenue-generating purposes. For example, an Internet service provider is allowed to install this program on their systems and permit clients to use SSH to connect; however, actively distributing SSH to clients for the purpose of providing added value requires separate licensing.
SSH2 clients cannot talk to SSH1 servers. This was by design in an attempt to drive people to upgrade to the new protocol. SSH1 clients are able to talk to SSH2 servers.
The IDEA (default) algorithm is patented and requires a license to use commercially. The RSA algorithm is also patented, but that patent has either expired or is about to expire. If one can find a copy of "rsaref", formerly offered freely from RSA's FTP site, then one can use it instead of the internal RSA algorithm to work around this little hurdle.
One reason there is demand for another implementation of the SSH protocol is so that people in small businesses can continue to use SSH while still maintaining access to the source code and also staying $400/server closer to being profitable.
Given the incompatibility of the clients, upgrading from SSH1 to SSH2 requires a flag day upon which day every client and server must be simultaneously upgraded to SSH2. Trying to upgrade in stages results in those with SSH2 unable to connect to SSH1 servers. It is possible to install both versions of the client, but the user will have to be the one "failing over" to the other version. Irritating at best, costly and time-consuming at worst.
For more information about SSH implementations, check out the Open Directory Project's SSH Category.
No, actually you can stop chewing on that foot. Much of the client is still closed-source. Here are the reasons they give (on the same page linked from above):
Why is distributed.net still closed-source?
Although we are providing all of the code linked on this page for public perusal, it is still necessary to keep select portions of the codebase unavailable for general distribution. Indeed, this is an aspect of our operations that we would very much like to be able to eliminate. However, there are several motivating arguments against open-source development with the current clients:
Thankfully, they realize that client-side security is no security at all, and appear to be working on a server-side authentication method.
I admit, it would be very nice to have the complete code-- especially for people experimenting on bizarre high-end hardware. At one time I was very interested in building an HP-PA 2.0 version of the client, but alas the source was not to be had. I also had some PowerPC 620 system running AIX which could have been used-- note the distinct lack of any AIX clients this time.
Here's to hoping that either:
or...
This one is pretty scary. Normally after all the uproar dies down and the claims are read it's not too bad. This one really is.
Claim 1
1. A method for running an application as an X-Client so as to enable the application to be displayed with an X-Windows manager, the method comprising the steps of:
I.e. starting a copy of Win98 inside VMware
I.e. starting up MS-Word
I.e. X-windows is constantly reading your mouse position
I.e. you've just clicked your mouse and dragged it over your typo
I.e. MS-Word now realizes that you've highlighted a selection of text.
I have to say of all the dubious patents we've seen floating by recently, this one takes the cake. They just patented running Windows apps. inside X-Windows. Neato.
However, if you don't launch an application from within Windows you're OK. And since IE is part of the operating system and not an application, you can freely browse the web in VMware without violating their patent. ;->
The Ex-Mozilla site has a self-maintaining list of people who have fled Netscape. Ironically, there is also a My Netscape Network channel which lists the most recently changed entries on Ex-Mozilla.
I had to laugh at some of the postings. The "expertise" requirements in some cases were absurd. One place wanted 23 years of ABAP/4 expertise. ABAP/4 wasn't even a pipe dream 23 years ago.
Reminds me of one of my buddies who went to a job interview in 1992 where they wanted someone with 10 years of NT experience. I bet they were looking for a LONG time...
Sun's internal disks indeed only work with Sun SCSI cards. However, Sun SCSI cards will work with other disks, and Sun's external disks work with other SCSI cards. Sorry if I wasn't clear.