I'm wondering whether they're going to come out with a 34mm (~50mm, guestimated) prime lens. I haven't (yet) bought one of these, but when I do, the 50mm 1.8 (or 1.4 budget permitting) is the first thing I plan on getting.
Computers these days (and I made this realisation with my most recent purchase) are cheap enough that you just buy a new one, and make a headless closet server out of the old one.
I'm making my recent cast off -- an old P200 -- an MP3 player for the GF. Interesting project because it has to be enginerred to recover gracefully from any number of things and also combine ease of use and power.
On that note (OT):
can anyone recommend a good mp3 server with the following characteristics?
1) play mp3s on server, with pretty web front end (a bit of flash for the animation would be great) 2) stream mp3s to shoutcast server 3) play mp3s on client (several simultaneous) 4) rip and catalog cds inserted into drive automatically 5) allow playlists to be burned to server cdr
A bit of research has given me mserv for 1 (+2 in devel), edna for 3, no solution yet for 4 or 5.
6) do it all in uniform interface. So preferably one interface for all of it.
The fun really begins when they start their mumbo-jumbo reasoning in the digital world. Oxygen-free solid copper core cables at how many $K/ft is all fine and dandy until someone starts trying to sell you a high performance cat-5 cable (for optimizing jitter in your streaming bits, natch).
The argument (that I actually had on k5, but in the context of a high-priced digital-out cd player) was that although two bit streams were IDENTICAL on the data layer, somehow the quality of the pyhsical layer would influence the D/A conversion...
Fantastic stuff. Mind you I like subjectivity. Life would be boring without it, and if you like to spend your paycheck that way, fine, but ignoring objective reasoning is absurd. </rant>
Well, add a motorized turntable to one of these babies, and you have a decent mockup of a laser lathe. 'course, you can't cut concave surfaces, but there's still alot it could automate.
Glass is not transparent to all wavelengths; notably IR and UV don't pass through. All you need is a LASER in some wavelength the glass isn't transparent to.
A follow-up question is what did they make the internal prisms from?
That just doesn't seem right. I have run both scenarios, both over solaris->netapp and linux->linux, and while solaris->netapp far blows away linux->linux nfs (what a dog! and that's with rsize and wsize set pretty generously, and running off the same switch), both were _far_ slower than local IDE disk. No need for benchmarks, you could feel the difference: night and day.
I'm really really confused by your experience. Perhaps you could run some benchmarks (I forget the name of the small one -- bonnie?) for us, so that I can see whether it's my network or your IDE which is broken.
I must be losing my explantory powers. The salt, by what I thougth was standard convention, is a random number generated by the password creation routine -- in this case javascript (as per my granp-parent post). My apologies for either misusing terminology or poorly explaing myself.
Assuming that is how you understood salts to work, then I am confused where human-memorable salts enter the picture. Why would the human even see the salt, as it is a random number supplied by the remote client program?
You're correct about the synchronized times, and that item of the tuple can be omitted, if you have some other way of combating replay, such as state on the server to disallow repeated use of a particular salt. (as per my parent post).
As for brute force, I had rather assumed that if that wasn't a valid attack in this threat model. Oh, I guess this would give you an opportunity to run dictionary attacks off line. Good point.
I guess you would have to use a secure hash rather than self-encryption to get around that. Send (salt, hash(enteredpass+salt)) as authetication, verify that hash(knownpass,salt) == auth.
The salt is encrypted w/ the password: Auth(enteredpw) = Enc(enteredpw, RandomSalt+time+enteredpw)
Verify(auth) = let salt,time,enteredpw = Dec(knownpw,auth)
check: enteredpw == knownpw && (timenow - time < replaywindow)
Is that what you understood me to say above? Ifso, could you explain how the dictionary attack comes in?
There is a window during which the entered password can be replayed; this can be countered by either having the server store the salt and allow a given salt to be used only once (in which case the time is not needed), or to restrict logins to be repeated only outside the replay window.
It shouldn't take too long to write a javascript function for encrypting salt+password with the password. Send this as your authentication; the server decrypts with known password to confirm.
Of course, I'm no security expert, so this may be horribly insecure. It just occurred to me that by setting the salt to include the current time of day, you should be able to thwart replay attacks that occur more than a given epsilon after the login, which is kinda neat.
Mozilla does this too. IT works by using regexps to identify inline ads (images and iframes -- good for flash) and setting their CCS display properties to invisible.
google search for mozilla ad-block userContent.ccs should find you the page on the mozilla website
If you don't listen to the experts, you end up with security mechanisms using only "secret" information like your social security number or mother's maiden name to secure your financial assets.
I think you're right in many instances, but in security, the customer should not be king. Unfortunately, this ends up with a bit of a prisoner's dilemma, which can require the help of courts; either by proscriptive law (via mandatory certification, as for cars) or product liability. Neither of which we currently have for software.
It shouldn't be ubiquitous because people should put more value on quality and less on convenience. Ultimately, it is this laziness which lets slipshod products (in any market, not just browsers) ride the tide of marketshare.
It can't be nonconductive; the pump works on electrolytes. I imagine that it is basically a small version of the "caterpillar drive" used by red october in the book of the same name.
It's an ion drive, but for liquid. For that to work, you need ions, and thereby conductivity.
All this from a quick skim of the article, so add salt (:-)) to taste.
static typing does not imply typecasts. ML and Haskell for example, do not have ANY casts in the language.
However, you are correct in that static typing will remove some expressiveness from your language. Whether the loss of expressiveness is outweighed by the static language support depends on the application. (and also how expressive the rest of the language is).
There are several other approaches out there. Some flavors of Scheme allow you to write optional types for arguments; the compiler will complain if it can't prove that those are the types that will be used. Language-level contracts give you more expressive pre and post conditions, but with more dynamic checking.
I thought the whole idea about loopback devices was that you abstracted away from the underlying medium, so that you could store the image in a file. So, I'm confused as to where the sectors enter into it.
To quote the article, they say that loopAES is not block-level encryption. I don't understand how it could be anything else.
No, the unreasonable part is suing 260 people for no reason other than being at the wrong place at the wrong time. Even in civil cases (IMO) higher standards of proof ought to be necessary before the courts get the ball rolling.
I'd label what you describe as a nuisance suit, and slap you with a fine for abusing the court system.
But that's why I'll never get to be a judge (that, and lack of any legal education)
nah, they've just invented a magnetic monopole. By varying the strength of the monopole, they can induce a current in another monopole up to four feet away. Pretty much the same thing as EM transmission.
Slashdot Mirror
14 MP, but lots of noise. Less useful information captured than the good canon, according to some test I read (photo.net?)
I'm wondering whether they're going to come out with a 34mm (~50mm, guestimated) prime lens. I haven't (yet) bought one of these, but when I do, the 50mm 1.8 (or 1.4 budget permitting) is the first thing I plan on getting.
Expandability is obsolete.
Computers these days (and I made this realisation with my most recent purchase) are cheap enough that you just buy a new one, and make a headless closet server out of the old one.
I'm making my recent cast off -- an old P200 -- an MP3 player for the GF. Interesting project because it has to be enginerred to recover gracefully from any number of things and also combine ease of use and power.
On that note (OT):
can anyone recommend a good mp3 server with the following characteristics?
1) play mp3s on server, with pretty web front end (a bit of flash for the animation would be great)
2) stream mp3s to shoutcast server
3) play mp3s on client (several simultaneous)
4) rip and catalog cds inserted into drive automatically
5) allow playlists to be burned to server cdr
A bit of research has given me mserv for 1 (+2 in devel), edna for 3, no solution yet for 4 or 5.
6) do it all in uniform interface. So preferably one interface for all of it.
website is a PITA
I like tables and all, but a bit of modern web-design would not hurt them on bit.
and a $1300 a pop, not exactly the same price range.
The fun really begins when they start their mumbo-jumbo reasoning in the digital world. Oxygen-free solid copper core cables at how many $K/ft is all fine and dandy until someone starts trying to sell you a high performance cat-5 cable (for optimizing jitter in your streaming bits, natch).
The argument (that I actually had on k5, but in the context of a high-priced digital-out cd player) was that although two bit streams were IDENTICAL on the data layer, somehow the quality of the pyhsical layer would influence the D/A conversion...
Fantastic stuff. Mind you I like subjectivity. Life would be boring without it, and if you like to spend your paycheck that way, fine, but ignoring objective reasoning is absurd.
</rant>
Well, add a motorized turntable to one of these babies, and you have a decent mockup of a laser lathe. 'course, you can't cut concave surfaces, but there's still alot it could automate.
Glass is not transparent to all wavelengths; notably IR and UV don't pass through. All you need is a LASER in some wavelength the glass isn't transparent to.
A follow-up question is what did they make the internal prisms from?
whaa? NFS faster than local disk?
That just doesn't seem right. I have run both scenarios, both over solaris->netapp and linux->linux, and while solaris->netapp far blows away linux->linux nfs (what a dog! and that's with rsize and wsize set pretty generously, and running off the same switch), both were _far_ slower than local IDE disk. No need for benchmarks, you could feel the difference: night and day.
I'm really really confused by your experience. Perhaps you could run some benchmarks (I forget the name of the small one -- bonnie?) for us, so that I can see whether it's my network or your IDE which is broken.
I must be losing my explantory powers. The salt, by what I thougth was standard convention, is a random number generated by the password creation routine -- in this case javascript (as per my granp-parent post). My apologies for either misusing terminology or poorly explaing myself.
Assuming that is how you understood salts to work, then I am confused where human-memorable salts enter the picture. Why would the human even see the salt, as it is a random number supplied by the remote client program?
You're correct about the synchronized times, and that item of the tuple can be omitted, if you have some other way of combating replay, such as state on the server to disallow repeated use of a particular salt. (as per my parent post).
As for brute force, I had rather assumed that if that wasn't a valid attack in this threat model.
Oh, I guess this would give you an opportunity to run dictionary attacks off line. Good point.
I guess you would have to use a secure hash rather than self-encryption to get around that. Send (salt, hash(enteredpass+salt)) as authetication, verify that hash(knownpass,salt) == auth.
The salt is encrypted w/ the password:
Auth(enteredpw) = Enc(enteredpw, RandomSalt+time+enteredpw)
Verify(auth) = let salt,time,enteredpw = Dec(knownpw,auth)
check: enteredpw == knownpw && (timenow - time < replaywindow)
Is that what you understood me to say above? Ifso, could you explain how the dictionary attack comes in?
There is a window during which the entered password can be replayed; this can be countered by either having the server store the salt and allow a given salt to be used only once (in which case the time is not needed), or to restrict logins to be repeated only outside the replay window.
It shouldn't take too long to write a javascript function for encrypting salt+password with the password. Send this as your authentication; the server decrypts with known password to confirm.
Of course, I'm no security expert, so this may be horribly insecure. It just occurred to me that by setting the salt to include the current time of day, you should be able to thwart replay attacks that occur more than a given epsilon after the login, which is kinda neat.
Mozilla does this too. IT works by using regexps to identify inline ads (images and iframes -- good for flash) and setting their CCS display properties to invisible.
google search for mozilla ad-block userContent.ccs should find you the page on the mozilla website
I'm suprised the FAA can't rescind those on a by-need basis for emergencies.
You win the prize for most insightful comment of the week.
Of course, shotgun shells are pretty cheap.
If you don't listen to the experts, you end up with security mechanisms using only "secret" information like your social security number or mother's maiden name to secure your financial assets.
I think you're right in many instances, but in security, the customer should not be king. Unfortunately, this ends up with a bit of a prisoner's dilemma, which can require the help of courts; either by proscriptive law (via mandatory certification, as for cars) or product liability. Neither of which we currently have for software.
http://hcs.harvard.edu/~igp/glass.html
That's quite disingeneous.
It shouldn't be ubiquitous because people should put more value on quality and less on convenience. Ultimately, it is this laziness which lets slipshod products (in any market, not just browsers) ride the tide of marketshare.
Wtf?! Bikinis aren't sfw?
It can't be nonconductive; the pump works on electrolytes. I imagine that it is basically a small version of the "caterpillar drive" used by red october in the book of the same name.
It's an ion drive, but for liquid. For that to work, you need ions, and thereby conductivity.
All this from a quick skim of the article, so add salt (:-)) to taste.
I thought that databases really liked to speak to the raw partition, rather than lying atop a filesystem.
If that is true, then any argument about which filesystem is better for databases is moot.
static typing does not imply typecasts. ML and Haskell for example, do not have ANY casts in the language.
However, you are correct in that static typing will remove some expressiveness from your language. Whether the loss of expressiveness is outweighed by the static language support depends on the application. (and also how expressive the rest of the language is).
There are several other approaches out there. Some flavors of Scheme allow you to write optional types for arguments; the compiler will complain if it can't prove that those are the types that will be used. Language-level contracts give you more expressive pre and post conditions, but with more dynamic checking.
confusion!
I thought the whole idea about loopback devices was that you abstracted away from the underlying medium, so that you could store the image in a file. So, I'm confused as to where the sectors enter into it.
To quote the article, they say that loopAES is not block-level encryption. I don't understand how it could be anything else.
help!
Your clarification is much appreciated.
If only this place would hand out law degrees, I could make a mint!
No, the unreasonable part is suing 260 people for no reason other than being at the wrong place at the wrong time. Even in civil cases (IMO) higher standards of proof ought to be necessary before the courts get the ball rolling.
I'd label what you describe as a nuisance suit, and slap you with a fine for abusing the court system.
But that's why I'll never get to be a judge (that, and lack of any legal education)
nah, they've just invented a magnetic monopole. By varying the strength of the monopole, they can induce a current in another monopole up to four feet away. Pretty much the same thing as EM transmission.
At least, that's what I got from the article.