With deleting all cookies many people are doing themselves a big disfavour, because session IDs then mostly get embeded into URLs instead (= you loose the logging feature, while sites could still track you).
What's always left out in these discussions is the differentiation between good cookies and tracking cookies (especially long-lasting session ids). See also cookies(5).
Lack of user education and bayesian cookie filters in browsers IMO.
Happily I've been using my homegrown XML-RPC library for PHP - mainly because Edd Dumbills version was unreadable and had an ugly API - and how dumb it looks use eval() on unchecked data?!
Defaults wouldn't help here. This is however a fully homebrew problem, and would have been solved by better terminology.
I don't wonder a bit that people are turned off from less privileged user accounts, if those are entitled with "RESTRICTED accounts". A label like "security-enhanced" or "safer user account type" made more people willing to use it or at least overcome their innert Windows Professional user attitude.
Maybe the FSF should spend more time on GCJ development instead of forking a biggy like OOo2. And maybe we'd already have a more compliant Java-implementation, if it wasn't that Debian hindered interest in this language with not including Suns JVM for that long - If there's no real VM distributed, there won't run many apps, and without any Java applications there has been little incentive in evolving the free-as-in-FSF implementations at all.
Yes, ok, someone has worked on it. But as you already said, it is not a thing one would want to / could do via SQL in Postgres. The API functions you pointed to clearly resemble BerkelyDB features; just extended by network access. If you can write custom applications and use the C API everything is fine.
Actually I'm favouring the text-based query+insert database interface, as you call it; and so it looks not all too intuitive to use a specialized API for anything but text and numerics. But then again, this is perfectly fine for custom applications and it is of course a lot safer, faster and senseful to do it this way, the favourable way to say the least - but still: PG here failed on its transition to becoming a real SQL database I'd say. Not meant to be rude, just my point of view.
I didn't talk about the inconvinience to run some escaping function before I throw data into the database, I refered to the fact that I'm forced to _unescape_ it everytime AFTER it's gone into the database. The database server can keep it's stuff in whatever format it wants, it just shouldn't expose ugly internals to the clients (which like in this case had to do post-processing on behalf of the DBMS).
I didn't say that data storage is the most important thing to do with a real DBMS (then everybody would still be using BerkelyDB), but storing DATA is an important task for DATAbases - all the search and calculation features are nice extensions, nothing more.
Right, but tha APIs BYTEA unencoding functions typically use regular expressions to do the trick. En/Decoding everything to base64 is faster than to/from the format the PG-guys have choosen. Both is a pain in the ass regarding CPU cycles; but what really makes this whole story annoying to me, is that you're forced to do it _client-side_ anyway. That's where PG is behind others.
And no: I didn't have run any tests on this - I just take it for granted if the docs tell me. And wether they use gzip or straight deflate doesn't change that much. Unless they use RLE, larger files _will_ get smaller this way on disk, unless they're not any further compressable things like PNG or JPEG images.
I've lately read that one thing where PG shines is, that it actually would compress
TEXT and *CHAR fields on-the-fly. And since base64 compresses quite well
this would also accomodate any redundancy in binary files, so files may
occasionally even become slower when stored this way (instead of in BYTEA
fields).
[...] - actually reading the documentation helps quite a bit
Only sad, that you didn't. That excerpt exactly told it: PG does not support
the "BLOB" type, but instead introduces "BYTEA", which is very annoying to
use (decoding on the client side is really backwards if you actually queried
a database for your data). What I'm saying is, that you're often better off
simply encoding anything into base64 before putting it into PG databases -
in the end it comes down to that. It was already mentioned (not to say
recommended) that way on their mailing lists, btw.
True, in this case it is MySQLs lack of standards compliance and features that allow it to store binary files into TEXT fields (I'm sure this in violation of the SQL standard) - since you cannot have any 8-bit value in UTF-8 strings.
And after all nobody should expect to get free string matching and regex features for BLOB fields anyhow (they're meant to be blackboxes). But what counts at the end of the day is, that MySQL is far more user-friendly and people would have a hard time to migrate to Postgres, despite the fact that it provides so much more possibilities everywhere else.
Sure, they have a thousand "advanced features" and keep adding new ones day after day, but making the whole thing 8-bit clean would be nice too, eventually;)
It's obvious that to them "advanced and custom datatype capability" sounds much cooler than support for "standard data types". It puzzles me why they so hardly fight the way everybody else does it.
Are you sure? Last time I checked it didn't know what "BLOB" means. If it finally found it's way into the Postgres code, then they should also put a note into their docs.
Well, Postgres is compelling from an academic point of view, but it misses some important features for real-world usability.
Appearantly their SQL parser is still very flawed and you cannot seriously store binary data with it (BLOBs), unless you can live by the ugly encoding you get your data back with. MySQL never had such problems (it also allows binary data in TEXT fields!), and even if the PG developers don't want to understand that, it are those little annoyances that will prevent PostgreSql from becoming any more wide-spread.
My last two sound cards were declared "soundblaster compatible" on the
package. Guess what, they weren't.
This is marketing bullshit, many soundcard chipsets provide a "soundblaster"
or "soundblaster pro" emulation, but first after some special
initialization, which you indeed need a native driver for. Those
soundcards aren't in "soundblaster compatible" mode right after booting your
computer, that's why the Linux soundblaster driver can't access them. Point.
The reason for not upgrading is that the newer the kernel, the slower the PC. If it wasn't that 2.4 provides journaling fs, I'd probably still use 2.0.38 these days.
Btw, now that 2.6 is out I'm really reconsidering FreeBSD.
Slashdot Mirror
What's always left out in these discussions is the differentiation between good cookies and tracking cookies (especially long-lasting session ids). See also cookies(5). Lack of user education and bayesian cookie filters in browsers IMO.
Happily I've been using my homegrown XML-RPC library for PHP - mainly because Edd Dumbills version was unreadable and had an ugly API - and how dumb it looks use eval() on unchecked data?!
http://xprofile.berlios.de/
Defaults wouldn't help here. This is however a fully homebrew problem, and would have been solved by better terminology.
I don't wonder a bit that people are turned off from less privileged user accounts, if those are entitled with "RESTRICTED accounts". A label like "security-enhanced" or "safer user account type" made more people willing to use it or at least overcome their innert Windows Professional user attitude.
Maybe the FSF should spend more time on GCJ development instead of forking a biggy like OOo2. And maybe we'd already have a more compliant Java-implementation, if it wasn't that Debian hindered interest in this language with not including Suns JVM for that long - If there's no real VM distributed, there won't run many apps, and without any Java applications there has been little incentive in evolving the free-as-in-FSF implementations at all.
If they don't want to get linked at all, they should switch from HTML to PDF or publish all pages in a single MSWord document. That's it.
The WWW was designed to allow for links from one document to the other. It is neither possible nor netiquette to prohibite that. Dumb bitches.
Yes, ok, someone has worked on it. But as you already said, it is not a thing one would want to / could do via SQL in Postgres. The API functions you pointed to clearly resemble BerkelyDB features; just extended by network access. If you can write custom applications and use the C API everything is fine.
Actually I'm favouring the text-based query+insert database interface, as you call it; and so it looks not all too intuitive to use a specialized API for anything but text and numerics. But then again, this is perfectly fine for custom applications and it is of course a lot safer, faster and senseful to do it this way, the favourable way to say the least - but still: PG here failed on its transition to becoming a real SQL database I'd say. Not meant to be rude, just my point of view.
I didn't talk about the inconvinience to run some escaping function before I throw data into the database, I refered to the fact that I'm forced to _unescape_ it everytime AFTER it's gone into the database. The database server can keep it's stuff in whatever format it wants, it just shouldn't expose ugly internals to the clients (which like in this case had to do post-processing on behalf of the DBMS).
I didn't say that data storage is the most important thing to do with a real DBMS (then everybody would still be using BerkelyDB), but storing DATA is an important task for DATAbases - all the search and calculation features are nice extensions, nothing more.
Right, but tha APIs BYTEA unencoding functions typically use regular expressions to do the trick. En/Decoding everything to base64 is faster than to/from the format the PG-guys have choosen. Both is a pain in the ass regarding CPU cycles; but what really makes this whole story annoying to me, is that you're forced to do it _client-side_ anyway. That's where PG is behind others.
And no: I didn't have run any tests on this - I just take it for granted if the docs tell me. And wether they use gzip or straight deflate doesn't change that much. Unless they use RLE, larger files _will_ get smaller this way on disk, unless they're not any further compressable things like PNG or JPEG images.
I've lately read that one thing where PG shines is, that it actually would compress TEXT and *CHAR fields on-the-fly. And since base64 compresses quite well this would also accomodate any redundancy in binary files, so files may occasionally even become slower when stored this way (instead of in BYTEA fields).
Only sad, that you didn't. That excerpt exactly told it: PG does not support the "BLOB" type, but instead introduces "BYTEA", which is very annoying to use (decoding on the client side is really backwards if you actually queried a database for your data). What I'm saying is, that you're often better off simply encoding anything into base64 before putting it into PG databases - in the end it comes down to that. It was already mentioned (not to say recommended) that way on their mailing lists, btw.
True, in this case it is MySQLs lack of standards compliance and features that allow it to store binary files into TEXT fields (I'm sure this in violation of the SQL standard) - since you cannot have any 8-bit value in UTF-8 strings.
And after all nobody should expect to get free string matching and regex features for BLOB fields anyhow (they're meant to be blackboxes). But what counts at the end of the day is, that MySQL is far more user-friendly and people would have a hard time to migrate to Postgres, despite the fact that it provides so much more possibilities everywhere else.
Sure, they have a thousand "advanced features" and keep adding new ones day after day, but making the whole thing 8-bit clean would be nice too, eventually ;)
It's obvious that to them "advanced and custom datatype capability" sounds much cooler than support for "standard data types". It puzzles me why they so hardly fight the way everybody else does it.
Are you sure? Last time I checked it didn't know what "BLOB" means. If it finally found it's way into the Postgres code, then they should also put a note into their docs.
Well, Postgres is compelling from an academic point of view, but it misses some important features for real-world usability.
Appearantly their SQL parser is still very flawed and you cannot seriously store binary data with it (BLOBs), unless you can live by the ugly encoding you get your data back with. MySQL never had such problems (it also allows binary data in TEXT fields!), and even if the PG developers don't want to understand that, it are those little annoyances that will prevent PostgreSql from becoming any more wide-spread.
My last two sound cards were declared "soundblaster compatible" on the package. Guess what, they weren't.
This is marketing bullshit, many soundcard chipsets provide a "soundblaster" or "soundblaster pro" emulation, but first after some special initialization, which you indeed need a native driver for. Those soundcards aren't in "soundblaster compatible" mode right after booting your computer, that's why the Linux soundblaster driver can't access them. Point.
The reason for not upgrading is that the newer the kernel, the slower the PC. If it wasn't that 2.4 provides journaling fs, I'd probably still use 2.0.38 these days. Btw, now that 2.6 is out I'm really reconsidering FreeBSD.