I thought I was the only one doing it in a simple way. In fact what I use is just Postfix (with some PERL Compatible Regular Expressions). My E-mail address is just as exposed on Slashdot as the parent's and I can confirm that he's right. The last month, the only thing I could consider spam was a 419 scam message, although my maillogs are full of filter warnings. I use to look in the maillogs regularly for false positives, and at least in the last 4 months I've had none.
I won't be too specific on what kinds of filters I use (because otherwise I would be giving spammers hints on how to circumvent them), but basically weird things that shouldn't go on regular E-mail messages are easy to spot and filter. First of all: almost all spam comes as HTML formatted E-mail. Having that in mind you can start filtering out strange things such as border thicknesses around pictures and tables, form tags, unordered and ordered listings, images inside hyperlinks, input and form tags, frames, iframes, and whatever else you find inappropriate for regular E-mail messages. For plain-text spam you can simply filter out words such as "revenue", "furnish", "\$[0-9.]{3}", "MIL?ION.*DOL?ARS", etc. Last but not least, remember to filter out certain MIME types such as "binary/octet-stream" and file extensions such as ".exe", ".com", ".bat", ".vbs", ".pif", etc.
Remember that these are just knee-jerk hints based on my own experience. I recommend you to read your E-mail sources carefully in order to find patterns which allow you to clearly track and filter spam. What you filter depends on you and your company's needs and policies, so I recommend you to redirect messages to a spamdrop account instead of filtering them all right away to make sure there aren't false positives in the first few months. If the filters do well, replace your REDIRECT rules by a REJECT ones and enjoy your new quite mailbox.
Re:Would like to go to gmails party....
on
The Webmail Wars
·
· Score: 2, Insightful
> What's with the Google business model anyhow? Do they think they can prosper by having "exclusive" customers?
Your point of view is logical and indeed expectable, but Google successfully exploits one of the most ignored and powerful forms of publicity: the word of mouth. Word of mouth is effective because it is a friend of yours who is advertising the said product, and he's not being paid for it, you believe him because you know that he's telling the truth about his experience, and if the said friend happens to be a computer geek, you believe him twice more, so you better give it a try while you have the chance, otherwise you may lose your exclusive opportunity. If you scrap the first chance and everyone around you joins the "community" you will feel even more tempted to become a part of it.
I had to deal with this issue a year ago when massive amounts of IRC friends joined Orkut and began exchanging contents and speaking through and about it everywhere all the time. My reaction? No I didn't join Orkut, I left IRC! But this only proves how effective Google's publicity model really is. People would never pay as much attention as they do if it was not an "exclusive" service.
Ok, this may sound rather lame for those of you who understand what this is all about, but I would like to know anyway: What kind of hologram are we talking about here? Is it really possible to project a tridimensional image in the space? If so, could someone explain me the science behind that?
I am sorry once again for asking all these questions, but I've been trying to figure it by myself and unfortunately never found anything conclusive.
What I don't understand is how Microsoft would see one's MAC address provided that Ethernet is not routable...
The rest of your idea seems pretty nice. It would help if someone perhaps created a journal or something for that purpose (as this article will be off the main page by tomorrow). I believe that with enough information even someone without an Xbox could make an ipfilter module for that purpose.
Anyway the problem might be a little harder to solve, especially if the connection is encrypted and the private key differs from one unit to another, but that would be a bigger and even more addictive challenge.
Man you really sound like the inexperienced, naive, and "know it all" fool who just finished the university. Get back to the real world and THINK for a change! How many people run Windows? How many people run and are involved with the Linux development? How many people run and are involved with the OpenBSD development? Yes, I am talking about numbers! Few people will bother targetting a system with such a marginal share as OpenBSD's, and even that hasn't stopped OpenBSD from having lots of known security holes in its rock-solid secure kernel!
Design is all about theory, which is something that does not apply very well in the real world. If you do not yet know that, real world experience will make sure you learn it right. Besides of what you've been told in the university, design and theory are NOT everything.
A simple and well thought design may address a lot of issues, but only those you were thinking about at the time. As soon as your system becomes more used and the world evolves, you will feel the need to add exceptions to your initial design, exceptions that will make it more and more complex over time and can potentially be used in unpredictable ways to break security. Of course you could chose to rewrite everything from the scratch each time your design was proven to be wrong just because it did not allow user X to perform Y, but that would be rather counter-productive. Either that or you could simply ignore user X, but that would not be a good choice if user X was your client.
Since you mentioned OpenBSD, lets take it as an example: The secure memory management in OpenBSD on i386 (known as W^X) uses a code segment whose size is smaller than the overlapping data segment's. This means that memory maps allocated below a specific address are executable while maps allocated above that address are not. This allows the system to distinguish between executable and non-executable virtual memory areas with hardware support, and thus, is the perfect* solution to the lack of an executable privilege definition in the pagination system.
* = There is at least one small (but if you keep reading you will notice that it's not as small as it seems) exception to this perfect solution: mprotect(). Since the execution privilege depends on the virtual memory address and mprotect() is only meant to change privileges, this perfect solution prevents mprotect() from functioning properly.
When confronted with the evidence, Theo replied with a POSIX quote stating that mprotect() shall fail if the system does not support it. The problem is that usually it does not fail, and therefore software has been written with that non-standard assumption in mind, and that software will break with this implementation, but for Theo if the software does not run is because it relies on insecure implementations...
One exemple of such an important piece of software that does not rely on insecure implementations and will probably break with W^X is GCC. Recent versions of GCC (since 3.3.0, I believe) now generate code that when assembled resultes in ELFs that change the executable permissions in the stack memory area, and this means writable and executable (W&X) stacks for everyone! To prevent from stack smashing exploits, StackGuard is now included in the mainstream versions of GCC. Why does it do so? Because GCC needs an executable and writable stack in which it can write its trampolines (I would go deeper and explain what trampolines are and how they work, but it's rather offtopic and my comment is already long enough).
GCC assumes that the ability to modify VMA privileges is present, and therefore uses it to stop decent implementations of secure memory management from crashing programs with trampolines. By ignoring this non-standard functionality just because "in theory noone is going to use it", Theo has made his kernel incompatible with newer versions of GCC. Since OpenBSD users are so few in number, this is not a real issue, but it would be if it was Linux or Windows.
The above is just a demonstration of how evolution and the real world can turn a supposedly perfect theory into something useless. Things evolve in unpredictable ways, and you are being presumptuous if you really think you can predict everything.
> No, but I fail to see why the kernel would have to see into the details of how a device driver is implemented.
First, because we are talking about a monolithic kernel in which if a driver poohes, the whole system poohes too, so it is a good idea to know what really poohed and why.
Second, because the more abstract you make your API the less optimized and useful it will be (which for device drivers is not a Good Thing).
Third, I don't really understand how this relates to the need for C++ on the kernel at all.
> I didn't mention anything about choice of language. The OP didn't either.
The whole story is about C++ on Linux, what are we talking about then?
> what's with the beef against C++?
First, it is not my problem if you haven't read the whole point on that FAQ, the story, or the article whatsoever.
Second, you are the one defending the change, but you don't seem to come up with any reasonable technical argument to support that change. Do you expect everyone to jump in just because you though it would be better?
For me it seems that the only useful thing that patch does is to add more useless code to the kernel.
> Yeah, who wants a common driver API for video, network, or sound cards...
I don't understand why a common driver API is not possible to do in C... Would you care explaining?
> Not to mention that drivers are all about abstracting the hardware and interface implementation from the OS itself anyway...
Does that mean we should give up on transparency?
> You can do some pretty neat things in C++ if you know what you are doing. If you don't know what you are doing, you can do some pretty crappy things.
This (again) begs the question: what can you do in C++ that you can not do in C? Is it just because classes, objects, constructors, destructors, inheritance, and all that crappy OOP stuff is specificly declared that C++ is that superior? You can do pretty well the same in C! There is absolutely no consistent technical reason supporting the use of C++ in the Linux kernel!
Quoting the FAQ that you should indeed read since there are some Linus quotes there:
Should the kernel use object-oriented programming techniques? Actually, it already does. The VFS (Virtual Filesystem Switch) is a prime example of object-oriented programming techniques. There are objects with public and private data, methods and inheritance. This just happens to be written in C. Another example of object-oriented programming is Xt (the X Intrinsics Toolkit), also written in C. What's important about object-oriented programming is the techniques, not the languages used.
> don't get this argument at all. Linux is a monolithic kernel but it has loadable modules which makes it a bit more modular. On top of that, neither WindowsXP or OSX is a microkernel.
The problem is that the modules depend too much on how the kernel is compiled. If Linux was a Microkernel with a consistent and stateless API in which every module could rely on regardless of the version of the kernel, its low level data structuress, and how it was compiled, such problems would not exist. Under Windows you are forced to use whatever comes with the system, so hardware vendors know what to expect, but this is not true under Linux where specific symbols are expected to be on the kernel before loading a module.
>...aren't there firewalls that can handle this yet?
Once upon a time (when I was an IRC user), I used to run a little forum in which people could post random stupod IRC quotes. Apparently someone got so mad about one of the quotes that they decided to hit me to death, so they distributed a worm which would simply resolve my domain and send me really huge fragmented UDP packets whose effect blocked my whole inbound traffic. I repeatedly asked my ISP to apply some QoS and lower the priority of that traffic, but they said they couldn't do anything about it. Then I realized that the worm was targeting my domain so I simply added a wildcard to resolve a CNAME to www.microsoft.com and registered another domain. A day later the traffic was gone (guess who had to deal with it)...
I think the difference between human and computer intelligence is that our software (conscious) is able to hard-wire the hardware (unconscious). We may not be able to consciously perform certain tasks such as floating point calculations because our software lacks low level access, but we can hard-wire our hardware for those tasks, this is why our unconscious is so quick and accurate when trained to recognize and respond to specific patterns regardless of their complexity.
Flexible: SpamAssassin encapsulates its logic in a well-designed, abstract API so it can be integrated anywhere in the email stream. The Mail::SpamAssassin classes can be used on a wide variety of email systems including procmail, sendmail, Postfix, qmail, and many others.
Since SpamAssassin is not limited to only one MTA and its purpose is to filter spam, the Apache Software Foundation needs to ensure proper domain validation is performed.
Ok, my previous post is rather confusing, so I'll try to rewrite it.
When you send a message from the authenticated host A to host B there may be forwarding agents (such as mailing lists, relays, etc.) routing your message, the message is not always direcly sent from host A to host B. With SPF you would be limited to that. You would have to mention (for example) all mailing lists in whom you are subscribed, which is not practical if you are not controlling the domain from where you send your messages. Sender ID addresses this limitation with PRA, an algorithm that computes the last responsible token, which may or may not be the sender MTA, thus allowing messages to be routed the same way they always have been.
For more information about the PRA algorithm, check this PDF. I am sorry for my last post. Should use the preview button more often. Please do NOT mod my last post up.
Sender ID is just SPF on steroids. E.g.: SPF points out the systems which can be used to send E-mail from a given domain while sender ID adds an additional algorithm (the PRA) which verifies if a given E-mail forwarded by mailing lists,.forward files, or relays (to name a few examples) is legitumate. Mailing list hosts may not have permission to send E-mails from your host, but they can specifically tell who they are and that they are just forwarding agents, thus making themselves responsible for the message and leaving you (the receiver) with an option to block E-mail coming from a particular forwarding domain (e.g.: the mailing list's domain) or from a particular sender domain.
In other words: the sender ID allows you to do almost everything you always did with your MTA but adds some authentication to the process. SPF alone would limit you to a single host or network, or force you to clearly specify which addresses could forward messages from your domain, which is not practical if you are using your ISP's domain to communicate with the Linux Kernel Mailing List, for example. Sender ID addresses this limitation.
Even better! Scrap the P4 and replace with a Celly, way cheaper!
The embedded soundcard is an ac97, supported by the mainstream Linux kernel; The ethernet chip is a sis900, also supported under the mainstream Linux kernel; I don't know if the embeded video card is supported by X.org (XF86 did not support it 2 years ago), but if not, one can still stick with VESA;
Of course that I am talking about my board, which is nolonger on the site (the closest one I found there is this one).
Seriously, those boards are wonderful for workstations!
Get one of these boards (I got one for $50 two years ago), an old P4 (1.6 or so), a cheap Seagate 120G hard drive (about $100 a year ago), some memory (sorry, no clue about the price for this one, but the boards I mentioned support SDRAM, so...), and you are done!
Oh, forgot to mention that you'll also need a case and a 200W power supply!
> Nonetheless, the hardware support of even the latest Linux distributions is inferior to that of Windows or even Mac OS X, and it's difficult to see how this is going to change when manufacturers continue to make their drivers closed-source and binary so that they only work with one kernel version, one distro, one libc
OS X doesn't have that much hardware to support. Have you seen how much hardware Linux supports today? Most hardware support under Windows is provided by third parties. If you get the latest sound card you won't get any sound under Windows (unless the soundcard is recognized as compatible with a previous model) without the manufacturer's drivers. My SBLIVE is not supported under Windows XP without Creative's drivers but is under Linux with the mainstream EMU10K1 driver. If you get the latest video card, you won't have Windows support for it, my RADEON 9600 is not supported under Windows XP without ATI's driver, but Linux has a generic ATI driver for the framebuffer interface.
Second: I'd rather that software developers distribute binary Linux drivers for a single distribution/libc than Windows ones. Why? Because at least for me they are easier to reverse engineer.
> In a way, its immense flexibility is a bad thing. Open source is a nice thing, and has the potential to take over - just look at Firefox. But Linux is just too monolithic and slow-to-change to be easy to toss onto a new PC and get up and running with. There's a proliferation of different versions, all incompatible, making ease-of-use impossible to attain.
I half-agree with you on this one. I think the real problem is not the flexibility. I've always argued that monolithic kernels aren't good for desktops, and this, in my opinion, is the only thing slowing down Linux acceptance on the desktop.
Slashdot Mirror
"binary/octet-stream" was supposed to be "application/octet-stream"
I thought I was the only one doing it in a simple way. In fact what I use is just Postfix (with some PERL Compatible Regular Expressions). My E-mail address is just as exposed on Slashdot as the parent's and I can confirm that he's right. The last month, the only thing I could consider spam was a 419 scam message, although my maillogs are full of filter warnings. I use to look in the maillogs regularly for false positives, and at least in the last 4 months I've had none.
I won't be too specific on what kinds of filters I use (because otherwise I would be giving spammers hints on how to circumvent them), but basically weird things that shouldn't go on regular E-mail messages are easy to spot and filter. First of all: almost all spam comes as HTML formatted E-mail. Having that in mind you can start filtering out strange things such as border thicknesses around pictures and tables, form tags, unordered and ordered listings, images inside hyperlinks, input and form tags, frames, iframes, and whatever else you find inappropriate for regular E-mail messages. For plain-text spam you can simply filter out words such as "revenue", "furnish", "\$[0-9.]{3}", "MIL?ION.*DOL?ARS", etc. Last but not least, remember to filter out certain MIME types such as "binary/octet-stream" and file extensions such as ".exe", ".com", ".bat", ".vbs", ".pif", etc.
Remember that these are just knee-jerk hints based on my own experience. I recommend you to read your E-mail sources carefully in order to find patterns which allow you to clearly track and filter spam. What you filter depends on you and your company's needs and policies, so I recommend you to redirect messages to a spamdrop account instead of filtering them all right away to make sure there aren't false positives in the first few months. If the filters do well, replace your REDIRECT rules by a REJECT ones and enjoy your new quite mailbox.
I guess they'r using floppies...
> What's with the Google business model anyhow? Do they think they can prosper by having "exclusive" customers?
Your point of view is logical and indeed expectable, but Google successfully exploits one of the most ignored and powerful forms of publicity: the word of mouth. Word of mouth is effective because it is a friend of yours who is advertising the said product, and he's not being paid for it, you believe him because you know that he's telling the truth about his experience, and if the said friend happens to be a computer geek, you believe him twice more, so you better give it a try while you have the chance, otherwise you may lose your exclusive opportunity. If you scrap the first chance and everyone around you joins the "community" you will feel even more tempted to become a part of it.
I had to deal with this issue a year ago when massive amounts of IRC friends joined Orkut and began exchanging contents and speaking through and about it everywhere all the time. My reaction? No I didn't join Orkut, I left IRC! But this only proves how effective Google's publicity model really is. People would never pay as much attention as they do if it was not an "exclusive" service.
Ok, this may sound rather lame for those of you who understand what this is all about, but I would like to know anyway: What kind of hologram are we talking about here? Is it really possible to project a tridimensional image in the space? If so, could someone explain me the science behind that?
I am sorry once again for asking all these questions, but I've been trying to figure it by myself and unfortunately never found anything conclusive.
Thanks in advance.
What I don't understand is how Microsoft would see one's MAC address provided that Ethernet is not routable...
The rest of your idea seems pretty nice. It would help if someone perhaps created a journal or something for that purpose (as this article will be off the main page by tomorrow). I believe that with enough information even someone without an Xbox could make an ipfilter module for that purpose.
Anyway the problem might be a little harder to solve, especially if the connection is encrypted and the private key differs from one unit to another, but that would be a bigger and even more addictive challenge.
ROFL literally! Thanks for the good laugh "Mac Sandwich"!
Man you really sound like the inexperienced, naive, and "know it all" fool who just finished the university. Get back to the real world and THINK for a change! How many people run Windows? How many people run and are involved with the Linux development? How many people run and are involved with the OpenBSD development? Yes, I am talking about numbers! Few people will bother targetting a system with such a marginal share as OpenBSD's, and even that hasn't stopped OpenBSD from having lots of known security holes in its rock-solid secure kernel!
Design is all about theory, which is something that does not apply very well in the real world. If you do not yet know that, real world experience will make sure you learn it right. Besides of what you've been told in the university, design and theory are NOT everything.
A simple and well thought design may address a lot of issues, but only those you were thinking about at the time. As soon as your system becomes more used and the world evolves, you will feel the need to add exceptions to your initial design, exceptions that will make it more and more complex over time and can potentially be used in unpredictable ways to break security. Of course you could chose to rewrite everything from the scratch each time your design was proven to be wrong just because it did not allow user X to perform Y, but that would be rather counter-productive. Either that or you could simply ignore user X, but that would not be a good choice if user X was your client.
Since you mentioned OpenBSD, lets take it as an example: The secure memory management in OpenBSD on i386 (known as W^X) uses a code segment whose size is smaller than the overlapping data segment's. This means that memory maps allocated below a specific address are executable while maps allocated above that address are not. This allows the system to distinguish between executable and non-executable virtual memory areas with hardware support, and thus, is the perfect* solution to the lack of an executable privilege definition in the pagination system.
* = There is at least one small (but if you keep reading you will notice that it's not as small as it seems) exception to this perfect solution: mprotect(). Since the execution privilege depends on the virtual memory address and mprotect() is only meant to change privileges, this perfect solution prevents mprotect() from functioning properly.
When confronted with the evidence, Theo replied with a POSIX quote stating that mprotect() shall fail if the system does not support it. The problem is that usually it does not fail, and therefore software has been written with that non-standard assumption in mind, and that software will break with this implementation, but for Theo if the software does not run is because it relies on insecure implementations...
One exemple of such an important piece of software that does not rely on insecure implementations and will probably break with W^X is GCC. Recent versions of GCC (since 3.3.0, I believe) now generate code that when assembled resultes in ELFs that change the executable permissions in the stack memory area, and this means writable and executable (W&X) stacks for everyone! To prevent from stack smashing exploits, StackGuard is now included in the mainstream versions of GCC. Why does it do so? Because GCC needs an executable and writable stack in which it can write its trampolines (I would go deeper and explain what trampolines are and how they work, but it's rather offtopic and my comment is already long enough).
GCC assumes that the ability to modify VMA privileges is present, and therefore uses it to stop decent implementations of secure memory management from crashing programs with trampolines. By ignoring this non-standard functionality just because "in theory noone is going to use it", Theo has made his kernel incompatible with newer versions of GCC. Since OpenBSD users are so few in number, this is not a real issue, but it would be if it was Linux or Windows.
The above is just a demonstration of how evolution and the real world can turn a supposedly perfect theory into something useless. Things evolve in unpredictable ways, and you are being presumptuous if you really think you can predict everything.
They will probably sell better, larger, and heavier upgrade batteries for the modest price of $200 each. That's Sony's way!
> Hello? Of course it's dropped: most people don't use search engines for pr0n anymore. They use P2P!!!!
Besides, nowadays porn is advertised everywhere and there, so noone really needs to search for it.
> And when he was reading me back the letters, expanding each with a word for clarity, he said "...and 'p', as in Pierre."
Next time tell them to read this.
> Your glass is half-empty: trains also start at train stations and buses also start at bus stations.
Similarly, workstations also reboot.
> No, but I fail to see why the kernel would have to see into the details of how a device driver is implemented.
First, because we are talking about a monolithic kernel in which if a driver poohes, the whole system poohes too, so it is a good idea to know what really poohed and why.
Second, because the more abstract you make your API the less optimized and useful it will be (which for device drivers is not a Good Thing).
Third, I don't really understand how this relates to the need for C++ on the kernel at all.
> I didn't mention anything about choice of language. The OP didn't either.
The whole story is about C++ on Linux, what are we talking about then?
> what's with the beef against C++?
First, it is not my problem if you haven't read the whole point on that FAQ, the story, or the article whatsoever.
Second, you are the one defending the change, but you don't seem to come up with any reasonable technical argument to support that change. Do you expect everyone to jump in just because you though it would be better?
For me it seems that the only useful thing that patch does is to add more useless code to the kernel.
> Yeah, who wants a common driver API for video, network, or sound cards...
I don't understand why a common driver API is not possible to do in C... Would you care explaining?
> Not to mention that drivers are all about abstracting the hardware and interface implementation from the OS itself anyway...
Does that mean we should give up on transparency?
> You can do some pretty neat things in C++ if you know what you are doing. If you don't know what you are doing, you can do some pretty crappy things.
This (again) begs the question: what can you do in C++ that you can not do in C? Is it just because classes, objects, constructors, destructors, inheritance, and all that crappy OOP stuff is specificly declared that C++ is that superior? You can do pretty well the same in C! There is absolutely no consistent technical reason supporting the use of C++ in the Linux kernel!
Quoting the FAQ that you should indeed read since there are some Linus quotes there:
> don't get this argument at all. Linux is a monolithic kernel but it has loadable modules which makes it a bit more modular. On top of that, neither WindowsXP or OSX is a microkernel.
The problem is that the modules depend too much on how the kernel is compiled. If Linux was a Microkernel with a consistent and stateless API in which every module could rely on regardless of the version of the kernel, its low level data structuress, and how it was compiled, such problems would not exist. Under Windows you are forced to use whatever comes with the system, so hardware vendors know what to expect, but this is not true under Linux where specific symbols are expected to be on the kernel before loading a module.
> ...aren't there firewalls that can handle this yet?
Once upon a time (when I was an IRC user), I used to run a little forum in which people could post random stupod IRC quotes. Apparently someone got so mad about one of the quotes that they decided to hit me to death, so they distributed a worm which would simply resolve my domain and send me really huge fragmented UDP packets whose effect blocked my whole inbound traffic. I repeatedly asked my ISP to apply some QoS and lower the priority of that traffic, but they said they couldn't do anything about it. Then I realized that the worm was targeting my domain so I simply added a wildcard to resolve a CNAME to www.microsoft.com and registered another domain. A day later the traffic was gone (guess who had to deal with it)...
I think the difference between human and computer intelligence is that our software (conscious) is able to hard-wire the hardware (unconscious). We may not be able to consciously perform certain tasks such as floating point calculations because our software lacks low level access, but we can hard-wire our hardware for those tasks, this is why our unconscious is so quick and accurate when trained to recognize and respond to specific patterns regardless of their complexity.
> What reason would Apache have to do anything with Sender-ID?
Perhaps because of SpamAssassin?
Quoting ASF:
Since SpamAssassin is not limited to only one MTA and its purpose is to filter spam, the Apache Software Foundation needs to ensure proper domain validation is performed.
Ok, my previous post is rather confusing, so I'll try to rewrite it.
When you send a message from the authenticated host A to host B there may be forwarding agents (such as mailing lists, relays, etc.) routing your message, the message is not always direcly sent from host A to host B. With SPF you would be limited to that. You would have to mention (for example) all mailing lists in whom you are subscribed, which is not practical if you are not controlling the domain from where you send your messages. Sender ID addresses this limitation with PRA, an algorithm that computes the last responsible token, which may or may not be the sender MTA, thus allowing messages to be routed the same way they always have been.
For more information about the PRA algorithm, check this PDF. I am sorry for my last post. Should use the preview button more often. Please do NOT mod my last post up.
Sender ID is just SPF on steroids. E.g.: SPF points out the systems which can be used to send E-mail from a given domain while sender ID adds an additional algorithm (the PRA) which verifies if a given E-mail forwarded by mailing lists, .forward files, or relays (to name a few examples) is legitumate. Mailing list hosts may not have permission to send E-mails from your host, but they can specifically tell who they are and that they are just forwarding agents, thus making themselves responsible for the message and leaving you (the receiver) with an option to block E-mail coming from a particular forwarding domain (e.g.: the mailing list's domain) or from a particular sender domain.
In other words: the sender ID allows you to do almost everything you always did with your MTA but adds some authentication to the process. SPF alone would limit you to a single host or network, or force you to clearly specify which addresses could forward messages from your domain, which is not practical if you are using your ISP's domain to communicate with the Linux Kernel Mailing List, for example. Sender ID addresses this limitation.
Even better! Scrap the P4 and replace with a Celly, way cheaper!
The embedded soundcard is an ac97, supported by the mainstream Linux kernel;
The ethernet chip is a sis900, also supported under the mainstream Linux kernel;
I don't know if the embeded video card is supported by X.org (XF86 did not support it 2 years ago), but if not, one can still stick with VESA;
Of course that I am talking about my board, which is nolonger on the site (the closest one I found there is this one).
Seriously, those boards are wonderful for workstations!
Get one of these boards (I got one for $50 two years ago), an old P4 (1.6 or so), a cheap Seagate 120G hard drive (about $100 a year ago), some memory (sorry, no clue about the price for this one, but the boards I mentioned support SDRAM, so...), and you are done!
Oh, forgot to mention that you'll also need a case and a 200W power supply!
> Nonetheless, the hardware support of even the latest Linux distributions is inferior to that of Windows or even Mac OS X, and it's difficult to see how this is going to change when manufacturers continue to make their drivers closed-source and binary so that they only work with one kernel version, one distro, one libc
OS X doesn't have that much hardware to support. Have you seen how much hardware Linux supports today? Most hardware support under Windows is provided by third parties. If you get the latest sound card you won't get any sound under Windows (unless the soundcard is recognized as compatible with a previous model) without the manufacturer's drivers. My SBLIVE is not supported under Windows XP without Creative's drivers but is under Linux with the mainstream EMU10K1 driver. If you get the latest video card, you won't have Windows support for it, my RADEON 9600 is not supported under Windows XP without ATI's driver, but Linux has a generic ATI driver for the framebuffer interface.
Second: I'd rather that software developers distribute binary Linux drivers for a single distribution/libc than Windows ones. Why? Because at least for me they are easier to reverse engineer.
> In a way, its immense flexibility is a bad thing. Open source is a nice thing, and has the potential to take over - just look at Firefox. But Linux is just too monolithic and slow-to-change to be easy to toss onto a new PC and get up and running with. There's a proliferation of different versions, all incompatible, making ease-of-use impossible to attain.
I half-agree with you on this one. I think the real problem is not the flexibility. I've always argued that monolithic kernels aren't good for desktops, and this, in my opinion, is the only thing slowing down Linux acceptance on the desktop.
> Not that I'd claim my version is the authority however.
:-)
Neither do I. This is the same kind of transformation as in RTFM. Who cares about the word anyway, as long as the acronym is meaningful...
> What does S.O.L. mean?
Sadly Outta Luck