Re:A bad workman blames his tools
on
PHP and SQL Security
·
· Score: 2, Insightful
No, you are missing the point. magic_quotes_gpc is a handy safe-guard for newbies, most of whom will be using MySQL. The downside is some errant slashes that may be annoying, but are far less dangerous.
So you're saying it's a language feature aimed at helping newbies producing mediocre code.
magic_quotes_gpcis dangerous, in that it confuses said newbies horribly about a critical issue. They may be producing mediocre code where they would have been producing bad code, but it will lengthen the time until they learn to produce good code. Or maybe prevent them from ever doing so!
When newbies see words like "magic quotes", they may think "okay, everything's quoted and safe". When it's not nearly so simple.
A feature intended to help people mix untrusted data into SQL statements suggests that it is a good practice to do so. It's not! It's much better to use bind variables.
It increases the operating modes a program executes in. Take a look at this bit from the get_magic_quotes_gpc section of the manual:
They're promoting the idea of having the same program work in both modes. Do you think people extensively test both? It would be much better to say "loudly fail if your program is not run in the expected mode". Hell, they're not even doing this in a general function; they're proposing doing that for each variable reference! That's stupid! People will inevitably write code that works in one mode or the other. Seeing this pattern elsewhere in the code will falsely lead people to believe the entire thing works in both modes.
With this "safety" feature on, truly safe code would be much more complicated than without, and this is never stated in the manual. The correct way before was to "escape stuff in way X right as you use it in way X". Now it needs an addendum: "except if it's from a GET/POST string and it's to a MySQL or PostgreSQL database literal. and when you use GET/POST strings for anything else, strip off the slashes first." That's complicated enough that a newbie may never learn the correct way of doing things in any mode. They'll always think it is too complicated to really understand, always be tinkering, and always screw it up.
it makes people have some data floating around that should be treated quite differently depending on where they got it. If they get it from the database, it's not escaped in a similar way. Do you think they'll keep rigorously keep track of every string being passed around and state and follow a contract for how each function's arguments should be quoted? (And yes, there are valid reasons for getting something from the database and sending it right back.)
By the way, you mentioned stripslashes. I'd argue that any use of stripslashes means that you've screwed up and escaped something badly. If something has slashes, it's intended to be parsed through a layer that mixes strings and some higher-level construct. So when you strip them out, either:
you're writing a parser that doesn't know the length of the string until it's done. It'll be appending to the string as it goes. stripslashes doesn't help.
you've got something escaped in the style to send it through a layer you actually aren't using. You're escaping something at the wrong place in your code. If you haven't already screwed it up and introduced a security problem, you soon will, because your function's contracts are too confusing.
Most people are attempting to solve cross-site scripting and SQL injection vulnerabilities (the #4 and #6 causes of web security problems, according to this article) through brute force. Everywhere they use these, they use an escaped version. But this approach doesn't work! For several reasons:
it's hard to notice when something is not there.
people tend to push these farther and farther away from the actual usage, so they get confused about what has been escaped. It's hard to maintain clear contracts between functions about something like this.
even if you're diligent when writing the initial code, it's easy to slip when applying patches
So I think a new approach is needed. One where you don't mix instructions and data so easily, or flag them more readily.
With SQL, this has been around for a while: bind variables. Your SQL queries tend to be static with ? thrown in (or:foo for named bind variables). In Perl, it looks like:
my $sth = $dbh->prepare('select * from mytable where foo = ?'); $sth->execute($foo);
Not everyone is using bind variables, and I don't know why. One reason may be that positional bind variables can be confusing: they require you to correlate two lists in your head to position the correct variables in the correct spots. Not all language/database combos support named bind variables. (JDBC doesn't!) But they can be emulated - that's one reason I made xmldb.
For HTML, it's more rare to find something that does this. Apache Cocoon does, but it's grotesquely complex. I'm working on a simpler system, though it's not ready for production. Here's the idea: my files (XFP) are to a SAX ContentHandler as JSP is to a byte stream.
I like SAX because it's a way of making XML that does things right. Instead of doing something like:
it's nice in that you don't do any of the escaping yourself - you just tell it how you're using each string, so it can do the escaping right.
But that's six ugly lines instead of one, and it's worse with real SAX because you need extra arguments for namespaces and things.
So I looked at JSP. It sticks Java code inside the text to produce. I stick Java code inside the XML to produce. I write something like this:
...and it turns it into the code above when it makes a.java file. It still knows how to escape things from context. And whenever you stick in literal text, you can write it just like you'd normally write XML - less long-winded. I might change it to this:
<elem a="{foo}" b="blah">Blah: {bar}</elem>
which is shorter still.
My code is all Java. But the concepts should apply to PHP, Perl, Python, anything.
Anyone else working on a system to solve this problem? I'd be interested to share ideas.
Re:A bad workman blames his tools
on
PHP and SQL Security
·
· Score: 3, Informative
Indeed, by default, PHP comes with gpc_magic_quotes enabled, which prevents the more obvious SQL injection attacks. Of course, nothing is 100% foolproof, but we're nowhere near the sieve that ASP+Sequel Sewer is.
No, no, no, no, no!
magic_quotes_gpc is totally broken. For those unfamiliar, it escapes all HTTP GET and POST strings MySQL-style. But this is stupid. How you want your strings escaped (if you do at all!) depends on where you are sending them to, not where you are getting them from. Consider these things you might be doing with the strings:
using in a database statement (DML or query) with bind variables: no escaping. (This is the best way to use these in SQL!)
sending them out as character data in a HTML page: escape & to &, escape < to <, and (when in an attribute, harmless otherwise) escape " to "
using in a MySQL or PostgreSQL literal: that way is actually correct
using in a MySQL or PostgreSQL identifier: that might also be correct? not sure. certainly " needs to be escaped, though.
using in a standard SQL literal: ' needs to be escaped to ''. \ should not be escaped.
using in a standard SQL identifier: " needs to be escaped to "". \ should not be escaped.
PHP has a shiny red button that you never want to press. This is one of many reasons that I say PHP is a broken tool.
Mr. Oram's long-winded screed on MySql, while interesting, really makes the situation sound much more complicated than it is. You don't need to over-analyze this thing. The truth is simple and readily clear to everybody already.
In a nutshell, MySql is free. Is it great? Hell no, but it's free. The only deep understanding of human nature or the DB marketplace one needs to comprehend here is that given the choice between something great and expensive vs. something mediocre and free, the overwhelming majority will go for free.
It's not that simple. If it were, everyone would be using PostgreSQL instead of MySQL. It's free, and it's better.
I think the big reason is marketing. MySQL people are really good at that. The PostgreSQL people are learning, but there's still a ways to go. Also, PostgreSQL doesn't work natively on Windows; that's one of the features they hope to have Real Soon Now.
There's also a huge misconception that MySQL is much easier to install than PostgreSQL. The process seems exactly the same to me. I don't understand at all why people think this.
> > Guys, it's time to face the facts. C is a relic from a time when compilers were stupid. Declare all your variables before executing code, declare all your functions before using them, include headers that almost invariably break one another, hurrah.
> > I'm so glad that every time I write C I get to write each function signature several times, that's lovely. In addition, C takes much more time to compoile than Java/C# because all the stupid headers take forever to parse.
> What will you use for your low level device drivers? Or how about that code that needs run fast?
You're complaining about the virtual machine aspect of most high-level languages (not D). And the garbage collector of most high-level languages (including D). You haven't addressed his criticisms of C at all. (And how could you? He's absolutely right.)
If this is your only concern, you could easily come up with a language (D-, maybe?;) that is like D except that it has delete instead of a garbage collector. And then implement smart pointers as in C++. It would have none of the deficiencies of C/C++ that the grandparent mentioned.
Yeah, "real" programmers keep on coding in C++...they press on despite:
...a high incidence of memory management related problems, which are often very hard to find
That's true of older C++ code. But now there are very good smart pointers classes. I just don't have these sorts of problems anymore. At most, I get an unexpected NULL, which immediately causes a SIGSEGV - not so different from Java's java.lang.NullPointerException.
...common security issues, often involving buffer overflows
You can screw this up in C++, so languages like Java are arguably more secure in this fashion. But C++ is not C. It's easier to do things safely than to screw them up.
...compiler incompatibilities, including frequent lack of proper template support, exception handling, namespaces and so on
True, but getting better.
...obscure and often terribly non-intuitive syntax
True.
...overly complex and redundant idioms necessary to work around language shortcomings
I've never found a situation where I actually required the additional functionality that multiple inheritance allows and coudn't be done better with just interfaces.
How about StreamSocket. Okay, multiple inheritance isn't required in the strictest sense, but object-oriented programming isn't, either. MI makes this class make much more sense - it is both a stream and a socket.
In a language providing only support for multiple interfaces, you'd have to reimplement at least one of those in the derived class. You'd probably end up just dispatching all of the calls in the derived class to a shared implementation elsewhere. Not nearly as clean.
Or you could pull a Java and have a getStream() method on the StreamSocket. (Make the caller do the dispatching to the shared implementation.) I don't like it either.
Plus, if you were gonna copy multiple inheritance from c++ you'd need to copy all those nasty casting operators.
I don't see how eliminating MI makes any of them unnecessary:
static_cast<> - still useful. I like saying "make it an error at compile-time if this can be false". Catching errors earlier = more goodness. C didn't have this, but C didn't ever have a way of knowing one structure could be cast to another safely, since it lacked OOness (inheritance, specifically). Also better performance than a dynamic cast.
dynamic_cast<> - yup, still useful. A little simplified (it would always return the same actual address or NULL). This is basically what Java's cast is.
const_cast<> - nothing to do with MI. (Nonexistant in Java because Java doesn't have constness at all.)
reinterpret_cast<> - nothing to do with MI. Necessary for backwards-compatibility with C stuff.
The counterargument to my counterargument is that by burning & re-ripping you are losing quality
I agree with this counter-counter argument. Particularly with classical music, the quality loss is nasty. I bought Carmina Burana off the iTunes Music Store. Do you want to listen to that through two rounds of lossy encoding?
the counterargument to this counterargument of my counterargument is that if you were enough of an audiophile to care about this, you wouldn't be buying 128K mp4s from iTMS anyway.
That counter-counter-counter argument is bunk. 128K.m4a's are good quality. But when you take a.m4a file, and re-encode it to any lossy format, it's worse than some crappy.mp3 you found on <insert-trendy-P2P-scheme-here>. You could save the ripped file in a lossless format, but then you're using a lot of space for no benefit. Enough so that it restricts your use of a lot of portable music players.
I'm a big Apple fan, but they really screwed up with FairPlay. I have an expectation that I can play my music on my Linux box, on my roommate's TiVo, on any brand of portable music player[*], etc. That's true for all the music except the iTunes Music Store stuff. It's less valuable to me because of their DRM. The VLC people and PlayFair people worked to remove these restrictions, and Apple sued them for it. Suck!
Besides, I have philosophical objections to ever having even a single line of code that I pay for not be there to serve me. When I write software, every line is for the customer. Some they may never actually interact with themselves (debugging code), but it's all there to make the customer's experience better. That's one reason I like open source - if they put extraneous code in, people will rip it out.
[*] - I have an iPod, so I actually can listen to FairPlay music on it. But it's the principle. I shouldn't have to buy the Apple hardware for this. They should compete on merit. This is a Microsoft-like tactic.
Protons and neutrons are, but electrons are not, they're fundamental particles (as far as our current knowledge goes, anyway).
Or do I remember it all wrong?
No, you're right. Did you read the part about not posting at 4AM? I should be sleeping now. Imagine I said "protons are composed of quarks" instead.
All that said, not all particles are sub-atomic particles. The particles of potato-chip at the bottom of my bag are not sub-atomic particles.
Each bit of potato chip is composed of many sub-atomic particles. You're abusing the word "particle". Look at the physics definitions at dictionary.com:
3. Physics.
a. A body whose spatial extent and internal motion and structure, if any, are irrelevant in a specific problem.
b. An elementary particle.
c. A subatomic particle. See table at subatomic particle.
(a) is just describing approximations used in problems. It's like saying "massless rod". No such things exist, but in many problems the effects of a rod's mass are so small that we can safely ignore them. And we do so, for the purpose of easier math.
What's left are subatomic particles. (elementary particle = fundamental particle = subatomic particle. #2 and #3 are mutually redundant.)
Likewise, nutrinos and photons, while they can pass through atoms and collide with or originate from them, are not subatomic particles. Aside from light being massless, photons are not sub-atomic particles because they are not "glued" inside an atom by electrostatic forces, strong nuclear forces, weak nuclear forces, gravitational forces, or any other kind of force.
Consider this definition of subatomic:
Of or relating to particles that are smaller than an atom.
It doesn't require anything about being a part of an atomic or interacting with one in any way. Just being smaller. And even photons have a "size" (or something that can be used as one - a range of positions that constitutes the bulk of a photon's probability function). Actual sizes vary (what kind of atom? hydrogen? uranium?), but I think it's reasonable to say photons are subatomic.
AFAIK, all particles are subatomic. "elementary", "fundamental", and "subatomic" when used as adjectives to "particle" just mean that someone is using the proper physics definitions. And not the colloquial English ones or the physics approximation definition.
Funny, you don't see all those paragraphs of justification follow a Windows BSOD joke...
You're right, and do they apply to Windows.
On the other hand, it's a lot harder to get something fixed with Windows. It's not much comfort that you're only hitting one bug over and over if it's not getting fixed anyway.
I think Microsoft does have a crash reporter now, though. You send in your crashes to some website and it tells you what caused it. Don't know if that translates into actually getting it fixed or not, and I can't seem to find the site now.
I love the speed increases that the 2.6 kernel has achieved on the desktop (and for things like media: mplayer never bugs out with that charming "YOUR COMPUTER IS TOO SLOW" message anymore). However, I don't know if it can be considered even remotely stable. Since switching, my uptime has been a Windows like joke.
[...]
- Firewire and sbp2 support is completely broken. Ironically this has, I believe, more from "experimental" in 2.4 to a normal feature, yet it worked fine before and now doesn't work at all (the linux1394 forums forums reflect that I am not alone in this). Trying to copy data to sbp2 drives segfaults, hangs, and worse. Beware of connecting to 2.6 if you have a firewire drive with data you hold dear...
It's important to keep some perspective. Usually whenever anyone says something is full of bugs, they mean that they keep running into the same bug over and over. If you're having problems with Firewire, very likely you're running into one bug in your driver repeatedly. The other people complaining may have the same chipset and the same problem.
My point is that you can't make any generalizations to the entire kernel series (or even subsystem, like 1394) being more or less stable just because you encounter a single bug that you didn't used to. Look more closely at the oopses and your system logs, see where it's happening, file a good bug report. They'll probably have it fixed in a couple releases.
People use "stable" or "unstable" to mean a lot of different things:
If they're changing the APIs constantly or not.
If the core of the system doesn't crash and performs well under a variety of loads
If their system doesn't crash and performs well under their load
...and #3 really needs to be qualified with "for me" or "with this exact hardware, doing this". Because otherwise, you're saying the whole series sucks because of a single bug. And very likely, a bug in a driver. When I read kernel traffic, lwn, or kernel trap, I frequently see mention of fixing some unsafe coding practice...in the core kernel. Drivers are left for their maintainers to update. Some do so quickly and well. Some don't.
Ideally, a system would be so rock-solid that you would never run into even one stability or performance bug. But I don't think that's much more realistic for Linux 2.4 than it is for 2.6.
(This message is not just aimed at you. I see this a lot.)
Lumpy wrote:
in other words, every company out there that uses KDE legally needs to buy a QT license???
Otter replied: You're assuming wrong. This has to do with QT development -- ie, you can't develop proprietary internal apps with the free Qt version. As opposed to the GPL which only deals with release. (Apple has similar restraints on using modified Darwin internally.)
I don't think that's right either. Qt is available under two licenses:
the GPL. (Qt/X11 only.)
a more permissive licenses that costs $$$ per developer. (All Qt versions.)
...and the big thing with the GPL is that you application can only be distributed under its terms if it's based on any GPL software (including Qt/X11).
That's not a problem with internal applications. They're not distributed at all. Thus, you can develop internal apps against the GPLed Qt/X11. No money required.
Where you do need to buy a license is if you are doing any of these things:
distributing a Qt-based application without source code. (violates the GPL)
distributing a Qt-based application without allowing your users to redistribute it. (violates the GPL)
distributing a Qt-based application there are patents on, unless your users are unconditionally granted usage without charge. (violates the GPL)
developing an application against Qt/Windows, Qt/Mac, or Qt/Embedded. (Even if you're not distributing it.) (These versions are not available under the GPL at all.)
Of course, you should read the GPL yourself, where the terms are stated much more precisely.
1) It's not in Word format. Why not?
Not everyone can afford Microsoft Office,
although everyone can afford Open Office.
If they had used their own tools, it would have been Microsoft Publisher. It's the QuarkXPress wannabe. Even Microsoft would tell you that Word isn't the right tool for making this sort of document.
Greger47 said: VALUES is a table constructor; interleaving identifiers and literals only makes sense if you're inserting a single record.
I said: No, it's not. insert values (...) and insert (...) values (...) always insert a single record. values does not occur anywhere else in SQL, AFAIK.
Greger47 replied: Nope, you can insert multiple records with one statement, the syntax is: insert into foo (x,y,z) values (1,1,1), (2,2,2), (3,3,3),...
Requiring tuples' values to have (valid identifier) names would take SQL even further away from relational algebra, and who knows what other changes in the language would be required to ensure that every value has a name.
What I proposed was solely a syntactic change. Every column in the table already has to have a valid identifier. My modified example just has the column name and associated value closer together; they were both there in the original case. (I'm talking about the insert into mytable (foo, bar, baz) values (:foo,:bar,:baz) case here.)
I would not take away the syntax in which you do not need to specify the column names at all (insert into mytable values (:foo,:bar,...)). I never use it myself (for similar reasons), but I don't see a need to eliminate it.
VALUES is a table constructor; interleaving identifiers and literals only makes sense if you're inserting a single record.
No, it's not. insert values (...) and insert (...) values (...) always insert a single record. values does not occur anywhere else in SQL, AFAIK.
DBI's encouragement to use dynamic SQL to prepare the same statement over and over is dumb. Perl should support embedded SQL (which uses the:name syntax to access any language's local variables) instead.
I don't like the embedded syntaxes. I prefer an external query library, as provided by my xmldb project. SQL is different enough that I think it should not be lumped in the same file, for maintenance reasons if nothing else.
xmldb also provides a form of named parameters, internally using the ? placeholders. I'd like the JDBC people and all the vendors to support the named syntax, but this way I can use something similar right away.
Re your parameterized view, it seems like all you need is...
Check your query again. It would return (for each group) all records if and only if they are all on or before:some_date. I'm looking for one that (for each group) returns the latest record on or before:some_date.
Views only exist for access control or optimization of frequent queries.
Those are good reasons, but convenience is important, too.
Can a parameterized view do anything that a subquery on a normal view doesn't?
There are sooo many general programming languages but only one database access languages: SQL?
There are more than that. Here's one: Xplain. That page describes a converter to SQL, so you can write Xplain queries and make them against a standard DBMS. I don't know much about this language, as I just learned of it recently.
There are many others which are not based on the relational model. It's difficult for me to take them seriously, as the relational model is so powerful.
SQL is so old, it hurts. It's basically COBOL.
I don't care how old it is. What's wrong with it?
By "is basically COBOL", are you complaining that it favors words over symbols? I do not find this to be a problem. My SQL queries are short enough and a small enough part of the whole program that I prefer the clarity over any additional possible terseness. COBOL is different in that whole programs are written in it.
If I were to make any complaints about SQL, they would be:
null lumps together "unknown" and "inapplicable". For this reason, a lot of people find the comparison rules for "x == null" and "x null" confusing. If these were separated, I think more logical behavior would be possible. (Dr. Codd, the relation algebra guy, proposed having multiple types of null at one point.)
it requires you to match up pairs of lists in several situations:
insert into table (column_a, column_b, column_c) values (value_a, value_b, value_c) ...which looks okay there, but gets hard when you have too many columns to fit on one line. Versus insert into table (column_a => value_a, column_b => value_b, column_c => value_c which is always clear.
insert into table (column_a, column_b, column_c) select 'foo', 'bar', column_c ... versus insert into table select 'foo' as column_a, 'bar' as column_b, column_c ...
$sth = $dbh->prepare('insert into mytable values (?, ?, ?)'); $sth->execute($foo, $bar, $baz); versus $sth = $dbh->prepare('insert into mytable values (:foo,:bar,:baz)'); $sth->execute(foo => $foo, bar => $bar, baz => $baz); I think the placeholder syntax is not actually specified by the SQL standard, but it should be. The '?' syntax is dumb. The named syntax should be mandatory. In most DBMS/API combinations, only the '?' syntax is available.
there are no parameterized views. I'd like to be able to do something like
select * from latest_chronological_v(some_date) where...
instead of the
select * from chronological_table where date <= some_date and not exists ( select 'x' from chronological_table later_entry where later_entry.group = chronological_table.group and later_entry.date > chronological_table.date)
that I need now to do whenever date is not sysdate. (I believe SQL-99 has something like this, but it's not implemented in PostgreSQL or Oracle.)
I read your post, but didn't mean to contradict your point. Rather, I meant to further a related point: The default "friendly error message" being sent out was an after-the-SMTP-conversation email that was generated by the virus-filter engine. These emails are not part of the SMTP conversation and therefore does not bounce back as part of the conversation nor appear as a "postmaster" response. These are therefore viewsed as spam...probably because the email also suggested using their product to fix it. [...] Agree?:-)
Agreed. Those messages are neither solicited (by the person they're actually sent to) nor helpful, so they're definitely junk. And since they do mention a commercial product (or even suggest buying it? that's bad), I see the argument for calling them spam.
Am I the only slashdot reader who rankles at our editors' lack of good English?
It bugs me, too. I saw this one in the subscriber-only preview, but I did not point it out to them because the idea of paying to be a proof-reader does not sit well with me. So I'd rather publically mock them later.
Ferchrissakes, folks, read Strunk and White -- it's online these days.
I hate that guide. They should have followed their own rules, particularly "Omit needless words". Look at this paragraph:
In general, however, it is best, in writing, to avoid using
so in this manner; there is danger that the writer who uses it at all may use it too often. A simple correction, usually serviceable, is to omit the word so, and begin the first clause with as:
The same thought could be much more clearly expressed by:
Avoid overusing
so. Consider omitting it and beginning the first clause with as:
They also seem comma-happy:
Divide words at line-ends, in accordance with their formation and pronunciation
Why is that comma there? There's no parenthetic expression, "in" is not a conjunction, and there's no "when" in that sentence. I'm also intuitively suspicious of it because when I say the sentence, I don't pause there. I assert that it's wrong.
My point here is that I had the "friendly error message" enabled, saying something like "Hey, you sent a virus and you may want to check your computer." Unfortunately, there was probably such an abundance of these unsolicited email replies (i.e. those who received these notices were the spoofed folks who didn't actually send the email)
Please read the rest of the message you replied to; it addressed this problem in depth.
Try telling that to someone who has received thousands of bounces because some idiot mail server admin decided it was a good idea to send bounces to mail addresses that have obviously been forged.
Someone like me?
You read my message with blinders on. I noted this exact problem and said that it was unacceptable to bounce messages for this reason. It takes a peculiar set of circumstances for a virus email to bounce because of me - the virus sending it through an intermediary SMTP server (which I think only happens if there's a transparent SMTP proxy; quite rare) which doesn't catch the virus itself, and then bounces the message on 5xx failure sending. And those rare ones do not all flood the same person, as the virus selects random addresses to forge. So I think this is acceptable.
You're complaining to the wrong person. Go talk to one of those antivirus companies that consistently send worthless replies like "you sent us this exact virus, which we know forges senders."
Btw: I thought that it contradicts the SMTP standard to reject messages after the DATA portion
It violates a SHOULD in RFC-821 for it to fail under these circumstances:
The DATA command should fail only if the mail transaction was incomplete (for example, no recipients), or if resources are not available.
...but as the hyperlink notes, there can be valid reasons for not following a SHOULD. Besides, RFC-2821 (which obsoletes RFC-821) explicitly allows this case:
or if the server determines that the
message should be rejected for policy or other reasons.
It's standard practice to do this with Postfix, and presumably with other mailers.
this would mean that the direct-connecting clients could do anything when being told that the message was rejected -- including silently dropping it -- and still be standards compliant!
Absolutely not. Even with a strict interpretation of RFC 821, they have to allow for the case where the receiving MTA does not have enough available resources to store the message.
The first time my ISP has a false positive and blocks a legitimate email, I'm going to be pissed.
This is probably why they don't do it - they can't risk false positives.
False positives aren't that bad if you handle them well. The trick is to never silently discard an email. It's much better to send a friendly error message like:
"Appears to be W32/Sobig virus. If this is a legitimate message, please change the subject line and resend." (They can easily do so.)
"Attachment name "$1" ends with ".$2", which I've disallowed because of worms filling the mail queues. Please arrange an alternate way to send this file." (If nothing else, they can send an email saying 'tried to send you a ZIP file; it didn't work' and I can temporarily relax the rule.)
I do this with a 5xx rejection during the SMTP session. So what happens is:
if their client connects directly to my mailserver, they get an error message before the compose window has even gone away. They can make the necessary changes and resend easily.
if their client connects indirectly, the other mailserver will generate a bounce from this message. The sender will get their original as an attachment, so they can modify it even if they don't keep sent messages.
if a virus or worm connects directly (the most common case), it receives an error message and gives up. No bounce is sent to the owner of the "From" address. That's good because the address is forged; said owner has nothing to do with the infected machine. No point in filling their mailbox with bounces.
if the virus connects indirectly, the owner of the "From" address does get a bounce. Undesirable but not devastating. This seems to happen rarely. Maybe only when there's a transparent SMTP proxy along the way or something.
Of course, if everyone were using an intelligent editor, then moronic conventions like Hungarian wouldn't be necessary, because your editor could instantly tell you the type of any variable and perhaps display it in small letters above the variable name at all times.
That's what I mean by annotations. Are you saying that you know of an existing editor that does this? Hmm. I'm still using vim. Maybe I need to look around at other editors again. I'd like one that:
is relatively lightweight. I like to go to the commandline and type "vim blah" and have it instantly pop up. I don't like the emacs attitude that you do everything within the editor.
Can decouple what I see, type, and store in interesting ways. (Which requires knowledge of the languages I edit: C++, Java, Python, XML (XSLT, XHTML), SQL, etc.) Ways like syntax highlighting, smart indentation, folding, completion, annotations, etc.
has some economy of movement like vim. I love that it doesn't require me to move between the keyboard and mouse often, and that it doesn't require me to contort my fingers in bizarre ways (emacs)
supports collaboration features (like SubEthaEdit).
is configurable: I can tell it style conventions for various projects, templates for new files in those projects, etc.
I've yet to find anything that does all of that. vim is the closest I've come.
it should be easy to strip off the type prefixes when editing code (for those who don't like them) and add them back, since they can be automatically determined from the variable's type.
That's a good idea. More generally, I think we should be using editors (or IDEs) which know more about the code we are editing. In addition to the completion features (that Eclipse has, for example), they can add annotations like this. We can remove the implicit assumption that what we see, type, and store should be exactly the same.
Slashdot Mirror
So you're saying it's a language feature aimed at helping newbies producing mediocre code.
magic_quotes_gpc is dangerous, in that it confuses said newbies horribly about a critical issue. They may be producing mediocre code where they would have been producing bad code, but it will lengthen the time until they learn to produce good code. Or maybe prevent them from ever doing so!
By the way, you mentioned stripslashes. I'd argue that any use of stripslashes means that you've screwed up and escaped something badly. If something has slashes, it's intended to be parsed through a layer that mixes strings and some higher-level construct. So when you strip them out, either:
So I think a new approach is needed. One where you don't mix instructions and data so easily, or flag them more readily.
With SQL, this has been around for a while: bind variables. Your SQL queries tend to be static with ? thrown in (or :foo for named bind variables). In Perl, it looks like:
Not everyone is using bind variables, and I don't know why. One reason may be that positional bind variables can be confusing: they require you to correlate two lists in your head to position the correct variables in the correct spots. Not all language/database combos support named bind variables. (JDBC doesn't!) But they can be emulated - that's one reason I made xmldb.
For HTML, it's more rare to find something that does this. Apache Cocoon does, but it's grotesquely complex. I'm working on a simpler system, though it's not ready for production. Here's the idea: my files (XFP) are to a SAX ContentHandler as JSP is to a byte stream.
I like SAX because it's a way of making XML that does things right. Instead of doing something like:
you write something like:it's nice in that you don't do any of the escaping yourself - you just tell it how you're using each string, so it can do the escaping right. But that's six ugly lines instead of one, and it's worse with real SAX because you need extra arguments for namespaces and things. So I looked at JSP. It sticks Java code inside the text to produce. I stick Java code inside the XML to produce. I write something like this:...and it turns it into the code above when it makes aMy code is all Java. But the concepts should apply to PHP, Perl, Python, anything.
Anyone else working on a system to solve this problem? I'd be interested to share ideas.
No, no, no, no, no!
magic_quotes_gpc is totally broken. For those unfamiliar, it escapes all HTTP GET and POST strings MySQL-style. But this is stupid. How you want your strings escaped (if you do at all!) depends on where you are sending them to, not where you are getting them from. Consider these things you might be doing with the strings:
PHP has a shiny red button that you never want to press. This is one of many reasons that I say PHP is a broken tool.
In a nutshell, MySql is free. Is it great? Hell no, but it's free. The only deep understanding of human nature or the DB marketplace one needs to comprehend here is that given the choice between something great and expensive vs. something mediocre and free, the overwhelming majority will go for free.
It's not that simple. If it were, everyone would be using PostgreSQL instead of MySQL. It's free, and it's better.
I think the big reason is marketing. MySQL people are really good at that. The PostgreSQL people are learning, but there's still a ways to go. Also, PostgreSQL doesn't work natively on Windows; that's one of the features they hope to have Real Soon Now.
There's also a huge misconception that MySQL is much easier to install than PostgreSQL. The process seems exactly the same to me. I don't understand at all why people think this.
> > I'm so glad that every time I write C I get to write each function signature several times, that's lovely. In addition, C takes much more time to compoile than Java/C# because all the stupid headers take forever to parse.
> What will you use for your low level device drivers? Or how about that code that needs run fast?
You're complaining about the virtual machine aspect of most high-level languages (not D). And the garbage collector of most high-level languages (including D). You haven't addressed his criticisms of C at all. (And how could you? He's absolutely right.)
If this is your only concern, you could easily come up with a language (D-, maybe? ;) that is like D except that it has delete instead of a garbage collector. And then implement smart pointers as in C++. It would have none of the deficiencies of C/C++ that the grandparent mentioned.
That's true of older C++ code. But now there are very good smart pointers classes. I just don't have these sorts of problems anymore. At most, I get an unexpected NULL, which immediately causes a SIGSEGV - not so different from Java's java.lang.NullPointerException.
You can screw this up in C++, so languages like Java are arguably more secure in this fashion. But C++ is not C. It's easier to do things safely than to screw them up.
True, but getting better.
True.
True.
How about StreamSocket. Okay, multiple inheritance isn't required in the strictest sense, but object-oriented programming isn't, either. MI makes this class make much more sense - it is both a stream and a socket.
In a language providing only support for multiple interfaces, you'd have to reimplement at least one of those in the derived class. You'd probably end up just dispatching all of the calls in the derived class to a shared implementation elsewhere. Not nearly as clean.
Or you could pull a Java and have a getStream() method on the StreamSocket. (Make the caller do the dispatching to the shared implementation.) I don't like it either.
Plus, if you were gonna copy multiple inheritance from c++ you'd need to copy all those nasty casting operators.
I don't see how eliminating MI makes any of them unnecessary:
I agree with this counter-counter argument. Particularly with classical music, the quality loss is nasty. I bought Carmina Burana off the iTunes Music Store. Do you want to listen to that through two rounds of lossy encoding?
the counterargument to this counterargument of my counterargument is that if you were enough of an audiophile to care about this, you wouldn't be buying 128K mp4s from iTMS anyway.
That counter-counter-counter argument is bunk. 128K .m4a's are good quality. But when you take a .m4a file, and re-encode it to any lossy format, it's worse than some crappy .mp3 you found on <insert-trendy-P2P-scheme-here>. You could save the ripped file in a lossless format, but then you're using a lot of space for no benefit. Enough so that it restricts your use of a lot of portable music players.
I'm a big Apple fan, but they really screwed up with FairPlay. I have an expectation that I can play my music on my Linux box, on my roommate's TiVo, on any brand of portable music player[*], etc. That's true for all the music except the iTunes Music Store stuff. It's less valuable to me because of their DRM. The VLC people and PlayFair people worked to remove these restrictions, and Apple sued them for it. Suck!
Besides, I have philosophical objections to ever having even a single line of code that I pay for not be there to serve me. When I write software, every line is for the customer. Some they may never actually interact with themselves (debugging code), but it's all there to make the customer's experience better. That's one reason I like open source - if they put extraneous code in, people will rip it out.
[*] - I have an iPod, so I actually can listen to FairPlay music on it. But it's the principle. I shouldn't have to buy the Apple hardware for this. They should compete on merit. This is a Microsoft-like tactic.
No, you're right. Did you read the part about not posting at 4AM? I should be sleeping now. Imagine I said "protons are composed of quarks" instead.
...which is not true. elementary particle = fundamental particle != subatomic particle. electrons are composed of quarks.
Moral of the story: don't post at 4AM.
Each bit of potato chip is composed of many sub-atomic particles. You're abusing the word "particle". Look at the physics definitions at dictionary.com:
(a) is just describing approximations used in problems. It's like saying "massless rod". No such things exist, but in many problems the effects of a rod's mass are so small that we can safely ignore them. And we do so, for the purpose of easier math.
What's left are subatomic particles. (elementary particle = fundamental particle = subatomic particle. #2 and #3 are mutually redundant.)
Likewise, nutrinos and photons, while they can pass through atoms and collide with or originate from them, are not subatomic particles. Aside from light being massless, photons are not sub-atomic particles because they are not "glued" inside an atom by electrostatic forces, strong nuclear forces, weak nuclear forces, gravitational forces, or any other kind of force.
Consider this definition of subatomic:
It doesn't require anything about being a part of an atomic or interacting with one in any way. Just being smaller. And even photons have a "size" (or something that can be used as one - a range of positions that constitutes the bulk of a photon's probability function). Actual sizes vary (what kind of atom? hydrogen? uranium?), but I think it's reasonable to say photons are subatomic.
AFAIK, all particles are subatomic. "elementary", "fundamental", and "subatomic" when used as adjectives to "particle" just mean that someone is using the proper physics definitions. And not the colloquial English ones or the physics approximation definition.
You're right, and do they apply to Windows.
On the other hand, it's a lot harder to get something fixed with Windows. It's not much comfort that you're only hitting one bug over and over if it's not getting fixed anyway.
I think Microsoft does have a crash reporter now, though. You send in your crashes to some website and it tells you what caused it. Don't know if that translates into actually getting it fixed or not, and I can't seem to find the site now.
I love the speed increases that the 2.6 kernel has achieved on the desktop (and for things like media: mplayer never bugs out with that charming "YOUR COMPUTER IS TOO SLOW" message anymore). However, I don't know if it can be considered even remotely stable. Since switching, my uptime has been a Windows like joke.
[...]
- Firewire and sbp2 support is completely broken. Ironically this has, I believe, more from "experimental" in 2.4 to a normal feature, yet it worked fine before and now doesn't work at all (the linux1394 forums forums reflect that I am not alone in this). Trying to copy data to sbp2 drives segfaults, hangs, and worse. Beware of connecting to 2.6 if you have a firewire drive with data you hold dear...
It's important to keep some perspective. Usually whenever anyone says something is full of bugs, they mean that they keep running into the same bug over and over. If you're having problems with Firewire, very likely you're running into one bug in your driver repeatedly. The other people complaining may have the same chipset and the same problem.
My point is that you can't make any generalizations to the entire kernel series (or even subsystem, like 1394) being more or less stable just because you encounter a single bug that you didn't used to. Look more closely at the oopses and your system logs, see where it's happening, file a good bug report. They'll probably have it fixed in a couple releases.
People use "stable" or "unstable" to mean a lot of different things:
...and #3 really needs to be qualified with "for me" or "with this exact hardware, doing this". Because otherwise, you're saying the whole series sucks because of a single bug. And very likely, a bug in a driver. When I read kernel traffic, lwn, or kernel trap, I frequently see mention of fixing some unsafe coding practice...in the core kernel. Drivers are left for their maintainers to update. Some do so quickly and well. Some don't.
Ideally, a system would be so rock-solid that you would never run into even one stability or performance bug. But I don't think that's much more realistic for Linux 2.4 than it is for 2.6.
(This message is not just aimed at you. I see this a lot.)
Otter replied: You're assuming wrong. This has to do with QT development -- ie, you can't develop proprietary internal apps with the free Qt version. As opposed to the GPL which only deals with release. (Apple has similar restraints on using modified Darwin internally.)
I don't think that's right either. Qt is available under two licenses:
...and the big thing with the GPL is that you application can only be distributed under its terms if it's based on any GPL software (including Qt/X11).
That's not a problem with internal applications. They're not distributed at all. Thus, you can develop internal apps against the GPLed Qt/X11. No money required.
Where you do need to buy a license is if you are doing any of these things:
Of course, you should read the GPL yourself, where the terms are stated much more precisely.
If they had used their own tools, it would have been Microsoft Publisher. It's the QuarkXPress wannabe. Even Microsoft would tell you that Word isn't the right tool for making this sort of document.
Greger47 said: VALUES is a table constructor; interleaving identifiers and literals only makes sense if you're inserting a single record.
I said: No, it's not. insert values (...) and insert (...) values (...) always insert a single record. values does not occur anywhere else in SQL, AFAIK.
Greger47 replied: Nope, you can insert multiple records with one statement, the syntax is: insert into foo (x,y,z) values (1,1,1), (2,2,2), (3,3,3),...
I've never seen that syntax before, and it's not allowed by the Oracle grammar or the PostgreSQL grammar.
What I proposed was solely a syntactic change. Every column in the table already has to have a valid identifier. My modified example just has the column name and associated value closer together; they were both there in the original case. (I'm talking about the insert into mytable (foo, bar, baz) values (:foo, :bar, :baz) case here.)
I would not take away the syntax in which you do not need to specify the column names at all (insert into mytable values (:foo, :bar, ...)). I never use it myself (for similar reasons), but I don't see a need to eliminate it.
VALUES is a table constructor; interleaving identifiers and literals only makes sense if you're inserting a single record.
No, it's not. insert values (...) and insert (...) values (...) always insert a single record. values does not occur anywhere else in SQL, AFAIK.
DBI's encouragement to use dynamic SQL to prepare the same statement over and over is dumb. Perl should support embedded SQL (which uses the :name syntax to access any language's local variables) instead.
I don't like the embedded syntaxes. I prefer an external query library, as provided by my xmldb project. SQL is different enough that I think it should not be lumped in the same file, for maintenance reasons if nothing else.
xmldb also provides a form of named parameters, internally using the ? placeholders. I'd like the JDBC people and all the vendors to support the named syntax, but this way I can use something similar right away.
Re your parameterized view, it seems like all you need is ...
Check your query again. It would return (for each group) all records if and only if they are all on or before :some_date. I'm looking for one that (for each group) returns the latest record on or before :some_date.
Views only exist for access control or optimization of frequent queries.
Those are good reasons, but convenience is important, too.
Can a parameterized view do anything that a subquery on a normal view doesn't?
Not sure. Maybe not.
There are more than that. Here's one: Xplain. That page describes a converter to SQL, so you can write Xplain queries and make them against a standard DBMS. I don't know much about this language, as I just learned of it recently.
There are many others which are not based on the relational model. It's difficult for me to take them seriously, as the relational model is so powerful.
SQL is so old, it hurts. It's basically COBOL.
I don't care how old it is. What's wrong with it?
By "is basically COBOL", are you complaining that it favors words over symbols? I do not find this to be a problem. My SQL queries are short enough and a small enough part of the whole program that I prefer the clarity over any additional possible terseness. COBOL is different in that whole programs are written in it.
If I were to make any complaints about SQL, they would be:
values (value_a, value_b, value_c) ...which looks okay there, but gets hard when you have too many columns to fit on one line. Versus insert into table (column_a => value_a,
column_b => value_b,
column_c => value_c which is always clear.
select 'foo',
'bar',
column_c
... versus insert into table
select 'foo' as column_a,
'bar' as column_b,
column_c
...
$sth->execute($foo, $bar, $baz); versus $sth = $dbh->prepare('insert into mytable values (:foo,
$sth->execute(foo => $foo,
bar => $bar,
baz => $baz); I think the placeholder syntax is not actually specified by the SQL standard, but it should be. The '?' syntax is dumb. The named syntax should be mandatory. In most DBMS/API combinations, only the '?' syntax is available.
Agreed. Those messages are neither solicited (by the person they're actually sent to) nor helpful, so they're definitely junk. And since they do mention a commercial product (or even suggest buying it? that's bad), I see the argument for calling them spam.
It bugs me, too. I saw this one in the subscriber-only preview, but I did not point it out to them because the idea of paying to be a proof-reader does not sit well with me. So I'd rather publically mock them later.
Ferchrissakes, folks, read Strunk and White -- it's online these days.
I hate that guide. They should have followed their own rules, particularly "Omit needless words". Look at this paragraph:
The same thought could be much more clearly expressed by:
They also seem comma-happy:
Why is that comma there? There's no parenthetic expression, "in" is not a conjunction, and there's no "when" in that sentence. I'm also intuitively suspicious of it because when I say the sentence, I don't pause there. I assert that it's wrong.
Please read the rest of the message you replied to; it addressed this problem in depth.
Someone like me?
You read my message with blinders on. I noted this exact problem and said that it was unacceptable to bounce messages for this reason. It takes a peculiar set of circumstances for a virus email to bounce because of me - the virus sending it through an intermediary SMTP server (which I think only happens if there's a transparent SMTP proxy; quite rare) which doesn't catch the virus itself, and then bounces the message on 5xx failure sending. And those rare ones do not all flood the same person, as the virus selects random addresses to forge. So I think this is acceptable.
You're complaining to the wrong person. Go talk to one of those antivirus companies that consistently send worthless replies like "you sent us this exact virus, which we know forges senders."
Btw: I thought that it contradicts the SMTP standard to reject messages after the DATA portion
It violates a SHOULD in RFC-821 for it to fail under these circumstances:
...but as the hyperlink notes, there can be valid reasons for not following a SHOULD. Besides, RFC-2821 (which obsoletes RFC-821) explicitly allows this case:
It's standard practice to do this with Postfix, and presumably with other mailers.
this would mean that the direct-connecting clients could do anything when being told that the message was rejected -- including silently dropping it -- and still be standards compliant!
Absolutely not. Even with a strict interpretation of RFC 821, they have to allow for the case where the receiving MTA does not have enough available resources to store the message.
False positives aren't that bad if you handle them well. The trick is to never silently discard an email. It's much better to send a friendly error message like:
I do this with a 5xx rejection during the SMTP session. So what happens is:
That's what I mean by annotations. Are you saying that you know of an existing editor that does this? Hmm. I'm still using vim. Maybe I need to look around at other editors again. I'd like one that:
I've yet to find anything that does all of that. vim is the closest I've come.
That's a good idea. More generally, I think we should be using editors (or IDEs) which know more about the code we are editing. In addition to the completion features (that Eclipse has, for example), they can add annotations like this. We can remove the implicit assumption that what we see, type, and store should be exactly the same.