one reason that the survey might have turned up such a shift in social networks is that many respondents might have interpreted the questions differently in 2004 than they did in 1985.
Sure. In 1985, a close friend was anyone who shared my hobbies and was on a first-name basis with me. There weren't many to pick from so I had to work at maintaining a friendship with all of them.
Thanks to cheap telepresence I'm now in touch with plenty of people who share my interests. I can reserve close friend status for the very few people I'd trust with my life.
Television programs transferred to portable devices using TiVo Desktop Plus contain information that can be used to identify the TiVo account and/or DVR from which the transfer originated.
Javascript is an OPTIONAL component of the web surfing experience. A header flag doesn't have to solve the problem for all cases; it need only solve it for the cases where the web applications choose not to implement anything associated with Javascript.
The article's point (and its a good one) is that a web server's failure to implement an optional feature should never be able to open a security hole in a web browser. If it does, that's the browser's fault.
Incorrect. I believe I made it very clear that my software was the client-side terminal emulator. It required and used no special software on the server/BBS side. Like Javascript, it was intentionally designed to do all its work on the client-side so that no change was needed on the BBS.
Browsers are meant to run JavaScript.
And my terminal emulator was meant to run machine code. So what? Since when is it the server's responsibility to accomodate client-side features beyond the agreed-upon baseline? Javascript is not a required component of web surfing. Why should a server that doesn't use that optional feature have to make special arrangements with the expectation that its present? It shouldn't, any more than BBS authors should have had to accomodate my special terminal emulator software.
These websites are designed for distributing content, the same as your bog-standard BBS. People upload content, website displays it. All that is needed to secure it, is to get it to treat code as text, rather than as code. In terms of HTML, that's easy. Just run a regexp on all user-supplied data to convert to >, and the content will be treated as text.
Yeah, I got that. The same argument could have been made about my software: all BBSes could have been programmed to recognize the text escape sequences that would trigger my software and eliminate them. Problem is, they were (as you say) bog-standard BBSes. They weren't expecting to receive any sort of text that some wacky guy's terminal emulator would render as machine code.
Did that make the BBSes insecure? I say baloney. The BBSes weren't the problem. The problem was that my software would accept such text and render it as machine code.
Browsers that run Javascript could be rigged so that some kind of activator has to be present in the main <head> section or no later code will be recognized. They aren't so suddenly its the fault of every individual web form author who doesn't account for the possibility that someone might enter some code in to the form. No way. Put the fault where it belongs: the architecture of the Javascript language.
"Whoever, in or affecting interstate or foreign commerce, knowingly" is pretty close to boilerplate. Judicial precedent has interpreted it to mean "virtually everything except for very rare circumstances where there is no possible tangential connection that pushes it over state lines." A grain of sand is covered in this language because it could reasonably be caught in someone's shoe and carried to another state. No, really, how do you think the EPA gets its authority to regulate solid waste despite the supposed constitutional seperation?
"Multiple commercial electronic mail messages," reads as "more than one message that's neither personal nor from a registered tax exempt organization."
"Intentionally initiates the transmission," means it wasn't done by a hacker controlling your computer.
I should hope there are differences between my situation and XSS attacks. They're seperated by the better part of two decades of advances in computing.
Nevertheless, many of the fundamentals were similar:
1. The client (terminal emulator) allowed the server (BBS) to download and run code. 2. A BBS expecting a post (text message) received machine code from a user instead. 3. The BBS sent that code to the next viewer expecting a text message. 4. The viewer performed undesired and unauthorized actions as a result.
The biggest difference is that today's crop of programmers keep insisting they'll find a way to secure the scripting functionality while I gave it up for bad right away.
1. Publish an SPF record. For a custom setup like yours, you can choose a subdomain just for your application and publish a record just for it, even if you don't want to use SPF for the main domain.
2. Process the bounces. Hotmail notices and ranks the source accordingly.
3. Make sure the reverse DNS for your server matches the forward DNS and that both resolve to a server name that is not obviously a dynamic IP address. Mail from a machine named customer43.dsl.bigisp.com tends to get weighted as spam for reasons which should be obvious.
Back in the 1980s' BBS days, I wrote a terminal emulator for the commodore 64 that would allow a BBS to enhance the user's experience by downloading and running short assembly programs. Users of any standard BBS software could even post such programs to the message boards for other users to enjoy.
JMP 64738 (system reset) was the unavoidable result. The next version of the software recognized that the functionality could not be secured and removed it.
1) 40 characters is sufficient to generate a 256 bit key directly.
2) You don't have to generate a key directly. Given that you'd want to accellerate the process through the IDE controller anyway, you can store the much longer key in the hardware there and use the password to unlock it. Rig a time delay measured in clock cycles before you can try again on a failed password and you won't be cracking it any time soon, even with only 8 characters.
The problem is that the data on the hard disks is not encrypted. This is not surprising: most software isn't set up effectively to enjoy the advantages of encryption.
Let me put that another way: demanding application-level encryption just for the telecommuters is a non-starter. It adds too much to the cost of doing business. It won't happen.
The alternative would be encryption activated at the BIOS POST. The BIOS' already have an setting to require a password there, but its doesn't really do anything. So, make it do something. Use the password to scramble the hard disk contents. If you reset the password and don't pick the same one, the hard disk contents are unreadable. You can reformat it but you can't recover it.
Problem solved. Now a thief can steal the laptop but he can't recover the contents of the drive.
At a previous job, the lead engineers used to joke that our email servers were actually agent servers that also ran email. It would have been funnier if it wasn't true.
Most monitoring agents go overboard. They monitor everything under the sun, even things that require a significant amount of computing power to wrangle in to useful data.
Even lightweight agents like Nagios' nrpe do stupid things like an expensive forking scan of the process table once for each monitored process. God help you if you're running HP's Openview.
Since the article is heavy on claims and light on the basis for those claims, I thought I'd dig in to it a bit. Turned out to be a difficult. I couldn't find the registration agreement via Godaddy's web page. I had to search Google for it.
Section 7 is the one that deals with spam. Here's what it says:
7. restriction of services; right of refusal
You agree not to use the services provided by Go Daddy, or to allow or enable others, to use the services provided by Go Daddy for the purposes of:
* The transmission of unsolicited email (Spam).
* Repetitive, high volume inquires into any of the services provided by Go Daddy (i.e. domain name availability, etc.).
If You are hosting Your domain's domain name servers ("DNS") on Go Daddy's servers, or are using our systems to forward a domain, URL, or otherwise to a system or site hosted elsewhere, or if You have your domain name registered with Go Daddy, You are responsible for ensuring that there is no excessive overloading on Go Daddy's DNS systems. You may not use Go Daddy's servers and Your domain as a source, intermediary, reply to address, or destination address for mail bombs, Internet packet flooding, packet corruption, or other abusive attack. Server hacking or other perpetration of security breaches is prohibited. You agree that Go Daddy reserves the right to deactivate Your domain name from its DNS system if Go Daddy deems it is the recipient of activities caused by your site that threaten the stability of its network.
You agree that Go Daddy, in its sole discretion and without liability to You, may refuse to accept the registration of any domain name. Go Daddy also may in its sole discretion and without liability to You delete the registration of any domain name during the first thirty (30) days after registration has taken place. Go Daddy may also cancel the registration of a domain name, after thirty (30) days, if that name is being used in association with spam or morally objectionable activities. Morally objectionable activities will include, but not be limited to: activities designed to defame, embarrass, harm, abuse, threaten, slander or harass third parties; activities prohibited by the laws of the United States and/or foreign territories in which You conduct business; activities designed to encourage unlawful behavior by others, such as hate crimes, terrorism and child pornography; activities that are tortious, vulgar, obscene, invasive of the privacy of a third party, racially, ethnically, or otherwise objectionable; activities designed to impersonate the identity of a third party; and activities designed to harm minors in any way. In the event Go Daddy refuses a registration or deletes an existing registration during the first thirty (30) days after registration, You will receive a refund of any fees paid to Go Daddy in connection with the registration either being canceled or refused. In the event Go Daddy deletes the registration of a domain name being used in association with spam or morally objectionable activities, no refund will be issued.
Okay, so there are some pretty nasty things in there. One thing I don't see is where they say they'll hold on to the name, refuse to let you transfer it or charge you an extra fee. In fact, they're quite specific: If you spam, they cancel the registration. Period.
I also read the supposed letter from godaddy at http://majordomo.ru/about/letter.htm . Maybe its just me, but the letter smells false. That's not the careful legal language I would expect from a company Godaddy's size faced with this sort of situation. I'm not discounting the possibility that its real, but it smells false. If I saw that letter in my inbox, I'd suspect phishing.
If you want a cert that's directly under the root, you buy Verisign. Thawte is Verisign, so you buy Verisign. Their business model is highway robbery but if you need to interact with stupidly broken applicances that's your tough luck.
If you just need to work with any web browser released in the last 5 years, you buy a chained certificate from, well, just about anyone. Godaddy is my preference, but you can use ssl.com or any of the others. I don't recall having a problem checking out with firefox.
There are few people who can afford D&D books but live in an area where the electric routinely goes out for more than a few minutes. If you're one of them, buy the dead tree versions.
Let me create an example. I'll use Linux terminology but it would be the same for any OS.
Lets say I have 8 20-gig hard disks. I want to build a web server with a MySQL backend. The mysqld process will be heavily disk bound on files that reside in/var/lib/mysql. The web pages themselves will reside in/var/www.
Situation: The web server is under heavy load. Browsers request database-drive web pages with static inline graphics. Option 1: The graphic loads get stuck in the elevator alongside the database requests resulting in a slower load time for the whole page. Option 2: The web server becomes relatively unresponsive under heavy load. Graphics take forever to fill in. Option 3: The OS makes the database and graphic loads from the disks in parallel. Since there is little activity to the drives holding the graphics, the server is able to fill them quickly even though there is a long queue of requests on the database drive.
Lets look at another example. Situation: dd if=/dev/zero of=/file1 bs=1024 count=10000000 & dd if=/dev/zero of=/var/lib/mysql/file2 bs=1024 count=10000000 sync Option 1: Finishes in X seconds. All 8 drives seek back and forth between the disk locations chosen for the two files. Option 2: Finishes in about 1.1 X seconds. All 8 drives seek back and forth and they collide on the same filesystem so you end up with fragmentation to boot. Option 3: Finishes in less than 1/2 X seconds. Two drives seek to the file1 position and start writing. The other six seek to the file 2 position and start writing.
This is why I say that throwing all the drives into a single RAID 5 or RAID 1+0 logical drive and then partitioning it at the OS level is a naive approach.
In the RAID adapter's setup program you create logical drives which are presented to the OS as if they were physical drives. These logical drives are generally either 1 physical drive, 2 drives configured in a RAID 1 or 3 or more drives configured in a RAID 5.
Many naive users throw all drives in a single massive RAID 5 logical drive and then partition that drive at the OS level. I call that naive because when you set up the array that way you get very poor speed performance: IO from all running programs has to hit the logical drive.
Generally, you want to set up a RAID 1 logical drive for the OS and either RAID 1, 1+0 or 5 logical drives for the various I/O-bound applications running on the system. RAID 1 or 1+0 is typically faster than RAID 5 while RAID 5 offers more usable disk space.
Unfortunately, the Megaraid and AACRaid controllers do not support deleting logical drives so you can't delete the data drives, change the drives in the machine, and create new data drives. If you retask the server you have to clear the config and reinstall.
Do any of those RAID cards support deleting an unwanted logical drive without deleting all of the logical drives? That's been a royal pain for me with both the Adaptec raid controllers and LSI's Megaraid controllers. What use is it if you can't remove old smaller disks and add new larger disks without rebuilding the entire system?
Also, have they gotten any better about continuing to run during single-disk failures? With the megaraid cards I've used its about 50/50 whether the raid subsystem crashes during a single-disk failure under Linux. Sure I can reboot and it comes back up but half the point of a raid card is to keep running despite the disk failure.
So far the only controller I've found that's worth a damn is HP/Compaq's Smartarray. Sadly those cost boku bucks unless you get them built in to HP/Compaq servers.
The old Mylex DAC960-based cards used to kick ass but then the Linux driver author died in a helicopter crash, LSI bought Mylex and when the kernel changed from 2.2 to 2.4, the dac960 driver malfunctioned badly.
5000 lines of debugged code per year!? I hadn't heard that Microsoft programmers were idiots. In fact I've generally heard the opposite. Must be a badly broken process if that's all the more productive they are.
no conclusive evidence to support global warming as a phenomenon
When I worked as an intern at the US Office of Naval Research more than a decade ago, one of the interesting projects discussed was using sound wave propagation through thousand-mile spans of ocean to estimate the average water temperature worldwide. Sound waves move differently through water depending on the temperature. The physics involved are well understood and the measurements are cheap and easy to make.
The water temperature was and is continuing to rise. So yes, there is conclusive evidence to support global warming as a phenomenon and you pretty much have to have your head stuck in the sand not to see it.
Whether or not human beings are at fault for global warming remains unproven. There is some interesting evidence to suggest that we are responsible and some interesting evidence to suggest that we're not. For example, Mars is undergoing global warming as measured by its melting ice caps. The earth is warming at exactly the same time and humans are certainly not responsible for warming on mars. That hints towards a solar component to the phenomenon. That is but one data point among a great many, but together they don't paint a very clear picture.
If he'd said all that they just would've hired someone else.
When the founders of a small business look to hire their first employee, they're looking for three criteria:
1. Well above average expertise. Like themselves, in other words. Such people are available, but it takes months of interviews to find them.
2. Fanatic dedication to the work. Like themselves, in other words. Nine-to-fivers need not apply. When combined with criteria #1, these people are no longer a commodity. They can be found but it takes a while. By the time you sit in the interview the founders will have figured this out and are willing to negotiate.
3. Will work for well under the going wage. At this stage of a startup, the founders are taking out perhaps a third of what they would be able to get in a salaried job. If they're lucky it pays the mortgage and utilities. Unless they're particularly well funded (and few startups are) the founders will have to cut their own salaries even further in order to make that first hire.
Its incredibly galling to take a paycut so you can hire someone at a salary you won't claw your way back to for a couple years. The founders don't want to do it, so they look for prospective employees who will accept a basement salary in exchange for buying in to the company itself.
Their offer is invariably stock options. They can't simply give an untested guy stock; it wouldn't be fair to them. But options are reasonable from their perspective. There is no down-side risk and the employee gets a nice payday if the company survives.
Unfortunately this offers the employee has no protection whatsoever from the downside risk and no say in how the company is run in order to avoid that downside risk. He's not going to get a say in how the company is run, but he can negotiate in order to mitigate his downside risk. And if its at all possible they'll say yes because nine times out of ten he's the only prospective employee who met all three of their criteria.
From the poster's description, he met all three criteria. That's why they hired him. The problem is, he took their offer instead of making his own deal. It gave him zero protection from the downside risk.
First, as others have suggested, tell them what a fair market salary and benefits package is and assume the options will be worth $0.
Then, decide how much less money you're willing to take per year for a shot at a bigger pie later. Call that number $X.
Ask them to pay you for the first 2 years as a form-1099 contractor and give them a vesting schedule for buying out your ownership of the intellectual property you produce. At six months they can buy you out for X cash. At 12 they can buy you out for X cash and X stock. At 2 years they can buy you out for 4X stock. If at any time prior to 2 years they fail to maintain your contract, the offer to sell changes to 3X cash and is good for 3 years. Upon buyout or after 2 years (whichever comes first) you expect to be offered a W2 salaried position at the fair market value of your services.
This way you're both reasonably protected. If things go well, they have a fixed and reasonable buyout. If things go poorly then either you walk away with your work-product or whoever they sell the remains to will have to seperatly buy your work product from you. And if the buyer insists on a package deal, they even have a fixed price for it that they know up front.
Slashdot Mirror
one reason that the survey might have turned up such a shift in social networks is that many respondents might have interpreted the questions differently in 2004 than they did in 1985.
Sure. In 1985, a close friend was anyone who shared my hobbies and was on a first-name basis with me. There weren't many to pick from so I had to work at maintaining a friendship with all of them.
Thanks to cheap telepresence I'm now in touch with plenty of people who share my interests. I can reserve close friend status for the very few people I'd trust with my life.
If you bounce too much mail, the mail that doesn't bounce tends to end up in the spam folders. Understand?
From the web page:
Television programs transferred to portable devices using TiVo Desktop Plus contain information that can be used to identify the TiVo account and/or DVR from which the transfer originated.
Javascript is an OPTIONAL component of the web surfing experience. A header flag doesn't have to solve the problem for all cases; it need only solve it for the cases where the web applications choose not to implement anything associated with Javascript.
The article's point (and its a good one) is that a web server's failure to implement an optional feature should never be able to open a security hole in a web browser. If it does, that's the browser's fault.
And where did your software live? On the BBS.
Incorrect. I believe I made it very clear that my software was the client-side terminal emulator. It required and used no special software on the server/BBS side. Like Javascript, it was intentionally designed to do all its work on the client-side so that no change was needed on the BBS.
Browsers are meant to run JavaScript.
And my terminal emulator was meant to run machine code. So what? Since when is it the server's responsibility to accomodate client-side features beyond the agreed-upon baseline? Javascript is not a required component of web surfing. Why should a server that doesn't use that optional feature have to make special arrangements with the expectation that its present? It shouldn't, any more than BBS authors should have had to accomodate my special terminal emulator software.
These websites are designed for distributing content, the same as your bog-standard BBS. People upload content, website displays it. All that is needed to secure it, is to get it to treat code as text, rather than as code. In terms of HTML, that's easy. Just run a regexp on all user-supplied data to convert to >, and the content will be treated as text.
Yeah, I got that. The same argument could have been made about my software: all BBSes could have been programmed to recognize the text escape sequences that would trigger my software and eliminate them. Problem is, they were (as you say) bog-standard BBSes. They weren't expecting to receive any sort of text that some wacky guy's terminal emulator would render as machine code.
Did that make the BBSes insecure? I say baloney. The BBSes weren't the problem. The problem was that my software would accept such text and render it as machine code.
Browsers that run Javascript could be rigged so that some kind of activator has to be present in the main <head> section or no later code will be recognized. They aren't so suddenly its the fault of every individual web form author who doesn't account for the possibility that someone might enter some code in to the form. No way. Put the fault where it belongs: the architecture of the Javascript language.
unless I'm reading it wrong
You're reading it wrong.
"Whoever, in or affecting interstate or foreign commerce, knowingly" is pretty close to boilerplate. Judicial precedent has interpreted it to mean "virtually everything except for very rare circumstances where there is no possible tangential connection that pushes it over state lines." A grain of sand is covered in this language because it could reasonably be caught in someone's shoe and carried to another state. No, really, how do you think the EPA gets its authority to regulate solid waste despite the supposed constitutional seperation?
"Multiple commercial electronic mail messages," reads as "more than one message that's neither personal nor from a registered tax exempt organization."
"Intentionally initiates the transmission," means it wasn't done by a hacker controlling your computer.
I should hope there are differences between my situation and XSS attacks. They're seperated by the better part of two decades of advances in computing.
Nevertheless, many of the fundamentals were similar:
1. The client (terminal emulator) allowed the server (BBS) to download and run code.
2. A BBS expecting a post (text message) received machine code from a user instead.
3. The BBS sent that code to the next viewer expecting a text message.
4. The viewer performed undesired and unauthorized actions as a result.
The biggest difference is that today's crop of programmers keep insisting they'll find a way to secure the scripting functionality while I gave it up for bad right away.
1. Publish an SPF record. For a custom setup like yours, you can choose a subdomain just for your application and publish a record just for it, even if you don't want to use SPF for the main domain.
2. Process the bounces. Hotmail notices and ranks the source accordingly.
3. Make sure the reverse DNS for your server matches the forward DNS and that both resolve to a server name that is not obviously a dynamic IP address. Mail from a machine named customer43.dsl.bigisp.com tends to get weighted as spam for reasons which should be obvious.
Back in the 1980s' BBS days, I wrote a terminal emulator for the commodore 64 that would allow a BBS to enhance the user's experience by downloading and running short assembly programs. Users of any standard BBS software could even post such programs to the message boards for other users to enjoy.
JMP 64738 (system reset) was the unavoidable result. The next version of the software recognized that the functionality could not be secured and removed it.
Also, have you tried sending the email spoofing the receivers email address?
Never do this. Forging the return address is one of the few things that actually is illegal.
1) 40 characters is sufficient to generate a 256 bit key directly.
2) You don't have to generate a key directly. Given that you'd want to accellerate the process through the IDE controller anyway, you can store the much longer key in the hardware there and use the password to unlock it. Rig a time delay measured in clock cycles before you can try again on a failed password and you won't be cracking it any time soon, even with only 8 characters.
The problem is that the data on the hard disks is not encrypted. This is not surprising: most software isn't set up effectively to enjoy the advantages of encryption.
Let me put that another way: demanding application-level encryption just for the telecommuters is a non-starter. It adds too much to the cost of doing business. It won't happen.
The alternative would be encryption activated at the BIOS POST. The BIOS' already have an setting to require a password there, but its doesn't really do anything. So, make it do something. Use the password to scramble the hard disk contents. If you reset the password and don't pick the same one, the hard disk contents are unreadable. You can reformat it but you can't recover it.
Problem solved. Now a thief can steal the laptop but he can't recover the contents of the drive.
At a previous job, the lead engineers used to joke that our email servers were actually agent servers that also ran email. It would have been funnier if it wasn't true.
Most monitoring agents go overboard. They monitor everything under the sun, even things that require a significant amount of computing power to wrangle in to useful data.
Even lightweight agents like Nagios' nrpe do stupid things like an expensive forking scan of the process table once for each monitored process. God help you if you're running HP's Openview.
Since the article is heavy on claims and light on the basis for those claims, I thought I'd dig in to it a bit. Turned out to be a difficult. I couldn't find the registration agreement via Godaddy's web page. I had to search Google for it.
o w_doc.asp?se=+&pageid=REG_SA
http://www.godaddy.com/gdshop/legal_agreements/sh
Section 7 is the one that deals with spam. Here's what it says:
7. restriction of services; right of refusal
You agree not to use the services provided by Go Daddy, or to allow or enable others, to use the services provided by Go Daddy for the purposes of:
* The transmission of unsolicited email (Spam).
* Repetitive, high volume inquires into any of the services provided by Go Daddy (i.e. domain name availability, etc.).
If You are hosting Your domain's domain name servers ("DNS") on Go Daddy's servers, or are using our systems to forward a domain, URL, or otherwise to a system or site hosted elsewhere, or if You have your domain name registered with Go Daddy, You are responsible for ensuring that there is no excessive overloading on Go Daddy's DNS systems. You may not use Go Daddy's servers and Your domain as a source, intermediary, reply to address, or destination address for mail bombs, Internet packet flooding, packet corruption, or other abusive attack. Server hacking or other perpetration of security breaches is prohibited. You agree that Go Daddy reserves the right to deactivate Your domain name from its DNS system if Go Daddy deems it is the recipient of activities caused by your site that threaten the stability of its network.
You agree that Go Daddy, in its sole discretion and without liability to You, may refuse to accept the registration of any domain name. Go Daddy also may in its sole discretion and without liability to You delete the registration of any domain name during the first thirty (30) days after registration has taken place. Go Daddy may also cancel the registration of a domain name, after thirty (30) days, if that name is being used in association with spam or morally objectionable activities. Morally objectionable activities will include, but not be limited to: activities designed to defame, embarrass, harm, abuse, threaten, slander or harass third parties; activities prohibited by the laws of the United States and/or foreign territories in which You conduct business; activities designed to encourage unlawful behavior by others, such as hate crimes, terrorism and child pornography; activities that are tortious, vulgar, obscene, invasive of the privacy of a third party, racially, ethnically, or otherwise objectionable; activities designed to impersonate the identity of a third party; and activities designed to harm minors in any way. In the event Go Daddy refuses a registration or deletes an existing registration during the first thirty (30) days after registration, You will receive a refund of any fees paid to Go Daddy in connection with the registration either being canceled or refused. In the event Go Daddy deletes the registration of a domain name being used in association with spam or morally objectionable activities, no refund will be issued.
Okay, so there are some pretty nasty things in there. One thing I don't see is where they say they'll hold on to the name, refuse to let you transfer it or charge you an extra fee. In fact, they're quite specific: If you spam, they cancel the registration. Period.
I also read the supposed letter from godaddy at http://majordomo.ru/about/letter.htm . Maybe its just me, but the letter smells false. That's not the careful legal language I would expect from a company Godaddy's size faced with this sort of situation. I'm not discounting the possibility that its real, but it smells false. If I saw that letter in my inbox, I'd suspect phishing.
If you want a cert that's directly under the root, you buy Verisign. Thawte is Verisign, so you buy Verisign. Their business model is highway robbery but if you need to interact with stupidly broken applicances that's your tough luck.
If you just need to work with any web browser released in the last 5 years, you buy a chained certificate from, well, just about anyone. Godaddy is my preference, but you can use ssl.com or any of the others. I don't recall having a problem checking out with firefox.
There are few people who can afford D&D books but live in an area where the electric routinely goes out for more than a few minutes. If you're one of them, buy the dead tree versions.
these should appear online within a month or so
They've been online for some time now. alt.binaries.e-book.rpg. 'Nuff said.
Let me create an example. I'll use Linux terminology but it would be the same for any OS.
/var/lib/mysql. The web pages themselves will reside in /var/www.
/dev/sda.
/dev/sda1 = /boot
/dev/sda2 = swap
/dev/sda3 = /
/dev/sda5 = /var/www
/dev/sda6 = /var/lib/mysql
/dev/sda.
/dev/sda1 = /boot
/dev/sda2 = swap
/dev/sda3 = /
/dev/sda and /dev/sdb
/dev/sda1 = /boot
/dev/sda2 = swap
/dev/sda3 = /
/dev/sda4 = /var/www
/dev/sdb1 = /var/lib/mysql
Lets say I have 8 20-gig hard disks. I want to build a web server with a MySQL backend. The mysqld process will be heavily disk bound on files that reside in
Option 1:
8-way RAID 5, 140 gigs usable.
Option 2:
8-way RAID 5, 140 gigs usable.
Option 3:
2-way RAID 1 + 6-way RAID 5. 20+100 gigs usable.
Situation:
The web server is under heavy load. Browsers request database-drive web pages with static inline graphics.
Option 1: The graphic loads get stuck in the elevator alongside the database requests resulting in a slower load time for the whole page.
Option 2: The web server becomes relatively unresponsive under heavy load. Graphics take forever to fill in.
Option 3: The OS makes the database and graphic loads from the disks in parallel. Since there is little activity to the drives holding the graphics, the server is able to fill them quickly even though there is a long queue of requests on the database drive.
Lets look at another example. Situation:
dd if=/dev/zero of=/file1 bs=1024 count=10000000 &
dd if=/dev/zero of=/var/lib/mysql/file2 bs=1024 count=10000000
sync
Option 1: Finishes in X seconds. All 8 drives seek back and forth between the disk locations chosen for the two files.
Option 2: Finishes in about 1.1 X seconds. All 8 drives seek back and forth and they collide on the same filesystem so you end up with fragmentation to boot.
Option 3: Finishes in less than 1/2 X seconds. Two drives seek to the file1 position and start writing. The other six
seek to the file 2 position and start writing.
This is why I say that throwing all the drives into a single RAID 5 or RAID 1+0 logical drive and then partitioning it at the OS level is a naive approach.
In the RAID adapter's setup program you create logical drives which are presented to the OS as if they were physical drives. These logical drives are generally either 1 physical drive, 2 drives configured in a RAID 1 or 3 or more drives configured in a RAID 5.
Many naive users throw all drives in a single massive RAID 5 logical drive and then partition that drive at the OS level. I call that naive because when you set up the array that way you get very poor speed performance: IO from all running programs has to hit the logical drive.
Generally, you want to set up a RAID 1 logical drive for the OS and either RAID 1, 1+0 or 5 logical drives for the various I/O-bound applications running on the system. RAID 1 or 1+0 is typically faster than RAID 5 while RAID 5 offers more usable disk space.
Unfortunately, the Megaraid and AACRaid controllers do not support deleting logical drives so you can't delete the data drives, change the drives in the machine, and create new data drives. If you retask the server you have to clear the config and reinstall.
Do any of those RAID cards support deleting an unwanted logical drive without deleting all of the logical drives? That's been a royal pain for me with both the Adaptec raid controllers and LSI's Megaraid controllers. What use is it if you can't remove old smaller disks and add new larger disks without rebuilding the entire system?
Also, have they gotten any better about continuing to run during single-disk failures? With the megaraid cards I've used its about 50/50 whether the raid subsystem crashes during a single-disk failure under Linux. Sure I can reboot and it comes back up but half the point of a raid card is to keep running despite the disk failure.
So far the only controller I've found that's worth a damn is HP/Compaq's Smartarray. Sadly those cost boku bucks unless you get them built in to HP/Compaq servers.
The old Mylex DAC960-based cards used to kick ass but then the Linux driver author died in a helicopter crash, LSI bought Mylex and when the kernel changed from 2.2 to 2.4, the dac960 driver malfunctioned badly.
5000 lines of debugged code per year!? I hadn't heard that Microsoft programmers were idiots. In fact I've generally heard the opposite. Must be a badly broken process if that's all the more productive they are.
no conclusive evidence to support global warming as a phenomenon
When I worked as an intern at the US Office of Naval Research more than a decade ago, one of the interesting projects discussed was using sound wave propagation through thousand-mile spans of ocean to estimate the average water temperature worldwide. Sound waves move differently through water depending on the temperature. The physics involved are well understood and the measurements are cheap and easy to make.
The water temperature was and is continuing to rise. So yes, there is conclusive evidence to support global warming as a phenomenon and you pretty much have to have your head stuck in the sand not to see it.
Whether or not human beings are at fault for global warming remains unproven. There is some interesting evidence to suggest that we are responsible and some interesting evidence to suggest that we're not. For example, Mars is undergoing global warming as measured by its melting ice caps. The earth is warming at exactly the same time and humans are certainly not responsible for warming on mars. That hints towards a solar component to the phenomenon. That is but one data point among a great many, but together they don't paint a very clear picture.
If he'd said all that they just would've hired someone else.
When the founders of a small business look to hire their first employee, they're looking for three criteria:
1. Well above average expertise. Like themselves, in other words. Such people are available, but it takes months of interviews to find them.
2. Fanatic dedication to the work. Like themselves, in other words. Nine-to-fivers need not apply. When combined with criteria #1, these people are no longer a commodity. They can be found but it takes a while. By the time you sit in the interview the founders will have figured this out and are willing to negotiate.
3. Will work for well under the going wage. At this stage of a startup, the founders are taking out perhaps a third of what they would be able to get in a salaried job. If they're lucky it pays the mortgage and utilities. Unless they're particularly well funded (and few startups are) the founders will have to cut their own salaries even further in order to make that first hire.
Its incredibly galling to take a paycut so you can hire someone at a salary you won't claw your way back to for a couple years. The founders don't want to do it, so they look for prospective employees who will accept a basement salary in exchange for buying in to the company itself.
Their offer is invariably stock options. They can't simply give an untested guy stock; it wouldn't be fair to them. But options are reasonable from their perspective. There is no down-side risk and the employee gets a nice payday if the company survives.
Unfortunately this offers the employee has no protection whatsoever from the downside risk and no say in how the company is run in order to avoid that downside risk. He's not going to get a say in how the company is run, but he can negotiate in order to mitigate his downside risk. And if its at all possible they'll say yes because nine times out of ten he's the only prospective employee who met all three of their criteria.
From the poster's description, he met all three criteria. That's why they hired him. The problem is, he took their offer instead of making his own deal. It gave him zero protection from the downside risk.
First, as others have suggested, tell them what a fair market salary and benefits package is and assume the options will be worth $0.
Then, decide how much less money you're willing to take per year for a shot at a bigger pie later. Call that number $X.
Ask them to pay you for the first 2 years as a form-1099 contractor and give them a vesting schedule for buying out your ownership of the intellectual property you produce. At six months they can buy you out for X cash. At 12 they can buy you out for X cash and X stock. At 2 years they can buy you out for 4X stock. If at any time prior to 2 years they fail to maintain your contract, the offer to sell changes to 3X cash and is good for 3 years. Upon buyout or after 2 years (whichever comes first) you expect to be offered a W2 salaried position at the fair market value of your services.
This way you're both reasonably protected. If things go well, they have a fixed and reasonable buyout. If things go poorly then either you walk away with your work-product or whoever they sell the remains to will have to seperatly buy your work product from you. And if the buyer insists on a package deal, they even have a fixed price for it that they know up front.