The original Walkman had an ambient sound button and two little mikes at the front. The button was yellow and would allow you to hear whomever was trying to talk to you by simply pressing said yellow button. Usually they were saying "what the hell is that thing?"
I always wondered why they got rid of that feature.
Yeah, I had one of those when I was really young. I thought that was the coolest feature. I'd use it as a spy device and what-not.
These days, it's pull off the headphones and/or pull the iPod out of the pocket/case and hit pause. Far less convenient.
Re:HowTo IPv6 for the Home
on
The State of IPv6
·
· Score: 2, Informative
I've always built my own firewalls (it's easy, and I trust them), and since about 1995 or 1996, they've had IPv6 support.
I had a tunnel over my cable to the 6bone via http://www.freenet6.net/...but I recently shut my cable off so I need to bring it up over DSL, just haven't got around to it.
OS X configures up IPv6 by default, as far as I can tell. My router solicitations help, of course. I've got two IPv6 subnets (wired and wireless). All's well.
Unfortunatly is was mostly negative development. All you see on TV these days are annoying commercials, re-re-reruns, commercials, F-movies, commercials, "reality" shows, commercials, talkshows and commercials.
You forgot commercials.
I see that, like most of us, you also don't see (or at least pay attention to) commercials.
All of the/etc/rc* scripts are written in pdksh, but root's shell is tcsh.
I've not used OpenBSD in a while, but last time I did, it didn't come with tcsh. root's shell was csh. If this is a problem for you, it's because you're doing something wrong (i.e. logging in as root).
There is no/etc/profile, which is unfathomable to me.
I am incredibly annoyed by some of the customization that is coming with recent Linux systems I've used. For example, I signed up for a web host that has craploads of completions that create a behavior I'm completely not used to and is not useful to me. I sometimes have a need to rename a file to a variation of itself where I type `mv fi[tab] fi[tab]^H2' or something...except on this system, the second parameter of mv completes to a directory only, so I can't rename it, or grab more than one file at a time, or anything else like that with completions. Let me customize my own shell.
OpenBSD does not have methods to easily start/stop services (i.e. redhat "service network restart") for reasons of nostalgia. FreeBSD is somewhat more forward-thinking in this.
I think FreeBSD is using NetBSD's implementation of the individual rc scripts in a directory with built-in dependencies. The scripts themselves are far more simple than classic SysV scripts and can do a lot more. Not to mention the dependencies are done correctly so you don't end up with fifteen S99 scripts like I've always seen.
We're also a java shop. We use struts in our app and I've built a thing that allows us to write struts actions in jython or bsh (the latter just to prove the interface was generic, I don't much like bsh).
Right tool for the job and all. I can reliably process a *tremendous* amount of data with my ocaml apps very quickly. And I like the language.:)
I tend to chain a few things together. I've got processes that consist of bourne shell scripts, python, jython, ocaml, and pure java apps. And the whole thing's documented in a web server/wiki written in smalltalk.:)
There's something to be said for trying to establish standards, but it takes many tools to build something useful.
ocaml is slowly migrating from the tool that I use when speed is a priority to the general purpose tool for which python used to always be the first choice.
1. Would it be faster in C or C++? Sure 2. Would the change of a defect increase in C or C+ vs python: Sure, far more chance to screw something up 3. Is it worth rewriting in order to get 1200 million firewall events / day instead of 300 on a single server? Not now - I'd rather keep it in python and just split the processing across two servers than implement in C or C++. Of course, we could always go to psycho, or rewrite small parts first. But eventually, if those steps failed to keep the load manageable, then *maybe* i'd consider rewriting in C/C++.
There are more languages than python and C and C++ (two different languages).
I had a similar issue with some of my log processing apps at work. I prototyped all of the original stuff in python, and in some cases it was taking 23 hours to process the daily logs. I tried various languages for rewrites. I really dislike C as a language, but I rewrote some of the slowest components in C while looking at other languages.
This was a very good thing for me, as it's how I discovered O'Caml. It's a very pleasant language to use...very high level, functional, generic, statically typed (but types are inferred, so you write like you're writing dynamically typed code), and mind bogglingly fast. It's not uncommon to see stuff like this from new users:
I'm trying to find information on building/using Arch for Win32. I see some references to using it under Cygwin - less than ideal, IMHO. Sure, it depends on patch, tar and diff, but I have MinGW builds of these and they are readily available for Win32. Maybe I'll futz around and see if it's possible.
Sorry, I don't do windows, so I can't offer much help there.
It's really just that much different from other programming environments, which makes it hard for open source projects for open source systems to catch up. cygwin gets you there, but people always complain about cygwin (I see it here as well as in reference to postgres).
But I don't do windows. For years, people have been telling me that someday, it's going to be required for my job. It hasn't been, and I can't imagine why it ever would be a requirement for anything (circular requirements aside).
Is the 'tla' binary all you need? I thought it shelled out to tar, diff, rcs, apache and other processes to do the "real" work.
Well, most modern systems have a reasonable tar, diff, diff3, and patch. Why should tla reimplement them?
That said, arch is a specification. An implementation of tla might implemement tar, diff, diff3, and patch internally and avoid shelling out.
But yes, the current system does require a few basic parts of the system. On some systems (i.e. solaris), I've had to provide some of the gnu utilities.
That lets me talk to my standard OS X Apache server, or an ftp server, or local filesystem, etc... I don't have to create a special apache2 based web server with its webdav and deltav and bdb and whatever else they might need now.
Arch avoids the whole issue by never rewriting or removing files which have been added to the repository
I don't think this can be emphasized enough. The most important thing a revision control system can do for me is guarantee the safety of my code (as it's my work product and the most valuable thing I've got). Knowing that the history of my project is accurate because it is never modified (by the arch tools, anyway) is very important to me.
I can't really dump CVS until there is support for the major IDEs (Including EMACS!).
Apparently one of the xemacs developers uses arch, and I've read about various emacs arch integrations.
Personally, I don't really see the point of an IDE in general (and I get plenty done). The most important thing to me is keeping my source safe. Having replicates, knowing that changesets are *not* ever modified, etc...gets me there. Toolkit integration is secondary.
That said, I do have vim adding arch-tags to code when I add it. I can just sit around making changes to code and then then create a commit message and check it all in when I'm done, knowing any file I added, deleted, or modified will be picked up transparently.
I also use xcode for some projects, and get the same effects.
But I am waiting for subversion to finish their version 1, so I can kill -9 cvs forever
Try tla (arch)'s 1.1. It's far easier to set up and fairly well along (as far as I can tell, it does more, and does so more reliably and flexibly). Or if you want, try the 1.2 betas and get gpg support.
I haven't really checked out GNU Arch - it seems to claim to support changesets (groups of changes), and thus I presume atomic commits, better/faster branching and merging and so on - the other good stuff that CVS is lacking. My guess is that Arch is even less mature than Subversion though, since it appears to have not been around as long.
Try arch, it's amazing. I've thrown away CVS at my installation in favor of arch. It works quite a bit better than anything else I've used (which is pretty much RCS, CVS, and perforce) and it's simple enough to understand without even having the source code.
It doesn't require anything special to get going. The one tla binary you build when you download the sources (self-contained) allows you to create/manage archives (repositories) on local filesystems, webdav, ftp, sftp, etc... I run my main repository on webdav and have it replicated to about five locations (two out of cron, three to laptops manually).
From any of the replications, I can build a branch to a local filesystem (like I do on my laptops when I'm traveling) and develop within the branch until I get home. At home, I merge my changesets back into the main archive and all's well.
And it's so easy, I don't have to read the documenation each time. I've never processed a branch in CVS without having to look up the documentation. Same with perforce and building branches.
As far as maturity, there was a call for cryptographically signed changesets for various revision control systems. Arch's flexibility allowed this functionality to go from design to implementation in probably less than a week's worth of work (I didn't follow it that well, being the holiday and all). People have already converted their archives so all the changesets are signed, while still maintaining backwards compatibility.
The reason? It's so simple, yet so flexible. Subversion is incredibly complicated, which reduces its flexibility. I can't be the first person who gave up a few times on subversion because I don't run Linux and couldn't get all of the pieces working on any of my systems. tla (C version of arch) is a download, configure, make. Then you can either make install or just do what I do, take the ``tla'' binary and put it everywhere you want it.
Marriage is now equated in many peoples mind with a "license" to fuck someone
Remember, a wife isn't a special case in a rape suit. Not that that's a problem, except the definition of ``rape'' in California basically covers any sexual act a woman regrets and can prove.
Overall, I think there's something wrong with this country...I just can't quite put my finger on it.
I got in an argument with a windows adminstrator at work a few years ago about this. He'd always tell me how wonderful Microsoft is and cite things that had nothing to do with MS. One day I told him I was taking away their DHCP server because they weren't doing much with it and we needed to use it for the Unix servers. He told me that Windows would do it better because DHCP is a Microsoft invention. I pointed him to the standard and asked him to show me the word ``Microsoft.'' Nothing, of course.
This particular RFC (3004) you're referencing is regards to a new option to be added to DHCP. That they'll extend a protocol is not news.
Re:Props! You have too much time.
on
Cube House
·
· Score: 1
Wow, I tried to do the same thing once with a shared cube (we'd removed the walls from the middle). My cubemate brought in that same type of camo, except it had been to burning man and smelled like it, so we aborted the project.
Re:Digitemp alternative ?
on
Linux Toys
·
· Score: 1
Just buy the stuff from www.ibutton.com or Dallas Semi (or whatever they're called now...Maxim?) directly. It's cheap. I think I've been paying around $5 per sensor.
I'll leave finding protocol information on the other standards used and supported by Exchange Server (SMTP, NNTP, IMAP4, POP3, LDAP, etc) as an exercise for the interested reader.
Sure, I get to use the exchange server at work via imap4. It works OK most of the time. It'll frequently stop informing of new mail (but let me remain connected and read certain things, though many functions fail to wokr), but I have workarounds for getting most of my mail most of the time...
except some attachments. Anyone ever get those attachments that work great if you're using outlook, but for IMAP users, they come through as ``>>'' or something like that? I almost missed the Christmas party to that one.
And LDAP? Apparently not in my installation. I had to request IMAP access specifically.
And which one of these protocols let me see and manipulate these calendars that people keep talking about. I think it's a stupid calendar model to begin with (I much prefer iCal's model), but I'd be interested in making a translator if I knew what the protocol was.
Apparently newer versions allow you to access some of the stuff with WebDAV, but good luck getting people who barely understand what their working with now to upgrade.
Look at big companies like IBM and SGI, or small ones like Red Hat. Why do they spend their own R&D dollars improving Linux, and then releasing the source code publicly? Why didn't they do the same thing with a BSD Unix?
Big companies were using BSD unix in their products for a while (and continue to do so). They were not obligated to release the code, which is why you didn't see quite as much.
Linux is about mind share, though. SGI didn't release XFS to Linux because, as a company, they thought Linux needed a better filesystem. They wanted a significant contribution to something that's on a lot of people's minds. Linux is big business now, and everyone wants to have a piece of it. It's not because it's GPL, it's because it's Linux.
But the GPL license gives them dual motivators: an obligation to release new code as payment for using old, and an assurance that code they do give out won't be turned against them by a competitor.
I don't think that describes ``dual motivators.'' It sounds like they have a restriction on their freedom vs. the BSD license (freedom to produce a product from the thing without giving away their work product), but a consolation that says that at least anyone looking at the code will also have to release their changes.
That does *not* keep their code from being used against them. One company may be great at producing code while another is great at getting money from it. The code the first company releases is available to anyone, so they don't really have anything special to offer after it's written. If this company were the only source of this implementation (i.e. closed-source), they would then have an advantage.
There's lots of GPL code, but I don't see lots of companies going out of their way to produce GPL code.
But yeah, Linux is big business right now because people can use it at home, and it solves many enterprise problems. I imagine we'll see postgres doing the same thing at some point for the same reasons. The thing is, postgres can do it more quietly since there's no requirement to ship tweaks and stuff.
I could of course be wrong but I'm pretty sure there aren't 31-bit architectures.
Right, but that doesn't necessarily dictate how the 32 bits of 32-bit architectures should work. I ran into a problem in a programming system that used 30-bit numbers when I tried to represent time as an int. The programming system wanted two bits of the int for itself (or maybe it was just one and the sign, can't remember).
It's a pity the MySQL guys are trying to reinvent Oracle.
If that's their motivation, they're missing by far. Postgres is *way* closer to oracle.
Postgres does have a plPHP as you're describing. I wouldn't say that being a weakly typed language or having a standard API for talking to a particular type of database make for a good language.
But postgres allows you to make that decision for yourself. Stored functions and procedures may be written in any language and it's easy to plug them in.
Ruby, perl, python, tcl, and I believe java language (there's a pljava project, but I'm not sure what the status is on that one) plugins are all available for postgres. Many of them have been there for a while.
Slashdot Mirror
The original Walkman had an ambient sound button and two little mikes at the front. The button was yellow and would allow you to hear whomever was trying to talk to you by simply pressing said yellow button. Usually they were saying "what the hell is that thing?"
I always wondered why they got rid of that feature.
Yeah, I had one of those when I was really young. I thought that was the coolest feature. I'd use it as a spy device and what-not.
These days, it's pull off the headphones and/or pull the iPod out of the pocket/case and hit pause. Far less convenient.
I've always built my own firewalls (it's easy, and I trust them), and since about 1995 or 1996, they've had IPv6 support.
...but I recently shut my cable off so I need to bring it up over DSL, just haven't got around to it.
I had a tunnel over my cable to the 6bone via http://www.freenet6.net/
OS X configures up IPv6 by default, as far as I can tell. My router solicitations help, of course. I've got two IPv6 subnets (wired and wireless). All's well.
Do you work for the mob?
The printers don't refuse to print money, they refuse to print what they think might be money.
Also, keep in mind, it's legal to produce one-sided color images of US currency as long as it's big or small enough.
You forgot commercials.
I see that, like most of us, you also don't see (or at least pay attention to) commercials.
then charges $130 per client per version for it. They don't release any changes.
I paid more like $40 per client and (at least in previous versions), have used the released source to work around bugs in things I'm doing.
All of the /etc/rc* scripts are written in pdksh, but root's shell is tcsh.
/etc/profile, which is unfathomable to me.
I've not used OpenBSD in a while, but last time I did, it didn't come with tcsh. root's shell was csh. If this is a problem for you, it's because you're doing something wrong (i.e. logging in as root).
There is no
I am incredibly annoyed by some of the customization that is coming with recent Linux systems I've used. For example, I signed up for a web host that has craploads of completions that create a behavior I'm completely not used to and is not useful to me. I sometimes have a need to rename a file to a variation of itself where I type `mv fi[tab] fi[tab]^H2' or something...except on this system, the second parameter of mv completes to a directory only, so I can't rename it, or grab more than one file at a time, or anything else like that with completions. Let me customize my own shell.
OpenBSD does not have methods to easily start/stop services (i.e. redhat "service network restart") for reasons of nostalgia. FreeBSD is somewhat more forward-thinking in this.
I think FreeBSD is using NetBSD's implementation of the individual rc scripts in a directory with built-in dependencies. The scripts themselves are far more simple than classic SysV scripts and can do a lot more. Not to mention the dependencies are done correctly so you don't end up with fifteen S99 scripts like I've always seen.
And let's not even get started on Mac OS X.
Why not?
We're also a java shop. We use struts in our app and I've built a thing that allows us to write struts actions in jython or bsh (the latter just to prove the interface was generic, I don't much like bsh).
:)
:)
Right tool for the job and all. I can reliably process a *tremendous* amount of data with my ocaml apps very quickly. And I like the language.
I tend to chain a few things together. I've got processes that consist of bourne shell scripts, python, jython, ocaml, and pure java apps. And the whole thing's documented in a web server/wiki written in smalltalk.
There's something to be said for trying to establish standards, but it takes many tools to build something useful.
ocaml is slowly migrating from the tool that I use when speed is a priority to the general purpose tool for which python used to always be the first choice.
1. Would it be faster in C or C++? Sure
l .
2. Would the change of a defect increase in C or C+ vs python: Sure, far more chance to screw something up
3. Is it worth rewriting in order to get 1200 million firewall events / day instead of 300 on a single server? Not now - I'd rather keep it in python and just split the processing across two servers than implement in C or C++. Of course, we could always go to psycho, or rewrite small parts first. But eventually, if those steps failed to keep the load manageable, then *maybe* i'd consider rewriting in C/C++.
There are more languages than python and C and C++ (two different languages).
I had a similar issue with some of my log processing apps at work. I prototyped all of the original stuff in python, and in some cases it was taking 23 hours to process the daily logs. I tried various languages for rewrites. I really dislike C as a language, but I rewrote some of the slowest components in C while looking at other languages.
This was a very good thing for me, as it's how I discovered O'Caml. It's a very pleasant language to use...very high level, functional, generic, statically typed (but types are inferred, so you write like you're writing dynamically typed code), and mind bogglingly fast. It's not uncommon to see stuff like this from new users:
http://caml.inria.fr/archives/200401/msg00301.htm
I'm trying to find information on building/using Arch for Win32. I see some references to using it under Cygwin - less than ideal, IMHO. Sure, it depends on patch, tar and diff, but I have MinGW builds of these and they are readily available for Win32. Maybe I'll futz around and see if it's possible.
Sorry, I don't do windows, so I can't offer much help there.
It's really just that much different from other programming environments, which makes it hard for open source projects for open source systems to catch up. cygwin gets you there, but people always complain about cygwin (I see it here as well as in reference to postgres).
But I don't do windows. For years, people have been telling me that someday, it's going to be required for my job. It hasn't been, and I can't imagine why it ever would be a requirement for anything (circular requirements aside).
Is the 'tla' binary all you need?
I thought it shelled out to tar, diff, rcs, apache and other processes to do the "real" work.
Well, most modern systems have a reasonable tar, diff, diff3, and patch. Why should tla reimplement them?
That said, arch is a specification. An implementation of tla might implemement tar, diff, diff3, and patch internally and avoid shelling out.
But yes, the current system does require a few basic parts of the system. On some systems (i.e. solaris), I've had to provide some of the gnu utilities.
That lets me talk to my standard OS X Apache server, or an ftp server, or local filesystem, etc... I don't have to create a special apache2 based web server with its webdav and deltav and bdb and whatever else they might need now.
Arch avoids the whole issue by never rewriting or removing files which have been added to the repository
I don't think this can be emphasized enough. The most important thing a revision control system can do for me is guarantee the safety of my code (as it's my work product and the most valuable thing I've got). Knowing that the history of my project is accurate because it is never modified (by the arch tools, anyway) is very important to me.
I can't really dump CVS until there is support for the major IDEs (Including EMACS!).
Apparently one of the xemacs developers uses arch, and I've read about various emacs arch integrations.
Personally, I don't really see the point of an IDE in general (and I get plenty done). The most important thing to me is keeping my source safe. Having replicates, knowing that changesets are *not* ever modified, etc...gets me there. Toolkit integration is secondary.
That said, I do have vim adding arch-tags to code when I add it. I can just sit around making changes to code and then then create a commit message and check it all in when I'm done, knowing any file I added, deleted, or modified will be picked up transparently.
I also use xcode for some projects, and get the same effects.
But I am waiting for subversion to finish their version 1, so I can kill -9 cvs forever
Try tla (arch)'s 1.1. It's far easier to set up and fairly well along (as far as I can tell, it does more, and does so more reliably and flexibly). Or if you want, try the 1.2 betas and get gpg support.
I haven't really checked out GNU Arch - it seems to claim to support changesets (groups of changes), and thus I presume atomic commits, better/faster branching and merging and so on - the other good stuff that CVS is lacking. My guess is that Arch is even less mature than Subversion though, since it appears to have not been around as long.
Try arch, it's amazing. I've thrown away CVS at my installation in favor of arch. It works quite a bit better than anything else I've used (which is pretty much RCS, CVS, and perforce) and it's simple enough to understand without even having the source code.
It doesn't require anything special to get going. The one tla binary you build when you download the sources (self-contained) allows you to create/manage archives (repositories) on local filesystems, webdav, ftp, sftp, etc... I run my main repository on webdav and have it replicated to about five locations (two out of cron, three to laptops manually).
From any of the replications, I can build a branch to a local filesystem (like I do on my laptops when I'm traveling) and develop within the branch until I get home. At home, I merge my changesets back into the main archive and all's well.
And it's so easy, I don't have to read the documenation each time. I've never processed a branch in CVS without having to look up the documentation. Same with perforce and building branches.
As far as maturity, there was a call for cryptographically signed changesets for various revision control systems. Arch's flexibility allowed this functionality to go from design to implementation in probably less than a week's worth of work (I didn't follow it that well, being the holiday and all). People have already converted their archives so all the changesets are signed, while still maintaining backwards compatibility.
The reason? It's so simple, yet so flexible. Subversion is incredibly complicated, which reduces its flexibility. I can't be the first person who gave up a few times on subversion because I don't run Linux and couldn't get all of the pieces working on any of my systems. tla (C version of arch) is a download, configure, make. Then you can either make install or just do what I do, take the ``tla'' binary and put it everywhere you want it.
Marriage is now equated in many peoples mind with a "license" to fuck someone
Remember, a wife isn't a special case in a rape suit. Not that that's a problem, except the definition of ``rape'' in California basically covers any sexual act a woman regrets and can prove.
Overall, I think there's something wrong with this country...I just can't quite put my finger on it.
This is really good stuff. I hope more people see this.
Didn't they have something to do with DHCP?
I got in an argument with a windows adminstrator at work a few years ago about this. He'd always tell me how wonderful Microsoft is and cite things that had nothing to do with MS. One day I told him I was taking away their DHCP server because they weren't doing much with it and we needed to use it for the Unix servers. He told me that Windows would do it better because DHCP is a Microsoft invention. I pointed him to the standard and asked him to show me the word ``Microsoft.'' Nothing, of course.
This particular RFC (3004) you're referencing is regards to a new option to be added to DHCP. That they'll extend a protocol is not news.
Wow, I tried to do the same thing once with a shared cube (we'd removed the walls from the middle). My cubemate brought in that same type of camo, except it had been to burning man and smelled like it, so we aborted the project.
Just buy the stuff from www.ibutton.com or Dallas Semi (or whatever they're called now...Maxim?) directly. It's cheap. I think I've been paying around $5 per sensor.
I've used a program called ``findbugs'' for java code that was pretty impressive.
I'll leave finding protocol information on the other standards used and supported by Exchange Server (SMTP, NNTP, IMAP4, POP3, LDAP, etc) as an exercise for the interested reader.
Sure, I get to use the exchange server at work via imap4. It works OK most of the time. It'll frequently stop informing of new mail (but let me remain connected and read certain things, though many functions fail to wokr), but I have workarounds for getting most of my mail most of the time...
except some attachments. Anyone ever get those attachments that work great if you're using outlook, but for IMAP users, they come through as ``>>'' or something like that? I almost missed the Christmas party to that one.
And LDAP? Apparently not in my installation. I had to request IMAP access specifically.
And which one of these protocols let me see and manipulate these calendars that people keep talking about. I think it's a stupid calendar model to begin with (I much prefer iCal's model), but I'd be interested in making a translator if I knew what the protocol was.
Apparently newer versions allow you to access some of the stuff with WebDAV, but good luck getting people who barely understand what their working with now to upgrade.
Look at big companies like IBM and SGI, or small ones like Red Hat. Why do they spend their own R&D dollars improving Linux, and then releasing the source code publicly? Why didn't they do the same thing with a BSD Unix?
Big companies were using BSD unix in their products for a while (and continue to do so). They were not obligated to release the code, which is why you didn't see quite as much.
Linux is about mind share, though. SGI didn't release XFS to Linux because, as a company, they thought Linux needed a better filesystem. They wanted a significant contribution to something that's on a lot of people's minds. Linux is big business now, and everyone wants to have a piece of it. It's not because it's GPL, it's because it's Linux.
But the GPL license gives them dual motivators: an obligation to release new code as payment for using old, and an assurance that code they do give out won't be turned against them by a competitor.
I don't think that describes ``dual motivators.'' It sounds like they have a restriction on their freedom vs. the BSD license (freedom to produce a product from the thing without giving away their work product), but a consolation that says that at least anyone looking at the code will also have to release their changes.
That does *not* keep their code from being used against them. One company may be great at producing code while another is great at getting money from it. The code the first company releases is available to anyone, so they don't really have anything special to offer after it's written. If this company were the only source of this implementation (i.e. closed-source), they would then have an advantage.
There's lots of GPL code, but I don't see lots of companies going out of their way to produce GPL code.
But yeah, Linux is big business right now because people can use it at home, and it solves many enterprise problems. I imagine we'll see postgres doing the same thing at some point for the same reasons. The thing is, postgres can do it more quietly since there's no requirement to ship tweaks and stuff.
I could of course be wrong but I'm pretty sure there aren't 31-bit architectures.
Right, but that doesn't necessarily dictate how the 32 bits of 32-bit architectures should work. I ran into a problem in a programming system that used 30-bit numbers when I tried to represent time as an int. The programming system wanted two bits of the int for itself (or maybe it was just one and the sign, can't remember).
It's a pity the MySQL guys are trying to reinvent Oracle.
If that's their motivation, they're missing by far. Postgres is *way* closer to oracle.
Postgres does have a plPHP as you're describing. I wouldn't say that being a weakly typed language or having a standard API for talking to a particular type of database make for a good language.
But postgres allows you to make that decision for yourself. Stored functions and procedures may be written in any language and it's easy to plug them in.
Ruby, perl, python, tcl, and I believe java language (there's a pljava project, but I'm not sure what the status is on that one) plugins are all available for postgres. Many of them have been there for a while.