It's probably a little different than the "Ahnold" action movies you were weaned on.
It's a lot different then the action movies you've grown up on. In fact, when I was serving in Somalia, the situation was closer to "Blackhawk Down" than "Stripes".
Most Americans associate Jane Fonda far more with her exercise video.
Then most Americans are ignorant of the real reasons to hate the treasonous scum.
Before you mod this "Flamebait", go read that page and tell me whether it's reasonable to completely detest that loser and everything she stands for. John Kerry seriously needs to distance himself as far as possible.
You make it sound like someone picked him out of a distant crowd. Have you even looked at the picture? He's positioned inches away from her. To get any closer, she would've had to have been sitting in his lap.
This isn't some tangential "two people in the same crowd" story; it's not like they were both at Woodstock or some other large, amorphous rally.
Of course she wasn't "Hanoi Jane" at the time of the picture, she visited Hanoi 2 years later.
I mentioned that in my original post.
Nor was he friends with Fonda, they were both speakers at the same rally.
So the hung out with the same groups, sat near each other at rallies, and shared the same political convictions. They may not've been living together, but that's a little closer to the devil than I'd like for someone running for Commander-In-Chief.
Sure. Any time he's willing to public declare that he does not share Jane Fonda's views, I'll be happy to consider his statements. To my knowledge, this has not yet happened. If not, why?
Frankly, I don't care what politicians did when they were younger, because well all do a few dumb things. I would like him to at least acknowledge that he had poor choice in friends at that point.
I think it's interesting that the media is following the forged photo and completely ignoring the fact that the man claiming now to be pro-military and bragging about his service record has been proven to be one of Hanoi Jane's fellow protesters. Granted, she was not yet personally, directly responsible for killing American servicemen, but I somehow doubt her claims that she suddenly had a radical change of heart between the time they were hanging out together and when she starting partying in North Vietnam.
Don't take this wrong, but you really need to upgrade your hardware. Even a cheap PCI Ensoniq will work much better than your old ISA card.
I'm all for backward compatibility where reasonable, but there's just not a whole lot of motive for the ALSA team to spend time supporting legacy equipment when it's so extremely cheap to buy newer stuff.
I don't know what else to suggest. On my Debian desktop (P4/2.4GHz), artsd uses 0% when idle, and 10% when playing MP3s with Noatun. I wish you luck with your setup, but I'm out of ideas.
The advantage is that rsync will cheerfully resume where it left off if the drive is goofed to the point that you can't copy it in one pass. Just repeat the process as necessary, and each time rsync will copy a bit (well, hopefully more than one bit) more.
But still only one sound source at the time, right? KDE does not give status sounds when playing a mpeg clip, Mplayer refuses to start as long as XMMS is playing?
That's not true anymore. As a quick test, I opened three xterms and used mpg123 to play an MP3 in each. The sound was mixed as expected. Go into the KDE Control Center / Sound & Multimedia / Sound System / Hardware (tab). Be sure the audio device is set to ALSA. I'd bet that your programs are using ALSA's OSS emulation, which is still single-use-only (AFAIK).
By the way, is there any reason you keep killing artsd? Especially since explicitly configuring it to use ALSA (instead of letting it auto-detect), it just sits idle in the background on my machine using 0% of the CPU when I'm not using it. I've heard some people mention that they don't like it, but I never heard any legitimate complaints about it (that is, those not referring to ancient versions, "some guy from EFNet said...", or extreme mis-configuration).
What are you talking about? If you're using a LFS system, then I could see that you might have to manually rework a few things. All of the major distributions have made upgrading relatively painless, though, so you can't just say that "you wont get everything to work perfectly" without a lot of work.
Besides, one of the strengths of Linux is that there's a pretty clean divide between kernel and userspace. The vast majority of software on any given system is completely kernel-agnostic. That's why most Linux software runs well on FreeBSD systems, and I assure you that the difference between the FreeBSD and Linux kernels is far larger than the difference between 2.4 and 2.6.
I've never had problems, although I'd primarily used old ESS-1371 cards for my limited audio needs (anything can play an MP3 reasonably well).
I recently bought an SB-Live and decided to switch to ALSA. Debian made this as easy as choosing my soundcard from a list, and it automagically worked. I had the same experience at the office with my PC's onboard Intel 8x0 sound - no manual configuration was necessary.
Sound used to be a pain in the neck, but I pretty much consider it a solved problem now (except for maybe exotic boards). ALSA does an awesome job of getting it right with minimal user intervention.
We were running the open source version, I'm almost certain. I came into the company after the server was well established, so I'm not completely sure of what was current at the time of installation.
Furthermore, I have no idea of what the backup procedure was before I came onboard. I do know that the database contained many errors when I started, and that they weren't readily apparent until I started auditing the backup logs and conducting tests.
Yes, you are correct - gbak didn't work at all on the corrupted files.
Your entire argument is 100% correct, and also applies in exactly the same way to the grandparent post. I certainly didn't mean to imply that you could backup a running database with tar, and I don't think that the grandparent did either.
2 - I'm not surprised. Of course, I wrote that three years ago.
3 - We were using SuperServer.
4 - gfix and gbak segfaulted every time we tried to run them, even after moving the whole mess onto a new server.
5 - See also my program that I mentioned in the post you replied to.:-)
YMMV, of course, but on our server IB was big, slow, and crashy, and supported features that the shop wasn't using at that time. It was a complete loss for us.
Yes. It didn't work at all on corrupted tables. I originally wrote the "dbreplicate" that I mentioned in an earlier post for the precise reason that gbak would always segfault when it tried to read certain tables, and it was absolutely critical that we be able to salvage as much information from those as possible (off-topic - the tables had silently failed longer ago than the rotation cycle of our regular backups before we ever found the corruption).
You asserted that Firebird is a maintenance-free system. It provably is not, as there is plenty of anecdotal evidence that many people have had problems with it over the years. I won't argue that it wasn't stable on your system, because that would be silly, but saying that one instance of a product runs well is not the same as saying that the product itself runs well.
I might've been over-assertive, but you wouldn't believe the hassle that this particular system put me and my employers through.
Follow the first "Interbase" link in my post to read the explanation I'd written earlier. Some of the problems might've been fixed by now, but it boils down to this: PostgreSQL is widely used, fast, supports the same features, and has major commercial backing. Firebird's main strength is that is used to be Interbase and is a good thing for people with legacy applications built around that system. It's almost like a comparison of Python and COBOL - both are Turing complete, sure, but I'd hate to do new development on the latter unless I worked in a shop that depended on it.
The whole database is just one file (at least was) so a simple tar or zip will backup your stuff.
That's all well and good, except that you're completely wrong. First, you can back up any database that uses OS-level files using tar and gzip - that's certainly nothing special for Interbase/Firebird. Second, we experienced table corruptions constantly that resulted in rows that were still present in the table, but couldn't be fetched. Relational integrity means jack squat when referenced rows suddenly cease to be accessible.
Interbase/Firebird obviously worked for at least some people, or else it would've been altogether dropped years ago, but it's bitten enough people that it's just not accurate to call it "maintence-free" (unless that has a backhand slam at the abyssmal state of the administrative tools, and you meant "-free" as in "-not-capable-of").
Its main claim is that it sucks less than Interbase, so if you have to support a horrid Interbase installation, then upgrading to Firebird would probably be a good idea.
On the other hand, I hated having to administer that hell-pit of a server so badly that I wrote a migration program to transfer entire databases from Firebird to PostgreSQL. I can't describe how happy I was to switch a fairly large online store's backend to a modern platform.
I don't know why, but that line cracked me up. It was a very Gary Larson sort of thing.
Do your own homework. Here's a start.
It's a lot different then the action movies you've grown up on. In fact, when I was serving in Somalia, the situation was closer to "Blackhawk Down" than "Stripes".
Then most Americans are ignorant of the real reasons to hate the treasonous scum.
Before you mod this "Flamebait", go read that page and tell me whether it's reasonable to completely detest that loser and everything she stands for. John Kerry seriously needs to distance himself as far as possible.
This isn't some tangential "two people in the same crowd" story; it's not like they were both at Woodstock or some other large, amorphous rally.
I mentioned that in my original post.
Nor was he friends with Fonda, they were both speakers at the same rally.
So the hung out with the same groups, sat near each other at rallies, and shared the same political convictions. They may not've been living together, but that's a little closer to the devil than I'd like for someone running for Commander-In-Chief.
Frankly, I don't care what politicians did when they were younger, because well all do a few dumb things. I would like him to at least acknowledge that he had poor choice in friends at that point.
Oh, wait, only one of the pictures of them together was forged, while the other has been verified.
I think it's interesting that the media is following the forged photo and completely ignoring the fact that the man claiming now to be pro-military and bragging about his service record has been proven to be one of Hanoi Jane's fellow protesters. Granted, she was not yet personally, directly responsible for killing American servicemen, but I somehow doubt her claims that she suddenly had a radical change of heart between the time they were hanging out together and when she starting partying in North Vietnam.
How would that be any different than now?
I'm all for backward compatibility where reasonable, but there's just not a whole lot of motive for the ALSA team to spend time supporting legacy equipment when it's so extremely cheap to buy newer stuff.
I don't know what else to suggest. On my Debian desktop (P4/2.4GHz), artsd uses 0% when idle, and 10% when playing MP3s with Noatun. I wish you luck with your setup, but I'm out of ideas.
The advantage is that rsync will cheerfully resume where it left off if the drive is goofed to the point that you can't copy it in one pass. Just repeat the process as necessary, and each time rsync will copy a bit (well, hopefully more than one bit) more.
That's not true anymore. As a quick test, I opened three xterms and used mpg123 to play an MP3 in each. The sound was mixed as expected. Go into the KDE Control Center / Sound & Multimedia / Sound System / Hardware (tab). Be sure the audio device is set to ALSA. I'd bet that your programs are using ALSA's OSS emulation, which is still single-use-only (AFAIK).
By the way, is there any reason you keep killing artsd? Especially since explicitly configuring it to use ALSA (instead of letting it auto-detect), it just sits idle in the background on my machine using 0% of the CPU when I'm not using it. I've heard some people mention that they don't like it, but I never heard any legitimate complaints about it (that is, those not referring to ancient versions, "some guy from EFNet said...", or extreme mis-configuration).
Besides, one of the strengths of Linux is that there's a pretty clean divide between kernel and userspace. The vast majority of software on any given system is completely kernel-agnostic. That's why most Linux software runs well on FreeBSD systems, and I assure you that the difference between the FreeBSD and Linux kernels is far larger than the difference between 2.4 and 2.6.
I recently bought an SB-Live and decided to switch to ALSA. Debian made this as easy as choosing my soundcard from a list, and it automagically worked. I had the same experience at the office with my PC's onboard Intel 8x0 sound - no manual configuration was necessary.
Sound used to be a pain in the neck, but I pretty much consider it a solved problem now (except for maybe exotic boards). ALSA does an awesome job of getting it right with minimal user intervention.
Furthermore, I have no idea of what the backup procedure was before I came onboard. I do know that the database contained many errors when I started, and that they weren't readily apparent until I started auditing the backup logs and conducting tests.
Yes, you are correct - gbak didn't work at all on the corrupted files.
Your entire argument is 100% correct, and also applies in exactly the same way to the grandparent post. I certainly didn't mean to imply that you could backup a running database with tar, and I don't think that the grandparent did either.
2 - I'm not surprised. Of course, I wrote that three years ago.
3 - We were using SuperServer.
4 - gfix and gbak segfaulted every time we tried to run them, even after moving the whole mess onto a new server.
5 - See also my program that I mentioned in the post you replied to. :-)
YMMV, of course, but on our server IB was big, slow, and crashy, and supported features that the shop wasn't using at that time. It was a complete loss for us.
Yes. It didn't work at all on corrupted tables. I originally wrote the "dbreplicate" that I mentioned in an earlier post for the precise reason that gbak would always segfault when it tried to read certain tables, and it was absolutely critical that we be able to salvage as much information from those as possible (off-topic - the tables had silently failed longer ago than the rotation cycle of our regular backups before we ever found the corruption).
I might've been over-assertive, but you wouldn't believe the hassle that this particular system put me and my employers through.
Follow the first "Interbase" link in my post to read the explanation I'd written earlier. Some of the problems might've been fixed by now, but it boils down to this: PostgreSQL is widely used, fast, supports the same features, and has major commercial backing. Firebird's main strength is that is used to be Interbase and is a good thing for people with legacy applications built around that system. It's almost like a comparison of Python and COBOL - both are Turing complete, sure, but I'd hate to do new development on the latter unless I worked in a shop that depended on it.
That's all well and good, except that you're completely wrong. First, you can back up any database that uses OS-level files using tar and gzip - that's certainly nothing special for Interbase/Firebird. Second, we experienced table corruptions constantly that resulted in rows that were still present in the table, but couldn't be fetched. Relational integrity means jack squat when referenced rows suddenly cease to be accessible.
Interbase/Firebird obviously worked for at least some people, or else it would've been altogether dropped years ago, but it's bitten enough people that it's just not accurate to call it "maintence-free" (unless that has a backhand slam at the abyssmal state of the administrative tools, and you meant "-free" as in "-not-capable-of").
On the other hand, I hated having to administer that hell-pit of a server so badly that I wrote a migration program to transfer entire databases from Firebird to PostgreSQL. I can't describe how happy I was to switch a fairly large online store's backend to a modern platform.
Somewhere out there, in a quiet and secluded landfill, a Harvard Mark I furiously spins in its grave...
Be sure to LART the person who installed it for you. telnetd is not part of Debian's base installation, so it had to have been manually added later.