MattCohn.com said: > I understood what he ment, even if it wasn't 100% acurate.
Well, it's interesting that your definitions don't match his. So I don't think you do understand what he meant. And I don't either, or I wouldn't have replied to begin with.
InterruptDescriptorT said: >>>> Where, I wonder, would one buy individual parts for a notebook?
It's pretty easy to go to your local dealer and pick up an Athlon, mobo of your choice, some cheap RAM, hard drive, etc. I have to say that I've never seen notebook parts available a la carte like with regular computer paraphernalia.
MattCohn.com said:
> Build:
"Alright. I take the Athlon, slide it in the slot, insert my RAM, configure my drives as slave/master, plug them into the IDE ribbon"......
So clearly InterruptDescriptorT is used to building by that definition.
kfg said: >>> You are used to shopping in stores that cater to people who *assemble* computers, and only stock those things that those people buy.
In the stores that cater to people who *build* computers you'll find everything you need.
...but kfg says he's used to shopping in stores for people who assemble. With components in that store, it's really not clear to me what a store for people who build would have, if not the raw materials to make components.
You are used to shopping in stores that cater to people who *assemble* computers, and only stock those things that those people buy.
In the stores that cater to people who *build* computers you'll find everything you need.
Umm, your distinction is silly. "Assemble" means putting together premanufactured pieces. That's what the pieces of the laptop would be also, unless you are talking about buying raw materials like silicon, gold, oil, etc, designing everything, and fabricating the chips and boards yourself. And refining the oil into plastic. And...
...this is pretty similar to the computer program described in The Jazz by Melissa Scott. A kid stumbles onto a program that can tell him how similar something is to existing works. It goes slightly further - making suggestions also - but the idea is the same. In the book, a major studio uses it for movies.
Not long ago I walked a client several hundred km away through an OpenBSD boot via floppy so he could change his forgotten root password. I don't hear the masses screaming for Theo's head because this is possible.
Oh yeah? Well, They have. In satire of genuinely stupid advisories, I think. Although it's hard to tell the difference between this one and some others I've seen...
Here's an excerpt:
Section 2 [Preface]:
Usually, Team Leet keeps our code and research quite private until we
spew our diarrhea all over your computer monitor. But, what really annoys
us, is when a very big figure in the computer security community lies to the
people who make him who he is. The person I speak of is Bob Dobbs. Bob
Dobbs claims that OpenBSD hasn't experienced a local root hole in the default
install for many years. Yet, during his internal audits, he regularly finds
unfaithfulness to the church, and he never notifies the public. I think you
guys are lame. You have demonstrated sins, transgressions, intemperances,
vices, errors, failings, personal faults, indiscretions, lapses, trespasses,
and crimes agsinst man, woman, child, law, nature and god. What worries Team
Leet is that our servers might be hacked. We have found many other
exploitable holes in previous OpenBSD distributions, that have miraculously
been patched and never revealed. Next, there is the "Three years without a
remote hole in the default install." I hope this advisory breaks that
aswell, because, techinically:
Walk up to the machine
Turn it off
Unplug it
Take it with you
Although we have not confirmed it, we believe this bug is also
exploitable via NFS, RSH, TELNET, and SSH.
> > The point being that chess is a, theoretically, *solvable* game.
> Interesting. Is there a formal proof of this somewhere? I don't recall having seen one.
The algorithm to do it is completely trivial, actually. You just construct a tree with every possible move branching out until completion. (Actually, I think it's a DAG, but that's not really the point.) With the complete game tree, you can basically do anything you want.
Essentially this algorithm has been used to solve simpler games: tic-tac-toe (you should try it; it's not that hard to do, actually), Connect-Four, etc.
However, in our universe it is infeasible to solve chess this way. The algorithm is theoretically perfect, but chess has 10^123 states and our Universe contains only 10^81 atoms. I suppose you could store more than one bit per atom (the number of quarks is greater, and I guess you could manipulate their spins or something) but I think you need to store more than one bit of information per state also...in any case, devoting a significant portion of the Universe to this problem is not feasible. In fact, there might be a formal proof somewhere that this is impossible, based on thermodynamics/entropy calculations.
So if chess is solved, it will be through a different way.
I keep seeing people say that Linux has better hardware support than FreeBSD, but it has not been my experience. In the past year, I've had three machines that Redhat 7.3 and 8.0 refuse to work on. Redhat 7.x installers would choke and the 8.0 installer works but leaves you with an unbootable machine when it finishes. Linux just doesn't get along with the Adaptec AIC-789x controller that was built into the motherboard on these machines. FreeBSD, on the other hand, installs and boots fine without any problems.
That's way too specific to draw a general conclusion from. You say three machines, but really the problem is one hardware device. Overall, I don't think anyone can seriously dispute that Linux has much broader hardware support. And I've had no problems with my 2940UW (which I think uses the same chipset), so it's probably something pretty specific about your devices.
Furthermore, you probably could have gotten it to work if you'd really wanted to. Yes, you shouldn't have to do anything more than going through the installer. But typically people are pretty influenced by their bias in this: if they're surprised that it didn't work (as you probably would be for FreeBSD), they'll go the extra mile to find a patch and/or submit a bug report. And then it will work the next time. If they're not surprised (like you for Linux), they won't do that, and it won't be improved. So it's a feedback loop.
...addressed to "Scott X Lamb" at the "Extensis Sold Me Out" corporation. Seriously. I wish I still had it to take a picture, but it's either gone or hopelessly lost by now.
They get those things from mailing lists from other companies, the same way people get any other sort of junk mail. They don't really know much about the people they send them to; they're just hoping for a response. Ignore it or say "go away" - even if you come to their attention, they still can do nothing. They have no authority to search your property. And even the police would need proof of guilt, not lack of proof of innocence. That's how America works.
Minna Kirai wrote: "But Chinese contains more than 10k characters, many so rare that just 10% of the Chinese population can reproduce them."
kalidasa wrote: "the second figure (percentage of the Chinese population who can reproduce all valid charactes in the Chinese writing system) is almost by definition 0%"
That's a completely different statement. Minna said that there exist characters that only 10% of the population can reproduce. You said no, there are very few, if any, people who can reproduce every character. Both statements could be true, since Minna has not claimed any one person is in all of those 10%s.
You should pay a little more attention to what people are saying before claiming they are wrong.
A bit of preprocessing before gzip should do better than that. How about this? [...] This is completely reversible. Try it and see how well it compresses.
Umm, you try it. Presumably they've spent a lot of time on designing a format. You should take a little bit of effort before claiming you can do much better, especially since verifying the compression of such a simple format should be easy. Making the claim without even taking that much effort is insulting.
Besides, FLAC has important features your format does not. In particular, FLAC is seekable. As anyone who has tried to quickly extract a single file from a large.tar.gz knows, gzip is not.
Re:congestion caused by too much information...
on
Web-based Road Monitoring
·
· Score: 2, Insightful
However, a system which aims to provide better information about traffic congestion to individual drivers can have the unexpected consequence of making congestion worse --- one study by Mahmassani and Jayakrishnan showed that when individuals use a best response strategy the performance of the system as a whole degrades if more than 25% of drivers have access to real time traffic information.
Interesting, but that sounds like a different situation. The traffic congestion is caused by drivers, so the "smart" drivers cause new congestion when they try to avoid old congestion. The drivers don't cause snow/ice, so I don't think the same problem will happen here.
You're not getting it. I know it was a troll - I said as much. I'm angry that the moderators were so stupid as to mod it up. They apparently believed it was genuine.
Please mod the parent down. I don't want to see this crap. I'm surprised people fell for such obviously wrong statements from someone named "eggtroll". I try to refrain from calling people trolls when there's any doubt, but there's none here.
* Ease of use. After about a day I had an excellent understanding of both PHP and SQL. I was able to get a stable, useable and presentable website up within 24 hours of reading the basics of PHP. Learning Perl
took me weeks and I'm still not even as good with it as I am with PHP. I would definitely not recommend anyone new to programming begin with Perl.
That's a nebulous statement. I think Perl is not a hard language to learn. Furthermore, I don't see anything in this post that leads me to believe eggtroll has ever used either language, so this isn't even good anecdotal evidence.
* The OO of PHP is excellent. In my experience, it rivals Smalltalk. We all know that Perl's OO still needs work (whether or not OO is all that great is another discussion.) Hopefully Perl will be patched up so it supports such must-have OO features like introspection, reflection, self-replication and ontological data-points.
Perl's OO support does need work. But it does support introspection. (Reflection is another term for introspection.)
Real problems with Perl's OO: it does not statically check anything. It does not enforce encapsulation. It feels like a kludge in general to me. From what I've been reading of Perl 6, I think it will be much better. I'm looking forward to it.
Self-replication? Ontological data-points? These are not OO terms.
I do not use PHP, but I would be shocked if its OO support rivalled SmallTalk's. You'd need to provide a lot of evidence for me to accept that.
* Outstanding database support. PHP supports virtually every DB under the sun (although Berkeley DB is missing, oddly enough.) Perl seems limited to MySQL and PostgreSQL, and its really a kludge for the later.
I regularly use Perl with Oracle. There are many different database drivers.
* Speed. [...] Its [sic] definitely faster than Perl in almost every case, particularly in regex which has long been Perl's
strongest point.
I assert otherwise. Prove it. In fact, I think PHP uses the PCRE - Perl-compatible regex library, intended to be like Perl's but somewhat less complete.
* Portability. I can take PHP code off my Linux box and plop it onto an IIS server, or even one of those new Macintosh servers and have it run without having to change a single line of code. Try doing this with Perl!
I do regularly, with success.
* Graphics. [...] Perl lacks a graphics library
of any kind.
* Data Structures. [...] Under Perl you're extremely limited in what you can do. This is because Perl isn't OO (so you can't create Node classes, for example, usefull in a linked list) and because it lacks pointers. Some of you may notice that PHP lacks pointers, but look deeper! Behind the scenes, hidden from the user pointers are used.
Perl has references. As in Java, they are essentially safe pointers with automatic memory management (though the GC is less sophisticated). And it does have OO support, at least to the extent required to make a Node class. There is no limit to the data structures possible in Perl.
SWT [...] abandons [...] the idea that the same binary must run on all platforms. [...] Even though the libraries are implemented completely differently, the public interfaces are the same.
Hmm, I can't get the first statement from the second. In Java, you shouldn't ever need to recompile code unless the interface it uses is changed. So a jar you make that uses swt.jar shouldn't need to be recompiled unless it uses JNI itself. No different than AWT.
SWT and AWT both use JNI, so both (the libraries themselves, not consumers thereof) need to be compiled for the appropriate platform. The only difference is that Sun makes AWT, so you can assume that it came with the JVM and avoid distributing your own copy. Probably not a reasonable assumption for SWT.
I wrote: It does not mention the need to prevent them from accessing one interface's IP from another interface.
Blkdeath wrote: It does, however, continue to state the need for a firewall in an effective protection setup;
Sure, but you're not getting my point. It mentions that as "defense in depth"; redundant security. The draft implies throughout that these are totally independent methods. They aren't. It's not just a single poorly-worded paragraph; it's wrong.
I wrote: First, I think it's reasonable to assume that nearly anyone with multiple interfaces will have IP routing enabled.
Blkdeath wrote: Not neccesarily. Sometimes computers are just on multiple networks.
Thus the "nearly". But I can't even think why you'd need to do that in a well-designed network.
I wrote: Second, I'd guess most NetFilter configurations wouldn't stop this. You have to have a rule that denies anything coming in from the external interface for the internal IP.
Blkdeath wrote: That's part of any proper BOGON filter set, or any decent firewall.
I agree, but I'd still guess that most people don't. I often don't see it in tutorials for NetFilters and similar tools, and I imagine it's pretty common to end up with a firewall very similar to those.
If I ever saw someone suggesting it as an alternative to firewalling, I'd call them on it.
Did you read that portwalling draft that berzerke linked to? I quote:
If you could configure your web server (and for Apache it is possible, and not that hard), to listen for connections on only 127.0.0.1 port 80 and 192.168.1.1 port 80, then no one from the internet could send packets to your web server even without a firewall running!
It does not mention the need to prevent them from accessing one interface's IP from another interface.
This relies, of course, on having IP routing enabled on the Linux box (disabled per default) without having the wherewithall to run NetFilter (or another suitable firewall).
First, I think it's reasonable to assume that nearly anyone with multiple interfaces will have IP routing enabled.
Second, I'd guess most NetFilter configurations wouldn't stop this. You have to have a rule that denies anything coming in from the external interface for the internal IP. (Or that denies the service specifically, but then there's no real point to binding to the inside interface only.) Binding only to "safe" interfaces is sometimes pointed to as an alternative to firewalling services, so it's important to point out where that can fail. With the one rule, it works well.
In addition to the firewalling, cups can also be portwalled too (see http://www.spotswood-computer.net/portwalling.html [spotswood-computer.net] for details on this concept). Make sure it's not listening on an internet interface (which it would by default)
That's not necessarily enough. See this email about "weak end host". The short version is attackers can access the IP of one interface through another on Linux unless you go out of your way to prohibit it.
I've had pretty good luck by politely requesting: "Add this number to your no-call list"; so far, every telemarketer has understood this request. Some of them have read me a warning that it will take X weeks to propagate.
The correct response to this is "it had better not" or "sucks to be you then" as the legislation makes no such allowance. They are allowed one mistake per year. After that it's $500/call. Even if the request, the mistake, and the first violation happen in the same day.
Re:Drive reliability/backups are major factors
on
IDE RAID Examined
·
· Score: 2
So, we just build a second mirror raid array on a separate box, tie the two together with point-to-point gigabit, and cron an rsync every evening at 1 AM. It works great and we get the extra protection against accidental deletion and file corruption that comes with tape backups...
Umm...no, you don't. What happens when something happens before 1AM and you discover it after 1AM? That seems not only possible but likely. With tapes, that's easily solved - just rotate your tapes. Plus, it's a lot easier to take them off-site for protection against fire.
Sure. That's the JDBC method for it - there may be a more generic term I don't know. You just prepare an insert/update statement. Then you loop over it and call addBatch() instead of execute() and an executeBatch() at the end and it's faster than calling execute() each time, even within the same transaction. I think it does this by sending them all to the database at once (which I guess the JDBC driver could/maybe does do already; just semicolon-separating them) but also eliminating parsing the statement, which is necessary even with prepared statements now ("execute mystatement (param,...)"). (That's planned for 7.4, right?) Maybe something else, too. So I don't know that it's anything that can't be accomplish with COPY; it's just more standard.
Other than that, I agree that all the points you raised are worth implementing.
Cool. It's nice to know a PostgreSQL developer values everything on my wishlist.
Please let me know when the database migration fairies are finished.;) Seriously, thanks for the great work. I use Oracle at work, but I love PostgreSQL at home.
Did they do anything to improve/add replication support? That seems to be the only real thing that was holding it back from replacing Oracle, as far as I can tell.
I think that's the sort of thing that as soon as that feature is filled in, people will say it's "just" something else that's missing. There are a bunch of features I can think of that would be nice and PostgreSQL doesn't have. And probably there's someone who considers each one to be vital:
Database links to Oracle data warehouses. Obviously Oracle has a bit of an advantage here, but you might want to use PostgreSQL and link to an existing system outside your control.
Materialized views. These are kind of a cross between tables and views. They are used for expensive views; ones with complex calculations and/or ones over data links. They can be refreshed manually, every N hours, or in some cases when the underlying tables change. They can even be updateable. You can use them to rewrite queries that don't even know about them.
Index-organized tables. This is just a performance optimization - instead of the primary key index referencing the table row, the entire row is stored in the index. Good for tables with few columns where you often look for the primary key.
Point-in-time recovery. (Planned for 7.4, and not too big a step from what they already have with the WAL, I think.)
Savepoints/nested transactions. There's a discussion about this for 7.4. It would also allow a failed update/insert/whatever to not invalidate the entire transaction.
Better cursor support in JDBC bindings (and presumably other language interfaces). Right now, executing a query fetches the entire results to memory. That doesn't scale of course. But I hope to see this change soon. Nic Ferrier is working on a patch, though it won't work with resultsets you use across transactions. (PostgreSQL doesn't (yet?) support cursors outside of transactions.)
executeBatch and such that I think would be helpful for inserting a lot of rows quickly. There's COPY, but I think it's completely non-standard.
Surrounding tools. Oracle Forms & Reports, for instance. I consider GNUe Forms & Reports to be a long way from a replacement. Don't know of any other projects even as close as they are.
Tablespaces. Mostly for performance, I think - we just keep all the indexes in a different tablespace on a different array for less disk seeking.
Multi-column function-based indexes. "create index person_upper_name_idx on per.person (upper(lname), upper(fname)) tablespace bob".
Good Win32 support.
Database migration fairies. We use Oracle at work, even though it is a relatively small database. Even if all the other features were completed, I don't think we'd switch unless database migration fairies helped us with the transition.
So what's going to happen when someone creates a virus/worm that uncaps cable modem speeds??
I predict that if that happens, the cable companies will quickly find a way to cap bandwidth on their end, as they should have been from the beginning. It's just obviously bad security for the person being restricted to be in control of the restrictions, even if there is a way to monitor it.
And at some point, I think the law enforcement people are going to realize that the cable companies are doing the equivalent of whining about being repeatedly robbed, yet never locking their doors. A crime was committed against them (and the people who committed it should be prosecuted, sure), but I find it harder to have sympathy for the cable companies when they don't take obvious steps to prevent it.
It would be leaky if there was no clean way to do it properly, other than to chuck Perl and write it in C.
That's really not how I read leaky in his paper. It was more like the abstraction failed to completely insulate you from details of the underlying system. Regular expression matching fails to completely insulate you from details of how searches are performed. Leaky doesn't mean worthless, just imperfect.
Now that simply isn't true. Imagine you need to do reformat the data in a text file. In Perl, this is trivial, because you don't have to worry about buffer size and maximum line length, and so on. Plus you have a nice string type that lets you concatenate strings in a clean and efficient way.
But this is still a leaky abstraction:
if you put a huge file or even line into a variable in memory, there's a cost. Performance could suffer or it could just not run at all. [*]
making string concatenation (for example) so easy may lead you to do more than is necessary and more than would be ideal from a performance perspective. Certainly with high-level stuff, it's harder to see the cost of a single line of code.
But it's still a useful one because these things are smaller/less common problems than the ones in C that you mentioned.
I think Joel is right - the really good programmers are the ones who understand the system at all levels. That's something I strive for personally, since I don't anticipate that ever changing.
But at the same time, many of the specific leaky abstractions he mentioned can be plugged. The C++ one, certainly - it really only is like that because of backward compatibility. Java has no such problem. The SQL one, maybe not - but even when I have to mess with the query planner, it's less work than having to do everything myself.
And as a general rule, I think our abstractions have lowered the entrance barrier to programming, increased the scale an expert can work on, and increased the speed at which an expert can do things. From the article, I don't think he disagrees. He just pointed out that they can be dangerous, which is definitely true.
[*] - Perl 6 will support streaming regular expressions, so in one way this is less of a problem, or at least can be sidestepped. But still you might not know that and put it into a variable first, you might put large chunks of the results of the regexp into a variable, or you might make regexps that backtrack...so the leak is still there, just smaller.
Slashdot Mirror
Well, it's interesting that your definitions don't match his. So I don't think you do understand what he meant. And I don't either, or I wouldn't have replied to begin with.
InterruptDescriptorT said: >>>> Where, I wonder, would one buy individual parts for a notebook? It's pretty easy to go to your local dealer and pick up an Athlon, mobo of your choice, some cheap RAM, hard drive, etc. I have to say that I've never seen notebook parts available a la carte like with regular computer paraphernalia.
MattCohn.com said: > Build: "Alright. I take the Athlon, slide it in the slot, insert my RAM, configure my drives as slave/master, plug them into the IDE ribbon"......
So clearly InterruptDescriptorT is used to building by that definition.
kfg said: >>> You are used to shopping in stores that cater to people who *assemble* computers, and only stock those things that those people buy. In the stores that cater to people who *build* computers you'll find everything you need.
...but kfg says he's used to shopping in stores for people who assemble. With components in that store, it's really not clear to me what a store for people who build would have, if not the raw materials to make components.
Umm, your distinction is silly. "Assemble" means putting together premanufactured pieces. That's what the pieces of the laptop would be also, unless you are talking about buying raw materials like silicon, gold, oil, etc, designing everything, and fabricating the chips and boards yourself. And refining the oil into plastic. And...
...this is pretty similar to the computer program described in The Jazz by Melissa Scott. A kid stumbles onto a program that can tell him how similar something is to existing works. It goes slightly further - making suggestions also - but the idea is the same. In the book, a major studio uses it for movies.
Oh yeah? Well, They have. In satire of genuinely stupid advisories, I think. Although it's hard to tell the difference between this one and some others I've seen...
Here's an excerpt:
Section 2 [Preface]:
Usually, Team Leet keeps our code and research quite private until we spew our diarrhea all over your computer monitor. But, what really annoys us, is when a very big figure in the computer security community lies to the people who make him who he is. The person I speak of is Bob Dobbs. Bob Dobbs claims that OpenBSD hasn't experienced a local root hole in the default install for many years. Yet, during his internal audits, he regularly finds unfaithfulness to the church, and he never notifies the public. I think you guys are lame. You have demonstrated sins, transgressions, intemperances, vices, errors, failings, personal faults, indiscretions, lapses, trespasses, and crimes agsinst man, woman, child, law, nature and god. What worries Team Leet is that our servers might be hacked. We have found many other exploitable holes in previous OpenBSD distributions, that have miraculously been patched and never revealed. Next, there is the "Three years without a remote hole in the default install." I hope this advisory breaks that aswell, because, techinically:
Although we have not confirmed it, we believe this bug is also exploitable via NFS, RSH, TELNET, and SSH.
Three years without a remote hoe? Strike that.
For the record, you're wrong.
Please look at wxPython and Perl's entire user interface section of CPAN.
Please do the tiniest bit of research before you post. It would have been enough.
> Interesting. Is there a formal proof of this somewhere? I don't recall having seen one.
The algorithm to do it is completely trivial, actually. You just construct a tree with every possible move branching out until completion. (Actually, I think it's a DAG, but that's not really the point.) With the complete game tree, you can basically do anything you want.
Essentially this algorithm has been used to solve simpler games: tic-tac-toe (you should try it; it's not that hard to do, actually), Connect-Four, etc.
However, in our universe it is infeasible to solve chess this way. The algorithm is theoretically perfect, but chess has 10^123 states and our Universe contains only 10^81 atoms. I suppose you could store more than one bit per atom (the number of quarks is greater, and I guess you could manipulate their spins or something) but I think you need to store more than one bit of information per state also...in any case, devoting a significant portion of the Universe to this problem is not feasible. In fact, there might be a formal proof somewhere that this is impossible, based on thermodynamics/entropy calculations.
So if chess is solved, it will be through a different way.
That's way too specific to draw a general conclusion from. You say three machines, but really the problem is one hardware device. Overall, I don't think anyone can seriously dispute that Linux has much broader hardware support. And I've had no problems with my 2940UW (which I think uses the same chipset), so it's probably something pretty specific about your devices.
Furthermore, you probably could have gotten it to work if you'd really wanted to. Yes, you shouldn't have to do anything more than going through the installer. But typically people are pretty influenced by their bias in this: if they're surprised that it didn't work (as you probably would be for FreeBSD), they'll go the extra mile to find a patch and/or submit a bug report. And then it will work the next time. If they're not surprised (like you for Linux), they won't do that, and it won't be improved. So it's a feedback loop.
They get those things from mailing lists from other companies, the same way people get any other sort of junk mail. They don't really know much about the people they send them to; they're just hoping for a response. Ignore it or say "go away" - even if you come to their attention, they still can do nothing. They have no authority to search your property. And even the police would need proof of guilt, not lack of proof of innocence. That's how America works.
kalidasa wrote: "the second figure (percentage of the Chinese population who can reproduce all valid charactes in the Chinese writing system) is almost by definition 0%"
That's a completely different statement. Minna said that there exist characters that only 10% of the population can reproduce. You said no, there are very few, if any, people who can reproduce every character. Both statements could be true, since Minna has not claimed any one person is in all of those 10%s.
You should pay a little more attention to what people are saying before claiming they are wrong.
Umm, you try it. Presumably they've spent a lot of time on designing a format. You should take a little bit of effort before claiming you can do much better, especially since verifying the compression of such a simple format should be easy. Making the claim without even taking that much effort is insulting.
Besides, FLAC has important features your format does not. In particular, FLAC is seekable. As anyone who has tried to quickly extract a single file from a large .tar.gz knows, gzip is not.
Interesting, but that sounds like a different situation. The traffic congestion is caused by drivers, so the "smart" drivers cause new congestion when they try to avoid old congestion. The drivers don't cause snow/ice, so I don't think the same problem will happen here.
You're not getting it. I know it was a troll - I said as much. I'm angry that the moderators were so stupid as to mod it up. They apparently believed it was genuine.
* Ease of use. After about a day I had an excellent understanding of both PHP and SQL. I was able to get a stable, useable and presentable website up within 24 hours of reading the basics of PHP. Learning Perl took me weeks and I'm still not even as good with it as I am with PHP. I would definitely not recommend anyone new to programming begin with Perl.
That's a nebulous statement. I think Perl is not a hard language to learn. Furthermore, I don't see anything in this post that leads me to believe eggtroll has ever used either language, so this isn't even good anecdotal evidence.
* The OO of PHP is excellent. In my experience, it rivals Smalltalk. We all know that Perl's OO still needs work (whether or not OO is all that great is another discussion.) Hopefully Perl will be patched up so it supports such must-have OO features like introspection, reflection, self-replication and ontological data-points.
Perl's OO support does need work. But it does support introspection. (Reflection is another term for introspection.)
Real problems with Perl's OO: it does not statically check anything. It does not enforce encapsulation. It feels like a kludge in general to me. From what I've been reading of Perl 6, I think it will be much better. I'm looking forward to it.
Self-replication? Ontological data-points? These are not OO terms.
I do not use PHP, but I would be shocked if its OO support rivalled SmallTalk's. You'd need to provide a lot of evidence for me to accept that.
* Outstanding database support. PHP supports virtually every DB under the sun (although Berkeley DB is missing, oddly enough.) Perl seems limited to MySQL and PostgreSQL, and its really a kludge for the later.
I regularly use Perl with Oracle. There are many different database drivers.
* Speed. [...] Its [sic] definitely faster than Perl in almost every case, particularly in regex which has long been Perl's strongest point.
I assert otherwise. Prove it. In fact, I think PHP uses the PCRE - Perl-compatible regex library, intended to be like Perl's but somewhat less complete.
* Portability. I can take PHP code off my Linux box and plop it onto an IIS server, or even one of those new Macintosh servers and have it run without having to change a single line of code. Try doing this with Perl!
I do regularly, with success.
* Graphics. [...] Perl lacks a graphics library of any kind.
Wrong. It has image libraries and windowing libraries.
* Data Structures. [...] Under Perl you're extremely limited in what you can do. This is because Perl isn't OO (so you can't create Node classes, for example, usefull in a linked list) and because it lacks pointers. Some of you may notice that PHP lacks pointers, but look deeper! Behind the scenes, hidden from the user pointers are used.
Perl has references. As in Java, they are essentially safe pointers with automatic memory management (though the GC is less sophisticated). And it does have OO support, at least to the extent required to make a Node class. There is no limit to the data structures possible in Perl.
Perl has its flaws, but these are not they.
SWT [...] abandons [...] the idea that the same binary must run on all platforms. [...] Even though the libraries are implemented completely differently, the public interfaces are the same.
Hmm, I can't get the first statement from the second. In Java, you shouldn't ever need to recompile code unless the interface it uses is changed. So a jar you make that uses swt.jar shouldn't need to be recompiled unless it uses JNI itself. No different than AWT.
SWT and AWT both use JNI, so both (the libraries themselves, not consumers thereof) need to be compiled for the appropriate platform. The only difference is that Sun makes AWT, so you can assume that it came with the JVM and avoid distributing your own copy. Probably not a reasonable assumption for SWT.
Blkdeath wrote: It does, however, continue to state the need for a firewall in an effective protection setup;
Sure, but you're not getting my point. It mentions that as "defense in depth"; redundant security. The draft implies throughout that these are totally independent methods. They aren't. It's not just a single poorly-worded paragraph; it's wrong.
I wrote: First, I think it's reasonable to assume that nearly anyone with multiple interfaces will have IP routing enabled.
Blkdeath wrote: Not neccesarily. Sometimes computers are just on multiple networks.
Thus the "nearly". But I can't even think why you'd need to do that in a well-designed network.
I wrote: Second, I'd guess most NetFilter configurations wouldn't stop this. You have to have a rule that denies anything coming in from the external interface for the internal IP.
Blkdeath wrote: That's part of any proper BOGON filter set, or any decent firewall.
I agree, but I'd still guess that most people don't. I often don't see it in tutorials for NetFilters and similar tools, and I imagine it's pretty common to end up with a firewall very similar to those.
If I ever saw someone suggesting it as an alternative to firewalling, I'd call them on it.
Did you read that portwalling draft that berzerke linked to? I quote:
It does not mention the need to prevent them from accessing one interface's IP from another interface.
First, I think it's reasonable to assume that nearly anyone with multiple interfaces will have IP routing enabled.
Second, I'd guess most NetFilter configurations wouldn't stop this. You have to have a rule that denies anything coming in from the external interface for the internal IP. (Or that denies the service specifically, but then there's no real point to binding to the inside interface only.) Binding only to "safe" interfaces is sometimes pointed to as an alternative to firewalling services, so it's important to point out where that can fail. With the one rule, it works well.
That's not necessarily enough. See this email about "weak end host". The short version is attackers can access the IP of one interface through another on Linux unless you go out of your way to prohibit it.
The correct response to this is "it had better not" or "sucks to be you then" as the legislation makes no such allowance. They are allowed one mistake per year. After that it's $500/call. Even if the request, the mistake, and the first violation happen in the same day.
Umm...no, you don't. What happens when something happens before 1AM and you discover it after 1AM? That seems not only possible but likely. With tapes, that's easily solved - just rotate your tapes. Plus, it's a lot easier to take them off-site for protection against fire.
Sure. That's the JDBC method for it - there may be a more generic term I don't know. You just prepare an insert/update statement. Then you loop over it and call addBatch() instead of execute() and an executeBatch() at the end and it's faster than calling execute() each time, even within the same transaction. I think it does this by sending them all to the database at once (which I guess the JDBC driver could/maybe does do already; just semicolon-separating them) but also eliminating parsing the statement, which is necessary even with prepared statements now ("execute mystatement (param, ...)"). (That's planned for 7.4, right?) Maybe something else, too. So I don't know that it's anything that can't be accomplish with COPY; it's just more standard.
Other than that, I agree that all the points you raised are worth implementing.
Cool. It's nice to know a PostgreSQL developer values everything on my wishlist.
Please let me know when the database migration fairies are finished. ;) Seriously, thanks for the great work. I use Oracle at work, but I love PostgreSQL at home.
I think that's the sort of thing that as soon as that feature is filled in, people will say it's "just" something else that's missing. There are a bunch of features I can think of that would be nice and PostgreSQL doesn't have. And probably there's someone who considers each one to be vital:
I predict that if that happens, the cable companies will quickly find a way to cap bandwidth on their end, as they should have been from the beginning. It's just obviously bad security for the person being restricted to be in control of the restrictions, even if there is a way to monitor it.
And at some point, I think the law enforcement people are going to realize that the cable companies are doing the equivalent of whining about being repeatedly robbed, yet never locking their doors. A crime was committed against them (and the people who committed it should be prosecuted, sure), but I find it harder to have sympathy for the cable companies when they don't take obvious steps to prevent it.
That's really not how I read leaky in his paper. It was more like the abstraction failed to completely insulate you from details of the underlying system. Regular expression matching fails to completely insulate you from details of how searches are performed. Leaky doesn't mean worthless, just imperfect.
But this is still a leaky abstraction:
But it's still a useful one because these things are smaller/less common problems than the ones in C that you mentioned.
I think Joel is right - the really good programmers are the ones who understand the system at all levels. That's something I strive for personally, since I don't anticipate that ever changing.
But at the same time, many of the specific leaky abstractions he mentioned can be plugged. The C++ one, certainly - it really only is like that because of backward compatibility. Java has no such problem. The SQL one, maybe not - but even when I have to mess with the query planner, it's less work than having to do everything myself.
And as a general rule, I think our abstractions have lowered the entrance barrier to programming, increased the scale an expert can work on, and increased the speed at which an expert can do things. From the article, I don't think he disagrees. He just pointed out that they can be dangerous, which is definitely true.
[*] - Perl 6 will support streaming regular expressions, so in one way this is less of a problem, or at least can be sidestepped. But still you might not know that and put it into a variable first, you might put large chunks of the results of the regexp into a variable, or you might make regexps that backtrack...so the leak is still there, just smaller.