Yes, it supports stored procedures. Ini fact, you can use about a dozen languages to write them: plPG/SQL (which is similar to Oracle's procedural SQL), C, C++, Perl, Python, Java, Ruby, R, TCL, PHP and (I believe) Javascript.
The reason VACUUM is a seperate command in PostgreSQL is to improve transaction performance. Any multiversioning database has to clean up old versions of rows. You can either do it during each transaction, which imposes a variable-length overhead to each transaction, or you can choose to do the cleanup at a later time, such as when the DB isn't busy. PostgreSQL chose the latter option. However, there have been many improvements to the VACUUM code in 7.4 and 8.0beta which significantly lower its overhead, so you can choose to run the autovacuum daemon. This is a contributed module which monitors internal PostgreSQL statistics and automatically runs a VACUUM when needed.
It's rather odd that you're seeing this behavior, since MVCC is designed specifically to prevent it. What is your transaction isolation level set to? Also, why aren't you using a SEQUENCE for car_type_id?
Does it not bother anyone that this is still only available to ydl.net Enhanced members, which means you need to pay about $90 to get it? I thought Linux was supposed to be free.:P
But if the kernel is properly developed, then it shouldn't matter. Besides, most user-space apps shouldn't be making calls that could vary that much from one kernel to another.
Regarding pmap, I meant something comparable to Solaris pmap, not the limited Linux pmap. On Solaris, pmap can display unresolved dynamic links, hardware page sizes, swap information, etc. And on Solaris 10, pmap will explicitely label the stack, can work on a core file,
Regarding ppgsz, I know that x86 chips do support multiple page sizes - Linux 2.6 includes so-called "hugetlbfs" support, but this works by allocating a fixed number of 2 MB pages. You can't set the page size on a per-process level, like you can on Solaris. Without the ability to do this, oprofile's TLB output isn't so useful. See this article on Sun Blueprints for how Solaris handles it.
Actually, it's based on reading kerneltrap and on my own experiences. There are still fairly large changes going into the "stable" tree (check out LWN's kernel page each week). And why shouldn't you be using a vanilla kernel on a production machine?
Regarding the max number of file descriptors, you need to set the rlim_fd_max and rlim_fd_cur settings in/etc/system.
Btw, when will Linux finally get tools like pmap, trapstat, lockstat, ppgsz, libumem, etc? I was a longtime Linux user, but now that I'm using Solaris more, I find them hard to live without.
Not really, Sun was a major workstation company in the mid and late '80s, long before the.bomb days. Sun made a lot of many during the.com craze, but they were a major player before that as well.
As for Solaris/x86, I'm sorry, but the facts just don't back you up. When Sun most recently tried to kill Solaris/x86, it was the user community who compalined to Sun to get it back. See the thread here for more info. Further, if you look at Blastwave's main mirror stats, you'll see that the x86 packages are downloaded quite a lot (granted, not as much as the sparc packages). See here and here.
As for Linux on SPARC, I have tried it. Over the years, I've had about a dozen SPARC machines, both 32- and 64-bit. Some versions of Linux were slightly faster on older 32-bit machines, but even on something as old as an Ultra 2, Solaris is a faster, especially the newer versions.
Re:Note this is only for Solaris x86
on
Linux Apps On Solaris
·
· Score: 2, Informative
Well, it's about a year old, but you might want to take a look at this story on osnews that compared RedHat 9 and Solaris 9.
Funny, I have the opposite impression of Linux 2.6. The lack of a proper development tree is pretty disturbing. And there are way too many patches going into an allegedly "stable" tree.
It seems you have no perspective on things. Sun has been around a lot longer than the ".bomb wave." They made a lot of pioneering developments on Unix (NFS, PAM, etc). They're still one of the largest Unix vendors in the world. Solaris 10 is looking very nice (and has some capabilities that it will take Linux years to clone).
Sun's management realized that they're in financial trouble, and they've taken steps to correct that. They're pushing Solaris x86 hard now, and they've introduced very competitively priced Opteron-based workstations and servers. Solaris licensing is now cheaper than RedHat's in many cases. And like Apple, Sun is trying to innovate their way out of trouble, rather than become yet another Linux/x86 vendor (since that strategy worked so well for SGI).
Why should Sun push Linux on SPARC? Solaris is faster on SPARC, and Sun already supports it. Where is there any evidence that there's a large market for Linux/SPARC? Further, gcc still has issues on SPARC. Your own argument is inconsistent -- SPARC-based systems cost more than x86-based ones. They always have and likely always will. x86 has economy of scale; SPARC doesn't (and SPARC is, arguably, better designed with more fault-tolerance and management abilities). If "Sun's base is scientists and enginers who have no control over purchasing" then why would Sun push Linux/SPARC when they have Solaris/SPARC?
But the ability to run Linux apps natively on x86 hardly seems to matter, when you can just download GPL'ed source and compile away with good chance of success.
Yes and no. I'm a maintainer for Blastwave, a community project which ports and packages open-source software for Solaris. Belive me, a lot of the GNU-based projects have a lot of cruft in them, and it can often be quite a pain getting them compiled on Solaris (gcc in particular is quite troublesome). But I don't think this is why Sun is pushing this technology. It's really geared towards running binary-only Linux/x86 software on Solaris. It's the same rationale behind FreeBSD's Linux ABI support, for example.
So in essence Sun is saying here "you can run your linux apps on your legacy Sun workstations", and not much else.
No.
"Legacy Sun workstations" all use SPARC-based processors. This announcement is solely about compatibility for x86 Linux apps on Solaris x86. Sun just announced their first x86-based workstations (I'm not counting the ancient 386-based one from the '80s), which run Solaris x86, Linux and Windows. All Sun is trying to do is to make life easier on their customers who want to run Solaris x86.
Not really. This isn't about owning Linux, per se. It's about owning the distro IBM is using. There are only a handful of viable commercial Linux distros out there, essentially RedHat and SuSE. Those are two most popular, and commercial apps are almost exclusively certified for those two. If IBM is moving away from RedHat (due to their licensing and pricing games), and Sun owns SuSE, then that leaves Sun in a pretty good position.
Yeah, you could just say "just use Debian/Gentoo/whatever," but if Oracle & co. only run (certified) on RH and SuSE, you're out of luck.
Well, I wasn't even speaking of 2 people with 2 accounts. If you wanted to have 2 people streaming music from the same account, with AE you're out of luck.
None of this changes my original point - that Airport Express is a glorified wireless speaker. The point of control is still the computer, not the device itself. So unless you're in fromt of your machine, you can't do anything other than change the volume. With other devices (Tivo w/ HMO, Roku SoundBridge, etc), you can use a remote to control your music. There isn't much appeal in having to run over to my mac, FUS to my account and change playlists if I wanted to change a song.
If you have 2 Airport Express units in your house, and 1 mac, then you can only play music to one of them, since the AE is basically a wireless speaker. But if you have 2 Rokus, they each connect to the mac and play different songs, because they use the iTunes Sharing protocol (DAAP). As far as iTunes is concerned, it's just two machines connected to it.
I was thinking more from a multi-user perspective. If I'm in the kitchen and want to listen to Song A, but my roommate is in the living room and wants to listen to Song B, where songs A and B are on the same mac, then there's no way to do this with Airport Express.
I really wish Apple would license their FairPlay DRM scheme to other manufacturers. I can understand them not wanting to license it to Real, or to other portable mp3 player manufacturers, but they should license it to companies who make in-home music players. Off the top of my head, Tivo (with the Home Media Option), RokuLabs, and SlimDevices (the SqueezeBox) come to mind. Unfortunately, Apple considers the iTunes Music Store only as a way to sell more iPods.
Slashdot Mirror
Yes, it supports stored procedures. Ini fact, you can use about a dozen languages to write them: plPG/SQL (which is similar to Oracle's procedural SQL), C, C++, Perl, Python, Java, Ruby, R, TCL, PHP and (I believe) Javascript.
Well, if you're using a decent computer, like a Mac or a Sun, you don't need to use a floppy disk to update your firmware :P
MySQL's optimized count() function only exists for MyISAM tables. On transaction-safe tables, like InnoDB, you still have to do a full table scan.
Also, PostgreSQL doesn't do row-level locking. It uses MultiVersion Concurrency Control to avoid locking outright.
The reason VACUUM is a seperate command in PostgreSQL is to improve transaction performance. Any multiversioning database has to clean up old versions of rows. You can either do it during each transaction, which imposes a variable-length overhead to each transaction, or you can choose to do the cleanup at a later time, such as when the DB isn't busy. PostgreSQL chose the latter option. However, there have been many improvements to the VACUUM code in 7.4 and 8.0beta which significantly lower its overhead, so you can choose to run the autovacuum daemon. This is a contributed module which monitors internal PostgreSQL statistics and automatically runs a VACUUM when needed.
It's rather odd that you're seeing this behavior, since MVCC is designed specifically to prevent it. What is your transaction isolation level set to? Also, why aren't you using a SEQUENCE for car_type_id?
Dude, it was a joke. Hence the ":P" after my comment.
Does it not bother anyone that this is still only available to ydl.net Enhanced members, which means you need to pay about $90 to get it? I thought Linux was supposed to be free. :P
But if the kernel is properly developed, then it shouldn't matter. Besides, most user-space apps shouldn't be making calls that could vary that much from one kernel to another.
Regarding pmap, I meant something comparable to Solaris pmap, not the limited Linux pmap. On Solaris, pmap can display unresolved dynamic links, hardware page sizes, swap information, etc. And on Solaris 10, pmap will explicitely label the stack, can work on a core file,
Regarding ppgsz, I know that x86 chips do support multiple page sizes - Linux 2.6 includes so-called "hugetlbfs" support, but this works by allocating a fixed number of 2 MB pages. You can't set the page size on a per-process level, like you can on Solaris. Without the ability to do this, oprofile's TLB output isn't so useful. See this article on Sun Blueprints for how Solaris handles it.
Actually, it's based on reading kerneltrap and on my own experiences. There are still fairly large changes going into the "stable" tree (check out LWN's kernel page each week). And why shouldn't you be using a vanilla kernel on a production machine?
Regarding the max number of file descriptors, you need to set the rlim_fd_max and rlim_fd_cur settings in /etc/system.
Btw, when will Linux finally get tools like pmap, trapstat, lockstat, ppgsz, libumem, etc? I was a longtime Linux user, but now that I'm using Solaris more, I find them hard to live without.
Not really, Sun was a major workstation company in the mid and late '80s, long before the .bomb days. Sun made a lot of many during the .com craze, but they were a major player before that as well.
As for Solaris/x86, I'm sorry, but the facts just don't back you up. When Sun most recently tried to kill Solaris/x86, it was the user community who compalined to Sun to get it back. See the thread here for more info. Further, if you look at Blastwave's main mirror stats, you'll see that the x86 packages are downloaded quite a lot (granted, not as much as the sparc packages). See here and here.
As for Linux on SPARC, I have tried it. Over the years, I've had about a dozen SPARC machines, both 32- and 64-bit. Some versions of Linux were slightly faster on older 32-bit machines, but even on something as old as an Ultra 2, Solaris is a faster, especially the newer versions.
Well, it's about a year old, but you might want to take a look at this story on osnews that compared RedHat 9 and Solaris 9.
Funny, I have the opposite impression of Linux 2.6. The lack of a proper development tree is pretty disturbing. And there are way too many patches going into an allegedly "stable" tree.
It seems you have no perspective on things. Sun has been around a lot longer than the ".bomb wave." They made a lot of pioneering developments on Unix (NFS, PAM, etc). They're still one of the largest Unix vendors in the world. Solaris 10 is looking very nice (and has some capabilities that it will take Linux years to clone).
Sun's management realized that they're in financial trouble, and they've taken steps to correct that. They're pushing Solaris x86 hard now, and they've introduced very competitively priced Opteron-based workstations and servers. Solaris licensing is now cheaper than RedHat's in many cases. And like Apple, Sun is trying to innovate their way out of trouble, rather than become yet another Linux/x86 vendor (since that strategy worked so well for SGI).
Why should Sun push Linux on SPARC? Solaris is faster on SPARC, and Sun already supports it. Where is there any evidence that there's a large market for Linux/SPARC? Further, gcc still has issues on SPARC. Your own argument is inconsistent -- SPARC-based systems cost more than x86-based ones. They always have and likely always will. x86 has economy of scale; SPARC doesn't (and SPARC is, arguably, better designed with more fault-tolerance and management abilities). If "Sun's base is scientists and enginers who have no control over purchasing" then why would Sun push Linux/SPARC when they have Solaris/SPARC?
Yes and no. I'm a maintainer for Blastwave, a community project which ports and packages open-source software for Solaris. Belive me, a lot of the GNU-based projects have a lot of cruft in them, and it can often be quite a pain getting them compiled on Solaris (gcc in particular is quite troublesome). But I don't think this is why Sun is pushing this technology. It's really geared towards running binary-only Linux/x86 software on Solaris. It's the same rationale behind FreeBSD's Linux ABI support, for example.
No.
"Legacy Sun workstations" all use SPARC-based processors. This announcement is solely about compatibility for x86 Linux apps on Solaris x86. Sun just announced their first x86-based workstations (I'm not counting the ancient 386-based one from the '80s), which run Solaris x86, Linux and Windows. All Sun is trying to do is to make life easier on their customers who want to run Solaris x86.
Sun never threatened to buy Novell. It was essentially a random musing in a blog post by Schwartz that got blown way out of proportion.
Have you checked out Solaris 10? There is a lot of revolutionary stuff in there. DTrace, Predictive Self-healing, and Zones all come to mind.
Not really. This isn't about owning Linux, per se. It's about owning the distro IBM is using. There are only a handful of viable commercial Linux distros out there, essentially RedHat and SuSE. Those are two most popular, and commercial apps are almost exclusively certified for those two. If IBM is moving away from RedHat (due to their licensing and pricing games), and Sun owns SuSE, then that leaves Sun in a pretty good position.
Yeah, you could just say "just use Debian/Gentoo/whatever," but if Oracle & co. only run (certified) on RH and SuSE, you're out of luck.
Not if you're using a wireless connection from the Mac, since OS X will disconnect your network connections when you FUS out.
Well, I wasn't even speaking of 2 people with 2 accounts. If you wanted to have 2 people streaming music from the same account, with AE you're out of luck.
None of this changes my original point - that Airport Express is a glorified wireless speaker. The point of control is still the computer, not the device itself. So unless you're in fromt of your machine, you can't do anything other than change the volume. With other devices (Tivo w/ HMO, Roku SoundBridge, etc), you can use a remote to control your music. There isn't much appeal in having to run over to my mac, FUS to my account and change playlists if I wanted to change a song.
Sorry, let me clarify.
If you have 2 Airport Express units in your house, and 1 mac, then you can only play music to one of them, since the AE is basically a wireless speaker. But if you have 2 Rokus, they each connect to the mac and play different songs, because they use the iTunes Sharing protocol (DAAP). As far as iTunes is concerned, it's just two machines connected to it.
I was thinking more from a multi-user perspective. If I'm in the kitchen and want to listen to Song A, but my roommate is in the living room and wants to listen to Song B, where songs A and B are on the same mac, then there's no way to do this with Airport Express.
Right, which is why Airport Express isn't all that interesting - it's basically a fancy wireless speaker for your powerbook. The other big problem with Airport Express is that you can only play to one of them at a time. So if you have one AE in your kitchen, another in your living room and one in your bedroom, you can only play a song on one of them at a time. Something like the Roku SoundBridge/a would be a lot more useful, except that it can't play protected AAC files (and it's about twice the price of the Airport Express).
I really wish Apple would license their FairPlay DRM scheme to other manufacturers. I can understand them not wanting to license it to Real, or to other portable mp3 player manufacturers, but they should license it to companies who make in-home music players. Off the top of my head, Tivo (with the Home Media Option), RokuLabs, and SlimDevices (the SqueezeBox) come to mind. Unfortunately, Apple considers the iTunes Music Store only as a way to sell more iPods.