Publishing SPF records does exactly what AOL needs. Specifically it reduces the number of joe-jobs directed at its clients. As more mail servers are set up to check these records, the better it gets for them.
What does implementing Microsoft's Caller-ID have to offer in addition to AOL's subscribers?
The real issue is these library programmers are serving two masters:
1) Desktop use 2) Embedded use.
Generally they code for the latter, even if they know that the majority of use is going to be for the former. I've seen claims in libraries like libpng and zlib about how little memory required for decoding and such and such.
Well guess what? It's all that grasping for allocating the smallest buffers possible that gets you into trouble. Because it's really easy to fuck up there. If you just play it safe and allocate as big a buffer as some atom of your file format is theoretically going to need to do what it does, then you wouldn't have to worry about stuff like that.
And, it's like, so what! EVERY desktop operating system out there has a paged virtual memory system, and I guarantee if you don't use that extra unallocated memory in most cases, it won't "actually" get allocated. So the operating system (and thus the user) could care less, since it's demand-based anyway. But in the odd case that someone tries to fuck with you and actually use that memory, well you'll notice when your hard drive starts paging that somethings' up.:-)
And not to disparage embedded developers: it could be as simple as adding a conditional compiler flag that uses the "safe" mode or the memory/pointer/fiddling version.
libpng was already doing that with respect to feature support. Why not play fast and loose with memory in the full profile version?
As long as it's not a RAW screendump or uncompressed TIFF file or something, there's going to be some interpretation of the file's content to produce the human-consumable output. And it'll be based on a parameterized command stream. And if the interpretation of those parameters is not handled rigourously, or if the system does not account for every possible combination of commands, well then you're ripe for an exploit.
That's basically EVERY file format.
Even text can be dangerous. Ever heard of a terminal or ANSI bomb? (scroll down in link).
The only "safe" viewer is a hex editor. Or less (maybe, you get the idea).
- fully pre-emptible - robust thread priority inversion - fine-grained locking in memory subsys and vfs
These are all things that make the SunOS kernel scalable. That being said, Linux is pretty much there too. With the latest addition of task queueing, it's kernel is essentially fully pre-emptible as well (IF you're using an IO-APIC...) The new O(1) scheduler gets a grip on IO bound and CPU bound threads much better... but I think the VFS is still a bit of a bottleneck. IIRC the addition of RCU into certain critical places should improve that situation.
Linux was already on it's way there. A look at the SunOS threading code might serve to verify that kernel developers were headed down the right path, or expose a different way of doing the same thing, but I don't think it's going to shock or amaze anyone.
... at the office. Apparently my coworker (who's been there a long time) used it to clean reel-to-reel tapes. He still has it, and it's still crystal clear and it smells like all kinds of NASTY. We used it to clean some equipment that had been outside (with birds) and it did a real good job.
That's just for the standard VGA character set, and it applies nowhere else (bizarre, eh?).
Actually, ISO-8859-1 (ASCII with extended Latin) puts a 2 superscripted at 0xB2, and a 3 superscripted at 0xB3. 0xB0 is degree, 0xB4 is "prime", 0xB9 is a one superscripted (?), and 0xB0 is a 0 superscripted.
It doesn't include a truncated sinc function or polyphase filter (as far as I could tell)... what's the point? I mean, we already know how to "do it right".
What you really need is an MPEG/JPEG deblocker, THEN you resize the image. Duurrrr.
I mean, I'd pay $180 if it took the EXIF information from the picture, derived information about the CCD layout and lens/aperature settings, and information about the artifacts introduced by the particular quanitization that occured during JPEG compression -- to create a reconstruction filter that could then be combined with the resizing filter above to allow for adding back in detail in the resized image.
Ah yes... I think this is one of those applications where multi-rate filtering is useful for something other than filling journals. (right?) By taking into account the response of block DCT algorithms in the motion comp/optical blur removal steps, you can take full advantage of the entire system's response and extract even more accurate spatial domain information.
I wonder what specifically Sony models and how they adjust their models for varying input sources...
How exactly has linux been playing "catch up with the flurry" of CD-RW designs?
There is exactly TWO. The first is through ATAPI/MMC by the way of the ide-scsi driver (but more recently without the extra layer, which usually falls to userspace utility cdrecord.
The other way is by the experimental support for Mt. Rainier in the kernel, which is specifically for CD-RWs.
As far as hardware interfaces go... there isn't any. Either the device speaks SCSI or ATAPI/MMC (or MMC raw, but only cdrecord cares about the distinction). The drive itself contains the firmware and the hard logic to make it all work.
Any additional user-space complexity is primarily to achieve higher thorughput and reliability, not because of the complexity of controlling the medium. If the drive supports burnfree, a CD-R can be written with a very small subset of the protocol with few, if any, conditional branches.
SCSI has been around for almost as long as the PC floppy. I imagine the base protocols will still be around in a decade. Since each controller is almost universally bundled with a boot ROM that enables easy access to it's functionality through the BIOS (or OpenFirmware or whatever), it is on no less footing then the lowly floppy as far as universal, low-level access is considered.
is almost as difficult as writing to a CD-R for the host system. Floppy drives have next to zero internal smarts and the disk/head movement is almost entirely programmatically driven. This is not design at all. At least the CD-R allows for some seperation of mechanics to logical layout, and adheres to some specification (ATAPI/MMC).
Meanwhile, we your 100MB+ floppies. They're called Zip drives. They're cost-effective floppy alternatives, while being a bit more reliable.
For a lot of reasons. Incremental improvement in quality while simultaneously being much more propietary and/or unrippable, and wasted money on duplicate purchases.
That being said, DVD-Audio would be a semi-decent choice if the media companies would release more than a double-CDs set worth of music on them for a modest price ( $25).
Most BIOS manufacturers, if they add a bootable USB feature, then they also add a feature that makes USB storage devices look like hard disks or floppy disks for DOS's benefit. (These emulation features would be ignored if a "real" OS was booted from the USB dongle).
This is done because one of the primary reasons to boot from a dongle is to flash the BIOS or do other maintenance. Since XP cannot be readily adapted to do this, and BIOS manufacturers weren't going out of their way to be Linux or BSD friendly, they must provide this DOS emulation for that feature to be marketable.
I can't think of a system I've yet to come across where the USB boot support has your supposed limitation.
Slashdot Mirror
...when they make a pyramid scheme that gives away iRivers or Rio Karmas.
Why is everyone so desperate to get a free iPod anyway? You know you have to pay for the music on iTunes...
Graham added that while AOL will not check Sender ID for inbound messages, it will still publish records for outbound e-mail.
Publishing SPF records does exactly what AOL needs. Specifically it reduces the number of joe-jobs directed at its clients. As more mail servers are set up to check these records, the better it gets for them.
What does implementing Microsoft's Caller-ID have to offer in addition to AOL's subscribers?
(Of course, so does every other program that uses GTK for the interface/widgets...)
:-)
So unless someone has convinced you to download and use a GTK theme that has PNG files in it that exploit the vulnerability, you're okay.
The real issue is these library programmers are serving two masters:
:-)
1) Desktop use
2) Embedded use.
Generally they code for the latter, even if they know that the majority of use is going to be for the former.
I've seen claims in libraries like libpng and zlib about how little memory required for decoding and such and such.
Well guess what? It's all that grasping for allocating the smallest buffers possible that gets you into trouble. Because it's really easy to fuck up there. If you just play it safe and allocate as big a buffer as some atom of your file format is theoretically going to need to do what it does, then you wouldn't have to worry about stuff like that.
And, it's like, so what! EVERY desktop operating system out there has a paged virtual memory system, and I guarantee if you don't use that extra unallocated memory in most cases, it won't "actually" get allocated. So the operating system (and thus the user) could care less, since it's demand-based anyway. But in the odd case that someone tries to fuck with you and actually use that memory, well you'll notice when your hard drive starts paging that somethings' up.
And not to disparage embedded developers: it could be as simple as adding a conditional compiler flag that uses the "safe" mode or the memory/pointer/fiddling version.
libpng was already doing that with respect to feature support. Why not play fast and loose with memory in the full profile version?
As long as it's not a RAW screendump or uncompressed TIFF file or something, there's going to be some interpretation of the file's content to produce the human-consumable output. And it'll be based on a parameterized command stream. And if the interpretation of those parameters is not handled rigourously, or if the system does not account for every possible combination of commands, well then you're ripe for an exploit.
That's basically EVERY file format.
Even text can be dangerous. Ever heard of a terminal or ANSI bomb? (scroll down in link).
The only "safe" viewer is a hex editor. Or less (maybe, you get the idea).
I remember the first time we saw that Ball Park franks commercial with the fat guy going on about them.
Be Big. Be Meaty. Be Frank.
And then he goes "Uuuhhh" like that... and it looks like he just came in his pants in awe of the homoerotic plumpness.
I swear to god we spent fifteen minutes rewinding and pausing it at various intervals.
Thanks Tivo!!!
...you are to assume that the arbitrary modulation scheme is using the entire bandwidth to transfer data at the shannon limit (right term?)
- fully pre-emptible
- robust thread priority inversion
- fine-grained locking in memory subsys and vfs
These are all things that make the SunOS kernel scalable. That being said, Linux is pretty much there too. With the latest addition of task queueing, it's kernel is essentially fully pre-emptible as well (IF you're using an IO-APIC...) The new O(1) scheduler gets a grip on IO bound and CPU bound threads much better... but I think the VFS is still a bit of a bottleneck. IIRC the addition of RCU into certain critical places should improve that situation.
Linux was already on it's way there. A look at the SunOS threading code might serve to verify that kernel developers were headed down the right path, or expose a different way of doing the same thing, but I don't think it's going to shock or amaze anyone.
RHEL is LSB compliant I thought...
He made the music for DKC and DKC2... some of the best stuff to ever come out of a SNES, _ever_.
I'm surprised he hasn't released any solo CDs, because he's awesome.
It's the exact same card as the Toshiba bluetooth SD-card. Of course, Toshiba only provides drivers and information Pocket PC.
Sigh.
... at the office. Apparently my coworker (who's been there a long time) used it to clean reel-to-reel tapes. He still has it, and it's still crystal clear and it smells like all kinds of NASTY. We used it to clean some equipment that had been outside (with birds) and it did a real good job.
It even has an ABC price tag on it. Hilarious...
enjoy
Everyone takes the turnpike, AND, it takes over an hour to get anywhere even if it isn't rush hour.
That's just for the standard VGA character set, and it applies nowhere else (bizarre, eh?).
Actually, ISO-8859-1 (ASCII with extended Latin) puts a 2 superscripted at 0xB2, and a 3 superscripted at 0xB3. 0xB0 is degree, 0xB4 is "prime", 0xB9 is a one superscripted (?), and 0xB0 is a 0 superscripted.
So there!
It doesn't include a truncated sinc function or polyphase filter (as far as I could tell)... what's the point? I mean, we already know how to "do it right".
What you really need is an MPEG/JPEG deblocker, THEN you resize the image. Duurrrr.
I mean, I'd pay $180 if it took the EXIF information from the picture, derived information about the CCD layout and lens/aperature settings, and information about the artifacts introduced by the particular quanitization that occured during JPEG compression -- to create a reconstruction filter that could then be combined with the resizing filter above to allow for adding back in detail in the resized image.
Now that'd be a fucking cool plugin.
Ah yes... I think this is one of those applications where multi-rate filtering is useful for something other than filling journals. (right?)
By taking into account the response of block DCT algorithms in the motion comp/optical blur removal steps, you can take full advantage of the entire system's response and extract even more accurate spatial domain information.
I wonder what specifically Sony models and how they adjust their models for varying input sources...
# cdmrw -p -d
bgformat complete!
# cat < cdimage.iso >
# cmp
EOF on
# cdmrw -p -d /dev/hdc -f full ..wait... /dev/hdc /dev/hdc cdimage.iso /dev/hdc
bgformat complete!
# cat
# cmp
EOF on
How exactly has linux been playing "catch up with the flurry" of CD-RW designs?
There is exactly TWO. The first is through ATAPI/MMC by the way of the ide-scsi driver (but more recently without the extra layer, which usually falls to userspace utility cdrecord.
The other way is by the experimental support for Mt. Rainier in the kernel, which is specifically for CD-RWs.
As far as hardware interfaces go... there isn't any. Either the device speaks SCSI or ATAPI/MMC (or MMC raw, but only cdrecord cares about the distinction). The drive itself contains the firmware and the hard logic to make it all work.
Any additional user-space complexity is primarily to achieve higher thorughput and reliability, not because of the complexity of controlling the medium. If the drive supports burnfree, a CD-R can be written with a very small subset of the protocol with few, if any, conditional branches.
SCSI has been around for almost as long as the PC floppy. I imagine the base protocols will still be around in a decade. Since each controller is almost universally bundled with a boot ROM that enables easy access to it's functionality through the BIOS (or OpenFirmware or whatever), it is on no less footing then the lowly floppy as far as universal, low-level access is considered.
is almost as difficult as writing to a CD-R for the host system. Floppy drives have next to zero internal smarts and the disk/head movement is almost entirely programmatically driven. This is not design at all. At least the CD-R allows for some seperation of mechanics to logical layout, and adheres to some specification (ATAPI/MMC).
Meanwhile, we your 100MB+ floppies. They're called Zip drives. They're cost-effective floppy alternatives, while being a bit more reliable.
Crap.
For a lot of reasons. Incremental improvement in quality while simultaneously being much more propietary and/or unrippable, and wasted money on duplicate purchases.
That being said, DVD-Audio would be a semi-decent choice if the media companies would release more than a double-CDs set worth of music on them for a modest price ( $25).
Most BIOS manufacturers, if they add a bootable USB feature, then they also add a feature that makes USB storage devices look like hard disks or floppy disks for DOS's benefit. (These emulation features would be ignored if a "real" OS was booted from the USB dongle).
This is done because one of the primary reasons to boot from a dongle is to flash the BIOS or do other maintenance. Since XP cannot be readily adapted to do this, and BIOS manufacturers weren't going out of their way to be Linux or BSD friendly, they must provide this DOS emulation for that feature to be marketable.
I can't think of a system I've yet to come across where the USB boot support has your supposed limitation.