I'm rather excited by Slony. And it's nice to know the road-plan for Slony.
However, multimaster or not is one parameter for replication. Another is if replication is synchronous or asynchronous; and it's my impression that synchronous replication will not be in Slony any time soon (I could be wrong, though).
And then I stumbled across http://www.csra.co.jp/~mitani/jpug/pgcluster/en/ Does anyone have experiences with that?
Hopefully it will make it into the ANSI standard sometime because it's really useful!
The SQL standard (since SQL:1999) already specifies recursive SQL, through its WITH RECURSIVE construct (optional feature ID T131, "Recursive query"). You will sometimes see people referring to it using the name "common table expressions".
DB2 implements it, and it seems that SQL Server 2005 will also feature it.
Here's an article describing differences between WITH RECURSIVE and CONNECT BY.
As far as I remember, Mozilla-like software has not problem with being run from a network share. So if you're talking stationary PCs, then just have them run Mozilla from the network.
I worked at a TV station a couple of years ago. At that time, we - like most everyone else - streamed using Real's codecs and formats. Since then, they have completely switched to WMV3 (for Windows Media Player 9+). I don't know the history surrounding the decision to switch, but I can certainly think of many reasons.
Everyone with just a microgram of brains could see Microsoft coming, leveraging their platform monopoly - BUT also very much helped by the fact that almost everybody hated Real's (client) player-software, and pretty much still do:
'Ordinary' users were pissed because the software took ownership of too many file types.
'Ordinary users' were also annoyed because Real's distribution system made every effort to hide the freeware edition. Things seem to have changed a bit for the better during the last month, or so (should have happened years ago), although things are still not acceptable.
Finally, 'ordinary users' were annoyed by the registration procedure, both at the web site, and at the first run of the player. Why such registration? - Angry users often fill out all sorts of garbage in such registration situations, making the received data useless.
Network administrators hated it because it was a pain to get working in mass-installations.
Content providers were ashamed by the fact that they had to instruct their audience to use software surrounded with such a used-car-salesman distribution attitude.
Content provider financial departments were very annoyed by exorbitant streaming server license fees. I heard that this changed somewhat some time ago, though.
The open source community were seriously annoyed by the fact that at some points in time, it was nearly impossible to find - e.g. - a Linux version of the player (the site has changed again and again during the last couple of years). Open source users also had to put up with software which was poorly integrated with important software like the Mozilla browser (a lot of browser-player integration only worked on Windows, as far as I remember). - If they could get the player to run, at all.
People (like me) concerned with the grave aspects of Microsoft on yet another monopoly area sometimes tried to express just a little bit of support for Real: Boss, I think we should try to support several different streams, including Real (and MPEG4IP, WMV,...). But siding with Real gave a really bad taste, knowing how stupidly Real acted. Eventually, even the partial supporters couldn't resist becoming intense Real-haters.
This leads me to my question: Why on Earth did you sleep for so long?! You must have seen competition coming; in such a senario: why did you strive so hard to make foes with everyone?
The Helix project was years over-due (probably too late to make a difference, by now), and your recent (and incomplete) end-user improvements on the web-site were even more over-due.
Tell me: Exactly what major changes in your organization (such as getting rid of the jerks who stressed a goofy revenue-from-deived-end-users strategy) have your completed that should make me think again about trusting your strategy, products and distribution system? I'm asking because I don't want to waste a second keeping in touch with the development of the Helix projects, unless I'm convinced that your company has turned 180 degrees.
> Is altering a column type consistent with the SQL-99 spec?
As far as I can see, the SQL standards (looked at SQL:2003) don't specify a way to change a column's type. It does, however, specify how certain auxiliary column properties (such as its default value) can be changed.
> Same with Drop Column
The standard defines how to drop a column:
ALTER TABLE <tablename>
DROP [COLUMN] <column name> <drop behaviour>
<drop behaviour> is RESTRICT by default, but may also be CASCADE (although the CASCADE behaviour is only an optional feature, as far as I can see). If set to RESTRICT, then the column drop will be denied if another database object is dependent on the column. If CASCADE is specified, then dependent objects are dropped, too.
I googled RECURSION and SQL, and came back with very little - apparently its only Oracle that's implemented this
Wrong. DB2 is rather close to implementing SQL:1999's recursiveness. There is an article comparing Oracle and DB2's recursive features. -And a patch exists for adding Oracle-style recursion to PostgreSQL.
Whether WITH RECURSIVE or CONNECT BY work effectively is another question. I haven't seen any experimental articles considering this.
Without using recursive SQL, different encoding schemes exist for the purpose:
most well-known: adjacency list
nested set
nested intervals
materialized path
Joe Celko has recently published a book dedicated to the subject.
I'm not impressed. What you have described is not out of the ordinary. And the big problem still exists: What if someone with a key logger picks up the PIN codes, etc., what's from stopping them from misusing that information? (Except for the fact that it's actually hard to steal money electronically: Where can one transfer the stolen money to without revealing the thief?)
This is where the one-time codes come into play, and that's what's interesting about the cited article. My bank uses a system equivalent to the one mentioned from Sweden; initially, I feared that it would be too much of a hazzle to have to look up one-time codes and type them for each transfer, but it's no problem, actually. (I don't perform very many transfers, though.)
The latest OpenSSH PAM-problem affects versions 3.7.x of (the "Portable" version of) OpenSSH. Red Hat has never released anything newer than version 3.5, so no workarounds are needed. Don't expect updated packages from Red Hat for this particular OpenSSH vulnerability.
Generally, if you can, include these statements in your sshd_config file:
Protocol 2 PasswordAuthentication no ChallengeResponseAuthentication no
This means that the only way to access the SSH service is with key-based authorization, using the modern variant ("2") of the SSH protocol. Make sure you are comfortable with key-based authorization before turning off the non-key based methods as mentioned above.
If you use the lines above, then make sure that you don't override them by having PAMAuthenticationViaKbdInt in your sshd_config.
After this, your sshd will have to "speak" only one protocol, and it will have less authentication entry points (meaning less potentially buggy complexity).
The Red Hat/Fedora merger sounds OK.
One thing, though: In the past, it has been very difficult to verify the PGP signatures in Fedora's packages: The packager's public keys were hard - sometimes impossible - to find. I have looked through the fedora.redhat.com web site, hoping to find out how they plan to manage PGP-keys and signatures in the new Fedora distribution, but I couldn't find any information. Does anyone know?
SQL:1999 has been defined for years and some of the DBMSs have actually implemented some of its features. Yes, SQL:1999 is big and perhaps bloated in comparison with SQL-92, but it's not that bad if you concentrate on the core parts. Some of the news in SQL:1999 are actually clarifications on stuff in SQL-92.
SQL:2003 will probably be agreed on this year.
- So I find it strange to use the more than a decade old SQL-92 as the platform for a book published in the year 2002.
Another thing: I'd say it's "ISO SQL" nowadays (or ISO/IEC SQL), not "ANSI SQL".
Apart from that, I've put the book on my Safari bookshelf and look forward to reading (at least parts of) it. Unfortunately, it seems that Safari's index of the book is currently lost.
I like the approach where you start by thinking about the standard way to do it, and then try to squeeze your design into a real-World product. It's too bad that the official standard isn't online; fortunately, it's possible to get something close to being official. When trying to set up an initial, standards compliant schema, it's nice to have an evaluation-installation of Mimer SQL to play with. I wish it were open source or at least had an official price tag.
I expect that the book could be relevant in connection with a page about SQL differences that I've started writing, after having had to port some SQL from PostgreSQL to MSSQL.
I'm waiting for a system where the loudspeaker cables are digital, as well as the crossover. Each loudspeaker driver would then have its own DA-converter and loudspeaker. In combination with calibration systems like the one mentioned in the article, I would expect a very nice system.
<<It immediately creates the notion that Java is a proprietary language.
<Which it is, or might as well be.
Agree.
Unfortunately, java is pretty much "run once - run nowhere". Of course, all Slashdotters have an up-to-date JRE, but the fact is that JREs are a rare sight. It's easy to blame Microsoft for not distributing java with Windows any more. But seriously: When even Linux distributions have trouble distributing a java runtime enviroment, then there is _probably_ something wrong with the licenses associated with java technologies.
What's worse: Because Java is nowhere to be found, there is lack of consensus about where to put java libraries, how to handle classpaths, etc.
When I think of the non-programming-related software I use regularly, _no_ Java-based software comes to mind. (Except for a few JSP-based web-pages if that counts as software.)
I'm not very optimistic about Javas future, I'm afraid. Which is sad: It's a beautiful language (which will be even more beautiful when it get generics).
Fortunately, there are other good technologies than Java. A combination of Python (when speed is not that important), C/C++ (when you need speed and control of every bit) and perhaps C# (in the future) is actually all I ask for.
Slashdot Mirror
I'm rather excited by Slony. And it's nice to know the road-plan for Slony.
Does anyone have experiences with that?
However, multimaster or not is one parameter for replication. Another is if replication is synchronous or asynchronous; and it's my impression that synchronous replication will not be in Slony any time soon (I could be wrong, though).
And then I stumbled across http://www.csra.co.jp/~mitani/jpug/pgcluster/en/
Per Wigren wrote:
The SQL standard (since SQL:1999) already specifies recursive SQL, through its WITH RECURSIVE construct (optional feature ID T131, "Recursive query"). You will sometimes see people referring to it using the name "common table expressions".
DB2 implements it, and it seems that SQL Server 2005 will also feature it.
Here's an article describing differences between WITH RECURSIVE and CONNECT BY.
As far as I remember, Mozilla-like software has not problem with being run from a network share. So if you're talking stationary PCs, then just have them run Mozilla from the network.
I worked at a TV station a couple of years ago. At that time, we - like most everyone else - streamed using Real's codecs and formats. Since then, they have completely switched to WMV3 (for Windows Media Player 9+). I don't know the history surrounding the decision to switch, but I can certainly think of many reasons.
Everyone with just a microgram of brains could see Microsoft coming, leveraging their platform monopoly - BUT also very much helped by the fact that almost everybody hated Real's (client) player-software, and pretty much still do:
This leads me to my question: Why on Earth did you sleep for so long?! You must have seen competition coming; in such a senario: why did you strive so hard to make foes with everyone?
The Helix project was years over-due (probably too late to make a difference, by now), and your recent (and incomplete) end-user improvements on the web-site were even more over-due.
Tell me: Exactly what major changes in your organization (such as getting rid of the jerks who stressed a goofy revenue-from-deived-end-users strategy) have your completed that should make me think again about trusting your strategy, products and distribution system? I'm asking because I don't want to waste a second keeping in touch with the development of the Helix projects, unless I'm convinced that your company has turned 180 degrees.
As far as I can see, the SQL standards (looked at SQL:2003) don't specify a way to change a column's type. It does, however, specify how certain auxiliary column properties (such as its default value) can be changed.
The standard defines how to drop a column:
<drop behaviour> is RESTRICT by default, but may also be CASCADE (although the CASCADE behaviour is only an optional feature, as far as I can see). If set to RESTRICT, then the column drop will be denied if another database object is dependent on the column. If CASCADE is specified, then dependent objects are dropped, too.
Wrong. DB2 is rather close to implementing SQL:1999's recursiveness. There is an article comparing Oracle and DB2's recursive features.
-And a patch exists for adding Oracle-style recursion to PostgreSQL.
Whether WITH RECURSIVE or CONNECT BY work effectively is another question. I haven't seen any experimental articles considering this.
Without using recursive SQL, different encoding schemes exist for the purpose:
Joe Celko has recently published a book dedicated to the subject.
See my RDBMS links page for more on this.
You are wrong. The SQL:2003 standard specifies IDENTITY. See http://troels.arvin.dk/db/rdbms/#mix-identity
I'm not impressed. What you have described is not out of the ordinary. And the big problem still exists: What if someone with a key logger picks up the PIN codes, etc., what's from stopping them from misusing that information? (Except for the fact that it's actually hard to steal money electronically: Where can one transfer the stolen money to without revealing the thief?)
This is where the one-time codes come into play, and that's what's interesting about the cited article. My bank uses a system equivalent to the one mentioned from Sweden; initially, I feared that it would be too much of a hazzle to have to look up one-time codes and type them for each transfer, but it's no problem, actually. (I don't perform very many transfers, though.)
The latest OpenSSH PAM-problem affects versions 3.7.x of (the "Portable" version of) OpenSSH. Red Hat has never released anything newer than version 3.5, so no workarounds are needed. Don't expect updated packages from Red Hat for this particular OpenSSH vulnerability.
Generally, if you can, include these statements in your sshd_config file:
Protocol 2
PasswordAuthentication no
ChallengeResponseAuthentication no
This means that the only way to access the SSH service is with key-based authorization, using the modern variant ("2") of the SSH protocol. Make sure you are comfortable with key-based authorization before turning off the non-key based methods as mentioned above.
If you use the lines above, then make sure that you don't override them by having PAMAuthenticationViaKbdInt in your sshd_config.
After this, your sshd will have to "speak" only one protocol, and it will have less authentication entry points (meaning less potentially buggy complexity).
The Red Hat/Fedora merger sounds OK. One thing, though: In the past, it has been very difficult to verify the PGP signatures in Fedora's packages: The packager's public keys were hard - sometimes impossible - to find. I have looked through the fedora.redhat.com web site, hoping to find out how they plan to manage PGP-keys and signatures in the new Fedora distribution, but I couldn't find any information. Does anyone know?
SQL:1999 has been defined for years and some of the DBMSs have actually implemented some of its features. Yes, SQL:1999 is big and perhaps bloated in comparison with SQL-92, but it's not that bad if you concentrate on the core parts. Some of the news in SQL:1999 are actually clarifications on stuff in SQL-92.
SQL:2003 will probably be agreed on this year.
- So I find it strange to use the more than a decade old SQL-92 as the platform for a book published in the year 2002.
Another thing: I'd say it's "ISO SQL" nowadays (or ISO/IEC SQL), not "ANSI SQL".
Apart from that, I've put the book on my Safari bookshelf and look forward to reading (at least parts of) it. Unfortunately, it seems that Safari's index of the book is currently lost.
I like the approach where you start by thinking about the standard way to do it, and then try to squeeze your design into a real-World product. It's too bad that the official standard isn't online; fortunately, it's possible to get something close to being official. When trying to set up an initial, standards compliant schema, it's nice to have an evaluation-installation of Mimer SQL to play with. I wish it were open source or at least had an official price tag.
I expect that the book could be relevant in connection with a page about SQL differences that I've started writing, after having had to port some SQL from PostgreSQL to MSSQL.
I'm waiting for a system where the loudspeaker cables are digital, as well as the crossover. Each loudspeaker driver would then have its own DA-converter and loudspeaker. In combination with calibration systems like the one mentioned in the article, I would expect a very nice system.
Or maybe such a system already exists?
<Which it is, or might as well be.
Agree.
Unfortunately, java is pretty much "run once - run nowhere". Of course, all Slashdotters have an up-to-date JRE, but the fact is that JREs are a rare sight. It's easy to blame Microsoft for not distributing java with Windows any more. But seriously: When even Linux distributions have trouble distributing a java runtime enviroment, then there is _probably_ something wrong with the licenses associated with java technologies.
What's worse: Because Java is nowhere to be found, there is lack of consensus about where to put java libraries, how to handle classpaths, etc.
When I think of the non-programming-related software I use regularly, _no_ Java-based software comes to mind. (Except for a few JSP-based web-pages if that counts as software.)
I'm not very optimistic about Javas future, I'm afraid. Which is sad: It's a beautiful language (which will be even more beautiful when it get generics).
Fortunately, there are other good technologies than Java. A combination of Python (when speed is not that important), C/C++ (when you need speed and control of every bit) and perhaps C# (in the future) is actually all I ask for.
How does IPv6 change UDP to prevent spoofed segments?