Don't forget: it gets email from a hotmail account. I think there's a script for linux called gotmail that is (well, was a year ago) a kludgy work around to get hotmail into your local mail folders. I know that's the only reason I use OE, and I know a lot of people who like that feature.
There's a JavaMail provider that does the same thing. So any Java mail client will be able to do that as well. Mulberry would, though I don't like Mulberry's user interface.
Incidentally, if you do find a good Java mail client, I'd love to know. I don't use HotMail, but would like a mail client that's cross-platform, developed with a UI I could realistically modify (Swing is easy!), and fundamentally immune to buffer overflows.
Here atleast, the result is: you have a monetary fine, but you are not considered guilty of a traffic violation. Your car is. And you are responsible for any fines on your car. The same as you would be responsible for any parking tickets your car gets while someone you lent the car to it parks illegally.
Does this mean your insurance rates do not change as a result of these violations? If not, I think the distinction is not important. You still pay for it well beyond the cost of the ticket.
What's shocking to me is that almost no open source authors or advocates give a hoot about automated testing of any kind. The only free software I've found with a test suite is gcc. As much as I hate to say it, there's a good chance that the relative inexperience of most open source authors is a factor here.
Perl is really good about this. The Test::Harness and Test::More modules make it very easy to write test suites, so CPAN modules have lots of automated tests. It might even be a requirement to get a module into CPAN; I'm not sure.
PostgreSQL has regression tests.
There's a really nice test environment for Java code called JUnit. Lots of stuff is using it. Lots of articles about how to write effective tests. There's a project to develop mock versions of common objects (servlet requests, SQL queries) that fail in interesting, predefined ways.
I'm using a C++ workalike called CppUnit in one of my projects.
> > You go into a store. Software Product A is sitting on the shelf for $10.
> You decide that Product A isn't worth $10 to you. (The step you missed)
> > You go around to your friend's house. Software Product A is copied to you for free.
All other things being equal, if there were a product being sold at Store A and Store B for $50 and $30, respectively, I'd buy it at Store B. It doesn't mean it wasn't worth $50 to me, it meant I didn't want to burn $20.
Granted, all other things are not equal here -
to most people, not breaking the law is worth something. But it is not true that all people who pirate software do not consider the software to be worth its purchase price.
That's entirely missing the point. It's as if asked "I wish perl had a unified database handling module", somebody had answered: "well, you've got the oracle module, the sybase module and the mysql module. They don't have the same API, but they all allow you to connect to the database you're using.".
No, it's more like "there's Tk, Gtk, Qt, and wxWindows. All of these are portable across windowing systems." That's completely different from your example, in which the Oracle module, the Sybase module, and the MySQL module are not portable across databases. Any one of Tk, Gtk, Qt, and wxWindows fulfills a parallel role to DBI.
It would be dumb to have another abstraction layer on top of these. What would you gain? A single API to know? You can accomplish that by only using one of them. They each have advantages and disadvantages - an abstraction layer would make impossible/difficult anything that is not possible/easy with any one of these. You'd have a new API with the combined suckiness of them all. It would have the bugs of the underlying system its using, plus its own. It would have its own overhead. It would be worthless.
SQLServer has somethings that are just wonderful, for me as a developer. Enterprise manager is quite simply, fantastic. The comparison to Oracle's equivalent is rather... amusing. I havent used postgreSQL's configuration tools much. I also like to be able to run my queries, and it gives me a nice big table that shows where it is spending its time, were there any row scans, and please, sir, can you suggest any indices I'm missing? We will be doing an installation of our product soon that will be really seriously stressing the software, 100s of (web)requests per second. This is java talking to SQLServer. We can cluster the SQLServers if need be.
Oracle has a similar tool to analyze queries and see where additional indexes may be helpful or where existing ones aren't used. PostgreSQL doesn't have anything to gather information on all queries executed recently, but you can gather information on a particular query with the usual "explain <statement>" to see the query execution plan, and its own "explain analyze <statement>" to see the query plan against an actual execution.
I dont have performance benchmarks, but for me, SQLServer has an overwhelming number of tools and works, very very well. In my experience, that there can be an entire job title called "Oracle DBA", speaks volumes about how easy it is to administer.
I assert that, for the most part, Oracle's incredible number of tools are why there's an entire job title called "Oracle DBA". Even if the tools are easy to use, the sheer volume means there's a huge time investment in learning them all. (I'm of the opinion that adding more tools rarely allows you to get away with less knowledge if you want to do something well - it just makes particularly tedious tasks faster once you have a little more knowledge.) So if MS SQL Server has anywhere near its number, I find it hard to believe it's easier than Oracle to administer well.
MySQL is an interesting one. It really is designed for a different purpose, to be a fast, file based database. It really can't cope with the mission critical type installations, but is excellent in its domain.
I disagree. ACID features don't make PostgreSQL any more difficult to use. Performance-wise, I've not seen any conclusive benchmarks that MySQL is faster in realistic situations. (The benchmarks on mysql.com reveal a complete lack of understanding of performance. They are benchmarking things like creating tables. How often do you do that?) Or that performance is ever much more important than massively decreasing the chance of data corruption. How is MySQL better than PostgreSQL for the problem domain you mentioned?
I have to agree with part of the original statement, that advocating using MySQL would hurt his credibility. But PostgreSQL is a good database - I think it's better than Oracle in many situations, and MS SQL Server strikes me as an Oracle wannabe. You haven't convinced me otherwise.
I dont mean to cast dispersions on MySQL or PostreSQL, they are very good databases, but not in the same league as SQLServer, IMHO.
I'm also interested in hearing why you think Microsoft SQL Server is better than PostgreSQL. I've used PostgreSQL and Oracle and feel that PostgreSQL is as good or better in many situations. I'd be surprised if MS SQL Server had any real advantages over Oracle (except price, and it can't compete with PostgreSQL there).
Oracle's two big advantages, as I see them, are:
Large database features. There are a million features that contribute to this. Manufactured views, clustering, different tablespaces, quotas, replication, etc.
Extra software. Stuff like Oracle Forms & Reports is really great for rapid development. I haven't seen anything cross-database or PostgreSQL-specific that can match that at all.
On the other hand, PostgreSQL has:
Ease of administration. Oracle administration seems really, really complicated, even when you don't use any of those extra features. [*] PostgreSQL is very simple to set up correctly and keep running correctly. In my experience, keeping a database healthy is little more than doing a vacuum analyze in a cron job or something.
Lower cost. You can get the database free, with volunteer support from the mailing lists. If you want paid support, you can buy it as the RedHat Database, still with a much lower cost than Oracle.
Open source. I don't think I need to say here why this is good.
Now, MySQL...I don't understand why you'd use it when PostgreSQL is available. I certainly won't take quite as seriously anyone who advocates using it. It's not even a relational database, by definition. See Codd's Rule #10, for example. (I don't think any database supports all of these rules perfectly, but MySQL in particular is quite sad.)
[*] - I don't actually administer an Oracle database. I just use one and try to have some understanding of how its administration is done.
Way too much work. Here's similar Escapade [escapade.org] code:
Not similar enough. That makes 300 queries per hit against your database, and I don't think you even used prepared statements. His code slowed their software to a crawl by sleeping. Yours will slow your software to a crawl by excessive database traffic.
I think it would also be cool to provide another sort of editscript that allows more sequential editing, rather than a rule-based system, so that you could do more "artistic" edits, grabbing snippets of video and audio from various places and maybe mixing them with your own. That's not my major interest, though, mainly since such edits probably wouldn't be done 'on the fly' anyway.
I think that would be really great for stuff like The Phantom Edit. LucasFilm's objection to it is that their material is being passed around unauthorized. Something like this would allow you to basically distribute The Phantom Edit as a patch to the official movie. So in this format, people who have purchased the original can watch it and others can not. There's a clearer distinction between pirates and fans doing things like this. As a bonus, it'd take up a negligible amount of disk space and would be easier to re-re-edit.
lim x -> 0 of 4/x = undefined
lim x -> 0+ of 4/x = +inf
lim x -> 0- of 4/x = -inf
One statement says "as x approaches 0 from the left (x is an extremely small positive number), 4/x approaches positive infinity." The other says the same thing, except from the left (negative). Only if they are the same is the general limit true.
lim x -> x_0 = f(x) <=>
lim x -> x_0+ = lim x -> x_0- = f(x)
On Unix, filtering mail is normally done by Procmail, not by your mail client.
Not only that, but that's the best way to filter your mail anywhere. Since so many people access their email from several different places, filtering on the client side is not effective. Also, if you have different quotas in different folders (Cyrus IMAP servers for example), you want to make sure the filtering happens as soon as the mail arrives.
You can do server-side filtering with all the servers I've used:
Unix mboxes in/var/mail. procmail, as you said. (Or qmail's deliver. Or...)
Cyrus IMAP without even a Unix account on the server. It has something called Sieve which they want to become an Internet standard. (With eventual support for creating sieve rules graphically in lots of different mail clients.)
Microsoft Exchange. As much as I hate Exchange (we use it at work), it's only fair to mention it can do it as well. Outlook's "Rules Wizard" will tell you if a given rule can be performed on the server or not.
Data connection is only about 300 baud or so, but how much faster can you really talk (so that a computer can uderstand you) than 300 baud worth of text?
If your phone were doing the translation, that might be true. But combine that statement with one you made earlier:
Why not a feature like direct connect, but instead of 2-way radioing another person, a voice processor system, which returns the processed speech as text into whatever is running on the phone?
... and you've got a lot more than 300 baud of information being sent. If your phone knew enough to filter it down to 300 baud, it wouldn't need to send it at all.
This bug causes zlib to free() a malloc'ed block of memory more than once. free() on most other OS's (including Windows, FreeBSD and OpenBSD) is smart enough to check for this and will print a warning instead of destroying the heap; glibc's malloc (and by extension, Linux's) does not and will gleefully make a mess out of the whole memory space. This can cause all sorts of buggery when the next malloc() occurs, including what amounts to a buffer overflow exploit.
If you want this behavior, you can get it easily on Linux/glibc. From the malloc(3) manual page:
Recent versions of Linux libc (later than 5.4.23) and GNU
libc (2.x) include a malloc implementation which is tunable via environment variables. When MALLOC_CHECK_ is
set, a special (less efficient) implementation is used
which is designed to be tolerant against simple errors,
such as double calls of free() with the same argument, or
overruns of a single byte (off-by-one bugs). Not all such
errors can be proteced against, however, and memory leaks
can result. If MALLOC_CHECK_ is set to 0, any detected
heap corruption is silently ignored; if set to 1, a diagnostic is printed on stderr; if set to 2, abort() is
called immediately. This can be useful because otherwise
a crash may happen much later, and the true cause for the
problem is then very hard to track down.
IMHO, it's poor programming practice to let your errors slide up the stack without doing anything about it until you get to the top level (or any level above where the error happened). The farther from the source you handle an error, the harder it is to determine what exactly caused the error to begin with.
Yes, if it reaches the top of the stack, you've done something wrong. That happens to me when I forget about an exception altogether in C++. (In Java, you're forced to consider all possible types - it won't compile if your method can throw an exception it hasn't declared as such. Nice feature.)
At each function, you should make a conscious decision about each exception type: should it be caught or passed through. I've got a surprising number of functions for which passing through is the best solution.
An example: I have low-level IO stuff (based right on the system calls) that throws IOError and subtypes on failure. I have buffer management code that throws MemoryError on failure (and ensures the buffer was as before - some careful logic around realloc). My high-level IO doesn't deal with exceptions at all: it just passes them through. There was careful reasoning and documentation in each case, but no code.
In that vein, I prefer a small section of general cleanup code at the end of a function
With proper exceptions, general sections of cleanup code are rarely necessary. As you go up the stack, objects go out of scope. There are a lot of C++ classes out there (often called "monitors" or "guards") that really only exist for their constructors and destructors. When they go out of scope, they make release a lock, free a pointer, or whatever. No finally clause necessary; it correctly handles both exceptions and normal function exit. There's no possibility of programmer error. Something like this:
When that's a friend class of Mutex and Mutex's lock and unlock functions are protected, you can not lock/unlock mutexes otherwise. So you never will have a problem with a lock not being released.
(Side note: There's a function for locking multiple MutexMons in a certain order based on where they are in memory (an arbitrary criterium that's constant between threads). Even if all paths out of your code release locks, you still need to worry about deadlock.)
I have tried Java programming (okay, so it was only for a lame elective class at university, because I was luckily a class or two ahead of all the changes to java. They even changed the AI class and the OS class to use java!).
Yes, I'm still a student and they've done that here. I also think it was a bad choice, for the OS class in particular.
However, there does come a point where overhead does matter, and comparing lightweight goto-enabled error handling to heavier exceptions when dealing with server-side work (software that has to scale well, and still be performant), there is a difference.
I still don't buy that. I just can't think of many situations where you pump out exception after exception in a loop. Yes, they are at many places throughout your code. But those should be the branches that are infrequently taken. If they're not, I have to think something more fundamental is wrong.
If you have an example program that demonstrates a significant performance difference between these two techniques, I'd love to see it. Otherwise, I don't believe it exists.
I said: Remember, exceptions are exceptional - if you are throwing them regularly, something is wrong. The only one I have that's thrown even remotely close to commonly is IOBlockError - basically EWOULDBLK/EAGAIN in exception form.
ahde said: Not with java. Exceptions are a normal part of program flow. Not of necessity, but enough of the standard APIs and documentation relies on them to make it fairly standard.
I don't buy that. Yes, just about any function that can signal an error condition does so by an exception. But if your code is correct, that will not happen many times in an execution. I.e., if you've got an inner loop that throws/catches an exception at every iteration, you're doing something wrong. Exceptions are, by definition, not regular program flow.
God, I hope not. Exceptions are bad, especially when you're dealing with server-side software that needs to be performant. I much prefer an error code (say, HRESULT, if you're in the windows world), and a smallish error handler (usually reached via a goto, but the goto gets hidden in a macro). Much lighter on resources, and I prefer it. Plus, you don't have to write extra code for functions that don't already throw exceptions, though you'll still need to try/catch exceptions from functions that do throw them (ugly).
Exceptions are a very handy tool when used correctly. Yes, having to handle an "exception" and a "non-exception" version of the same thing would suck. But when used consistently (and you can makeoperator new and such have consistent behavior even if you don't like the system's - override them), they eliminate a lot of code. You don't need to handle every error right where it could happen; errors just slide down the stack until they are handled. Programmers are lazy enough that when they have to handle every error right where it happens (many if statements after repeated calls), they don't. So anything that makes error handling easier makes better (yes, more secure) code.
Performance-wise, I've never had a problem with exceptions. Yes, they play games with the stack behind the scenes...probably not as efficient as your goto. But unless you can show me a situation in which exceptions actually cause a performance problem, I'll continue to think they are much, much preferable to goto (ESPECIALLY when the goto is hidden away in a macro - very bad spaghetti). Remember, exceptions are exceptional - if you are throwing them regularly, something is wrong. The only one I have that's thrown even remotely close to commonly is IOBlockError - basically EWOULDBLK/EAGAIN in exception form.
Where I don't like C++ exceptions is debugging. Java has very, very good support for following exceptions and analyzing the stack. It's excellent for debugging; I don't even need a seperate debugger anymore - stack traces are all I use them for. C++ can't match that. g++/gdb are absolutely terrible about debugging exceptions. You can't catch one in the debugger. You have very little idea where one came from. If one reaches the top of the stack, the code does an abort without printing much useful diagnostic information.
In fact, you really should try writing Java code. You'll absolutely hate the performance (if you are doing gotos to get an extra nanosecond or whatever, you'll hate virtual machines). But it does exceptions extremely well, and you'll see they are a far superior way of handling errors correctly. And maybe it will teach you that a few nanoseconds here and there aren't as important as having proper algorithms - differences of seconds or minutes. Basically any little bit of code in Java will execute more slowly than C/C++, no matter what the Java advocates say. But if you do things properly, you can have a larger program that is not much slower - by spending time you would have spent on little things to improve the overall design.
My point was that simply switching from C to C++ is not enough to buy you security. You might get some things for free, but to truly be secure, you'll still have to code securely. There's no way around that (okay, there is, but it involves moving to languages other than C or C++).
C++ will be no more than secure than C if you treat it as C. But if you take advantage of the object-oriented constructs, you can (1) remove varargs (format string vulnerabilities gone) (2) reduce code that handles arrays (buffer overflows less likely). In other languages (Java, for example), you can completely eliminate both of these. There are still other kinds of problems - though not so common or so easy to fix.
[new and delete] aren't guaranteed to be any more safe [than malloc and free]. You still have to check the value of a pointer after new, and you still need to make sure you use delete.
That's half true. You still have to make sure you deallocate properly (call delete or delete[] appropriately exactly once). But you don't necessary need to check return from new - it throws an exception instead of returning null.
(This might not be true on all platforms. I think the standard specifies this, but am not sure. You can make a test that ensures this by trying to allocate a ridiculous amount of memory and catching an exception. I actually do test this for a library of mine, but have only run it on Linux, FreeBSD, and HP-UX with default allocators.)
Different syntax, same old problems. In and of themselves, C++'s stream objects are no safer than printf and scanf.
Not true. There's an entire class of vulnerabilities that printf and scanf are vulnerable to that cin and cout are not: format string vulnerabilities. I think cin and cout suck, but they are unquestionably more secure than C-style format strings + varargs.
Mind you, cin with char[] stuff is still vulnerable to buffer overflows. Don't do that. Use a string class instead.
I've been looking forward to the perchild MPM. It can run different server processes under different UID/GIDs. This is important because mod_{perl,php,python,snake} run in-process with the Apache server. It's the only way to run them securely for different people other than a completely seperate webserver for each person (with its own IP address, configuration file, memory footprint, etc.)
But perchild doesn't really work:
It's not portable to non-Linux platforms.
(There was talk on the mailing list of marking it experimental because of this.)
It hasn't compiled (even on Linux) out of the box in several releases. In 2.0.29, easy to fix but still doesn't work right. (Not compiling is a sure sign it hasn't been maintained.) Not quite as easy on 2.0.32. There's a patch, but it doesn't look right to me.
It's easy to misconfigure it into running virtual hosts as root. (Bug report)
So, Apache 2.0 may be promising in the future...but when a feature I've been looking forward to for a long time is broken, I'm kind of disappointed.
Seriously, what's the "preferred" way to add a normal, non super user, only has select, insert, update, and delete access to a given database that can connect from the local machine, and remotely. Is this even possible?
Add something like this to your pg_hba.conf:
local sameuser trust
host sameuser 127.0.0.1 255.255.255.255 trust
That's not authentication! "trust" just allows logins, period. Try "psql -U postgres" as anyone on that machine. You'll instantly be logged in as the superuser.
Something like this works fairly well on Postgresql 7.1:
host all 127.0.0.1 255.255.255.255 ident sameuser
host all 0.0.0.0 0.0.0.0 password
Then enable TCP/IP connections ("tcpip_socket = true" in postgresql.conf)
Very important: make sure your ident server is trustworthy. Many ident servers have an option to allow a user to fake identification. Turn it off.
Also, the config I posted there will let any user connect to any database. That's the simplest, but not the most secure. The "sameuser" in the database field won't be enough to let the superuser connect to databases. You might add a seperate line for that with an ident map containing only postgres (the file would have only the words "postgres postgres" in it, on one line). And then "all" in the database field with that map. I.e., "host all 127.0.0.1 255.255.255.255 ident postgres"
For remote connections, just make sure they have a password in the database:
create user slamb with password '12345';
alter user bob with password 'newpassword';
There's no authentication method here specified for UNIX domain sockets, so they just don't work. You'll need to set the PGHOSTNAME="localhost" environmental variable for stuff to authenticate correctly. I did this because pgsql 7.1 did not support ident on UNIX domain sockets. pgsql 7.2 now does, on certain platforms. (Just replace "host <db> <ip> <netmask> ident <map>" with "local <db> ident <map>")
pgsql 7.2 adds pam support. If your UNIX and PostgreSQL usernames correspond, it should work.
pgsql 7.2 also adds support of encrypted passwords. There's an option for storing password encrypted in the database and an option for challenge-based encryption. I think these methods are incompatible - good challenge-based encryption requires the password be stored in plaintext on the server.
There has been Kerberos auth for some time. I'm trying to switch over to this now, as I'm setting up Kerberos on my network. It's a more complicated system to set up correctly, though. Get something else working first.
My twin 75gig 75GXP's (in RAID 0) have been working fine for about 6 months now. Although I still put big coolers on them and treat them gently just in case.
You've got two drives well-known for their high failure rate. And you've put them in a RAID-0 (striped) arrangement. This means if either drive fails (likely), all your data are gone.
You've halved the already-low MTBF (mean time between failures) of your drives. (I think drive failures are a Poisson distribution, which means you can manipulate the MTBF like that if I remember my statistics).
Well, flowerpot, now I'm wondering whether arch uses the ftp programs, or just the ftp protocol. That is, do you need an ftp client or server installed for arch to work? From what I've seen it wouldn't be too hard to do the protocol yourself.
Whether or not you use a standard client or server, the protocol itself is flawed. It sends passwords in plaintext.
True, implementing an extremely simple FTP server might avoid the buffer overflows in standard stuff, but it couldn't solve that problem.
There were a ton of proprietary software vendors, wholely clueless that Linux users may prefer Linux because of the Freedom. [...] Ximian came accross as a slick, funded, bullshit corporation, selling their MS Exchange connector. I fear the future of GNOME in their hands.
Ximian Connector's purpose is to allow you to transition to Evolution, which is open-source. (And a very nice product, btw.) I'd hardly call Ximian a proprietary software vendor.
The connector itself is not open-source. My guess is this is because (A) they may have had to do some sort of NDA to get the info for it to talk to Exchange and/or (B) it's not as important that it be open-source, since the only people using it already have at least one proprietary product - Exchange.
The Connector is also commercial, which makes a lot of sense. It's targeted at enterprise people, who aren't afraid to spend money. News flash: businesses (such as Ximian) like money and will get it how they can. You should be glad...it means they will stay in business.
Excuse my ignorance, but what the heck are "MiB" and "KiB" ??
Mibibytes and kibibytes. They refer to 2^20 and 2^10 bytes, respectively. (I.e., what many other people call megabytes and kilobytes.)
The scientific community had decided on SI unit prefixes like 100 years ago. "Mega" means 10^6 and "kilo" means 10^3. The computer science people came along and said "no, those will be powers of two for us." These units are a (probably futile) attempt to correct that particular stupidity.
I think it won't work out, because there's too much legacy stuff that there will always be confusion at this point about what "mega" and "kilo" mean with computers. Besides, "mibi" and "kibi" sound stupid enough that they'll probably never catch on.
Slashdot Mirror
There's a JavaMail provider that does the same thing. So any Java mail client will be able to do that as well. Mulberry would, though I don't like Mulberry's user interface.
Incidentally, if you do find a good Java mail client, I'd love to know. I don't use HotMail, but would like a mail client that's cross-platform, developed with a UI I could realistically modify (Swing is easy!), and fundamentally immune to buffer overflows.
Does this mean your insurance rates do not change as a result of these violations? If not, I think the distinction is not important. You still pay for it well beyond the cost of the ticket.
What's shocking to me is that almost no open source authors or advocates give a hoot about automated testing of any kind. The only free software I've found with a test suite is gcc. As much as I hate to say it, there's a good chance that the relative inexperience of most open source authors is a factor here.
Perl is really good about this. The Test::Harness and Test::More modules make it very easy to write test suites, so CPAN modules have lots of automated tests. It might even be a requirement to get a module into CPAN; I'm not sure.
PostgreSQL has regression tests.
There's a really nice test environment for Java code called JUnit. Lots of stuff is using it. Lots of articles about how to write effective tests. There's a project to develop mock versions of common objects (servlet requests, SQL queries) that fail in interesting, predefined ways. I'm using a C++ workalike called CppUnit in one of my projects.
The Boost code has automated testing.
There's a project called qmtest.
The Wine people have recently started using regression tests.
> You decide that Product A isn't worth $10 to you. (The step you missed)
> > You go around to your friend's house. Software Product A is copied to you for free.
All other things being equal, if there were a product being sold at Store A and Store B for $50 and $30, respectively, I'd buy it at Store B. It doesn't mean it wasn't worth $50 to me, it meant I didn't want to burn $20.
Granted, all other things are not equal here - to most people, not breaking the law is worth something. But it is not true that all people who pirate software do not consider the software to be worth its purchase price.
No, it's more like "there's Tk, Gtk, Qt, and wxWindows. All of these are portable across windowing systems." That's completely different from your example, in which the Oracle module, the Sybase module, and the MySQL module are not portable across databases. Any one of Tk, Gtk, Qt, and wxWindows fulfills a parallel role to DBI.
It would be dumb to have another abstraction layer on top of these. What would you gain? A single API to know? You can accomplish that by only using one of them. They each have advantages and disadvantages - an abstraction layer would make impossible/difficult anything that is not possible/easy with any one of these. You'd have a new API with the combined suckiness of them all. It would have the bugs of the underlying system its using, plus its own. It would have its own overhead. It would be worthless.
Oracle has a similar tool to analyze queries and see where additional indexes may be helpful or where existing ones aren't used. PostgreSQL doesn't have anything to gather information on all queries executed recently, but you can gather information on a particular query with the usual "explain <statement>" to see the query execution plan, and its own "explain analyze <statement>" to see the query plan against an actual execution.
I dont have performance benchmarks, but for me, SQLServer has an overwhelming number of tools and works, very very well. In my experience, that there can be an entire job title called "Oracle DBA", speaks volumes about how easy it is to administer.
I assert that, for the most part, Oracle's incredible number of tools are why there's an entire job title called "Oracle DBA". Even if the tools are easy to use, the sheer volume means there's a huge time investment in learning them all. (I'm of the opinion that adding more tools rarely allows you to get away with less knowledge if you want to do something well - it just makes particularly tedious tasks faster once you have a little more knowledge.) So if MS SQL Server has anywhere near its number, I find it hard to believe it's easier than Oracle to administer well.
MySQL is an interesting one. It really is designed for a different purpose, to be a fast, file based database. It really can't cope with the mission critical type installations, but is excellent in its domain.
I disagree. ACID features don't make PostgreSQL any more difficult to use. Performance-wise, I've not seen any conclusive benchmarks that MySQL is faster in realistic situations. (The benchmarks on mysql.com reveal a complete lack of understanding of performance. They are benchmarking things like creating tables. How often do you do that?) Or that performance is ever much more important than massively decreasing the chance of data corruption. How is MySQL better than PostgreSQL for the problem domain you mentioned?
I have to agree with part of the original statement, that advocating using MySQL would hurt his credibility. But PostgreSQL is a good database - I think it's better than Oracle in many situations, and MS SQL Server strikes me as an Oracle wannabe. You haven't convinced me otherwise.
I'm also interested in hearing why you think Microsoft SQL Server is better than PostgreSQL. I've used PostgreSQL and Oracle and feel that PostgreSQL is as good or better in many situations. I'd be surprised if MS SQL Server had any real advantages over Oracle (except price, and it can't compete with PostgreSQL there).
Oracle's two big advantages, as I see them, are:
On the other hand, PostgreSQL has:
Now, MySQL...I don't understand why you'd use it when PostgreSQL is available. I certainly won't take quite as seriously anyone who advocates using it. It's not even a relational database, by definition. See Codd's Rule #10, for example. (I don't think any database supports all of these rules perfectly, but MySQL in particular is quite sad.)
[*] - I don't actually administer an Oracle database. I just use one and try to have some understanding of how its administration is done.
Way too much work. Here's similar Escapade [escapade.org] code:
Not similar enough. That makes 300 queries per hit against your database, and I don't think you even used prepared statements. His code slowed their software to a crawl by sleeping. Yours will slow your software to a crawl by excessive database traffic.
I think it would also be cool to provide another sort of editscript that allows more sequential editing, rather than a rule-based system, so that you could do more "artistic" edits, grabbing snippets of video and audio from various places and maybe mixing them with your own. That's not my major interest, though, mainly since such edits probably wouldn't be done 'on the fly' anyway.
I think that would be really great for stuff like The Phantom Edit. LucasFilm's objection to it is that their material is being passed around unauthorized. Something like this would allow you to basically distribute The Phantom Edit as a patch to the official movie. So in this format, people who have purchased the original can watch it and others can not. There's a clearer distinction between pirates and fans doing things like this. As a bonus, it'd take up a negligible amount of disk space and would be easier to re-re-edit.
No, that's not true.
lim x -> 0 of 4/x = undefined
lim x -> 0+ of 4/x = +inf
lim x -> 0- of 4/x = -inf
One statement says "as x approaches 0 from the left (x is an extremely small positive number), 4/x approaches positive infinity." The other says the same thing, except from the left (negative). Only if they are the same is the general limit true.
lim x -> x_0 = f(x) <=> lim x -> x_0+ = lim x -> x_0- = f(x)
Not only that, but that's the best way to filter your mail anywhere. Since so many people access their email from several different places, filtering on the client side is not effective. Also, if you have different quotas in different folders (Cyrus IMAP servers for example), you want to make sure the filtering happens as soon as the mail arrives.
You can do server-side filtering with all the servers I've used:
Data connection is only about 300 baud or so, but how much faster can you really talk (so that a computer can uderstand you) than 300 baud worth of text?
If your phone were doing the translation, that might be true. But combine that statement with one you made earlier:
Why not a feature like direct connect, but instead of 2-way radioing another person, a voice processor system, which returns the processed speech as text into whatever is running on the phone?
... and you've got a lot more than 300 baud of information being sent. If your phone knew enough to filter it down to 300 baud, it wouldn't need to send it at all.
If you want this behavior, you can get it easily on Linux/glibc. From the malloc(3) manual page:
Was there any reason for this possibly very damaging statement?
Yeah, because at the linked site:
On the other hand, this site seems quite active. I'm not sure what their relationship is.
Yes, if it reaches the top of the stack, you've done something wrong. That happens to me when I forget about an exception altogether in C++. (In Java, you're forced to consider all possible types - it won't compile if your method can throw an exception it hasn't declared as such. Nice feature.)
At each function, you should make a conscious decision about each exception type: should it be caught or passed through. I've got a surprising number of functions for which passing through is the best solution.
An example: I have low-level IO stuff (based right on the system calls) that throws IOError and subtypes on failure. I have buffer management code that throws MemoryError on failure (and ensures the buffer was as before - some careful logic around realloc). My high-level IO doesn't deal with exceptions at all: it just passes them through. There was careful reasoning and documentation in each case, but no code.
In that vein, I prefer a small section of general cleanup code at the end of a function
With proper exceptions, general sections of cleanup code are rarely necessary. As you go up the stack, objects go out of scope. There are a lot of C++ classes out there (often called "monitors" or "guards") that really only exist for their constructors and destructors. When they go out of scope, they make release a lock, free a pointer, or whatever. No finally clause necessary; it correctly handles both exceptions and normal function exit. There's no possibility of programmer error. Something like this:
class MutexMon : public Monitor {
public:
MutexMon(Mutex &m, bool lockImmediately = true) : m(m), locked(false)
{ if (lockImmediately) lock(); }
~MutexMon() { if (locked) unlock(); }
void lock() { assert (locked == false); m.lock(); locked = true; }
void unlock() { assert (locked == true); m.unlock(); locked = false; }
private:
Mutex m; bool locked;
};
When that's a friend class of Mutex and Mutex's lock and unlock functions are protected, you can not lock/unlock mutexes otherwise. So you never will have a problem with a lock not being released.
(Side note: There's a function for locking multiple MutexMons in a certain order based on where they are in memory (an arbitrary criterium that's constant between threads). Even if all paths out of your code release locks, you still need to worry about deadlock.)
I have tried Java programming (okay, so it was only for a lame elective class at university, because I was luckily a class or two ahead of all the changes to java. They even changed the AI class and the OS class to use java!).
Yes, I'm still a student and they've done that here. I also think it was a bad choice, for the OS class in particular.
However, there does come a point where overhead does matter, and comparing lightweight goto-enabled error handling to heavier exceptions when dealing with server-side work (software that has to scale well, and still be performant), there is a difference.
I still don't buy that. I just can't think of many situations where you pump out exception after exception in a loop. Yes, they are at many places throughout your code. But those should be the branches that are infrequently taken. If they're not, I have to think something more fundamental is wrong.
If you have an example program that demonstrates a significant performance difference between these two techniques, I'd love to see it. Otherwise, I don't believe it exists.
ahde said: Not with java. Exceptions are a normal part of program flow. Not of necessity, but enough of the standard APIs and documentation relies on them to make it fairly standard.
I don't buy that. Yes, just about any function that can signal an error condition does so by an exception. But if your code is correct, that will not happen many times in an execution. I.e., if you've got an inner loop that throws/catches an exception at every iteration, you're doing something wrong. Exceptions are, by definition, not regular program flow.
Exceptions are a very handy tool when used correctly. Yes, having to handle an "exception" and a "non-exception" version of the same thing would suck. But when used consistently (and you can make operator new and such have consistent behavior even if you don't like the system's - override them), they eliminate a lot of code. You don't need to handle every error right where it could happen; errors just slide down the stack until they are handled. Programmers are lazy enough that when they have to handle every error right where it happens (many if statements after repeated calls), they don't. So anything that makes error handling easier makes better (yes, more secure) code.
Performance-wise, I've never had a problem with exceptions. Yes, they play games with the stack behind the scenes...probably not as efficient as your goto. But unless you can show me a situation in which exceptions actually cause a performance problem, I'll continue to think they are much, much preferable to goto (ESPECIALLY when the goto is hidden away in a macro - very bad spaghetti). Remember, exceptions are exceptional - if you are throwing them regularly, something is wrong. The only one I have that's thrown even remotely close to commonly is IOBlockError - basically EWOULDBLK/EAGAIN in exception form.
Where I don't like C++ exceptions is debugging. Java has very, very good support for following exceptions and analyzing the stack. It's excellent for debugging; I don't even need a seperate debugger anymore - stack traces are all I use them for. C++ can't match that. g++/gdb are absolutely terrible about debugging exceptions. You can't catch one in the debugger. You have very little idea where one came from. If one reaches the top of the stack, the code does an abort without printing much useful diagnostic information.
In fact, you really should try writing Java code. You'll absolutely hate the performance (if you are doing gotos to get an extra nanosecond or whatever, you'll hate virtual machines). But it does exceptions extremely well, and you'll see they are a far superior way of handling errors correctly. And maybe it will teach you that a few nanoseconds here and there aren't as important as having proper algorithms - differences of seconds or minutes. Basically any little bit of code in Java will execute more slowly than C/C++, no matter what the Java advocates say. But if you do things properly, you can have a larger program that is not much slower - by spending time you would have spent on little things to improve the overall design.
My point was that simply switching from C to C++ is not enough to buy you security. You might get some things for free, but to truly be secure, you'll still have to code securely. There's no way around that (okay, there is, but it involves moving to languages other than C or C++).
C++ will be no more than secure than C if you treat it as C. But if you take advantage of the object-oriented constructs, you can (1) remove varargs (format string vulnerabilities gone) (2) reduce code that handles arrays (buffer overflows less likely). In other languages (Java, for example), you can completely eliminate both of these. There are still other kinds of problems - though not so common or so easy to fix.
That's half true. You still have to make sure you deallocate properly (call delete or delete[] appropriately exactly once). But you don't necessary need to check return from new - it throws an exception instead of returning null.
(This might not be true on all platforms. I think the standard specifies this, but am not sure. You can make a test that ensures this by trying to allocate a ridiculous amount of memory and catching an exception. I actually do test this for a library of mine, but have only run it on Linux, FreeBSD, and HP-UX with default allocators.)
Different syntax, same old problems. In and of themselves, C++'s stream objects are no safer than printf and scanf.
Not true. There's an entire class of vulnerabilities that printf and scanf are vulnerable to that cin and cout are not: format string vulnerabilities. I think cin and cout suck, but they are unquestionably more secure than C-style format strings + varargs.
Mind you, cin with char[] stuff is still vulnerable to buffer overflows. Don't do that. Use a string class instead.
I've been looking forward to the perchild MPM. It can run different server processes under different UID/GIDs. This is important because mod_{perl,php,python,snake} run in-process with the Apache server. It's the only way to run them securely for different people other than a completely seperate webserver for each person (with its own IP address, configuration file, memory footprint, etc.)
But perchild doesn't really work:
So, Apache 2.0 may be promising in the future...but when a feature I've been looking forward to for a long time is broken, I'm kind of disappointed.
That's not authentication! "trust" just allows logins, period. Try "psql -U postgres" as anyone on that machine. You'll instantly be logged in as the superuser.
Something like this works fairly well on Postgresql 7.1:
host all 127.0.0.1 255.255.255.255 ident sameuserhost all 0.0.0.0 0.0.0.0 password
Then enable TCP/IP connections ("tcpip_socket = true" in postgresql.conf)
Very important: make sure your ident server is trustworthy. Many ident servers have an option to allow a user to fake identification. Turn it off.
Also, the config I posted there will let any user connect to any database. That's the simplest, but not the most secure. The "sameuser" in the database field won't be enough to let the superuser connect to databases. You might add a seperate line for that with an ident map containing only postgres (the file would have only the words "postgres postgres" in it, on one line). And then "all" in the database field with that map. I.e., "host all 127.0.0.1 255.255.255.255 ident postgres"
For remote connections, just make sure they have a password in the database:
create user slamb with password '12345';
alter user bob with password 'newpassword';
There's no authentication method here specified for UNIX domain sockets, so they just don't work. You'll need to set the PGHOSTNAME="localhost" environmental variable for stuff to authenticate correctly. I did this because pgsql 7.1 did not support ident on UNIX domain sockets. pgsql 7.2 now does, on certain platforms. (Just replace "host <db> <ip> <netmask> ident <map>" with "local <db> ident <map>")
pgsql 7.2 adds pam support. If your UNIX and PostgreSQL usernames correspond, it should work.
pgsql 7.2 also adds support of encrypted passwords. There's an option for storing password encrypted in the database and an option for challenge-based encryption. I think these methods are incompatible - good challenge-based encryption requires the password be stored in plaintext on the server.
There has been Kerberos auth for some time. I'm trying to switch over to this now, as I'm setting up Kerberos on my network. It's a more complicated system to set up correctly, though. Get something else working first.
Official docs are here
You've got two drives well-known for their high failure rate. And you've put them in a RAID-0 (striped) arrangement. This means if either drive fails (likely), all your data are gone.
You've halved the already-low MTBF (mean time between failures) of your drives. (I think drive failures are a Poisson distribution, which means you can manipulate the MTBF like that if I remember my statistics).
You do keep backups...right?
Whether or not you use a standard client or server, the protocol itself is flawed. It sends passwords in plaintext.
True, implementing an extremely simple FTP server might avoid the buffer overflows in standard stuff, but it couldn't solve that problem.
Illegal or not, it would certainly be disgusting. Did you actually read the "Hello World" recipe? No one in their right mind would eat that.
Ximian Connector's purpose is to allow you to transition to Evolution, which is open-source. (And a very nice product, btw.) I'd hardly call Ximian a proprietary software vendor.
The connector itself is not open-source. My guess is this is because (A) they may have had to do some sort of NDA to get the info for it to talk to Exchange and/or (B) it's not as important that it be open-source, since the only people using it already have at least one proprietary product - Exchange.
The Connector is also commercial, which makes a lot of sense. It's targeted at enterprise people, who aren't afraid to spend money. News flash: businesses (such as Ximian) like money and will get it how they can. You should be glad...it means they will stay in business.
Mibibytes and kibibytes. They refer to 2^20 and 2^10 bytes, respectively. (I.e., what many other people call megabytes and kilobytes.)
The scientific community had decided on SI unit prefixes like 100 years ago. "Mega" means 10^6 and "kilo" means 10^3. The computer science people came along and said "no, those will be powers of two for us." These units are a (probably futile) attempt to correct that particular stupidity.
I think it won't work out, because there's too much legacy stuff that there will always be confusion at this point about what "mega" and "kilo" mean with computers. Besides, "mibi" and "kibi" sound stupid enough that they'll probably never catch on.