If you prefer something a little less cheap and nasty than the Minolta Z series, I used an Olympus C-750 for a while (before it was stolen, grr!); got some great shots, including some nice macros and full telephoto ones. Not the fastest camera in the world, and it only goes down to ~38mm equivilent (not good for wide angle), but it's sturdy, takes addon lenses/filters and has good battery life with decent NiMH AA's. Compared with my Minolta F200, the shots were also sharper and less noisy.
Minolta's A1/A2 is probably going to be more interesting to this guy, being Minolta's high end dSLR-alike, but it's not for me.. I think.. gah, too much choice! (stabilized x7 telephoto and a lovely body, but since the CCD's so small they have big problems with noise; macro range leaves a lot to be desired too)
dSLR wise I much prefered the Nikon D70's image quality to the Canon (less noisy; with it being a CCD instead of the Rebel's CMOS), but really you need to research this stuff yourself; cameras have a lot of size/price/performance/speed/power tradeoffs especially with compacts and ultra compacts. You need to decide what's important to you.
Some nice shots there, cbiffle. Be nice to see the original JPG's -- it's hard to evaluate noise and such with such small samples.. nice girl too;)
You can't measure all the properties of the photon -- for instance, if you measure one kind of polarization (diagonal, say), you forfit the ability to measure the other two (rectilinear and circular) because you destroyed the photon in order to measure it.
Both sides of the communications channel pick what polarization matters at random; that is the sender picks a polarization type at random to encode a random bit, and the receiver picks a type at random to detect. After sending and detecting the photon, they can tell each other what type they picked over an insecure (but authenticated) channel; if they picked the same type, they both add the bit to their one time pad; otherwise it's just discarded.
As an evesdropper, the best you can do is also pick types of polarization to detect at random; you can retransmit *a* photon with the polarization you detected encoded in it, but you have no way of knowing if it's the same one the sender and recipient are using.
Most of the time it won't matter; neither party will have picked the same polarization and the information is discarded. When they do pick the same one, chances are you haven't -- the photon you've retransmitted will then be incorrect, introducing lots of errors into the data, and although you'll get lucky some of the time, it'll become obvious that the errors that are introduced are not just a result of line noise or so.
The more bits that are transmitted across the channel, the lower the probability that an evesdropper went undetected out of blind luck.
That's what I gathered from Wikipedia, anyway. Now I need to sleep;)
I killed my Lexar JumpDrive "Secure" in about two months
I have one of these as a replacement to my stolen bytestor; technically it's about as uninspiring as USB Flashdrives get, but what really irritates me is the case feels cheap and nasty, especially the USB cap, which I constantly expect to fall off or find cracks in. It's stupidly bulky too. So much for Lexar's brand name:/
Do you still have the dead one, btw? Care opening it and seeing what's inside? Some JumpDrives act as SD card readers; be interesting to see if the sealed ones just include a cheapo Lexar SD card in there -- would explain why they're so bulky.
Amazon and Play tend to do half price offers on box sets every so often; think I got the whole of Family Guy and Futurama for 60% off - keep an eye out:)
I've seen explorer die on my XP machine without any such notices; I've also killed explorer without them. Happens pretty rarely though; in my experience XP is normally pretty stable:
\\OENONE has been up for: 6 day(s), 19 hour(s), 30 minute(s), 12 second(s)
Sadly FLAC won't help much when wanting to play on an iPod; Apple for some strange reason developed their own somewhat inferior and closed lossless format called (funnily enough) Apple Lossless. It gets largely similar bitrates, typically a few percent larger than an equivilent FLAC. Kinda sad given that FLAC already has hardware support and a lot of users:(
Shame.. 60G would just be enough to fit my music on, but hey, if they don't want my custom, that's their business. It just saddens me to see them ignore already established standards in favour of their own new and unnecessary ones.
Plus you tend to loose things like TLS, and of course being a single node for all mail for an ISP can make them a little slow and unreliable.
The best solution is probably to get your own server on a static IP and smarthost through that; since it's entirely under your control you know it's not going to get some handy config change which breaks your mail, nor is it likely to go away for hours on end while it's broken/fixed/upgraded without warning.
This isn't a DUL problem as such; it's a problem with it's users assuming that, since you're on the DUL, you must be a spammer, instead of just factoring that into some spam filtering heuristic.
Just set up your MTA to use a smarthost for sites which deny mail from you; whether you do that for all hosts or just those which suck is up to you and the capabilities of your MTA. There's not really a lot more you can do; the DUL is doing precisely what it's designed for -- it's the users which are taking "sending mail from a dynamic address range" == "spamming scumbag" which are causing the problem. You just have to route around the damage:)
In theory it should be possible to set up your MTA to take a rejection from a direct MX send and fall back automatically to a smarthost.. it's probably easier to just do it manually though -- it's not as if everyone is that stupid:)
Hmm.. I guess it might be easier to write a userspace app which used *ix filesystem code to read the filesystem directly from Win32's idea of a block device and provide an SMB/NFS interface to it... Network filesystems (especially NFS, which is meant to be very simple on the server side) have always struck me as something you could use to provide a nice system neutral filesystem to just about anything; even CVS/SVN. Using the same idea to access a real filesystem.. that'd even be handy just on the *ix side, potentially giving BSD's Reiser/XFS/etc support without having to worry about the kernel side of things.
Most magnetic fields aren't much of a danger to hard disks; they're so dense the magnetic material has to be quite resistant to all but the largest fields, because the heads can't focus the entire field on the exact area bits are stored on. Unless you're planning on being near an MRI machine or particle accelerator I wouldn't worry too much about it. Just don't store it near your rare earth magnet collection, ok?;)
Shock's more a factor of aerodynamics than shielding; will just have to see what the specs are like:)
I prefer having more than one way to do it in terms of choosing different algorithms and code styles; whether I want to do it like a script, a procedural or OO app, custom datatypes and objects or native types, language defined loops or methods with control over passed code blocks.. there's *plenty* of ways to do things without giving the language itself huge levels of redundancy; that's a naive and frankly silly way towards having MTOWTDI. But, hey, TMTOWTDI, that's why we have multiple languages:)
Well, it's going to happen sooner or later; one day it might even be cost effective in the general case. I hope we can come up with a better way of dealing with it than you when it finally is; that's probably giving humans a bit too much credit though.
"what the hell is the average human useful for"? Who said we had to be useful anyway? We have to survive (well, not really, but let's pretend); whether we do that working our asses off or having fun while our technology does our work for us doesn't make a whole lot of difference.
It does that by having a feature set around the level of links. Once you start having to walk the DOM applying CSS and table layout complexity shoots up quite a bit. Try turning off JS/Plugins/CSS in Opera for a while and set the rendering speed to Immediate and see if it feels faster too:)
Something like a Zaurus in a small notebook size package would rock. PDA size is a little small for extended usage, but even with just a 400MHz XScale, it would be very useful for a lot of applications; a larger form factor would let you fit in more CF/SD slots and a larger battery (maybe multiple hot swap ones, mmm!) and make it more usable with a larger keyboard and display.
I recon there would be a real market for such a device provided you really could make it scale that well.
Memory bandwidth doesn't tend to scale up with CPU speed, so while you can expect a linear speed increase for executing instructions in cache, most applications are going to be hitting system memory a lot and dragging performance down.
Check AMD's white paper on XP product numbering; you'll see they actually base their numbers on a wide range of benchmarks to try to give customers a number which actually reflects performance fairly well; that's important when, say, they increase the amount of on-die cache, as with the Barton; a 2500+ Tbred has a higher clockrate than a 2500+ Barton -- can you think of a clearer way of showing that their performance is largely the same?
It's still slow; again, if performance is a concern there are better solutions that will scale higher. Thankfully performance isn't much of a concern for me, so I stick with SA;)
I think it's a stupid solution; a userland webserver should easily be able to max out your upstream without resorting to hacks like this. OTOH if the very idea doesn't make you want to vomit maybe you should try it;)
3) The stored file sizes although smaller than the raw music are still way to big to be portable IMO.
Well, sure; I don't want to devote 90% of my 512M CF card to a single album, but for my desktop it's perfect. I just transcoded an album from it to Vorbis (this is where it's nice that FLAC is so effecient to decode) -q-1 (that's right, quality minus one) and it sounds fine on my iPAQ. FLAC reduced the filesize from 683M to 466M, which is fine for my desktop; Vorbis reduced the filesize from that to 23M. It's not the sort of thing I want anywhere near my desktop with it's 90UKP soundcard and Sennheiser headphones, but for a portable device it's fine.
In future I hope portable storage scales up to the point at which I don't need to worry about encoding to lossy formats though. In the mean time, having my source as FLAC means I can transcode to whatever format best suits the available technology; from burning an exact CDDA copy for my CD player to a bunch of MP3's for my DVD player to a bunch of ultra low bitrate Ogg Vorbis files for my iPAQ. That'll do me fine until I can get a 256G CF card:)
FLAC has an extensive testing suite if you're not convinced it's lossless, btw.
SpamAssassin's pretty heavyweight; a purer statistics based system like dspam is probably more suitable for large scale systems like this; you don't want a perl script chugging over every single email for seconds at a time. I wouldn't be suprised if they needed 20 mail servers if they were using SA...
It might be worth looking at thttpd (or some other lightweight nonblocking IO based server, there are quite a few) and running PHP as a FastCGI daemon; you get significantly better performance serving static files, keep the httpd's lightweight by keeping PHP out of them, and can loadbalance the PHP stuff across servers should you wish. Any database servers will thank you too, since it helps keep the number of PHP instances down.
The main thing holding us back is the lack of decent URL rewriting support in any of the other servers we've seen. Luckily at just 16 requests/second nominally, we can cope:)
Slashdot Mirror
If you prefer something a little less cheap and nasty than the Minolta Z series, I used an Olympus C-750 for a while (before it was stolen, grr!); got some great shots, including some nice macros and full telephoto ones. Not the fastest camera in the world, and it only goes down to ~38mm equivilent (not good for wide angle), but it's sturdy, takes addon lenses/filters and has good battery life with decent NiMH AA's. Compared with my Minolta F200, the shots were also sharper and less noisy.
;)
Minolta's A1/A2 is probably going to be more interesting to this guy, being Minolta's high end dSLR-alike, but it's not for me.. I think.. gah, too much choice! (stabilized x7 telephoto and a lovely body, but since the CCD's so small they have big problems with noise; macro range leaves a lot to be desired too)
dSLR wise I much prefered the Nikon D70's image quality to the Canon (less noisy; with it being a CCD instead of the Rebel's CMOS), but really you need to research this stuff yourself; cameras have a lot of size/price/performance/speed/power tradeoffs especially with compacts and ultra compacts. You need to decide what's important to you.
Some nice shots there, cbiffle. Be nice to see the original JPG's -- it's hard to evaluate noise and such with such small samples.. nice girl too
You can't measure all the properties of the photon -- for instance, if you measure one kind of polarization (diagonal, say), you forfit the ability to measure the other two (rectilinear and circular) because you destroyed the photon in order to measure it.
;)
Both sides of the communications channel pick what polarization matters at random; that is the sender picks a polarization type at random to encode a random bit, and the receiver picks a type at random to detect. After sending and detecting the photon, they can tell each other what type they picked over an insecure (but authenticated) channel; if they picked the same type, they both add the bit to their one time pad; otherwise it's just discarded.
As an evesdropper, the best you can do is also pick types of polarization to detect at random; you can retransmit *a* photon with the polarization you detected encoded in it, but you have no way of knowing if it's the same one the sender and recipient are using.
Most of the time it won't matter; neither party will have picked the same polarization and the information is discarded. When they do pick the same one, chances are you haven't -- the photon you've retransmitted will then be incorrect, introducing lots of errors into the data, and although you'll get lucky some of the time, it'll become obvious that the errors that are introduced are not just a result of line noise or so.
The more bits that are transmitted across the channel, the lower the probability that an evesdropper went undetected out of blind luck.
That's what I gathered from Wikipedia, anyway. Now I need to sleep
You mean like a Zaurus? A friend of mine has the SL-C860 -- it's like an ickle solid state Linux laptop! :)
I have one of these as a replacement to my stolen bytestor; technically it's about as uninspiring as USB Flashdrives get, but what really irritates me is the case feels cheap and nasty, especially the USB cap, which I constantly expect to fall off or find cracks in. It's stupidly bulky too. So much for Lexar's brand name
Do you still have the dead one, btw? Care opening it and seeing what's inside? Some JumpDrives act as SD card readers; be interesting to see if the sealed ones just include a cheapo Lexar SD card in there -- would explain why they're so bulky.
Amazon and Play tend to do half price offers on box sets every so often; think I got the whole of Family Guy and Futurama for 60% off - keep an eye out :)
Nope; ALS ha[ds]n't been finalized, and either way Apple didn't use it, as a quick Google will confirm.
Sadly FLAC won't help much when wanting to play on an iPod; Apple for some strange reason developed their own somewhat inferior and closed lossless format called (funnily enough) Apple Lossless. It gets largely similar bitrates, typically a few percent larger than an equivilent FLAC. Kinda sad given that FLAC already has hardware support and a lot of users :(
Shame.. 60G would just be enough to fit my music on, but hey, if they don't want my custom, that's their business. It just saddens me to see them ignore already established standards in favour of their own new and unnecessary ones.
Plus you tend to loose things like TLS, and of course being a single node for all mail for an ISP can make them a little slow and unreliable.
The best solution is probably to get your own server on a static IP and smarthost through that; since it's entirely under your control you know it's not going to get some handy config change which breaks your mail, nor is it likely to go away for hours on end while it's broken/fixed/upgraded without warning.
This isn't a DUL problem as such; it's a problem with it's users assuming that, since you're on the DUL, you must be a spammer, instead of just factoring that into some spam filtering heuristic.
:)
:)
Just set up your MTA to use a smarthost for sites which deny mail from you; whether you do that for all hosts or just those which suck is up to you and the capabilities of your MTA. There's not really a lot more you can do; the DUL is doing precisely what it's designed for -- it's the users which are taking "sending mail from a dynamic address range" == "spamming scumbag" which are causing the problem. You just have to route around the damage
In theory it should be possible to set up your MTA to take a rejection from a direct MX send and fall back automatically to a smarthost.. it's probably easier to just do it manually though -- it's not as if everyone is that stupid
Hmm.. I guess it might be easier to write a userspace app which used *ix filesystem code to read the filesystem directly from Win32's idea of a block device and provide an SMB/NFS interface to it... Network filesystems (especially NFS, which is meant to be very simple on the server side) have always struck me as something you could use to provide a nice system neutral filesystem to just about anything; even CVS/SVN. Using the same idea to access a real filesystem.. that'd even be handy just on the *ix side, potentially giving BSD's Reiser/XFS/etc support without having to worry about the kernel side of things.
Most magnetic fields aren't much of a danger to hard disks; they're so dense the magnetic material has to be quite resistant to all but the largest fields, because the heads can't focus the entire field on the exact area bits are stored on. Unless you're planning on being near an MRI machine or particle accelerator I wouldn't worry too much about it. Just don't store it near your rare earth magnet collection, ok? ;)
:)
Shock's more a factor of aerodynamics than shielding; will just have to see what the specs are like
I prefer having more than one way to do it in terms of choosing different algorithms and code styles; whether I want to do it like a script, a procedural or OO app, custom datatypes and objects or native types, language defined loops or methods with control over passed code blocks.. there's *plenty* of ways to do things without giving the language itself huge levels of redundancy; that's a naive and frankly silly way towards having MTOWTDI. But, hey, TMTOWTDI, that's why we have multiple languages :)
Well, it's going to happen sooner or later; one day it might even be cost effective in the general case. I hope we can come up with a better way of dealing with it than you when it finally is; that's probably giving humans a bit too much credit though.
"what the hell is the average human useful for"? Who said we had to be useful anyway? We have to survive (well, not really, but let's pretend); whether we do that working our asses off or having fun while our technology does our work for us doesn't make a whole lot of difference.
It does that by having a feature set around the level of links. Once you start having to walk the DOM applying CSS and table layout complexity shoots up quite a bit. Try turning off JS/Plugins/CSS in Opera for a while and set the rendering speed to Immediate and see if it feels faster too :)
It's not a number, it's a tuple of integers; [4, 10]. 10 is greater than 9, ergo it's an upgrade.
;)
Versions are not floating point numbers! Well, they can be, but that's just confusing and silly
Something like a Zaurus in a small notebook size package would rock. PDA size is a little small for extended usage, but even with just a 400MHz XScale, it would be very useful for a lot of applications; a larger form factor would let you fit in more CF/SD slots and a larger battery (maybe multiple hot swap ones, mmm!) and make it more usable with a larger keyboard and display.
I recon there would be a real market for such a device provided you really could make it scale that well.
Memory bandwidth doesn't tend to scale up with CPU speed, so while you can expect a linear speed increase for executing instructions in cache, most applications are going to be hitting system memory a lot and dragging performance down.
Check AMD's white paper on XP product numbering; you'll see they actually base their numbers on a wide range of benchmarks to try to give customers a number which actually reflects performance fairly well; that's important when, say, they increase the amount of on-die cache, as with the Barton; a 2500+ Tbred has a higher clockrate than a 2500+ Barton -- can you think of a clearer way of showing that their performance is largely the same?
Tend to != necessarily have. Polarising would be Bad[tm], but you don't want to get a pair of sunglasses made of crappy fogged plastic, do you? ;)
It's still slow; again, if performance is a concern there are better solutions that will scale higher. Thankfully performance isn't much of a concern for me, so I stick with SA ;)
I think it's a stupid solution; a userland webserver should easily be able to max out your upstream without resorting to hacks like this. OTOH if the very idea doesn't make you want to vomit maybe you should try it ;)
Well, sure; I don't want to devote 90% of my 512M CF card to a single album, but for my desktop it's perfect. I just transcoded an album from it to Vorbis (this is where it's nice that FLAC is so effecient to decode) -q-1 (that's right, quality minus one) and it sounds fine on my iPAQ. FLAC reduced the filesize from 683M to 466M, which is fine for my desktop; Vorbis reduced the filesize from that to 23M. It's not the sort of thing I want anywhere near my desktop with it's 90UKP soundcard and Sennheiser headphones, but for a portable device it's fine.
In future I hope portable storage scales up to the point at which I don't need to worry about encoding to lossy formats though. In the mean time, having my source as FLAC means I can transcode to whatever format best suits the available technology; from burning an exact CDDA copy for my CD player to a bunch of MP3's for my DVD player to a bunch of ultra low bitrate Ogg Vorbis files for my iPAQ. That'll do me fine until I can get a 256G CF card
FLAC has an extensive testing suite if you're not convinced it's lossless, btw.
SpamAssassin's pretty heavyweight; a purer statistics based system like dspam is probably more suitable for large scale systems like this; you don't want a perl script chugging over every single email for seconds at a time. I wouldn't be suprised if they needed 20 mail servers if they were using SA...
Eh, you can afford laptops, wireless networks and pools, but you skimp on the sunglasses!? Do you not like your eyes very much or something?
It might be worth looking at thttpd (or some other lightweight nonblocking IO based server, there are quite a few) and running PHP as a FastCGI daemon; you get significantly better performance serving static files, keep the httpd's lightweight by keeping PHP out of them, and can loadbalance the PHP stuff across servers should you wish. Any database servers will thank you too, since it helps keep the number of PHP instances down.
:)
The main thing holding us back is the lack of decent URL rewriting support in any of the other servers we've seen. Luckily at just 16 requests/second nominally, we can cope