The average temperature is not the limiting factor, but that enough times passes since the beginning of the last universe so that it is likely for such an unlikely event to occur.
Statistically, these quantum fluctuations don't exist (except when they do..., ^_^ ) so you have to wait an inordinate amount of time for it to decide to happen.
They farm out all of their R&D in the form of browsing the latest offerings from Taiwanese system integrators. That R&D budget buys hookers and pays engineers who muddle the power connectors on each new motherboard.
So saying Sun spends 10 times more than that ain't saying much.
Well, to be honest, I don't know PHP so I can't be qualified to make a comparison. I will say that I loathe to write simple CGI scripts in C, and defer to perl (like PHP) because it is an easier excercise, and no Makefiles required,:-)
What you find is that when you need to tie together unfriendly APIs, do device manipulation, and do heavy lifting, the C implementation can be comforting.
I wrote a 4-script cgi app in C that acts as a front-end/configuration tool for a hackneyed backup solution for windows boxen based on samba and tape archive metaphors. Another was a secure utility for maintaining non-ASCII docs in a CVS style hive.
To be fair, a small army of perl scripts do maintenance tasks outside of the cgi code's control. But that code (and some accompanying utils) are all C, about 2500 lines total.
I have been moving away from C recently, and towards perl for my rapid CGI development. I have done a similar thing where I push the C into the background, into daemons and utils that the perl script manipulates from the front end; acting as a sophisticated "display" layer. So, I feel that this must be a common POV.
Do investigate libcgi, it can save you during the times when you want to bolt a web front-end to an existing C/C++ code utility./C
Wait till they see me in my pneumatic hardsuit with the built in atmospheric controls and health monitoring. I'm still trying to perfect my ego-border dissolution skill so I can turn people in to puddles of jello in act 3.
Turning them back isn't so easy. Sigh.
There are people AGAINST this, and not spammers!
on
Do-Not-Email Registries?
·
· Score: 3, Insightful
I don't get it.
They (CAUCE) complain that it shifts the burden onto the consumer to be a member of the opt-out list (which is free, and easy to get into). The complain that we are treating the symptoms and not the cause.
Bull. It costs the spammers money to even SEE the lists, and they face $500+ penalties if they don't check and mail first. Hence, this is a real financial deterrent (at least in those states). This artificially raises the transaction costs, which gets at the cause (that is, email is cheap and free).
Instead, CAUCE wants it to be like junk fax laws wherein no one can send you email without having established "a business relationship" with the recipient. I see too many ways of twisting this around in court that would prevent legitimate email from being sent to people when your first contact with them would be through that medium. It would scare people away from just sending email notes because they won't know how it'll be interpreted at the other end. I can envision paranoid use policies sprouting up in IT departments all over our fair land. Nooo!!!!
What is unclear is whether both the spammer and the spammee (sp ?) have to be in the same state (or in states with similar laws) for this to be effective. In that case, all the spammers will just base their operations in Florida where half the GDP comes from MLM and other scams.
But they only thing I fear is that they will make the price much higher because they can justify to managers with marketing material stating how "flexible" it is and it is for "advanced developers" or some other bullshit; meanwhile they've mostly taken stuff out and bundled the things that should come with it but you download anyway from sysinternals or MSDN.
I could live with that, if I wasn't paying for it.
Then yes, it would be. usb-storage comes installed with everything lately; at most you might need gphoto if you want a pretty application to coddle your images.
For instance, we compute a running estimate of your soundcard's actual sampling rate. You can use that estimate to drive the sample rate converter (srate) device to resample audio to the actual rate of your sound card.
Now THAT's hardcore. If only this existed two years ago...::sobs::
1) commands run with as much permissions as the perl script itself, including umask. If there just happens to be a local r00t expl0it, well that's too bad. Perhaps it would motivate the server owner to apply some patches. Any damage would be limited to that which can be done with shell access otherwise (which this is supposed to provide). Moreover, it would behoove the owner of said script to make a few simple changes and use a white list of allowed commands or a blacklist of dubious things to prevent shenanigans (IE no eval, command interpolation, or exec, and limiting PATH)
2) htaccess is as secure as telnet (perhaps moreso). I have telnet open to untrusted accounts, and I've not been rooted. The only thing I would complain about is how browsers manage basic auth permissions. I would encourage users to modify the script to remove any weird html and write a user-interface shell script (using curl or something) to provide a pseudo-terminal session. This would prevent the session from being hijacked by browser bugs or by just not closing out of Moz or IE.
3) Finally, there is nothing about this that would prevent you from using SSL... a feature that some sites might provide as a side effect of having a management, ecommerce, or sign-up site hosted on the same machine.
One thing I don't like is the lack of simple console i/o. It would be nice to provide simple console support via HTTP/1.1 streaming and javascript on the client side; it wouldn't be interactive but it could at least emulate things like no-echo with a "password" textbox vs. a normal textbox. It sounds like a lot of work though.
BTW, I also agree with Hyperion as well. In particular, linux, in a lot of ways, sucks too. As a technological feat, it cannot be ignored. But it has a long way to go. In particular, it saddens me that linux is mostly focused on pulling in support for various technologies and standards and not too much else. That and tin-foil-hat patches. Why can't we be the ones deciding where we want it to go next? There are all sorts of weird ideas I'd love to see come to linux that aren't just copies of whatever else someone is doing. It would give it a distinctive flavor and make it an OS with its own merits (besides a philosophy and widespread nerd tolerance).
Also, I like the idea of ReactOS myself. Its not like software vendors are just going to stop making software compatible with NT 4.0 API next year; they probably aim for that as a target system, with NT5.0 as a convienient superset. So if it gets a gui soon, it will be eminently useful for a small group of NT d00dz. Plus, imagine what insights these programmers will gain after having to hack together a system that is modeled after the OSF3/win32 architecture. If they don't go insane, I imagine great things to come from a group who could manage that.
(please don't mod me down, oh please don't mod me down brer fox)
I like NT because it is probably the most "predictable" OS you can find; each installation is basically the same, especially within a company. Any changes are superficial, all you need to know is a few key version and service pack numbers and you've got a clear picture of the state of things. It is remarkably stable, especially if you don't buy crappy hardware. Because it hosts most of my favorite apps and games, I can live with myself having a few copies (legitimately, but not out of my own pocket...;-P )
And I like linux because when you have to get dirty with interfacing hardware, and no clear solution exists, you look to the source. I've had to do this too many times, and linux comes and saves my ass with bits and pieces scrounged from hither and yon, duct-taped up with perl, and boom, you have your custom widget for whatever-the-fuck was needed in a weeks time. My latest project: Palm Pilot m130 + otherwise useless P133 Dell Latitude = OGG player with IR remote for the car! w00t!!
Plus, I like being able to squeeze the last bit of performance out of machine, and knowing its operation front to back. It makes me feel safer when deploying a critical service; being able to feel confident it will stay up, and if it fails, I can diagnose it quickly because of said transparency. Linux, when set up conservatively, can take a huge beating. I've had servers with half-bad RAM and frayed SCSI cables stay up and limp along until I checked the logs... (MEDIC MEDIC!!!) So what about linux leaves you with such a bad taste in your mouth? Interstingly enough, that quality is shared by another less free system: Solaris. The documentation is incredibly thorough; so good, up to the point of throughly recognizing and explaining its own shortcomings (NFS RPC, etc.). I wish Sun was more forthcoming with hardware docs. Alas, this is how they make their money.:-(
Here is my thinking. This is your HOME machine. But you make it sound like this will be in a place where it will be exposed to a lot of people who have no business using it, or are desperate to break in. I mean, are your siblings or spouse wanting to use your PC that badly? Are they after your porn stash?:-) Just kidding. Or is your password that easily guessable... that is something you can fix without resorting to clever software that only belabors the authentication via obfuscation.
Even if it wasn't under attack, obfuscating the login screen is not really a good idea. All the malicious user would need to do to discover the secret is casually observe a legitimate user bypassing said fake login screen.
Moreover, your login program should not allow someone to sit at the computer all day and attempt passwords. It should lock unprivledged accounts out after a few wrong tries ( 5, preferably 3). If it does unlock itself, the cool off period should be at least an hour. Also, each attempt should take progressively longer to check after each failure. This is especially important for Administrator / root accounts which should not lock themselves out.
They often mistake nervousness (embarassment that you've been asked to step aside for an "interview" in the airport), vs. outright fibbing.
I have observed that many of the tests of these devices involve studies where the subjects are encouraged to fool or beat the machine and they base their results on that. However, the subjects are probably already familiar with the tests and are (I imagine) not in fear that something bad will happen to them if they fail.
In the case of the proposed settings (airports, police station), failing this lie detector test could lead to Bad Things. I wonder if these machines pick up the facial features that arise when "the subject is making an attempt to provide a satisfactory response" and THIS mental activity causes the facial feature changes the trained AI responds to.
I suspect the AI was created by evolving a neural net based on human trials (2-layered? -they even mention that it monitors 24 channels; this wouldn't take too long to evolve). Hence it is trained to the testing conditions, and these premises of what they are testing, and/or the methodology of the training may be incorrect.
Maybe the question really is: do we care that the device may be responding to mental stress vs. truth/lie telling? Some might consider it more useful that it just measures stress (which in a question and answer session can be caused by fabricating responses). It could indicate when someone should have a "bad feeling" about someone or their claims. At the same time I feel that if my allegations are true, this device also should (in addition to standard polygraphs) not be used to generate evidence for trial proceedings.
Anyone with more insight into this care to add?
It wouldn't be a simple markov matrix.
on
Immortal Code
·
· Score: 1
There would be sets of matricies that represent that probabilities of state changes, each tied to some internal state (word boundaries?). I imagine these numerous matricies are also very sparse, or that the matrix is updated through some sort of word->word transformation.
I doubt that the a static markov predictor would suffice for guessing phonemes, because it would provide you with too many equiprobable phonemes in your output vector; I (believe) phenomes are close to equally distributed over all speech.
FFTs are used of course to split the voice into energy bands, which are then used as to distinguish the phonemes with varying certainty. It would seem you can't do jack in signal processing without the FFT (unless you can waste CPU time doing a whole buttload of correlation and filtering)
Slashdot Mirror
The average temperature is not the limiting factor, but that enough times passes since the beginning of the last universe so that it is likely for such an unlikely event to occur.
Statistically, these quantum fluctuations don't exist (except when they do..., ^_^ ) so you have to wait an inordinate amount of time for it to decide to happen.
First quasi-pseudo-physics post
They farm out all of their R&D in the form of browsing the latest offerings from Taiwanese system integrators. That R&D budget buys hookers and pays engineers who muddle the power connectors on each new motherboard.
So saying Sun spends 10 times more than that ain't saying much.
Well, to be honest, I don't know PHP so I can't be qualified to make a comparison. I will say that I loathe to write simple CGI scripts in C, and defer to perl (like PHP) because it is an easier excercise, and no Makefiles required, :-)
What you find is that when you need to tie together unfriendly APIs, do device manipulation, and do heavy lifting, the C implementation can be comforting.
I wrote a 4-script cgi app in C that acts as a front-end/configuration tool for a hackneyed backup solution for windows boxen based on samba and tape archive metaphors. Another was a secure utility for maintaining non-ASCII docs in a CVS style hive.
To be fair, a small army of perl scripts do maintenance tasks outside of the cgi code's control. But that code (and some accompanying utils) are all C, about 2500 lines total.
I have been moving away from C recently, and towards perl for my rapid CGI development. I have done a similar thing where I push the C into the background, into daemons and utils that the perl script manipulates from the front end; acting as a sophisticated "display" layer. So, I feel that this must be a common POV.
Do investigate libcgi, it can save you during the times when you want to bolt a web front-end to an existing C/C++ code utility./C
so only a fool or a masochist would use it for simple text manipulation tasks (ever written a CGI script in C?)
Yes, I have. And surprisingly, it's not half bad.
libcgi and glib make things much easier than you would expect.
Pool Compatibility (Breathing Apparatus):
Poopy Suit: Yes
Hardsuit: No (amniotic fluid)
Protection against environmental hazards (jello):
Poopy Suit: Yes
Hardsuit: Yes
Protection against environmental activists:
Poopy Suit: Yes
Hardsuit: No
(oh well)
Smell:
Hardsuit: Smells like latex, saran wrap, and WD-40
Poopy Suit: Smells like poop.
Style:
Poopy Suit: Makes me look bloated. Also, so late 80s.
Hardsuit: White looks good on me. Also, shows off my boobs.
Verdict: Hardsuit, 10 to 8.
Available now at Walmart, or your local mecha ops surplus store
Wait till they see me in my pneumatic hardsuit with the built in atmospheric controls and health monitoring. I'm still trying to perfect my ego-border dissolution skill so I can turn people in to puddles of jello in act 3.
Turning them back isn't so easy. Sigh.
I don't get it.
They (CAUCE) complain that it shifts the burden onto the consumer to be a member of the opt-out list (which is free, and easy to get into). The complain that we are treating the symptoms and not the cause.
Bull. It costs the spammers money to even SEE the lists, and they face $500+ penalties if they don't check and mail first. Hence, this is a real financial deterrent (at least in those states). This artificially raises the transaction costs, which gets at the cause (that is, email is cheap and free).
Instead, CAUCE wants it to be like junk fax laws wherein no one can send you email without having established "a business relationship" with the recipient. I see too many ways of twisting this around in court that would prevent legitimate email from being sent to people when your first contact with them would be through that medium. It would scare people away from just sending email notes because they won't know how it'll be interpreted at the other end. I can envision paranoid use policies sprouting up in IT departments all over our fair land. Nooo!!!!
What is unclear is whether both the spammer and the spammee (sp ?) have to be in the same state (or in states with similar laws) for this to be effective. In that case, all the spammers will just base their operations in Florida where half the GDP comes from MLM and other scams.
People were writing simple simulators for machines that didn't exist anymore (or not at all) back in the 70s.
Java was a bigger, more amibitious effort; a language and core library effort coupled with a virtual machine.
\devmap blah-blah
\god on
\give all
\addbot xaero 5 "Dead Guy"
\say "Sssshhh... be very very quiet, I'm huntin' wabbits!"
But they only thing I fear is that they will make the price much higher because they can justify to managers with marketing material stating how "flexible" it is and it is for "advanced developers" or some other bullshit; meanwhile they've mostly taken stuff out and bundled the things that should come with it but you download anyway from sysinternals or MSDN.
I could live with that, if I wasn't paying for it.
Then yes, it would be. usb-storage comes installed with everything lately; at most you might need gphoto if you want a pretty application to coddle your images.
I'm not kidding. I love helping out (especially when I hear samba)
^_^
ANSI is where it's at.
INSANE CREATORS ENTERPRISES REPRAZENT! Keepin' it real, kickin' it old-skool.
For instance, we compute a running estimate of your soundcard's actual sampling rate. You can use that estimate to drive the sample rate converter (srate) device to resample audio to the actual rate of your sound card.
Now THAT's hardcore. If only this existed two years ago...
(see above)
For the rest of us who wonders what goes on inside the ivory towers...
Is pi in roman numerals?!
::explosion::
AHHHHHHRRRRRRGHHH!!!!
Whine whine whine script kiddies paradise, whine whine whine backdoor shenanigans
baka.
1) commands run with as much permissions as the perl script itself, including umask. If there just happens to be a local r00t expl0it, well that's too bad. Perhaps it would motivate the server owner to apply some patches. Any damage would be limited to that which can be done with shell access otherwise (which this is supposed to provide). Moreover, it would behoove the owner of said script to make a few simple changes and use a white list of allowed commands or a blacklist of dubious things to prevent shenanigans (IE no eval, command interpolation, or exec, and limiting PATH)
2) htaccess is as secure as telnet (perhaps moreso). I have telnet open to untrusted accounts, and I've not been rooted. The only thing I would complain about is how browsers manage basic auth permissions. I would encourage users to modify the script to remove any weird html and write a user-interface shell script (using curl or something) to provide a pseudo-terminal session. This would prevent the session from being hijacked by browser bugs or by just not closing out of Moz or IE.
3) Finally, there is nothing about this that would prevent you from using SSL... a feature that some sites might provide as a side effect of having a management, ecommerce, or sign-up site hosted on the same machine.
One thing I don't like is the lack of simple console i/o. It would be nice to provide simple console support via HTTP/1.1 streaming and javascript on the client side; it wouldn't be interactive but it could at least emulate things like no-echo with a "password" textbox vs. a normal textbox.
It sounds like a lot of work though.
(hey, I was in Houston-what else do they have to be proud of?) ::indignant expression::
Well, I was born there for starters, in the NERV-5 installation just to the southwest off 59.
But then, you probably weren't supposed to know about that back then, so I guess the space program is a start.
I've hit the karma cap.
^_^
BTW, I also agree with Hyperion as well.
In particular, linux, in a lot of ways, sucks too. As a technological feat, it cannot be ignored. But it has a long way to go. In particular, it saddens me that linux is mostly focused on pulling in support for various technologies and standards and not too much else. That and tin-foil-hat patches.
Why can't we be the ones deciding where we want it to go next? There are all sorts of weird ideas I'd love to see come to linux that aren't just copies of whatever else someone is doing. It would give it a distinctive flavor and make it an OS with its own merits (besides a philosophy and widespread nerd tolerance).
Also, I like the idea of ReactOS myself. Its not like software vendors are just going to stop making software compatible with NT 4.0 API next year; they probably aim for that as a target system, with NT5.0 as a convienient superset. So if it gets a gui soon, it will be eminently useful for a small group of NT d00dz. Plus, imagine what insights these programmers will gain after having to hack together a system that is modeled after the OSF3/win32 architecture. If they don't go insane, I imagine great things to come from a group who could manage that.
(please don't mod me down, oh please don't mod me down brer fox)
I like 'em both.
;-P )
:-(
NT and linux, who'd thunk it!
I like NT because it is probably the most "predictable" OS you can find; each installation is basically the same, especially within a company. Any changes are superficial, all you need to know is a few key version and service pack numbers and you've got a clear picture of the state of things.
It is remarkably stable, especially if you don't buy crappy hardware. Because it hosts most of my favorite apps and games, I can live with myself having a few copies (legitimately, but not out of my own pocket...
And I like linux because when you have to get dirty with interfacing hardware, and no clear solution exists, you look to the source. I've had to do this too many times, and linux comes and saves my ass with bits and pieces scrounged from hither and yon, duct-taped up with perl, and boom, you have your custom widget for whatever-the-fuck was needed in a weeks time. My latest project: Palm Pilot m130 + otherwise useless P133 Dell Latitude = OGG player with IR remote for the car! w00t!!
Plus, I like being able to squeeze the last bit of performance out of machine, and knowing its operation front to back. It makes me feel safer when deploying a critical service; being able to feel confident it will stay up, and if it fails, I can diagnose it quickly because of said transparency. Linux, when set up conservatively, can take a huge beating. I've had servers with half-bad RAM and frayed SCSI cables stay up and limp along until I checked the logs... (MEDIC MEDIC!!!)
So what about linux leaves you with such a bad taste in your mouth?
Interstingly enough, that quality is shared by another less free system: Solaris. The documentation is incredibly thorough; so good, up to the point of throughly recognizing and explaining its own shortcomings (NFS RPC, etc.).
I wish Sun was more forthcoming with hardware docs. Alas, this is how they make their money.
Degauss:
:-) Just kidding.
Here is my thinking. This is your HOME machine. But you make it sound like this will be in a place where it will be exposed to a lot of people who have no business using it, or are desperate to break in.
I mean, are your siblings or spouse wanting to use your PC that badly? Are they after your porn stash?
Or is your password that easily guessable... that is something you can fix without resorting to clever software that only belabors the authentication via obfuscation.
Even if it wasn't under attack, obfuscating the login screen is not really a good idea. All the malicious user would need to do to discover the secret is casually observe a legitimate user bypassing said fake login screen.
Moreover, your login program should not allow someone to sit at the computer all day and attempt passwords. It should lock unprivledged accounts out after a few wrong tries ( 5, preferably 3). If it does unlock itself, the cool off period should be at least an hour. Also, each attempt should take progressively longer to check after each failure. This is especially important for Administrator / root accounts which should not lock themselves out.
They often mistake nervousness (embarassment that you've been asked to step aside for an "interview" in the airport), vs. outright fibbing.
I have observed that many of the tests of these devices involve studies where the subjects are encouraged to fool or beat the machine and they base their results on that. However, the subjects are probably already familiar with the tests and are (I imagine) not in fear that something bad will happen to them if they fail.
In the case of the proposed settings (airports, police station), failing this lie detector test could lead to Bad Things. I wonder if these machines pick up the facial features that arise when "the subject is making an attempt to provide a satisfactory response" and THIS mental activity causes the facial feature changes the trained AI responds to.
I suspect the AI was created by evolving a neural net based on human trials (2-layered? -they even mention that it monitors 24 channels; this wouldn't take too long to evolve). Hence it is trained to the testing conditions, and these premises of what they are testing, and/or the methodology of the training may be incorrect.
Maybe the question really is: do we care that the device may be responding to mental stress vs. truth/lie telling? Some might consider it more useful that it just measures stress (which in a question and answer session can be caused by fabricating responses). It could indicate when someone should have a "bad feeling" about someone or their claims. At the same time I feel that if my allegations are true, this device also should (in addition to standard polygraphs) not be used to generate evidence for trial proceedings.
Anyone with more insight into this care to add?
There would be sets of matricies that represent that probabilities of state changes, each tied to some internal state (word boundaries?). I imagine these numerous matricies are also very sparse, or that the matrix is updated through some sort of word->word transformation.
I doubt that the a static markov predictor would suffice for guessing phonemes, because it would provide you with too many equiprobable phonemes in your output vector; I (believe) phenomes are close to equally distributed over all speech.
FFTs are used of course to split the voice into energy bands, which are then used as to distinguish the phonemes with varying certainty. It would seem you can't do jack in signal processing without the FFT (unless you can waste CPU time doing a whole buttload of correlation and filtering)