AutoZone quit using SCO's product. So they shouldn't have to pay for it. Of course, had AutoZone signed a contract that say they would pay for a certain period, whether they use it or not, then by not paying, it's just a contract issue.
But this appears to be a case where SCO believes that part of their system, the shared library, was used on a Linux server to make the porting of AutoZone's application easier. Since the porting went so smoothly and quickly (presumably with IBM's help), SCO believes they must have cheated somewhere.
Apparently SCO has a poor track record in the past of porting other company's applications to SCO's crappy system, but somehow they think that's the norm. Welcome to the real world, Darl, where well written applications can simply be recompiled and run anywhere (even on Windows).
Buy more AZO stock! You're buying it at a discount from the unbelievers, so don't think that the low price is really hurting AutoZone. When the price goes back up, it will be those who buy it now that will benefit.
I already block EV1 due to spamming. Back in March 2003, my servers were hit with a huge repeated spam attack coming from several addresses in an EV1 address range. It wasn't so huge as to bring down the servers, and they did keep running. But it played hell with my statistical and performance measurements. In terms of incoming email delivery attempts, it was a huge spike on the graph. And despite attempts to communicate with them to get them to stop this, sent my email and made by telephone, I was never able to get the word to any responsible person. A week into the situation it was still going on and I had heard nothing from several emails sent to their abuse address. So I called by telephone and spoke to idiots who refused to even pass on a message, much less get someone responsible on the phone. All he suggested was to send more email to an address that was obviously not being read by anyone capable of stopping the attack. This went on for 6 weeks.
So is it any wonder why I am blocking all of these EV1 address ranges from my mail server:
Note that it isn't because of the spam attack that these are blocked; it's because of the irresponsible way that EV1 is managed that these are blocked.
Had EV1 been sued by SCO, and fought the suit, that would have been reason enough for me to completely wipe out that spam attack incident and remove these blocks. Had Head Surfer even so much as simply announced a refusal to pay extortion money to SCO, and donated it instead to the defense fund, that would also have been reason enough for me to completely wipe out that spam attack incident and remove these blocks. But instead, SCO has not only been helped, but this practice of legalized extortion has been further encouraged. That's reason enough for me to lock these addresses in place.
To him, the cost of terminating a customer that is spamming at an extreme level is outweighed by the cost of being blocked due to that spamming continuing.
He certainly does seem to be one of those people who thinks in pure business terms, and never about doing things right. Maybe that's why my servers were under a 6 weeks long spam attack from their network, while all attempts to contact them by email and telephone never got past the idiots he hires to field (deflect) the calls.
To him, the cost of all that spam causing a huge spike in my mail server load stats is nothing compared to the cost of losing a paying customer, because he doesn't have to deal with the end result of the spam.
So now maybe you can understand why I have the entire EV1 network blocked from access to my mail servers. You would do well to find a different place for hosting.
So in some ways, we've got a McDonald's No. 5 super-size offering that costs $2.99 and someone just wants a Diet Coke that costs 99 cents. So do we cut the entire super-size No. 5 down to 98 cents, or do we try to find a way to just give somebody the Diet Coke if that's what they want?
Linux is definitely not a Diet Coke. It's more like a grand self-serve buffet, with food from all over the world, for just $0.50 or even less if you do your own cooking.
Your ephemeral addresses system should be made to work through some kind of outside service that won't appear to be directly an end user of some cable company that saves money (and claims lack of resources) by shifting the cost burden of spam to the recipients. That service would them implement methods to ensure its authorized users aren't abusing the relaying capability, such as a sender cost per message above a base package provision (something the cable company should be providing, but isn't).
They don't have the interest as long as no pressure is applied. Apply the pressure and they will start to take steps, like blocking port 25 from direct customers, and enforcing abuse policies now that abuses will be more obvious when they clog up their own mail servers (instead of clogging up other people's mail servers). If they don't have the resources, they are doing something very wrong. I'd block them just for being stupid enough to not have the resources.
Abuses are problems that need to be stopped before they get worse, either at the receiving end, or sooner at the sending end. Customers that are irresponsible should be cut off from the net, plain and simple, or I cut them off (and if their ISP makes it hard to pin point exactly that customer, I cut the ISP off).
Maybe some day when SMTP is redesigned supply some sender authentication during the initial exchange, before data is sent, then things will ease up (but only after everyone starts using it). But all this will be a long long time before it happens. In the mean time I have to cut the overload hitting my mail servers, as do so many others.
The issue you face is one of "identity distinction". By being on Comcast Cable, you appear to be one of the unwashed masses. Whether your system is secure or not isn't known, and isn't practical to find out (trying to actually crack your machine to see if one can get in, to refuse mail if the crack succeeds, has certain legal risks).
You can distinguish yourself by making your email address known and others can whitelist it. Of course that's only good up to the point that spammers start to joe-job you using that address (which may not be for quite a while). Another way (which won't work with Comcast because they are so clueless, but could work with some other ISPs) is to get static IP and arrange for reverse DNS to identify your domain name. Some (I do, for example) block Comcast based on the domain name (easier to manage than a bunch of IP address ranges), which means if your IP didn't have comcast.net on it, it might get through. And if you do have a static IP, you could just ask for that one to be whitelisted.
There are also message content ways to distinguish yourself, such as cryptographically signing your message. But the problem here is that mail servers have to accept all mail first to see that signature. That breaks the ability to refuse during the SMTP RCPT command; refusing at the DATA command not only means wasting the bandwidth always on every message, but also the inability to let users separately whitelist, or means sending bounces to unverified addresses (bad). If they would redesign SMTP to provide the crypto signature during the SMTP session, that would help a lot.
Probably the best solution is to subscribe to a mail submission service (e.g. someone who has a colocated mail server and takes your mail only via authenticated SMTP or MSA). Then the fact that you're on Comcast is hidden deeper in messy RFC headers.
I certainly encourage you and everyone else to focus your anger on the companies, corporate executives, and their stockholders, who are always trying to screw people over just for profits. Indians are just as much victims of this, if not more so. If these companies could find a way to do absolutely everything in a foreign country ultra cheap, or even on Mars, they would. And don't forget that Bush, Cheney, and many Republicans are in bed with these corporations. Use your vote in 2004 wisely.
Re:You can't get parts from India...
on
Orwellian Tech Support
·
· Score: 5, Interesting
You've certainly identified the real culprit here. Even before corporations started setting up shop in India to hire people for lower wages (which are probably great wages in India), it was very typical for corporations to misuse, or not even use at all, the advanced skills many people have. It seems they are doing exactly the same thing in India.
There was a situation a few years ago when I lived in Dallas. There was a woman who I met who was wanting to learn more about Unix. Turns out she was being hired on an H-1B visa by Texas Instruments to be a Unix systems administrator. But she seemed to be a smart person so I asked her more about herself and found out she had a master's degree in CS, and the only experience she had with Unix is having logged in as a student user to a Linux machine a few times. So why would an American corporation hire someone obviously well qualified for more advanced work into a lower level job (run around and fix Sun desktops for engineers) she had no experience in? Obviously for cheaper wages (which, despite claims to the contrary, is easy to get away with using H-1B) is one of the reasons. But they probably could have her doing the more advanced work at the lower wages, too, so why not? Corporations also try to keep people down; maybe managers are afraid of being replaced by people that know more. But this has been a common practice for decades, to underutilize people's skills. It didn't change even with H-1B, and it won't change with outsourcing in India.
I can't blame any Indians (or Chinese, or Russians, or anyone else) for wanting to find better work for better pay than they have been getting before. The real blame goes to corporate executives who just try to screw people over, whether American or Indian... all for profit. People in America are trying to recover their own jobs, and it's quite obvious the only way to do that is a change of government, since the corporations themselves are obviously not doing it (and aren't expected to, since their loyalty is strictly to their shareholders). The saddest part of this situation is that it will breed some hatred for India and Indians that is not due, and may take years to erase.
What I'd really like to see happen is that Indians get together and form all new companies that better respect people than the companies in America run by greedy fat cat scrooges, and end up not only putting everyone in India to work, but also end up coming to America and displacing these crappy companies we have here.
There are many things you may want the candidate to send to you. But asking them to send references in advance is not one of them. No candidate for any job should ever send a list of references in advance. Instead, bring the references with you to the interview. References do not provide new information that helps the initial selection process. What references are good for is verifying that what the candidate said was (well, might be) true, and that they are (well, might be) of good character.
Also, in the existing legal climate, references generally won't be all that forthcoming, anyway. You know a candidate won't provide references they believe will be negative. The value added by references is not that much for anything besides corporate level executives, anyway. So, unless you are hiring a CEO or CFO, references won't even do you much good.
The problem with sending references is that there are some bad companies out there (and the candidates usually cannot sort this out very easily, because some of these bad companies are big corporations, and the often sleazy headhunters they do business with) end up using the references information inappropriately. I've been harrassed as a result of being listed as a reference by someone, and I've had to tell anyone who asks to use me as a reference to never give my name until after it at least it seems, during the interview, that the job is a good match. The best scenario is for the employer to ask the candidate at the end of the interview for the references as an indication that the candidate is being placed on the short list.
So if you were to ask for references to be sent with the resume, please expect that those people who value and respect the privacy of the people they are identifying as references will not do so immediately. Portfolios provided in advance are a good thing, and for people like graphical artists, that should be a standard way (short of intellectual property issues). But providing references in advance is completely inappropriate.
Regardless of whether the author of the article has his own agenda (boosting business for recruiters) or not, the current crop of job boards are really not designed very well.
One thing that is mentioned is the fact that employers get listings of people sorted by date, most recently updated first. And sure, that could be that way because the job boards are trying to drive traffic, rather than actually match jobs with people (and sell advertising, which many of them do... more on that later). If candidates were listed in order of best match, it would serve the employer and the candidates better. But I'm not sure they can effectively do any decent matching.
These job boards seem to confuse business industry category (e.g. banking, auto manufacturing, software maker, internet provider) with job roles (accountant, lawyer, programmer, engineer, network administrator, secretary, janitor). If I pick the "internet hosting" category (most don't even get that detailed; the best you can do in many is "information technology" or "telecom") I end up seeing lots of jobs for Java Servlet programmers when what I really want might be a Network Administrator position. They also get job skills mixed up with job roles. There's lots of crossover between many job categories in terms of skills (a system administrator with programming skills in certain languages has an advantage in systsmes administrator, but might not want a job as a programmer, though would get matched with them because of that skill).
At a minimum, every job board should allow a candidate to specify each of the following:
Which industry categories the candidate is willing work in
What job roles the candidate wants to work in
What locations the candidate wants to work at
What scope and percentage of travel the candidate would be willing to do
What skills the candidate has
Whether the candidate is willing to work through a recruiter or not
Then for a job search to be done, or a position being posted, the employer would provide:
Which industry category the employer is
What job role this position is in
What location the job is at
What scope and percentage of travel the job involves
What skills the employer considers mandatory
What skills the employer considers a plus to measure candidates
Whether this position is being handled by a recruiter or not.
There are other things to add to this that would be optional, such as expected and probable pay level, previous job history (roles and business categories), etc.
I believe searches would be far more effective if more aspects of matching, such as the above, were provided for.
But it certainly seems to be the case that the job boards are more interested in driving higher numbers of page views.
Unfortunately, too many boards do search based strictly on keyword matching.
I've actually gotten a match when I searched with "linux" as a keyword with a job that said "we are not running Linux here".
The current job boards are also turn offs to both employers as well as candidates.
Employers generally have to pay for each posting, or monthly quota of posting, or a subscription.
Small businesses will generally not be there, and larger businesses won't put all their jobs there
(their own corporate web site is cheaper for them to post on).
Job boards should really be free to employers, as well as candidates.
I don't know how bad it is for the employers, but candidates generally have to endure not only a regular flow of spam,
but in many cases annoying things like pop-up ads, web bugs, and interstitial pages you have to select "no thanks" and click on as you go through each search or login.
I'd rather have Google style text ads (yes, I do sometimes click on them) support the site.
And since ads are really about impressions, they should not be paid on a click through basis (if I am interested in what the ad offers, I usually go visit the sit
I placed my resume on Monster and a few others several times. I did get several calls from recruiters (some who obviously didn't actually read my resume, and some who did). But I never got a single call from anyone with any kind of scam offer, unless they cleverly hid it behind what sounded like a very legitimate high tech job. There were no calls about work at home schemes or any selling. So I guess I just didn't qualify.
Whether such code falls under the original UNIX license or not is irrelevant. SCO's claim is that Sequent/IBM agreed under contract terms that any "derivative work" becomes SCO property. It's not unlike GPL, which requires derivative works of GPL code to also be under GPL. But the difference here is that it wasn't written into the UNIX license, per se, but was part of the agreed contract.
That said, we have to look at whether SCO's argument, and the contract terms, are flawed and/or have a loop hole. Suppose the development of the technology at issue here was being done independently. That makes it the property of those who are doing that development, e.g. Sequent and/or IBM. If this technology is subsequently contributed into the UNIX operating systems (Dynix/ptx and AIX), it isn't really a derived work, but rather is a combination or merger. I don't know about Sequent, but IBM most certainly has a lot of other irons in the development fire, including a major operating system (MVS or z/OS) for their mainframe systems, as well as OS/2 from the early PC days, in which this very technology would also be of vital importance. So who's to know (IBM might) whether this technology was developed independently (IBM has lots of R&D people doing this very kind of thing) and just added on to AIX?
Consider it this way. What if I had developed some technology that IBM found would be very good for their operating systems. They come to me to get this technology and I license them non-exclusive rights to use it. Thus, I retain original ownership, but IBM can use it in their products (and pay me royalty). Now suppose they add this technology to AIX. Does that make it a derived work of UNIX and thus belonging to SCO? That's not possible because I retain the original ownership.
Now there are two issues. Did IBM (or Sequent) genuinely develop these things in some independent way, and if so, does the fact that the same company that owns that technology and also signed the contract agreement for UNIX mean that they have to place all the ownership of that technology under UNIX? If IBM put that technology in their mainframe OS, too, then it would look pretty clear that it is an independent development. I'm not so sure about Sequent.
My argument would be that if IBM can put a licensed technology into AIX without it becoming a derived work of UNIX in the case where they license it from someone else, then they can also put technology into AIX without it becoming a derived work of UNIX in the case where the development of it was done independently. And once it is not a derived work of UNIX, IBM is free (as the original owner) to do with it as they please, including making a GPL distribution branch of it for Linux (and this would not in any way mean that the copy of it in AIX is GPL).
I suspect that the case is going to either hinge on something like the above argument, or the fact that the contractual license agreement itself having originally come from AT&T, any rights to so-called "derived works" were dismissed by AT&T long ago.
There will be encrypted underground networks then, as there are today... only more so given the available bandwidth to do it. The [RM][IP]AA* people don't even have a clue about some of the stuff out there.
*For those Windows people who don't catch on, "RM IP" can mean "ReMove Intellectual Property". "[RM][IP]AA" is a regular expression pattern that can match either "RIAA" or "MPAA".
Content for media devices, such as record players, movie projectors, CD players, video records, etc., has been called "software" for as long as that equipment has been called "hardware". The computer field does not own exclusivity to the term.
Let's add another 50 channels, and make them all 100 mbps, to the 2.4 GHz band.
Yeah right.
Wireless just doesn't have the ability to expand bandwidth like that. It's limited to what bandwidth exists at any given frequency, and much of that is already allocated and that would, itself, impose massive costs just to move things around. There's isn't the room for the scale we need below the 300 GHz frequency point, and that technology is still too expensive.
Fiber optic is mature enough now to scale up production to decrease costs to the commodity level once there is the commitment to roll out this kind of bandwidth. And while we are at it, why stop at 100 mbps. Let's go for 400 mbps or even 1 gbps.
As for whether we should "waste" it on TV, that should be a matter of each individual consumer to choose what they want to have fed through their little piece of glass. If they want to have TV, fine, let them. The only areas I see as being potential problems are what people like Ralsky and Richter and some others like them would do with it.
Every proposal I see stil ends up with the control in someone's hands. Whether it is in the hands of politicians in some country, in the hands of politicions of all countries toegther (such as via UN), in the hands of corporations, in the hands of the original network creators, or even in the hands of the kid down the street that cracked into the system without anyone noticing, the fact is, the power is concentrated somewhere. Every proposal concentrates the power somewhere away from other places who might not be happy with the way it is. I doubt a system can ever be made that makes everyone happy, but can there be a system that at least everyone things is fair?
I can come up with reasons for not putting the domain names in the hands of... any of those groups.
I hereby propose: total anarchy!
And my proposal won't require a vote of approval, either. The way this is done is that every DNS server operator will simply run their own root zone, and include whatever top level domains they like. If they want to use the [a-m].gtld-servers.net servers for the.com and.net domains, they can. If they want to use some other source, instead, that's up to them. If they want to add new domains like.mp3 or.nospam or.xxx, then they can. Who's going to say they can't, anyway. I have one of those three in my servers now and you can't make me take it back out.
The usual argument against my proposal is "it will fragment the net". My usual answer to that argument is "ah, I see, you do understand how it works". If we are going to not be fragmented, we all have to follow a common leadership. But I think it's quite clear that we do not wish to do that. I doubt very much that anyone of consequence will turn away from [a-m].gtld-servers.net for the.com and.net domains, and likewise for many others. In reality, the net will always have an unfragmented aspect to it. But my proposal also allows for the net to have the fragmented part, which will satisfy our need to not play "follow the leader" in all our domains.
Now, are people going to follow my lead, or are they just going to do whatever they wish?
I did this about 5 years ago. But my method was a bit different. Instead of using port numbers to contain the information (and that's all it really is, is just information), I sent a single UDP packet, with a source port of 53 (so it looks like a DNS answer), formatted like a DNS answer, that contained the information in the DNS answer data. Then it opened the SSH filter for that IP address to come in (I did it for 5 minutes, not 10 seconds). It still had to fully authenticate via SSH, so even if someone sniffed my DNS packet and tried to fake it, they could at most have a locked door to jiggle the handle on. Next time I do this, it will be to generate an MD5 checksum from the client IP and a secret salt, and send that as an IPv6 address in the packet. Then it can't even be faked from some other IP address.
It's a configuration option on Squid. You're caching poorly if you don't use it... depending on how many different users you have using it. If all your users are using the same exact browser version, it won't matter. But if all your users are using different browsers, they won't be "hitting" each other's cached data, even if the data is identical (unless the cache violates RFCs). 99.999% of web sites work fine. Wikipedia and New Scientist are the only web sites I can recall which have the problem with lack of User-Agent. Everything else, including Slashdot, works fine when User-Agent is omitted. Several ISPs have switched to no User-Agent mode to improve their caching. The only catch anyone should ever see is a lack of customized HTML, and that's not considered a good web design practice anymore considering that modern web standards work excellent on all new browsers, and degrade gracefully on old browsers.
Wikipedia still refuses to work with some proxies that choose to optimize their caching by not transmitting the User-Agent header. And they don't even do the courtesy of explaining why; they just give a "Forbidden: You don't have permission to access / on this server." error and that's it.
RFCs require that when a cache passes User-Agent, it must cache received data such that a client requesting exactly the same URL, but with a different User-Agent string, cannot use that cached data. Think of it as combining the User-Agent string value and the URL string to get the index into the cache. So with that and the fact that so many clients have so many variant strings, including version numbers and build numbers, caching works very poorly unless User-Agent is removed from the request (which is valid to do, even though the RFCs recommend not doing so).
So to use Wikipedia I have to stop using the cache server, which because I'm stuck on a slow dialup, is a big performance hit.
The reason for this, as I've found out, is that some web crawlers that abuse the site (because they run so fast), are recognized by not using User-Agent. I think they could do better by recognizing abusive sites and just blocking their IP address for a while (or teergrubing them), regardless of whether they have User-Agent or not.
Slashdot Mirror
AutoZone quit using SCO's product. So they shouldn't have to pay for it. Of course, had AutoZone signed a contract that say they would pay for a certain period, whether they use it or not, then by not paying, it's just a contract issue.
But this appears to be a case where SCO believes that part of their system, the shared library, was used on a Linux server to make the porting of AutoZone's application easier. Since the porting went so smoothly and quickly (presumably with IBM's help), SCO believes they must have cheated somewhere.
Apparently SCO has a poor track record in the past of porting other company's applications to SCO's crappy system, but somehow they think that's the norm. Welcome to the real world, Darl, where well written applications can simply be recompiled and run anywhere (even on Windows).
Buy more AZO stock! You're buying it at a discount from the unbelievers, so don't think that the low price is really hurting AutoZone. When the price goes back up, it will be those who buy it now that will benefit.
"Lawsuits Pending [tm]"
I already block EV1 due to spamming. Back in March 2003, my servers were hit with a huge repeated spam attack coming from several addresses in an EV1 address range. It wasn't so huge as to bring down the servers, and they did keep running. But it played hell with my statistical and performance measurements. In terms of incoming email delivery attempts, it was a huge spike on the graph. And despite attempts to communicate with them to get them to stop this, sent my email and made by telephone, I was never able to get the word to any responsible person. A week into the situation it was still going on and I had heard nothing from several emails sent to their abuse address. So I called by telephone and spoke to idiots who refused to even pass on a message, much less get someone responsible on the phone. All he suggested was to send more email to an address that was obviously not being read by anyone capable of stopping the attack. This went on for 6 weeks.
So is it any wonder why I am blocking all of these EV1 address ranges from my mail server:
- 64.246.0.0/18
- 66.98.128.0/17
- 207.44.128.0/17
- 207.218.192.0/18
- 216.12.192.0/19
- 216.40.192.0/18
- 216.88.76.0/23
- 216.127.64.0/19
Note that it isn't because of the spam attack that these are blocked; it's because of the irresponsible way that EV1 is managed that these are blocked.Had EV1 been sued by SCO, and fought the suit, that would have been reason enough for me to completely wipe out that spam attack incident and remove these blocks. Had Head Surfer even so much as simply announced a refusal to pay extortion money to SCO, and donated it instead to the defense fund, that would also have been reason enough for me to completely wipe out that spam attack incident and remove these blocks. But instead, SCO has not only been helped, but this practice of legalized extortion has been further encouraged. That's reason enough for me to lock these addresses in place.
Add this:
To him, the cost of terminating a customer that is spamming at an extreme level is outweighed by the cost of being blocked due to that spamming continuing.
He certainly does seem to be one of those people who thinks in pure business terms, and never about doing things right. Maybe that's why my servers were under a 6 weeks long spam attack from their network, while all attempts to contact them by email and telephone never got past the idiots he hires to field (deflect) the calls.
To him, the cost of all that spam causing a huge spike in my mail server load stats is nothing compared to the cost of losing a paying customer, because he doesn't have to deal with the end result of the spam.
So now maybe you can understand why I have the entire EV1 network blocked from access to my mail servers. You would do well to find a different place for hosting.
Well, at least you'll be behind ||//slanted//|| bars :-)
From the article:
Linux is definitely not a Diet Coke. It's more like a grand self-serve buffet, with food from all over the world, for just $0.50 or even less if you do your own cooking.
Your ephemeral addresses system should be made to work through some kind of outside service that won't appear to be directly an end user of some cable company that saves money (and claims lack of resources) by shifting the cost burden of spam to the recipients. That service would them implement methods to ensure its authorized users aren't abusing the relaying capability, such as a sender cost per message above a base package provision (something the cable company should be providing, but isn't).
They don't have the interest as long as no pressure is applied. Apply the pressure and they will start to take steps, like blocking port 25 from direct customers, and enforcing abuse policies now that abuses will be more obvious when they clog up their own mail servers (instead of clogging up other people's mail servers). If they don't have the resources, they are doing something very wrong. I'd block them just for being stupid enough to not have the resources.
Abuses are problems that need to be stopped before they get worse, either at the receiving end, or sooner at the sending end. Customers that are irresponsible should be cut off from the net, plain and simple, or I cut them off (and if their ISP makes it hard to pin point exactly that customer, I cut the ISP off).
Maybe some day when SMTP is redesigned supply some sender authentication during the initial exchange, before data is sent, then things will ease up (but only after everyone starts using it). But all this will be a long long time before it happens. In the mean time I have to cut the overload hitting my mail servers, as do so many others.
The issue you face is one of "identity distinction". By being on Comcast Cable, you appear to be one of the unwashed masses. Whether your system is secure or not isn't known, and isn't practical to find out (trying to actually crack your machine to see if one can get in, to refuse mail if the crack succeeds, has certain legal risks).
You can distinguish yourself by making your email address known and others can whitelist it. Of course that's only good up to the point that spammers start to joe-job you using that address (which may not be for quite a while). Another way (which won't work with Comcast because they are so clueless, but could work with some other ISPs) is to get static IP and arrange for reverse DNS to identify your domain name. Some (I do, for example) block Comcast based on the domain name (easier to manage than a bunch of IP address ranges), which means if your IP didn't have comcast.net on it, it might get through. And if you do have a static IP, you could just ask for that one to be whitelisted.
There are also message content ways to distinguish yourself, such as cryptographically signing your message. But the problem here is that mail servers have to accept all mail first to see that signature. That breaks the ability to refuse during the SMTP RCPT command; refusing at the DATA command not only means wasting the bandwidth always on every message, but also the inability to let users separately whitelist, or means sending bounces to unverified addresses (bad). If they would redesign SMTP to provide the crypto signature during the SMTP session, that would help a lot.
Probably the best solution is to subscribe to a mail submission service (e.g. someone who has a colocated mail server and takes your mail only via authenticated SMTP or MSA). Then the fact that you're on Comcast is hidden deeper in messy RFC headers.
I certainly encourage you and everyone else to focus your anger on the companies, corporate executives, and their stockholders, who are always trying to screw people over just for profits. Indians are just as much victims of this, if not more so. If these companies could find a way to do absolutely everything in a foreign country ultra cheap, or even on Mars, they would. And don't forget that Bush, Cheney, and many Republicans are in bed with these corporations. Use your vote in 2004 wisely.
You've certainly identified the real culprit here. Even before corporations started setting up shop in India to hire people for lower wages (which are probably great wages in India), it was very typical for corporations to misuse, or not even use at all, the advanced skills many people have. It seems they are doing exactly the same thing in India.
There was a situation a few years ago when I lived in Dallas. There was a woman who I met who was wanting to learn more about Unix. Turns out she was being hired on an H-1B visa by Texas Instruments to be a Unix systems administrator. But she seemed to be a smart person so I asked her more about herself and found out she had a master's degree in CS, and the only experience she had with Unix is having logged in as a student user to a Linux machine a few times. So why would an American corporation hire someone obviously well qualified for more advanced work into a lower level job (run around and fix Sun desktops for engineers) she had no experience in? Obviously for cheaper wages (which, despite claims to the contrary, is easy to get away with using H-1B) is one of the reasons. But they probably could have her doing the more advanced work at the lower wages, too, so why not? Corporations also try to keep people down; maybe managers are afraid of being replaced by people that know more. But this has been a common practice for decades, to underutilize people's skills. It didn't change even with H-1B, and it won't change with outsourcing in India.
I can't blame any Indians (or Chinese, or Russians, or anyone else) for wanting to find better work for better pay than they have been getting before. The real blame goes to corporate executives who just try to screw people over, whether American or Indian ... all for profit. People in America are trying to recover their own jobs, and it's quite obvious the only way to do that is a change of government, since the corporations themselves are obviously not doing it (and aren't expected to, since their loyalty is strictly to their shareholders). The saddest part of this situation is that it will breed some hatred for India and Indians that is not due, and may take years to erase.
What I'd really like to see happen is that Indians get together and form all new companies that better respect people than the companies in America run by greedy fat cat scrooges, and end up not only putting everyone in India to work, but also end up coming to America and displacing these crappy companies we have here.
There are many things you may want the candidate to send to you. But asking them to send references in advance is not one of them. No candidate for any job should ever send a list of references in advance. Instead, bring the references with you to the interview. References do not provide new information that helps the initial selection process. What references are good for is verifying that what the candidate said was (well, might be) true, and that they are (well, might be) of good character.
Also, in the existing legal climate, references generally won't be all that forthcoming, anyway. You know a candidate won't provide references they believe will be negative. The value added by references is not that much for anything besides corporate level executives, anyway. So, unless you are hiring a CEO or CFO, references won't even do you much good.
The problem with sending references is that there are some bad companies out there (and the candidates usually cannot sort this out very easily, because some of these bad companies are big corporations, and the often sleazy headhunters they do business with) end up using the references information inappropriately. I've been harrassed as a result of being listed as a reference by someone, and I've had to tell anyone who asks to use me as a reference to never give my name until after it at least it seems, during the interview, that the job is a good match. The best scenario is for the employer to ask the candidate at the end of the interview for the references as an indication that the candidate is being placed on the short list.
So if you were to ask for references to be sent with the resume, please expect that those people who value and respect the privacy of the people they are identifying as references will not do so immediately. Portfolios provided in advance are a good thing, and for people like graphical artists, that should be a standard way (short of intellectual property issues). But providing references in advance is completely inappropriate.
Regardless of whether the author of the article has his own agenda (boosting business for recruiters) or not, the current crop of job boards are really not designed very well.
One thing that is mentioned is the fact that employers get listings of people sorted by date, most recently updated first. And sure, that could be that way because the job boards are trying to drive traffic, rather than actually match jobs with people (and sell advertising, which many of them do ... more on that later). If candidates were listed in order of best match, it would serve the employer and the candidates better. But I'm not sure they can effectively do any decent matching.
These job boards seem to confuse business industry category (e.g. banking, auto manufacturing, software maker, internet provider) with job roles (accountant, lawyer, programmer, engineer, network administrator, secretary, janitor). If I pick the "internet hosting" category (most don't even get that detailed; the best you can do in many is "information technology" or "telecom") I end up seeing lots of jobs for Java Servlet programmers when what I really want might be a Network Administrator position. They also get job skills mixed up with job roles. There's lots of crossover between many job categories in terms of skills (a system administrator with programming skills in certain languages has an advantage in systsmes administrator, but might not want a job as a programmer, though would get matched with them because of that skill).
At a minimum, every job board should allow a candidate to specify each of the following:
Then for a job search to be done, or a position being posted, the employer would provide:
There are other things to add to this that would be optional, such as expected and probable pay level, previous job history (roles and business categories), etc. I believe searches would be far more effective if more aspects of matching, such as the above, were provided for. But it certainly seems to be the case that the job boards are more interested in driving higher numbers of page views.
Unfortunately, too many boards do search based strictly on keyword matching. I've actually gotten a match when I searched with "linux" as a keyword with a job that said "we are not running Linux here".
The current job boards are also turn offs to both employers as well as candidates. Employers generally have to pay for each posting, or monthly quota of posting, or a subscription. Small businesses will generally not be there, and larger businesses won't put all their jobs there (their own corporate web site is cheaper for them to post on). Job boards should really be free to employers, as well as candidates.
I don't know how bad it is for the employers, but candidates generally have to endure not only a regular flow of spam, but in many cases annoying things like pop-up ads, web bugs, and interstitial pages you have to select "no thanks" and click on as you go through each search or login.
I'd rather have Google style text ads (yes, I do sometimes click on them) support the site. And since ads are really about impressions, they should not be paid on a click through basis (if I am interested in what the ad offers, I usually go visit the sit
I placed my resume on Monster and a few others several times. I did get several calls from recruiters (some who obviously didn't actually read my resume, and some who did). But I never got a single call from anyone with any kind of scam offer, unless they cleverly hid it behind what sounded like a very legitimate high tech job. There were no calls about work at home schemes or any selling. So I guess I just didn't qualify.
<ianal>
Whether such code falls under the original UNIX license or not is irrelevant. SCO's claim is that Sequent/IBM agreed under contract terms that any "derivative work" becomes SCO property. It's not unlike GPL, which requires derivative works of GPL code to also be under GPL. But the difference here is that it wasn't written into the UNIX license, per se, but was part of the agreed contract.
That said, we have to look at whether SCO's argument, and the contract terms, are flawed and/or have a loop hole. Suppose the development of the technology at issue here was being done independently. That makes it the property of those who are doing that development, e.g. Sequent and/or IBM. If this technology is subsequently contributed into the UNIX operating systems (Dynix/ptx and AIX), it isn't really a derived work, but rather is a combination or merger. I don't know about Sequent, but IBM most certainly has a lot of other irons in the development fire, including a major operating system (MVS or z/OS) for their mainframe systems, as well as OS/2 from the early PC days, in which this very technology would also be of vital importance. So who's to know (IBM might) whether this technology was developed independently (IBM has lots of R&D people doing this very kind of thing) and just added on to AIX?
Consider it this way. What if I had developed some technology that IBM found would be very good for their operating systems. They come to me to get this technology and I license them non-exclusive rights to use it. Thus, I retain original ownership, but IBM can use it in their products (and pay me royalty). Now suppose they add this technology to AIX. Does that make it a derived work of UNIX and thus belonging to SCO? That's not possible because I retain the original ownership.
Now there are two issues. Did IBM (or Sequent) genuinely develop these things in some independent way, and if so, does the fact that the same company that owns that technology and also signed the contract agreement for UNIX mean that they have to place all the ownership of that technology under UNIX? If IBM put that technology in their mainframe OS, too, then it would look pretty clear that it is an independent development. I'm not so sure about Sequent.
My argument would be that if IBM can put a licensed technology into AIX without it becoming a derived work of UNIX in the case where they license it from someone else, then they can also put technology into AIX without it becoming a derived work of UNIX in the case where the development of it was done independently. And once it is not a derived work of UNIX, IBM is free (as the original owner) to do with it as they please, including making a GPL distribution branch of it for Linux (and this would not in any way mean that the copy of it in AIX is GPL).
I suspect that the case is going to either hinge on something like the above argument, or the fact that the contractual license agreement itself having originally come from AT&T, any rights to so-called "derived works" were dismissed by AT&T long ago.
</ianal>
There will be encrypted underground networks then, as there are today ... only more so given the available bandwidth to do it. The [RM][IP]AA* people don't even have a clue about some of the stuff out there.
*For those Windows people who don't catch on, "RM IP" can mean "ReMove Intellectual Property". "[RM][IP]AA" is a regular expression pattern that can match either "RIAA" or "MPAA".
Content for media devices, such as record players, movie projectors, CD players, video records, etc., has been called "software" for as long as that equipment has been called "hardware". The computer field does not own exclusivity to the term.
Let's add another 50 channels, and make them all 100 mbps, to the 2.4 GHz band.
Yeah right.
Wireless just doesn't have the ability to expand bandwidth like that. It's limited to what bandwidth exists at any given frequency, and much of that is already allocated and that would, itself, impose massive costs just to move things around. There's isn't the room for the scale we need below the 300 GHz frequency point, and that technology is still too expensive.
Fiber optic is mature enough now to scale up production to decrease costs to the commodity level once there is the commitment to roll out this kind of bandwidth. And while we are at it, why stop at 100 mbps. Let's go for 400 mbps or even 1 gbps.
As for whether we should "waste" it on TV, that should be a matter of each individual consumer to choose what they want to have fed through their little piece of glass. If they want to have TV, fine, let them. The only areas I see as being potential problems are what people like Ralsky and Richter and some others like them would do with it.
Maybe it's time for the BBC to end that license fee system?
He's obviously bringing in more readers. Isn't that what their goal is?
Every proposal I see stil ends up with the control in someone's hands. Whether it is in the hands of politicians in some country, in the hands of politicions of all countries toegther (such as via UN), in the hands of corporations, in the hands of the original network creators, or even in the hands of the kid down the street that cracked into the system without anyone noticing, the fact is, the power is concentrated somewhere. Every proposal concentrates the power somewhere away from other places who might not be happy with the way it is. I doubt a system can ever be made that makes everyone happy, but can there be a system that at least everyone things is fair?
I can come up with reasons for not putting the domain names in the hands of ... any of those groups.
I hereby propose: total anarchy!
And my proposal won't require a vote of approval, either. The way this is done is that every DNS server operator will simply run their own root zone, and include whatever top level domains they like. If they want to use the [a-m].gtld-servers.net servers for the .com and .net domains, they can. If they want to use some other source, instead, that's up to them. If they want to add new domains like .mp3 or .nospam or .xxx, then they can. Who's going to say they can't, anyway. I have one of those three in my servers now and you can't make me take it back out.
The usual argument against my proposal is "it will fragment the net". My usual answer to that argument is "ah, I see, you do understand how it works". If we are going to not be fragmented, we all have to follow a common leadership. But I think it's quite clear that we do not wish to do that. I doubt very much that anyone of consequence will turn away from [a-m].gtld-servers.net for the .com and .net domains, and likewise for many others. In reality, the net will always have an unfragmented aspect to it. But my proposal also allows for the net to have the fragmented part, which will satisfy our need to not play "follow the leader" in all our domains.
Now, are people going to follow my lead, or are they just going to do whatever they wish?
I did this about 5 years ago. But my method was a bit different. Instead of using port numbers to contain the information (and that's all it really is, is just information), I sent a single UDP packet, with a source port of 53 (so it looks like a DNS answer), formatted like a DNS answer, that contained the information in the DNS answer data. Then it opened the SSH filter for that IP address to come in (I did it for 5 minutes, not 10 seconds). It still had to fully authenticate via SSH, so even if someone sniffed my DNS packet and tried to fake it, they could at most have a locked door to jiggle the handle on. Next time I do this, it will be to generate an MD5 checksum from the client IP and a secret salt, and send that as an IPv6 address in the packet. Then it can't even be faked from some other IP address.
It's a configuration option on Squid. You're caching poorly if you don't use it ... depending on how many different users you have using it. If all your users are using the same exact browser version, it won't matter. But if all your users are using different browsers, they won't be "hitting" each other's cached data, even if the data is identical (unless the cache violates RFCs). 99.999% of web sites work fine. Wikipedia and New Scientist are the only web sites I can recall which have the problem with lack of User-Agent. Everything else, including Slashdot, works fine when User-Agent is omitted. Several ISPs have switched to no User-Agent mode to improve their caching. The only catch anyone should ever see is a lack of customized HTML, and that's not considered a good web design practice anymore considering that modern web standards work excellent on all new browsers, and degrade gracefully on old browsers.
Wikipedia still refuses to work with some proxies that choose to optimize their caching by not transmitting the User-Agent header. And they don't even do the courtesy of explaining why; they just give a "Forbidden: You don't have permission to access / on this server." error and that's it.
RFCs require that when a cache passes User-Agent, it must cache received data such that a client requesting exactly the same URL, but with a different User-Agent string, cannot use that cached data. Think of it as combining the User-Agent string value and the URL string to get the index into the cache. So with that and the fact that so many clients have so many variant strings, including version numbers and build numbers, caching works very poorly unless User-Agent is removed from the request (which is valid to do, even though the RFCs recommend not doing so).
So to use Wikipedia I have to stop using the cache server, which because I'm stuck on a slow dialup, is a big performance hit.
The reason for this, as I've found out, is that some web crawlers that abuse the site (because they run so fast), are recognized by not using User-Agent. I think they could do better by recognizing abusive sites and just blocking their IP address for a while (or teergrubing them), regardless of whether they have User-Agent or not.