Airplanes have a rigorous inspection process before each takeoff. This one-person flying machine sounds like a recipe for disaster when the least mechanical failure happens. Plus, there are no wings to save you from free fall!
The propulsion mechanism seems highly dependent on a zero-G environment. It must be tough to do earthbound testing of such a device. Of course, the article was short on details.
Re:Almost as convenient
on
PHP Security
·
· Score: 2
I don't know if you deliberately put no code in your post, but just in case:
Putting no code and leaving the default behavior of PHP does not cause code to see only the expected variables. Any variables a cracker sends by POST or GET can mask non-form variables.
A cracker is not going to have any more difficulty making fake POST variables than s/he would with GET variables. You have essentially the same lack of security as normal PHP.
The JDK is arguably an installation of the Java language. The JRE is just a virtual machine. Some of us like to have it around in order to run the same compiled Scheme code on Linux and Windows.
something that's more in line with the philosophy that/.ers support
There's one consistent philosophy that all/.ers support? Could somebody write it up and put it on a web page? How am I supposed to know what to think if nobody tells me?
A server-side web language can be almost as convenient as PHP without sacrificing security. For example, with BRL you simply declare your input variables, e.g.
[(inputs name email colour quest)]
Then those four variables, and only those four variables, take their values from form inputs. This is less convenient than PHP's default behavior, but more convenient than doing foo=$HTTP_POST_VARS['foo']; over and over. (I'm working on a BRL page today that takes 24 inputs!)
Hopefully PHP will add a similar feature in a future release.
I think you're mistaking supported drivers for included drivers. However, freetds_jdbc is good enough for use with BRL, even though a lot of advanced JDBC features are lacking. It's in production use where I work.
You can pre-build lists of matches by word, but regex is too general a concept. You can't pre-build an index that will help speed up a query based on some yet-to-be-specified regex. There's just no way to do it fast.
[IANAL, but of course you wouldn't go to Slashdot for legal advice anyway.]
There are two questions to ask yourself:
Would a court think that the proprietary code was a derived work based on the GPLed code?
Would the copyright holder think it was a derived work and sue (painful whether or not they win).
To answer question 2, ask the copyright holder. Answering question 1 is trickier. I would hope that they would base a decision on the extent that unique features of the GPLed code are essential to the functionality of the proprietary code, and not base the decision on the technicality of how/when the linking happens. But who knows?
This is why Kawa and BRL have an alternate license: no restrictions if used unchanged. This removes ambiguity about question 1, but might enable GPL circumvention via subclassing. I think exactly how to copyleft Java classes is still an open question.
Keep your goal and your audience in mind. MIT is out to produce computer scientists, not programmers. SICP might not be the best textbook for everybody. However, Scheme's advantages apply to other introductory courses as well, e.g. How To Design Programs.
Your difficulty in the AI course was probably due to the material covered, not the language used. How To Design Programs is even taught to high-school students.
Gooey (if that's the correct name) was opt-in. Smart Tags are opt-out. A lot of users, who can't even use the Back button, won't know how to opt out.
As a consequence of (1), Gooey users knew that they were looking at content that was separate from the web site. Some Smart Tags users will be confused.
The Gooey content was added by users. Smart Tags content is hand-picked by one company.
Gooey advocates could tell critics, "Don't tell me what I can do with my browser!" Smart Tags advocates can tell critics, "Don't tell MSFT what they can do with your customers' browsers."
I know you can do it with current browsers, but when MIT set up its SSL PKI a few years back, some users had a hard time with the series of dialog boxes involved in getting a certificate. We also had to do a lot of work to get certificate support integrated into Lynx. IIRC there was some issue in getting the same server (or was it CA?) cert to work in both Netscape and IE.
MIT solved the transport issue by setting up its own CA server, where you could type a password into a web form and get a cert in your current browser. No problem with having many valid certs, and you could set them to expire in a short time if desired.
The nice thing is anyone can set up a web server that authenticates MIT users, without needing any special private key.
Password-access sites have proliferated so much now that it seems SSL certificate-based authentication ought to make a comeback. Does the book talk about certificates much?
Unfortunately, browser support is the main issue holding back certificates; probably too mundane a topic for his book.
Although I agree with mikethegeek's general sentiments, there are
several points that need correction:
You need to directly address the question about use of the word
"free." It's worth pointing out that "free speech" is used to
describe rights that are not completely unrestricted, e.g. slander,
libel, yelling "fire" in a crowded theatre. The phrase "free
market" is used to describe markets that aren't 100% unrestricted.
The GPL does not prevent a closed-source company in general from
using your code for their own purpose, or even changing it without
sharing their changes from you. They are only required to give the
source to those to whom they give binaries. GPLed code can't
effectively be made part of a closed-source software distribution,
but it can be used for other purposes.
It was looseness in the Kerberos spec, not any particular code,
that enabled MSFT to "embrace and extend" the protocol.
The BSD license does not give you absolute freedom to do with
the code what you wish. You are not allowed to remove the copyright
notice, for example. An extremist definition of "free" does not fit
the BSD license any more than it fits the GPL. However, "free" as
English speakers generally use it fits both licenses.
The GPL does not force licensees to act in a generally ethical
manner. It merely prevents them from restricting certain freedoms
of downstream licensees. There are plenty of other ways to be
unethical.
In The Need for Speed, Jakob Nielsen describes the importance of speed for web usability. Toward the end he writes,
A final recommendation is to use a server that supports HTTP keep-alive: saving the overhead of establishing a new TCP/IP connection for every "hit" cuts latency dramatically. The experienced response time to load a page often
drops to about half by using keep-alive.
Yet most dynamic content systems don't do keep-alive. What have we learned since 1997?
Until proven otherwise, assume any wireless device is sniffable. IR is relatively safe. For RF devices, if the manufacturer doesn't boast about security measures, they don't have any. Even if they have security measures, chances are they aren't strong.
Slashdot Mirror
Do you really think casual users of this kind of craft will have the skill to pull off an auto rotation maneuver?
You're posting a fake link, pretending to abuse sourceforge. Why?
Airplanes have a rigorous inspection process before each takeoff. This one-person flying machine sounds like a recipe for disaster when the least mechanical failure happens. Plus, there are no wings to save you from free fall!
The propulsion mechanism seems highly dependent on a zero-G environment. It must be tough to do earthbound testing of such a device. Of course, the article was short on details.
I don't know if you deliberately put no code in your post, but just in case:
Putting no code and leaving the default behavior of PHP does not cause code to see only the expected variables. Any variables a cracker sends by POST or GET can mask non-form variables.
A cracker is not going to have any more difficulty making fake POST variables than s/he would with GET variables. You have essentially the same lack of security as normal PHP.
The JDK is arguably an installation of the Java language. The JRE is just a virtual machine. Some of us like to have it around in order to run the same compiled Scheme code on Linux and Windows.
There's one consistent philosophy that all /.ers support? Could somebody write it up and put it on a web page? How am I supposed to know what to think if nobody tells me?
A server-side web language can be almost as convenient as PHP without sacrificing security. For example, with BRL you simply declare your input variables, e.g.
Then those four variables, and only those four variables, take their values from form inputs. This is less convenient than PHP's default behavior, but more convenient than doing foo=$HTTP_POST_VARS['foo']; over and over. (I'm working on a BRL page today that takes 24 inputs!)
Hopefully PHP will add a similar feature in a future release.
3G wireless networks have been slower than expected, and I expect this "2.5G" trial to be disappointing as well. High-bandwidth wireless is a tough problem to solve.
I'm sure we're all good cryptics here
Do we really know that /. passwords are more secure than average. Everybody e-mail me your /. password. I'll summarize the results.
Bruce Perens: Don't bother; I have yours already.
http://lwn.net/daily/rh-database.php3
I think you're mistaking supported drivers for included drivers. However, freetds_jdbc is good enough for use with BRL, even though a lot of advanced JDBC features are lacking. It's in production use where I work.
You can pre-build lists of matches by word, but regex is too general a concept. You can't pre-build an index that will help speed up a query based on some yet-to-be-specified regex. There's just no way to do it fast.
Or, at least if they are biased, their bias is usually orthogonal to the issues being covered.
[IANAL, but of course you wouldn't go to Slashdot for legal advice anyway.]
There are two questions to ask yourself:
To answer question 2, ask the copyright holder. Answering question 1 is trickier. I would hope that they would base a decision on the extent that unique features of the GPLed code are essential to the functionality of the proprietary code, and not base the decision on the technicality of how/when the linking happens. But who knows?
This is why Kawa and BRL have an alternate license: no restrictions if used unchanged. This removes ambiguity about question 1, but might enable GPL circumvention via subclassing. I think exactly how to copyleft Java classes is still an open question.
Keep your goal and your audience in mind. MIT is out to produce computer scientists, not programmers. SICP might not be the best textbook for everybody. However, Scheme's advantages apply to other introductory courses as well, e.g. How To Design Programs.
Your difficulty in the AI course was probably due to the material covered, not the language used. How To Design Programs is even taught to high-school students.
You can use Kawa to compile Scheme to JVM bytecodes. It's easy to make use of Java objects as well.
I know you can do it with current browsers, but when MIT set up its SSL PKI a few years back, some users had a hard time with the series of dialog boxes involved in getting a certificate. We also had to do a lot of work to get certificate support integrated into Lynx. IIRC there was some issue in getting the same server (or was it CA?) cert to work in both Netscape and IE.
MIT solved the transport issue by setting up its own CA server, where you could type a password into a web form and get a cert in your current browser. No problem with having many valid certs, and you could set them to expire in a short time if desired.
The nice thing is anyone can set up a web server that authenticates MIT users, without needing any special private key.
Password-access sites have proliferated so much now that it seems SSL certificate-based authentication ought to make a comeback. Does the book talk about certificates much?
Unfortunately, browser support is the main issue holding back certificates; probably too mundane a topic for his book.
Although I agree with mikethegeek's general sentiments, there are several points that need correction:
Yet most dynamic content systems don't do keep-alive. What have we learned since 1997?
Until proven otherwise, assume any wireless device is sniffable. IR is relatively safe. For RF devices, if the manufacturer doesn't boast about security measures, they don't have any. Even if they have security measures, chances are they aren't strong.