This won't work for someone like me who has his own domain and has broadband at home. I send mail through my broadband carrier because I don't have access to mail on the server that hosts my domain. With your method, all SMTP servers will reject my email. This situation is similar to colocated servers that send out mail using the isp's MX because their domain doesn't have one of their own.
What you'd need to do is set up your domain on a dynamic DNS service and then use a ddns client on your home broadband system to update it. They'll let you do MXes through this as well. If you don't want to be receiving email at your home system, then you set your home system up as a low priority MX (so that email gets delivered to your other email server first) and set up a firewall to block incoming port 25 connections (which you do already... right?).
If a colocated server wants to send out email using an ISP's MX then the owner of the colocated server needs to make arrangements with the ISP so that the ISP will do the right thing, and set itself up as the domain that appears in the "MAIL FROM" exchange.
All the system I'm promoting does is make people prove that they're being honest.
I am afraid it won't work. Imagine I am a spammer who just found an open relay at (say) 10.11.12.13 and an open proxy at (say) 192.168.1.2. I change the MX-es for example.com to those IP addresses and start pumping spam through those machines.
You can't change the MXes for example.com to those IP addresses unless you are the owner of example.com (otherwise you'd have to hack into someone's DNS server).
So: that means that you're the owner of example.com.
But if you list an open relay as an MX for your domain and start sending spam from it, your domain suddenly gets put on a blacklist and people start dropping all your email from that domain on the floor, legitimate or not.
And as a spammer, that means that you're either out of business or you have to shell out another $10-$15 for a new domain. This eats into your profits because it costs you both time and money.
The answer to this shortcoming in the current email infrastructure is redesigning email protocols to allow spam to be stopped as it is sent.
No need to redesign any protocols. We already have what we need.
All we need to do is enforce a rule that says that any email sender for a domain must be listed as an MX for the domain (if you don't want that system to receive email for the domain, list it as a low priority MX and block incoming SMTP traffic to it. You're already doing the latter anyway, right?). You get information about which domain to look up from the SMTP "MAIL FROM" command (not to be confused with the "From:" line in the message headers).
So, imagine for a moment that someone sends a piece of email to a mail relay. Right now, if it's an open relay, the relay just forwards the email to all the recipients specified.
But under the scheme I'm thinking of, the relay will look up the MXes for the domain listed in the "MAIL FROM" command and compare them with the IP address of the sender. If there's a match, it delivers the mail. If there isn't a match, it drops the connection right then and there.
But even if the open relay doesn't do this, the system it tries to deliver email to will -- and the open relay will not be listed as an MX for the domain associated with the spam message, so the mail will be dropped on the floor by the receiving system.
And even if it is listed as an MX for the spammer's domain, you now have an entire domain you can blacklist.
And that means that spammers are now forced to set up their own domain. And that costs money. And worse, they now also have to list their sending system as an MX, which means that it becomes obvious where the bogus email is coming from -- so blacklists will be much more effective, because they can reference domains directly instead of IP addresses (the reason this is much better is that IP addresses change frequently because most of them are dynamically allocated, but domains are much more permanent). The more quickly you blacklist domains, the more money spammers have to put into buying new domain names.
Now, the real beauty of this scheme is that email gets through only if all of the relaying systems pass the email through. If only one of them decides that the system they're receiving the mail message from isn't an MX for the sender's domain, the email gets dropped on the floor (and never even hits the spool). Only if there's a DNS failure will the email get queued up, but it'll stay in the queue until the MX status is known. The SMTP server can be configured to bounce messages that have been queued up in that state for too long.
So there can be lots of open relays, and as long as your mail server enforces the above provision, you'll only get email from sources that are truly legitimate: sources that have control over their own domains.
That'll eliminate most of the spam originating from broadband addresses and almost all spam passed through open relays, among other things. It's real simple: if you want to be able to successfully send email directly from your machine, you have to operate a domain that lists your IP address as an MX for your domain. Otherwise you have to go through your ISP's email server. This isn't a big deal, since a number of dynamic DNS services exist these days, and setting up an MX for your domain through DDNS is commonplace and well understood.
Remember that the people behind these corporations are exactly that; people. They're not monsters hell-bent on destroying civilization, they are simply under pressure from their constituents (anyone who owns stock) to make money doing what they do.
Nonsense. These corporations are already making money doing what they do. A law like the DMCA isn't required for them to continue to make money, only for them to make even more of it. Profit is fine. Profit at the expense of the rights of the people is not. It's the latter that these corporations are after, and that is why the people who run them are evil. They're evil because of their indifference, not because of their malevolence.
As for what these executives are after, I think that's quite clear: pay per view content on computers, with the money going directly to them without any middlemen. Can't have that without something like the DMCA, since otherwise there would be no means to bring legal pressure on people who release cracks for such schemes.
...which I think is quite interesting, considering that it's one of the most recent arrivals on the Linux scene (MySQL and PostgreSQL are much more widely used on the Linux platform).
They're looking for contributors to help port the tests over to other databases, and I for one will be very interested in seeing how the various database engines for Linux stack up against each other when tested using these tools.
Actually the XRender extension does do what is needed. "compositing" of the alpha-transparency characters are done on the server, while before transparency requred the app to read what was on the screen (or more likely, remember what it drew there before) and do the compositing itself and send the resulting image back. Also XRender caches the glyphs on the server, or so I am lead to believe. Technically this addresses all of the real issues with supporting antialiased fonts.
I'm aware of this. Nevertheless, Render isn't required to do antialiased fonts, it merely speeds up the operation (by a lot, I might add). Admittedly, doing all on the client without help might not be fast enough to be useful, but I'm inclined to believe otherwise for the simple reason that clients like rxvt have been doing "transparency" long before Render came on the scene.
My entire point is that it's ludicrous for the client to even be aware that the fonts it's using are antialiased. On that we seem to be in agreement.
Re:Let the flames begin ... and ignore them.
on
XFree86 4.3.0 Released
·
· Score: 3, Insightful
Anti-aliased text? Check.
Uh, no.
There's not really any more support for anti-aliased fonts now than there was before the Render extension, except that the Render extension makes drawing of anti-aliased fonts fast.
But the application still has to do the work itself. Whether it does so through "standard" libraries like the gtk or KDE toolkits is irrelevant: the bottom line is that anti-aliased fonts requires client-side support.
Clients have always been able to do anti-aliased fonts if they wanted to, but prior to the Render extension they had to do it the hard way: by actually drawing the individual characters and doing the transparency blending themselves.
The implementation of anti-aliased fonts is all wrong, IMO. The XFree86 folks should define a new font server protocol that knows how to talk about transparency (indeed, the protocol could easily be implemented such that it uses the same socket and everything: if the X server sees that it's talking to an old font server then it will revert to the proper monochrome font protocol), implement a font server based on Freetype that actually uses it, and hack the X server backend so that it automatically does the right thing when asked to perform operations using an antialiased font. The client shouldn't even know or care if the font is antialiased: that's a server-side-only issue (it's acceptable to name antialiased fonts differently, using perhaps a different encoding name or something, in order to make it possible for the client to distinguish between antialiased and nonantialiased if necessary).
Font handling belongs in the server. The client should never have to worry about it. Which means that the situation as it is now should never have come to pass. The Render extension is very useful for things like doing transparent windows and such, but it should never have been used for font handling: that was an evil hack, and now we're stuck with it.
The PTO wasn't given authority to mark patents as valid or not.
How in the world was this marked as "insightful"??
If there's any government entity that has been given the authority to validate a patent, it's the USPTO, because they grant patents, and a patent is in force once it has been granted by the USPTO.
I'd agree with you if the USPTO were an advisory board only, but they're not. What they say about a patent has the force of law behind it unless and until a court of law says otherwise, just like a bill, once it passes both houses of Congress and the President, has the force of law behind it until a court of law says otherwise.
In essence, the USPTO is a body of government that passes very specific laws, ones which say that certain specific entities are entitled to a monopoly on certain specific inventions.
Doesn't matter. Look at how (in)effective the lock-down of DeCSS has been. Pirated movies are becoming quite mainstream for anyone with a broadband connection. I have quite a bit of faith that some 14-year-old (let's hope he stays anonymous this time) will crack this system, and millions of copies will be circulated before the MPAA can cry wolf.
Just because content protection systems have thus far been designed by morons with no understanding of encryption doesn't mean they'll always be designed by morons.
What do you think will happen when the operating system verifies the hardware with a cryptographic challenge-response to determine whether or not the hardware is trustworthy ("hey, hardware, sign this message with your private key, and I'll decrypt it with your public key that I have already verified has been signed by Microsoft"), then uses the hardware itself to store its private keys and to encrypt and sign documents, huh? Now in order to "crack" the system you'll have to somehow intercept the keys at the hardware level. And if it's all integrated into the processor, you're screwed.
Think you can avoid this forever? You'll be forced to upgrade your hardware sooner or later because hardware dies after a long enough period of time.
You think Microsoft is going to cryptographically sign the public keys of hardware vendors that decide not to bend over and implement a requirement that the OS the system loads be (ultimately) cryptographically signed by Microsoft? You think they'll set up their OS to run when it can't verify that the hardware's key has been signed by them?
Microsoft plays for keeps. Always. And they have time, lots of time. They'll increase their requirements slowly. Their OSes will initially allow Palladium to be turned on or off by the user. At that point it won't necessarily require underlying hardware support. Then, later, it'll require support from hardware that has a key signed by Microsoft, but will still be optional. Then, later, it'll be on all the time. Simultaneously, Microsoft will slowly ratchet up the hardware requirements on the part of vendors who wish to sell Windows, until finally they require the hardware vendor to manufacture machines that will only boot OSes that have been signed by Microsoft.
Think you can run that older version of Windows all the time? Think again. Windows has tons of security weaknesses. Whether that's intentional or not, it's something that Microsoft can take advantage of. Have a security vulnerability that you need patched? Sorry, but the patch also ratchets up Palladium to the next level. Take it or leave it, but you won't have a choice of separating the two. And the patch doesn't even need to be for Windows. It could be a patch for Office. Doesn't matter, you're running it under Windows, and that exposes you to the aforementioned "upgrade".
This has to be stopped early, or it won't be possible to stop it.
Your approach is too simplistic. I've been using my yahoo.com email address for years, but never once have I relayed through a Yahoo SMTP server. In fact, a previous ISP of mine wouldn't even allow that. I do not want to be forced to use an email address with ISPs domain in it either.
Then use your own domain! An ISP that won't let you send outbound email from your system is one that should be dumped, IMO. But let's assume that they won't, and they force you to use their system to relay email.
The email address that appears in the "From:" line is under your control. The email address that appears in the SMTP "MAIL FROM" command is under the ISP's control. They can easily set it up so that whenever you send email through their SMTP relay, the address that appears in the "MAIL FROM" command is that of your email account with the ISP (and can be gotten a couple of ways, including the authentication method you're using to the IP address you're using). They can also set it up so that what appears in the "MAIL FROM" command is a constant (e.g., "MAIL FROM mta@yourisp.net"). But no matter how you look at it, the problem you're talking about won't be an issue.
I have a static IP at home hosting a personal domain and mail server. The hostname for my static IP doesn't match that of my domain, although it is an MX. Thus the email addresses from my domain don't match the domain of the IP address (is that relevant??).
If you mean that the reverse lookup of your static IP address won't resolve to the domain you're using then no, that won't matter at all. That's something I tried to be very careful to avoid, because it's rare that someone has control over the result of a reverse lookup of his IP address.
All that matters is that when the receiver looks up the MX list for the domain mentioned in the "SMTP FROM" command, one of the MX IP addresses matches the IP address of the machine you're connecting to them with. Since you have control over your domain (and a static address...lucky bastard:-) you can add your IP address as an MX for your domain. If you already have other systems designated as MXes for it you'll probably want to list your static IP as a low-priority MX so that mail always gets delivered to your real MXes first. Then you just have to block incoming SMTP connections to your static IP address, unless you want it to actually act as an MX for your domain.
More troubling for me though is that I've configured my MTA (Exim) to do something along the lines of what you said. I've seen in my logs messages being rejected. For example, an old friend tried to contact me through FriendsReunited.co.uk - my mail server rejected the message because it couldn't verify the email address of the sender, which had a different domain.
That's not quite the same thing, because you got that information by trying to reverse the IP address of the sender, right? That's a method which is a lot more error prone because people don't have control over their reverse zones (thanks to how DNS is set up). But they do have control over their forward zones, which is why the scheme I'm promoting uses it.
The method I'm suggesting is a convention. Like any convention, it's not going to work if people don't adopt it. But aside from spam filters, there is no method that doesn't require the adoption of a convention, so the method I'm suggesting isn't any worse than any of the others in that regard.
No. The vast majority of the time, the MUA gives the MTA a MAIL FROM address which is identical to the From: line in the mail.
But if you have control over the box the MTA is running on then you supposedly have control over what the MTA will do in that situation. I suppose that's not necessarily true, since you may be running a proprietary MTA. In that event I'm not sure what to tell you, except perhaps to always use a From: line that refers to a domain that is under your control.
The biggest problem with the convention I described is that right now, people don't use systems that are declared MXes to send outbound email. It's something that would have to change, but to deal with the spam problem effectively something will have to change anyway.
This will work for most senders, but it is entirely possible that the addresses sending mail are different to those which can receive mail.
I addressed this problem in the original proposal: set up the systems that are sending mail as MXes anyway (at low priority, so all connections will try to go to the valid MXes first), and drop inbound port 25 connections to your systems that are email senders. You're dropping those connections anyway if you've got any brains at all (since your explicit intention is to not receive inbound email to those boxes from the outside world), so it's not like you have to make any drastic changes to the way you do things.
A "solution" like that would trash my outbound mail. I forge my From: addresses routinely.
What appears in the From: line and what appears in the SMTP "MAIL FROM" command are often two entirely different things. The former is set by you, the latter is usually set by your MTA. Generally, if you invoked your MTA then it'll use your username and whatever domain you've assigned to your box in the "MAIL FROM" command, if I'm not mistaken.
In any case, you should have enough control over your own box to control what appears in the "MAIL FROM" command, and that's the point: spammers do their deed by using systems that they do not control.
If you acquire your own domain and make your IP address an MX for your domain, then you'll be able to get past the scheme I described without any problems -- no matter what you set your "From:" line to. You can do this even if your IP address is dynamic; there are a number of dynamic DNS services out there that will do this for you, for your own domain.
I can't relay through the ISP's relays, because I'm outside of their IP range. (If they did some form of authenticated SMTP, such as SMTP-after-POP, they could let me.) And the cable vendor's mail relays won't send mail out with some other domain name on it. So I send everything out directly, no relays.
With the scheme I described, you won't need to relay through anybody. In fact, you won't be able to relay through anybody, except those systems that you control, or those systems belonging to your ISP that will generate an SMTP "MAIL FROM" command based on the "From:" line you use in your email -- and that means that you'll be forced to use their domain in your "From:" line if you want to use their relays. That's a benefit, not a drawback: it forces everyone to be honest, which is very much what the spammers do not want.
If the govt. is allowed to regulate standard telephony, they must do the same for VoIP. Otherwise, VoIP software companies and ISPs have an unfair advantage over telephone companies.
Since most ISPs end up relying on the telephone company for their data lines anyway, and considering that these same telephone companies (baby bells) have been running roughshod over local ISPs that are trying to provide DSL service, I have very little sympathy for the position of the telephone companies. Let them experience what little pain will come with VoIP (I say "what little pain" because they'll benefit from the increased internet business at the same time they're losing telephone income).
Right now everyone is forced to accept email connections from anyone who sends email because it's not possible to tell ahead of time whether or not the connection is coming from someone who is reliable, right? And spammers take advantage of this by sending millions of messages from open relays. Blocking that is a virtual impossibility because which relays are open changes over time.
The first inclination one has would be to suggest that everyone close their open relays. But this depends on people doing the right thing all the time, and has proven ineffective.
Fortunately, there's another way.
Right now, everyone who receives mail has to listen to everyone who tries to connect. The problem is how do you separate the wheat from the chaff?
The solution is to take advantage of the information SMTP and TCP/IP give you when a connection is established. The fact that you're receiving a connection gives you the address of the sender. And during an SMTP transaction, one of the SMTP commands (the MAIL FROM command) gives you the domain of the email's sender, e.g. "MAIL FROM slashdot@sysexperts.com".
When you're sending email to someone else, you do so by looking up the MX records for their domain, which tells you which systems are responsible for receiving email for that domain. This gives us a possible answer to the spam problem.
Suppose instead of blindly accepting email from everyone, you were to take the domain given to you by the MAIL FROM command, look up the MXes for that domain, and reject the email connection if the IP address of the sender doesn't match one of the domain's MXes?
Now, suddenly, you would end up rejecting email sent from every unauthorized relay, because the owner of the domain can make any system that is allowed to send email on behalf of his domain into an MX (and, if he doesn't want that system to be used for delivering email, then he simply makes such systems the lowest priority MXes in the list and blocks outside port 25 connections to them... something he's probably doing anyway).
Suddenly, the only systems that spammers can send email from are systems that they legitimately control and that are defined as MXes for a domain they control. Suddenly, spammers have to set up and maintain their own domains and their own boxes. The costs have just become a lot higher, which will get rid of most of the spammers.
And suddenly, blocking spam becomes orders of magnitude easier -- you only have to deal with spammers who have decided to pay the (now much higher) price for sending spam and who cannot use someone else's system to do their dirty work without permission.
Have you ever tried to read a patent? Trying to read a patent and not go nuts is quite a feat in some cases.
Since the whole purpose of the patent system is to publish ideas so that the world will be able to implement them freely when the patent expires (this is what the public is supposed to gain from the patent system), and therefore patents need to be readable, it seems to me that any patent that fits your description (which is most of them right now) should be automatically rejected due to unreadability.
The patent should make the idea it represents as obvious to the reader as possible. It's defrauding the public if it doesn't.
Yeah, I know that it's in the interests of the people writing the patents to do the opposite. Too fucking bad for them: if they want the benefits of a patent, they should be forced to accept the terms that should go along with it.
The patent office could enforce this, and we'd all be a lot better off for it. But noooooooo...
I assume if Mono dates from the period before the Patent application then MS is too late.
Given the USPTO's propensity to grant patents on pretty much anything thrown at them, whether or not there's any prior art, you assume far too much.
Re:What is BEHIND that money... that is the questi
on
The Future of Money
·
· Score: 1
The question isn't "what form will money be in", the question should be "what assets will back our money". I don't care if its in the form of rice crispies, as long as it is backed by an asset (gold, food, land, space rocks) and has real value.
Tying it to a hard asset doesn't help you. The reason it doesn't help you is that the asset itself is fluid just like the money that represents it: more of the asset can be acquired if need be in order to make the country in question appear "richer", and indeed that was commonly done back when gold was the standard. Acquisition of more of the backing asset is usually a matter of expending sufficient labor (sometimes in the form of the use of the military). Print money simply has a much lower expenditure rate per dollar produced. And as described below, it's highly advantageous to have your exchange mechanism be as fluid as possible.
Money itself is just a means of representing the value of something relative to the value of something else. Usually one of the things whose value is being measured is your labor (when you get paid and then spend the resulting money on something, the price of the something in question is just an indicator of the value of your labor relative to the value of the object you just purchased, and the value of the object is ultimately, more or less, the sum total of the value of the labor used to produce it). Ultimately, since the value of an object is essentially the value of the labor used to make it (which includes all the labor used to generate the raw materials, to process those materials, to assemble the object, and to manage all of that), money simply represents the value of your labor versus the value of someone else's.
In a perfect world, a change in the overall wealth of a country (as measured by the ability of the country to do work) would be instantly reflected in the price of goods relative to the price of labor. Unfortunately, the world is not perfect and there is a delay. And this is the reason for printing more money: so that the price of goods and services does not need to change significantly as the country is able to do more work. Print too much and the society has to adjust the prices to reflect the larger supply of tokens, just as it does if the country does't print enough.
Where things get complicated isn't really within a country's economic system: the currency for that is reasonably well-defined. The complication comes when dealing with other countries with their own currencies, particularly when those currencies are not managed the same way.
The cost of labor in India is lower than it is in the United States. It's lower because the cost of living is lower. But the lower cost of living isn't necessarily a consequence of the lower amount of total work it takes to supply someone with the goods and services needed to live, even when the person in question is living at the same standard of living as someone in the U.S. Nor is it necessarily a consequence of one country being more desirable to live in than another, though that probably factors into it some. Most of the difference is the result of the fact that markets require time to adjust themselves properly relative to other markets.
That's why programmers in India will eventually be paid roughly the same as programmers in the U.S.: the value of their labor isn't really much (if any) less than the value of the labor of programmers in the U.S. -- the hysteresis between the two labor markets just makes it appear that way temporarily. Corporations are now attempting to use that hysteresis to their own advantage, by shifting the demand for work towards markets which have not equalized themselves with the others. And the reason the markets themselves don't adjust on their own is that the labor in those markets isn't as fluid as the Corporate demand for labor, thanks primarily to immigration laws. That means that the labor cannot move to where the demand is. And even if it could, it would take time for the labor to move, and thus for the market to adjust. That time is the very thing which causes hysteresis between the markets.
Windows Update is easy to use, and I run it every few weeks, but the assorted packages on my linux box are much harder to track and keep patched so I miss patches that I should apply.
That's because you're not using Debian or an apt-based RPM system. Debian, in particular, releases security patches whenever an issue pops up, and it's particularly handy to be able to apply them all in one command (I had to set up a separate config file and sources.list), but now all I do is "apt-get --config-file=/etc/apt/apt.conf.security upgrade". I'll periodically do a "--dry-run" first to see what patches are available.
Debian may be annoying to install (it definitely is, in my experience) but it's a piece of cake to maintain.
I want stuff to cost less, and if producing it elsewhere can do that then that's what globalization is all about!
You want stuff to cost less. That's fine, in and of itself. But will it really cost less after you've lost your job?
See, lots of you people aren't accounting for something really important: how much something costs is relative to your income. As jobs move from here to other locations and unemployment rises here in the U.S., the competition for jobs here will rise and the average wage will fall. But if the average wage falls then fewer people will be able to afford goods at the same price point, so the demand for those goods drops. A drop in demand for the goods has to eventually result in a drop in the price of the goods. But if the average wage falls and the price of goods also falls, then the relative cost of goods will remain roughly the same.
But there are delays in the economic system: the average wage won't drop until some amount of time after the unemployment rate rises, the demand for goods won't drop until some amount of time after the average wage drops, and the cost of goods won't drop until some amount of time after the demand for them drops. Because of that, on the downward slide, there is a period of time when the salaries are low but the cost of goods is high, and that's when things hurt. That's when, in extreme cases, people have to move out on the street because they can no longer afford the high price of housing, or have to sell their car because they can no longer afford the payments on it, etc. Extreme cases like that are known as depressions, and I think we're headed for a really big one.
So the bottom line is that you're likely to get your wish, but you probably won't benefit from it at all. In fact, because of the delays, you're likely to suffer from it instead.
Slashdot Mirror
What you'd need to do is set up your domain on a dynamic DNS service and then use a ddns client on your home broadband system to update it. They'll let you do MXes through this as well. If you don't want to be receiving email at your home system, then you set your home system up as a low priority MX (so that email gets delivered to your other email server first) and set up a firewall to block incoming port 25 connections (which you do already ... right?).
If a colocated server wants to send out email using an ISP's MX then the owner of the colocated server needs to make arrangements with the ISP so that the ISP will do the right thing, and set itself up as the domain that appears in the "MAIL FROM" exchange.
All the system I'm promoting does is make people prove that they're being honest.
You can't change the MXes for example.com to those IP addresses unless you are the owner of example.com (otherwise you'd have to hack into someone's DNS server).
So: that means that you're the owner of example.com.
But if you list an open relay as an MX for your domain and start sending spam from it, your domain suddenly gets put on a blacklist and people start dropping all your email from that domain on the floor, legitimate or not.
And as a spammer, that means that you're either out of business or you have to shell out another $10-$15 for a new domain. This eats into your profits because it costs you both time and money.
No need to redesign any protocols. We already have what we need.
All we need to do is enforce a rule that says that any email sender for a domain must be listed as an MX for the domain (if you don't want that system to receive email for the domain, list it as a low priority MX and block incoming SMTP traffic to it. You're already doing the latter anyway, right?). You get information about which domain to look up from the SMTP "MAIL FROM" command (not to be confused with the "From:" line in the message headers).
So, imagine for a moment that someone sends a piece of email to a mail relay. Right now, if it's an open relay, the relay just forwards the email to all the recipients specified.
But under the scheme I'm thinking of, the relay will look up the MXes for the domain listed in the "MAIL FROM" command and compare them with the IP address of the sender. If there's a match, it delivers the mail. If there isn't a match, it drops the connection right then and there.
But even if the open relay doesn't do this, the system it tries to deliver email to will -- and the open relay will not be listed as an MX for the domain associated with the spam message, so the mail will be dropped on the floor by the receiving system.
And even if it is listed as an MX for the spammer's domain, you now have an entire domain you can blacklist.
And that means that spammers are now forced to set up their own domain. And that costs money. And worse, they now also have to list their sending system as an MX, which means that it becomes obvious where the bogus email is coming from -- so blacklists will be much more effective, because they can reference domains directly instead of IP addresses (the reason this is much better is that IP addresses change frequently because most of them are dynamically allocated, but domains are much more permanent). The more quickly you blacklist domains, the more money spammers have to put into buying new domain names.
Now, the real beauty of this scheme is that email gets through only if all of the relaying systems pass the email through. If only one of them decides that the system they're receiving the mail message from isn't an MX for the sender's domain, the email gets dropped on the floor (and never even hits the spool). Only if there's a DNS failure will the email get queued up, but it'll stay in the queue until the MX status is known. The SMTP server can be configured to bounce messages that have been queued up in that state for too long.
So there can be lots of open relays, and as long as your mail server enforces the above provision, you'll only get email from sources that are truly legitimate: sources that have control over their own domains.
That'll eliminate most of the spam originating from broadband addresses and almost all spam passed through open relays, among other things. It's real simple: if you want to be able to successfully send email directly from your machine, you have to operate a domain that lists your IP address as an MX for your domain. Otherwise you have to go through your ISP's email server. This isn't a big deal, since a number of dynamic DNS services exist these days, and setting up an MX for your domain through DDNS is commonplace and well understood.
Nonsense. These corporations are already making money doing what they do. A law like the DMCA isn't required for them to continue to make money, only for them to make even more of it. Profit is fine. Profit at the expense of the rights of the people is not. It's the latter that these corporations are after, and that is why the people who run them are evil. They're evil because of their indifference, not because of their malevolence.
As for what these executives are after, I think that's quite clear: pay per view content on computers, with the money going directly to them without any middlemen. Can't have that without something like the DMCA, since otherwise there would be no means to bring legal pressure on people who release cracks for such schemes.
An implementation of an idea. Which, of course, is exactly what patents are supposed to cover.
They're looking for contributors to help port the tests over to other databases, and I for one will be very interested in seeing how the various database engines for Linux stack up against each other when tested using these tools.
I'm aware of this. Nevertheless, Render isn't required to do antialiased fonts, it merely speeds up the operation (by a lot, I might add). Admittedly, doing all on the client without help might not be fast enough to be useful, but I'm inclined to believe otherwise for the simple reason that clients like rxvt have been doing "transparency" long before Render came on the scene.
My entire point is that it's ludicrous for the client to even be aware that the fonts it's using are antialiased. On that we seem to be in agreement.
Uh, no.
There's not really any more support for anti-aliased fonts now than there was before the Render extension, except that the Render extension makes drawing of anti-aliased fonts fast.
But the application still has to do the work itself. Whether it does so through "standard" libraries like the gtk or KDE toolkits is irrelevant: the bottom line is that anti-aliased fonts requires client-side support.
Clients have always been able to do anti-aliased fonts if they wanted to, but prior to the Render extension they had to do it the hard way: by actually drawing the individual characters and doing the transparency blending themselves.
The implementation of anti-aliased fonts is all wrong, IMO. The XFree86 folks should define a new font server protocol that knows how to talk about transparency (indeed, the protocol could easily be implemented such that it uses the same socket and everything: if the X server sees that it's talking to an old font server then it will revert to the proper monochrome font protocol), implement a font server based on Freetype that actually uses it, and hack the X server backend so that it automatically does the right thing when asked to perform operations using an antialiased font. The client shouldn't even know or care if the font is antialiased: that's a server-side-only issue (it's acceptable to name antialiased fonts differently, using perhaps a different encoding name or something, in order to make it possible for the client to distinguish between antialiased and nonantialiased if necessary).
Font handling belongs in the server. The client should never have to worry about it. Which means that the situation as it is now should never have come to pass. The Render extension is very useful for things like doing transparent windows and such, but it should never have been used for font handling: that was an evil hack, and now we're stuck with it.
How in the world was this marked as "insightful"??
If there's any government entity that has been given the authority to validate a patent, it's the USPTO, because they grant patents, and a patent is in force once it has been granted by the USPTO.
I'd agree with you if the USPTO were an advisory board only, but they're not. What they say about a patent has the force of law behind it unless and until a court of law says otherwise, just like a bill, once it passes both houses of Congress and the President, has the force of law behind it until a court of law says otherwise.
In essence, the USPTO is a body of government that passes very specific laws, ones which say that certain specific entities are entitled to a monopoly on certain specific inventions.
Hmm...yes, so it seems:
A few years later...
Just because content protection systems have thus far been designed by morons with no understanding of encryption doesn't mean they'll always be designed by morons.
What do you think will happen when the operating system verifies the hardware with a cryptographic challenge-response to determine whether or not the hardware is trustworthy ("hey, hardware, sign this message with your private key, and I'll decrypt it with your public key that I have already verified has been signed by Microsoft"), then uses the hardware itself to store its private keys and to encrypt and sign documents, huh? Now in order to "crack" the system you'll have to somehow intercept the keys at the hardware level. And if it's all integrated into the processor, you're screwed.
Think you can avoid this forever? You'll be forced to upgrade your hardware sooner or later because hardware dies after a long enough period of time.
You think Microsoft is going to cryptographically sign the public keys of hardware vendors that decide not to bend over and implement a requirement that the OS the system loads be (ultimately) cryptographically signed by Microsoft? You think they'll set up their OS to run when it can't verify that the hardware's key has been signed by them?
Microsoft plays for keeps. Always. And they have time, lots of time. They'll increase their requirements slowly. Their OSes will initially allow Palladium to be turned on or off by the user. At that point it won't necessarily require underlying hardware support. Then, later, it'll require support from hardware that has a key signed by Microsoft, but will still be optional. Then, later, it'll be on all the time. Simultaneously, Microsoft will slowly ratchet up the hardware requirements on the part of vendors who wish to sell Windows, until finally they require the hardware vendor to manufacture machines that will only boot OSes that have been signed by Microsoft.
Think you can run that older version of Windows all the time? Think again. Windows has tons of security weaknesses. Whether that's intentional or not, it's something that Microsoft can take advantage of. Have a security vulnerability that you need patched? Sorry, but the patch also ratchets up Palladium to the next level. Take it or leave it, but you won't have a choice of separating the two. And the patch doesn't even need to be for Windows. It could be a patch for Office. Doesn't matter, you're running it under Windows, and that exposes you to the aforementioned "upgrade".
This has to be stopped early, or it won't be possible to stop it.
Then use your own domain! An ISP that won't let you send outbound email from your system is one that should be dumped, IMO. But let's assume that they won't, and they force you to use their system to relay email.
The email address that appears in the "From:" line is under your control. The email address that appears in the SMTP "MAIL FROM" command is under the ISP's control. They can easily set it up so that whenever you send email through their SMTP relay, the address that appears in the "MAIL FROM" command is that of your email account with the ISP (and can be gotten a couple of ways, including the authentication method you're using to the IP address you're using). They can also set it up so that what appears in the "MAIL FROM" command is a constant (e.g., "MAIL FROM mta@yourisp.net"). But no matter how you look at it, the problem you're talking about won't be an issue.
If you mean that the reverse lookup of your static IP address won't resolve to the domain you're using then no, that won't matter at all. That's something I tried to be very careful to avoid, because it's rare that someone has control over the result of a reverse lookup of his IP address.
All that matters is that when the receiver looks up the MX list for the domain mentioned in the "SMTP FROM" command, one of the MX IP addresses matches the IP address of the machine you're connecting to them with. Since you have control over your domain (and a static address...lucky bastard :-) you can add your IP address as an MX for your domain. If you already have other systems designated as MXes for it you'll probably want to list your static IP as a low-priority MX so that mail always gets delivered to your real MXes first. Then you just have to block incoming SMTP connections to your static IP address, unless you want it to actually act as an MX for your domain.
That's not quite the same thing, because you got that information by trying to reverse the IP address of the sender, right? That's a method which is a lot more error prone because people don't have control over their reverse zones (thanks to how DNS is set up). But they do have control over their forward zones, which is why the scheme I'm promoting uses it.
The method I'm suggesting is a convention. Like any convention, it's not going to work if people don't adopt it. But aside from spam filters, there is no method that doesn't require the adoption of a convention, so the method I'm suggesting isn't any worse than any of the others in that regard.
But if you have control over the box the MTA is running on then you supposedly have control over what the MTA will do in that situation. I suppose that's not necessarily true, since you may be running a proprietary MTA. In that event I'm not sure what to tell you, except perhaps to always use a From: line that refers to a domain that is under your control.
The biggest problem with the convention I described is that right now, people don't use systems that are declared MXes to send outbound email. It's something that would have to change, but to deal with the spam problem effectively something will have to change anyway.
I addressed this problem in the original proposal: set up the systems that are sending mail as MXes anyway (at low priority, so all connections will try to go to the valid MXes first), and drop inbound port 25 connections to your systems that are email senders. You're dropping those connections anyway if you've got any brains at all (since your explicit intention is to not receive inbound email to those boxes from the outside world), so it's not like you have to make any drastic changes to the way you do things.
What appears in the From: line and what appears in the SMTP "MAIL FROM" command are often two entirely different things. The former is set by you, the latter is usually set by your MTA. Generally, if you invoked your MTA then it'll use your username and whatever domain you've assigned to your box in the "MAIL FROM" command, if I'm not mistaken.
In any case, you should have enough control over your own box to control what appears in the "MAIL FROM" command, and that's the point: spammers do their deed by using systems that they do not control.
If you acquire your own domain and make your IP address an MX for your domain, then you'll be able to get past the scheme I described without any problems -- no matter what you set your "From:" line to. You can do this even if your IP address is dynamic; there are a number of dynamic DNS services out there that will do this for you, for your own domain.
With the scheme I described, you won't need to relay through anybody. In fact, you won't be able to relay through anybody, except those systems that you control, or those systems belonging to your ISP that will generate an SMTP "MAIL FROM" command based on the "From:" line you use in your email -- and that means that you'll be forced to use their domain in your "From:" line if you want to use their relays. That's a benefit, not a drawback: it forces everyone to be honest, which is very much what the spammers do not want.
Since most ISPs end up relying on the telephone company for their data lines anyway, and considering that these same telephone companies (baby bells) have been running roughshod over local ISPs that are trying to provide DSL service, I have very little sympathy for the position of the telephone companies. Let them experience what little pain will come with VoIP (I say "what little pain" because they'll benefit from the increased internet business at the same time they're losing telephone income).
The first inclination one has would be to suggest that everyone close their open relays. But this depends on people doing the right thing all the time, and has proven ineffective.
Fortunately, there's another way.
Right now, everyone who receives mail has to listen to everyone who tries to connect. The problem is how do you separate the wheat from the chaff?
The solution is to take advantage of the information SMTP and TCP/IP give you when a connection is established. The fact that you're receiving a connection gives you the address of the sender. And during an SMTP transaction, one of the SMTP commands (the MAIL FROM command) gives you the domain of the email's sender, e.g. "MAIL FROM slashdot@sysexperts.com".
When you're sending email to someone else, you do so by looking up the MX records for their domain, which tells you which systems are responsible for receiving email for that domain. This gives us a possible answer to the spam problem.
Suppose instead of blindly accepting email from everyone, you were to take the domain given to you by the MAIL FROM command, look up the MXes for that domain, and reject the email connection if the IP address of the sender doesn't match one of the domain's MXes?
Now, suddenly, you would end up rejecting email sent from every unauthorized relay, because the owner of the domain can make any system that is allowed to send email on behalf of his domain into an MX (and, if he doesn't want that system to be used for delivering email, then he simply makes such systems the lowest priority MXes in the list and blocks outside port 25 connections to them ... something he's probably doing anyway).
Suddenly, the only systems that spammers can send email from are systems that they legitimately control and that are defined as MXes for a domain they control. Suddenly, spammers have to set up and maintain their own domains and their own boxes. The costs have just become a lot higher, which will get rid of most of the spammers.
And suddenly, blocking spam becomes orders of magnitude easier -- you only have to deal with spammers who have decided to pay the (now much higher) price for sending spam and who cannot use someone else's system to do their dirty work without permission.
Since the whole purpose of the patent system is to publish ideas so that the world will be able to implement them freely when the patent expires (this is what the public is supposed to gain from the patent system), and therefore patents need to be readable, it seems to me that any patent that fits your description (which is most of them right now) should be automatically rejected due to unreadability.
The patent should make the idea it represents as obvious to the reader as possible. It's defrauding the public if it doesn't.
Yeah, I know that it's in the interests of the people writing the patents to do the opposite. Too fucking bad for them: if they want the benefits of a patent, they should be forced to accept the terms that should go along with it.
The patent office could enforce this, and we'd all be a lot better off for it. But noooooooo...
You mean, like, to "defend" themselves against Mono?
(I'm only half joking here)
Given the USPTO's propensity to grant patents on pretty much anything thrown at them, whether or not there's any prior art, you assume far too much.
Tying it to a hard asset doesn't help you. The reason it doesn't help you is that the asset itself is fluid just like the money that represents it: more of the asset can be acquired if need be in order to make the country in question appear "richer", and indeed that was commonly done back when gold was the standard. Acquisition of more of the backing asset is usually a matter of expending sufficient labor (sometimes in the form of the use of the military). Print money simply has a much lower expenditure rate per dollar produced. And as described below, it's highly advantageous to have your exchange mechanism be as fluid as possible.
Money itself is just a means of representing the value of something relative to the value of something else. Usually one of the things whose value is being measured is your labor (when you get paid and then spend the resulting money on something, the price of the something in question is just an indicator of the value of your labor relative to the value of the object you just purchased, and the value of the object is ultimately, more or less, the sum total of the value of the labor used to produce it). Ultimately, since the value of an object is essentially the value of the labor used to make it (which includes all the labor used to generate the raw materials, to process those materials, to assemble the object, and to manage all of that), money simply represents the value of your labor versus the value of someone else's.
In a perfect world, a change in the overall wealth of a country (as measured by the ability of the country to do work) would be instantly reflected in the price of goods relative to the price of labor. Unfortunately, the world is not perfect and there is a delay. And this is the reason for printing more money: so that the price of goods and services does not need to change significantly as the country is able to do more work. Print too much and the society has to adjust the prices to reflect the larger supply of tokens, just as it does if the country does't print enough.
Where things get complicated isn't really within a country's economic system: the currency for that is reasonably well-defined. The complication comes when dealing with other countries with their own currencies, particularly when those currencies are not managed the same way.
The cost of labor in India is lower than it is in the United States. It's lower because the cost of living is lower. But the lower cost of living isn't necessarily a consequence of the lower amount of total work it takes to supply someone with the goods and services needed to live, even when the person in question is living at the same standard of living as someone in the U.S. Nor is it necessarily a consequence of one country being more desirable to live in than another, though that probably factors into it some. Most of the difference is the result of the fact that markets require time to adjust themselves properly relative to other markets.
That's why programmers in India will eventually be paid roughly the same as programmers in the U.S.: the value of their labor isn't really much (if any) less than the value of the labor of programmers in the U.S. -- the hysteresis between the two labor markets just makes it appear that way temporarily. Corporations are now attempting to use that hysteresis to their own advantage, by shifting the demand for work towards markets which have not equalized themselves with the others. And the reason the markets themselves don't adjust on their own is that the labor in those markets isn't as fluid as the Corporate demand for labor, thanks primarily to immigration laws. That means that the labor cannot move to where the demand is. And even if it could, it would take time for the labor to move, and thus for the market to adjust. That time is the very thing which causes hysteresis between the markets.
That's because you're not using Debian or an apt-based RPM system. Debian, in particular, releases security patches whenever an issue pops up, and it's particularly handy to be able to apply them all in one command (I had to set up a separate config file and sources.list), but now all I do is "apt-get --config-file=/etc/apt/apt.conf.security upgrade". I'll periodically do a "--dry-run" first to see what patches are available.
Debian may be annoying to install (it definitely is, in my experience) but it's a piece of cake to maintain.
You want stuff to cost less. That's fine, in and of itself. But will it really cost less after you've lost your job?
See, lots of you people aren't accounting for something really important: how much something costs is relative to your income. As jobs move from here to other locations and unemployment rises here in the U.S., the competition for jobs here will rise and the average wage will fall. But if the average wage falls then fewer people will be able to afford goods at the same price point, so the demand for those goods drops. A drop in demand for the goods has to eventually result in a drop in the price of the goods. But if the average wage falls and the price of goods also falls, then the relative cost of goods will remain roughly the same.
But there are delays in the economic system: the average wage won't drop until some amount of time after the unemployment rate rises, the demand for goods won't drop until some amount of time after the average wage drops, and the cost of goods won't drop until some amount of time after the demand for them drops. Because of that, on the downward slide, there is a period of time when the salaries are low but the cost of goods is high, and that's when things hurt. That's when, in extreme cases, people have to move out on the street because they can no longer afford the high price of housing, or have to sell their car because they can no longer afford the payments on it, etc. Extreme cases like that are known as depressions, and I think we're headed for a really big one.
So the bottom line is that you're likely to get your wish, but you probably won't benefit from it at all. In fact, because of the delays, you're likely to suffer from it instead.
*blink*
But...CmdrTaco posted it, so it has to be a dup! Right?
[ :-) for the humor impaired ]
In Soviet Russia, Clear Channel is owned by KGB??
(Ducks)