I don't think so--the missing header files can be copied accross from the Linux source code. It's just a pain having to do so to compile the drivers, when these files should have been included with the drivers in the first place.
Im my case, Debian, but it doesn't matter. ATI should include the DRM headers that they built their driver against in their source package, instead of relying on whatever files the end user has, if any, by chance matching their driver.
Where are the SATA drives! Finding them to buy is difficult enough, finding decent reviews of them on today's comparison-shopping-infested Web is next to impossible.:(
Well, Nvidia's drivers are already redistributable. Would be nice if ATI would do the same. What would be nicer is if ATI would fix their drivers so they can be built against a kernel-headers package instead of a full-blown kernel-source package.
I'd be willing to bet that the 1066 MHz that the FSB runs at are actually "bullshit marketing MHz" rather than an actual measurement of the speed at which the chips cycle.
Remember when the number your RAM was sold at actually indicated its speed? PC100 was 100 MHz, etc. It was simple. That 333 MHz FSB you sport is really only 166 MHz, but with two transfers per clock cycle. Of course, PC166 DDR isn't sexy enough, so the marketers randomly inflate the number to PC2700.:)
I recon that Intel are smearing the the same bullshit over their specifications: 1066 MBMhz == 266 MHz "QDR" (oh sorry, Quad Data Rate isn't sexy enough, we can call it QUAD PUMPED!! YEAH!)
I'd search for more reliable info, but I've given up trying to find any decent information about hardware on Google these days; it's all comparison shopping sites, as far as the eye can see.
Bullshit, bullshit, bullshit. After we kill all the lawyers, everyone in advertising will be next to go.
Test your SVG-enabled Mozilla with a working web serverl http://www.pinkjuice.com/svg/xslt/fractals/SVG-out/triangular01xslt/05.svg is the first working example I found on Google.
My point is that there is no reason to waste lots of time and energy coming up with a new, 'secure' email system, when existing tools do the job perfectly well already.
But SPF and Sender-ID are different systems with different methods and goals. I'm sorry if you wanted a jack-of-all-trades, master-of-none solution served to you on a plate!
You have just desribed Lisp, Python, Perl, etc...... and then you describe Java, Mono, etc...
Re:Crazy what stops the new release
on
Updates From Debian
·
· Score: 4, Informative
The actual release stopper at the moment is getting the Security autobuild network ready to build packages for Sarge.
While it's true that packages such as Abuse have release critical bugs, the release of Sarge will not be held up by them. Sarge cannot release while RC bugs are present--if it's simpler to remove Abuse from Sarge than it is to fix the RC bug, then Abuse will be removed.
> Check out the link I posted and see the screenshot -- it worked. The From: address was @redhat.com.
The point is that you cannot tell. The From header in the email itself tells you nothing. It is forgery of the the SMTP envelope sender that SPF guards against.
Consider:
220 some mailserver... ready! MAIL FROM: sneaky@fedora-redhat.com 250 OK RCPT TO: some_innocent@hotmail.com 250 OK DATA 354 you have a go From: security@redhat.com Subject: EMERGENCY SECURITY PATCH APPLY NOW!
Etc etc. The SPF check is performed against sneaky@fedora-redhat.com--as per the SPF specification. The recipient of the message never sees sneaky@fedora-redhat.com, however, and is none the wiser.
SPF certifies the envelope sender of a message, ensuring that an email has a non-forged return parth.
> Yes. Does it matter that the SPF spec says to use the return path? Is this any less useful?
Yes, and yes! Standard exist for a reason, ne? From the SPF FAQ:
---8---
Does [SPF] protect the "From:" header field?
SPF was designed to protect the envelope sender. That means the return-path that shows up in "MAIL FROM", and to a lesser extent the HELO argument that is supposed to be an FQDN....
Protecting authorship information is an important goal. However, the technical issues associated with protecting the "From:" header are much more numerous and challenging. The best way to protect the header "From:" is by using a cryptographic signature such as S/MIME, PGP, or (when it is released) Yahoo DomainKeys.
If you want to use the "From:" header as the subject of authentication with SPF, you need to be familiar with the following:
* mailing lists
*/etc/aliases-style forwarding
* MUA "resend this message to"
* web-generated email
* the Sender header
* the Resent-Sender and Resent-From headers
---8---
Checking the From header at the MUA would prevent me, for example, sending email from anywhere except my ISP's servers. I would no longer be able to set up remailers to allow me to have mail from several addresses sent to my main address, and so on. Other stuff as in the list above will also break...
I don't see the original email, but I'd bet that it came from something@fedora-redhat.com, and so the SPF record for redhat.com would not have been useful in this case.:)
On another note, concerning your SPF plugin: I have two points you may wish to consider (if you already have, then fair enough).
1. The From address used by the plugin comes from the From: header in the message? I thought you're not supposed to do this with SPF; it specifies that you should check the SMTP envelope sender (the MAIL FROM line from the SMTP dialogue). This information is not available to a MUA in any standard form AFAIK.
2. What happens if I open a message I stored from a few months/years ago, and the SPF record for the domain it's from has changed? Does the plugin validate a message whenever one is opened, and will I end up with a false positive/negative?
I believe these two issues are why SPF checking must be performed on the server side. The mail server alone has reliable access to the SMTP envelope sender, and can add a Recieved-SPF header at the time of message reception, which is the only time when it is guaranteed that the SPF records from DNS are relevant to the message in question.
SPF done on the client side basically turns into MICROS~1's (patented, if you believe that they'll allow crap like this to be patented!) Sender-ID system, where the From address is taken from a seletion of message headers.
Of course, if I'm wrong about any of this, please correct me.:)
I don't understand the problem so many of you have with Paypal. Admittedly I only use it for sending money to other people. I do this because I can dispute any payment I make with my credit card provider, in case the eBay seller tries to rip me off--an option I do not have if I send a cheque.
It's bad enough every media player and office application on the Windows platform re-inventing the wheel and drawing its own custom controls, now you Windows users expect every WEB PAGE to have this ability as well? God, I fear for you people, I really do.
Slashdot Mirror
Indeed, http://lxr.linux.no/source/drivers/char/drm/drm.h :)
I don't think so--the missing header files can be copied accross from the Linux source code. It's just a pain having to do so to compile the drivers, when these files should have been included with the drivers in the first place.
Im my case, Debian, but it doesn't matter. ATI should include the DRM headers that they built their driver against in their source package, instead of relying on whatever files the end user has, if any, by chance matching their driver.
Hah! I reckon this has happened to me! How childish. :(
Why can't we all just get along?
Where are the SATA drives! Finding them to buy is difficult enough, finding decent reviews of them on today's comparison-shopping-infested Web is next to impossible. :(
Well, Nvidia's drivers are already redistributable. Would be nice if ATI would do the same. What would be nicer is if ATI would fix their drivers so they can be built against a kernel-headers package instead of a full-blown kernel-source package.
I'd be willing to bet that the 1066 MHz that the FSB runs at are actually "bullshit marketing MHz" rather than an actual measurement of the speed at which the chips cycle.
:)
Remember when the number your RAM was sold at actually indicated its speed? PC100 was 100 MHz, etc. It was simple. That 333 MHz FSB you sport is really only 166 MHz, but with two transfers per clock cycle. Of course, PC166 DDR isn't sexy enough, so the marketers randomly inflate the number to PC2700.
I recon that Intel are smearing the the same bullshit over their specifications: 1066 MBMhz == 266 MHz "QDR" (oh sorry, Quad Data Rate isn't sexy enough, we can call it QUAD PUMPED!! YEAH!)
I'd search for more reliable info, but I've given up trying to find any decent information about hardware on Google these days; it's all comparison shopping sites, as far as the eye can see.
Bullshit, bullshit, bullshit. After we kill all the lawyers, everyone in advertising will be next to go.
Applications -> Desktop Prefs -> Removable Storage -> Uncheck all the options.
Anyone else want to tell him that fink is based on Debian's apt-get?
Beagle.
Because that makes far too much sense, and is far too inline with how DNS is supposed to be used.
:) 16:50 sam@xerces ~0 0 OK
t /triangular01xslt/05.svg is the first working example I found on Google.
$ HEAD http://www.design-ireland.net/images/logo.svgz
2
Connection: close
Date: Thu, 28 Oct 2004 15:50:18 GMT
Accept-Ranges: bytes
ETag: "78f3-afc-3f23d877"
Server: Apache/1.3.31 (Unix) mod_ssl/2.8.18 OpenSSL/0.9.7d FrontPage/5.0.2.2635 PHP/4.3.6 mod_throttle/3.1.2
Content-Encoding: x-gzip
Content-Length: 2812
Content-Type: text/html
Last-Modified: Sun, 27 Jul 2003 13:49:43 GMT
Client-Date: Thu, 28 Oct 2004 15:50:29 GMT
Client-Peer: 212.147.138.20:80
Client-Response-Num: 1
There's your problem, right there.
Test your SVG-enabled Mozilla with a working web serverl http://www.pinkjuice.com/svg/xslt/fractals/SVG-ou
My point is that there is no reason to waste lots of time and energy coming up with a new, 'secure' email system, when existing tools do the job perfectly well already.
But SPF and Sender-ID are different systems with different methods and goals. I'm sorry if you wanted a jack-of-all-trades, master-of-none solution served to you on a plate!
Google for "free speech zone".
I'm afraid I have to call bullshit here.
No one can forge child porn spam from me, because they don't have my GPG key.
Your better way to move email can be described as, "delete all non-signed and verified email".
You have just desribed Lisp, Python, Perl, etc... ... and then you describe Java, Mono, etc...
The actual release stopper at the moment is getting the Security autobuild network ready to build packages for Sarge.
While it's true that packages such as Abuse have release critical bugs, the release of Sarge will not be held up by them. Sarge cannot release while RC bugs are present--if it's simpler to remove Abuse from Sarge than it is to fix the RC bug, then Abuse will be removed.
Only technically. Use lftp and then tell me you are satisfied with ftp.exe.
> Check out the link I posted and see the screenshot -- it worked. The From: address was @redhat.com.
...
/etc/aliases-style forwarding
The point is that you cannot tell. The From header in the email itself tells you nothing. It is forgery of the the SMTP envelope sender that SPF guards against.
Consider:
220 some mailserver... ready!
MAIL FROM: sneaky@fedora-redhat.com
250 OK
RCPT TO: some_innocent@hotmail.com
250 OK
DATA
354 you have a go
From: security@redhat.com
Subject: EMERGENCY SECURITY PATCH APPLY NOW!
Etc etc. The SPF check is performed against sneaky@fedora-redhat.com--as per the SPF specification. The recipient of the message never sees sneaky@fedora-redhat.com, however, and is none the wiser.
SPF certifies the envelope sender of a message, ensuring that an email has a non-forged return parth.
> Yes. Does it matter that the SPF spec says to use the return path? Is this any less useful?
Yes, and yes! Standard exist for a reason, ne? From the SPF FAQ:
---8---
Does [SPF] protect the "From:" header field?
SPF was designed to protect the envelope sender. That means the return-path that shows up in "MAIL FROM", and to a lesser extent the HELO argument that is supposed to be an FQDN.
Protecting authorship information is an important goal. However, the technical issues associated with protecting the "From:" header are much more numerous and challenging. The best way to protect the header "From:" is by using a cryptographic signature such as S/MIME, PGP, or (when it is released) Yahoo DomainKeys.
If you want to use the "From:" header as the subject of authentication with SPF, you need to be familiar with the following:
* mailing lists
*
* MUA "resend this message to"
* web-generated email
* the Sender header
* the Resent-Sender and Resent-From headers
---8---
Checking the From header at the MUA would prevent me, for example, sending email from anywhere except my ISP's servers. I would no longer be able to set up remailers to allow me to have mail from several addresses sent to my main address, and so on. Other stuff as in the list above will also break...
I don't see the original email, but I'd bet that it came from something@fedora-redhat.com, and so the SPF record for redhat.com would not have been useful in this case. :)
:)
On another note, concerning your SPF plugin: I have two points you may wish to consider (if you already have, then fair enough).
1. The From address used by the plugin comes from the From: header in the message? I thought you're not supposed to do this with SPF; it specifies that you should check the SMTP envelope sender (the MAIL FROM line from the SMTP dialogue). This information is not available to a MUA in any standard form AFAIK.
2. What happens if I open a message I stored from a few months/years ago, and the SPF record for the domain it's from has changed? Does the plugin validate a message whenever one is opened, and will I end up with a false positive/negative?
I believe these two issues are why SPF checking must be performed on the server side. The mail server alone has reliable access to the SMTP envelope sender, and can add a Recieved-SPF header at the time of message reception, which is the only time when it is guaranteed that the SPF records from DNS are relevant to the message in question.
SPF done on the client side basically turns into MICROS~1's (patented, if you believe that they'll allow crap like this to be patented!) Sender-ID system, where the From address is taken from a seletion of message headers.
Of course, if I'm wrong about any of this, please correct me.
I don't understand the problem so many of you have with Paypal. Admittedly I only use it for sending money to other people. I do this because I can dispute any payment I make with my credit card provider, in case the eBay seller tries to rip me off--an option I do not have if I send a cheque.
The picture you got out the back of them would still look like ass, though.
Then how can it possibly be considered secure? You have no guarantees that what you see isn't being manipulated by the system you are running it from.
:)
Of course, you shouldn't be using someone else's computer anyway, god knows what kind of keyloggers or whatever it has lurking in it...
Because it's a fscking bad idea!
:)
It's bad enough every media player and office application on the Windows platform re-inventing the wheel and drawing its own custom controls, now you Windows users expect every WEB PAGE to have this ability as well? God, I fear for you people, I really do.
IHBT, I guess.