To some degree, they must work as they are still being produced and laptop sales are on a dramatic rise.
Where are you getting that from? I searched pretty thoroughly and didn't find any numbers to support that conclusion. In fact, the only numbers I found were from mid-2005, and showed a moderate, but consistent, decline for the previous year and a half to some of Apple's lowest numbers in a decade. I'm not sure of the viability of the source however, so I'm left wondering where the actual numbers lie.
Come on, if even slashdot can come up with applications that are far more marketable then "advertise on my back", why can't Philips?
I'm not sure anyone here has really come up with any applications more marketable than advertising. If you think they have, you're likely underestimating advertising expenditures. In an age where even packing materials are printed with marketing material, it's a massive source of revenue.
How come they aren't warning Apple about their iPod naming?
Because unlike Apple, they don't have a history of being overly litigious. Apple has sued or threatened to everyone from their own customers, to Google.
The definition of "store value" refers to the ability of an entity as a deposit for later financial recoup. Specifically, this is a feature of negotiable currency, which is referred to as its "store of value" nature. Since the article specifically uses the phrase "store value", the article is referring to a negotiable financial store. If the value were a perceived value by the owner, the phrase "store value" would not have been used.
In other words, it's not perceived value, it's a specific value of a monetary nature. You're referring to what could be ambiguous syntax, but the use of a specific fiscal term is what I'm referring to.
It specifically says there is more store value to the account than to the credit card used to pay the subscription fees. Store value, not perceived worth by the customer themselves.
'For a lot of the customers out there, there is more store value on their MMO characters than there is on the credit card with which they pay for the account,'
If that was really true, MMO's would let users pay their monthly fees with virtual gold.
Take for example, expose's ability to show you every window you have open at the same time. This is trivial to do. But it's such an amazingly useful thing and it's implemented elegantly.
Those of us who've been using 3DDesktop under *nix for the past four or five years would agree.
While I'm not a regular OS X user these days I really haven't seen a single thing in any release that was a completely original idea from Apple, except for the bits they took from their previous OSes (System7-9, especially). Implementing other people's idea in a visually appealing fashion has been Apple's only strength. Now if they could just make it *efficient* as well...
I see many comments remarking on how our boneheaded legislators, courts, and members of the executive imperium are "stupid" for creating these sorts laws. I'd suggest that these laws are rarely result of stupidity (although there certainly is no shortage of that particular commodity in DC), but part of a larger concerted effort to monitor, restrict, and control Americans' access and content on the Internet.
Certainly, this may have been voted for by the bulk of legislators in an unwitting fashion, but the individuals who crafted the bill are almost certainly aware of the issues it raises and precedents it sets.
It's subtle, slow, and nefarious. The most effective tyrannies aren't installed via coup, but produced through erosion. Add this into the lump of wiretaps, data mining, network data snooping, and "secret" CIA prisons detaining individuals (including American citizens) without acknowledgement of their existence, and you start to get a pretty clear piture of where all this is headed.
I dearly love my country, but I fear that what the government has already become is far from what most of us beleive it is, and is a mockery of what we learned in your civics class back in high school.
For a company that has a guiding creed of "Don't do evil", I wonder why I keep smelling traces of sulphur when their name comes up. Not all evil involves point-blank fraud, or requires a malicious nature.
We have indeed paid licensing fees, but we're not a commercial enterprise, and fit under the free use license. We even support MySQL because we use it in several places, and it's the right thing to do, not because we have to.:)
You wanted a custom build, of your preferred tools, rather than using the existing tools. This is a problem with *any* "Enterprise Level" scenario.
RHEL includes MySQL and Postfix as part of the install images. It offered by RH as a supported product. Perhaps this is a "if we didn't at least include it, no one would use RHEL" inclusion, but if that is the case, it should have been included in the extras channel, not in the core distribution. This is MySQL and Postfix we're talking about, neither of which is esoteric tech.
Beyond this, I stated in the original post that every route offered to us by the default packages included with RHEL failed to offer a working solution. It's a far different thing to support custom-built pacakges than it is to edit configurations. The latter is what RHEL advertises, really (enterprise-readiness). The former is what it delivers.
I'm wasn't trying to roll out some radical new service here, it's email. Rolling out a robust, flexible, capable email service under an enterprise linux should have been so well implemented that a monkey with a fascination for shiny red buttons could have rolled it out....That's why you were being steered away from a slower database technology into a faster directory technology.
Enterprise Server (ES, which was chosen for this solution) is specifically marketed by RH as their "solution for small to mid-range servers used for the majority of today's business computing". Application Server (AS) is the large-scale offering, where I'd expect to be steered towards LDAP, but not in ES. We're not serving millions of users, just several hundred with that one server.
It's quite possible that you are one of the very few users who wanted to run a mail server architecture based on a slower *database* technology metaphor,
I'd disagree with you there. While the bulk of email accounts in the world are bound to be on large scale services, the bulk of the email *systems* are almost certainly going to tilt towards a smaller median size. I can't give any numbers to corroborate this, but logic leads me to that conclusion.
In my book, we've got the right solution for our size. Lookup info is stored in a fast (yes, not as fast as LDAP, but infinitely more accessible by existing tools) database. Mailboxes are handled virtually, with maildirs under XFS on the back end. LDAP would be faster, yes, but far more setup and management intensive (I'd end up doing all of the account management or writing a significant number of webapps to let people do it, instead of just dropping in an off-the-shelf solution).
In any case, the particular server in question wasn't mail for the entire enterprise I work with, but instead a department within the larger organization. I should have been more clear about that, I suppose. We do have an LDAP directory available (NDS), but it's organization-wide and doesn't provide support as we need it for department or workgroup level needs, only for the enterprise-level ones (depending on who you ask).
Yes, I know. If I could fix that, I would. *grumble grumble*
While I'm confident in my abilities, I am not assuming I know better than you do because I'm well educated, highly experienced in my field (12 years of enterprise systems engineering and support), intelligent, experienced, hard-working and rational.
I do believe though that after working on a rather complex system (complex enough that the two previous implementations during the past four years by competent and well-experienced persons had problematic issues), finding and implementing a stable, robust, and responsive system which requires little hands-on maintenance, that I certainly know IT better than YOU do.
By your comments, you work for a web hosting company. You provide services to people who provide services to users, and handle the end-user support. I work providing services directly to clients in an enterprise environment. YOUR work environment is nothing like MINE. I can say THAT with confidence, because from late 2000 to early 2002 I was an engineer for an international enterprise-level hosting company, and honestly, it was far more cut and dried than what I work with now.
You have never seen nor do you know the environment, requirements, or history of the system I have only briefly discussed, and yet you assume that I've built something of duct-tape and cardboard. Nothing could be further from the truth. From the backing hardware to the end-user tools, every part of that mail system was chosen after careful consideration and testing. Every step was discussed, tested, and approved by the client. It's also working beautifully.
I'm sorry you take affront to my signing posts with 'Regards', it wasn't intended with any intent in either direction. I sign my personal correspondence the same way, so it's a natural closing for me when conversing with another person. Although I think you're behaving boorishly, I don't feel compelled to respond in kind. It could just be that you're having a bad day (who doesn't), or that Postfix shot your dog and MySQL stole your wife.
While it's become apparent that you do not wish me the same, I do wish you regards, and may you be happy with your work, choices, opinions, and whatever else it takes to let you sleep well at night.
We did investigate this as a possibility, but as of our last look (about 4 montsh ago) the only third party commercial package support for Postfix with MySQL enabled that we found was for RHEL3 (two different vendors). This could have changed by this point, but since I have the system stable and in production, it's unlikely to get revisited any time soon with enough priority to receive funding.
Although it would have made things easier at the time, now it would just be reimplementing a working solution.
Keeping a server running isn't difficult, it's the amount of time it takes to keep them ALL going that gets to be a bother.
The nature of my work (as is the case with most of us, I'd guess) is that there are always new services and systems needing to be built (or rebuilt, as they age) while existing services rarely get mothballed, and so even a modicum of building packages easily snowballs over time into an all-consuming task. The less time I have to spend looking backwards, the more I can keep us moving forward.
It boils down to time. If maintaining that single mail system was my only job, I'd be on easy street, but at best that systems encompasses but a sliver of my job responsibilities. I prefer to avoid spending hours each week building and pushing custom packages to servers, if I can implement a solution which is more hands-off.
The big selling point of enterprise systems for large organizations is the centralized management and administration tools, which often become useless when you aren't using prebuilt packages from the vendor.
The other problem here is that every environment is different, and the environment a server works in can significantly change the requirements, as well as the time investment, for installing and maintaining.
While I'm very experienced with Linux and very at-ease in most *nix environments, I'm not a one-person shop, and while I can build and maintain complex, custom systems doesn't mean the guy who's running that server six months from now has my skill set. Part of being a good administrator is making the job easy for whoever gets called to fix a server when you're on vacation, or after you leave.
I'm at a loss as to why you think I have no argument, my case is stated clearly. I provided a direct reference to my original post which stated an exact answer to your comment.
Neither Exim nor Sendmail provided an out-of-the-box solution which met our specific our needs under RHEL4. I never claimed that setting up systems shouldn't take work, I merely stated that RHEL did not support basic functionality which we desired, that was written into the packages themselves but not enabled at compile time.
My reference to you being a troll is that you assume that what I built is a "POS" that is on the verge of a breakdown. If you do not wish to be categorized as a troll, perhaps you should stop cursing travelers from underneath your bridge.
I would ask you to reread the paragraph in my original post in which I stated that no matter which route I took (sendmail, exim, or postfix), in order to get the features we needed, I would have been stuck in the same boat.
Although I'm guessing this was just a troll, the server is working beautifully, with no unexpected downtime in eight months (the only downtime came from two reboots following kernel updates).
I'd ask though that you please refrain from using your broad brush to paint me as incompetent simply because you do not understand the mechanics of a real-world environment of which you are not a part.
I work for a large organization which has supported services including computer-based mail since the mid-70's. We have a lot of standing requirements to meet in order to replace existing systems. Most of the choices we've made are quite possibly the same ones you would have made, if faced with the environment, resources, and needs we have.
I'm also pretty certain if we paid one of the many companies which provide commercial Debian support the amount of money we're paying Red Hat, we would receive satistfactory service. We've done it before.
With Ellison... Red Hat is unfortunately not meeting the needs of its users. Although we agree, our reasoning is different.
A significant part of my job is Linux sysadmin work, using licensed Red Hat Enterprise products. The tools are (for the most part) useful, reliable, and complete. The problem is, the enterprise distros are severely lacking in their packages and features.
Recently, while building a distributed mail system (multiple servers in the mail chain, multidomain support and virtual mailboxes) on RHEL4,
The recommended version for mail and database servers (Enterprise Server) does indeed have packages for Postfix (our preferred mail app) and MySQL available, but none of the Postfix packages have MySQL support enabled (Postfix has good MySQL support, including DB connection caching through a proxy interface). This effectively meant that none of the dozens of excellent mail administration tools out there would be available to us, and we couldn't put together a mail system that didn't rely on flat files in some fashion or another, without setting up parallel services (LDAP) solely to support mail services.
I built the server once on Red Hat ES and when all was said and done, I ended up with seven major components having to be compiled either from source, or rebuilt RPMs with modified spec files and/or compile flags. This doesn't bother me, except for the fact that the whole reason my employer pays thousands upon thousands of dollars for an enterprise Linux was so that we could stick to standard packages, so that if a particular machine has issues, we don't have to rely on one person to know what's going on.
I can't imagine we're the only paying client Red Hat has that wants to run a mail server that relies on a database server. It wouldn't chagrin me to change mail server or database packages (I've used most of the common ones), but looking deeper just led me to the realization that no matter which packages or paths I took, I'd still be stuck with the same issues.
Until Red Hat gains better flexibility, timeliness, and awareness of their client needs, perhaps Ellison is on the ball with his visions of supporting the clients directly. I'm guessing he won't be supporting MySQL, though. And after rebuilding the server on Debian stable, with all features we desired being available in the core distro, we're happier.
And I'm the only guy here who groks Debian well enough to run it, sigh.
Oops, always read twice before posting. Second sentence in the second paragraph should have read:
"They haven't completed a single assessment of their own efficacy, and the last note about this is that in 2005, the project to determine how to assess their own operations was begun, but has not been completed."
This is called the Air Marshall system (yes, I know they're not FBI), and nobody has ever griped about it being an invasion of privacy or a waste of money.
Well, I'd certainly complain if they started rifling through my luggage mid-flight.
The biggest complaint one could really have is that a rather expensive program at $660 million dollars a year of funding, with very little to show for it. They haven't completed a single assessment of their own efficacy, and the last note about this is that in 2005, the project to determine how much less completed guidelines one how to assess their own operations.
Attacks between 1990 and September 10, 2001 involving terrorists aboard U.S. aircraft: 0 Federal Air Marshals in active commercial flight duty, same period: max. 50 (33 agents on 9/11/2001)
Attacks following September 11, 2001 involving terrorists aboard U.S. aircraft: 0 Federal Air Marshals in active commercial flight duty, same period: "thousands" (numbers no longer released)
Indeed, the only real news about FAM operations seems to be when they mistakely shot and killed a passenger who was distressed over a spousal argument and stormed off of the plane upon their arrival in Miami, in the mistaken belief he was a terrorist.
So hey, for millions of added dollars, we've gotten the same efficacy we had before the single milestone event that caused the agency's expansion. Zero. But on the plus side, there's one less tourist in Miami.
I suppose the moral of this is the same as ever other post: for the right price, your government can certainly instill in you an illusion of security. The most effective ways of fighting crime tend to assume everyone is a criminal to begin with, and work from there.
Yeah yeah, but hey, I use it under Linux too.;) In any case, it's the one that best fit my hand after trying out several. The angle , size, and slope make it near-perfect for painless mousing, all day long, and it's accurate as they come.
If you're a lefty, you're out of luck as far as I know, because I've not seen any good trackballs which are left-hand specific. Trackballs (more to the point, thumb-balls) are great... I used to like the Logitech ones, but the MS ones fit my hand much better.
Slashdot Mirror
To some degree, they must work as they are still being produced and laptop sales are on a dramatic rise.
Where are you getting that from? I searched pretty thoroughly and didn't find any numbers to support that conclusion. In fact, the only numbers I found were from mid-2005, and showed a moderate, but consistent, decline for the previous year and a half to some of Apple's lowest numbers in a decade. I'm not sure of the viability of the source however, so I'm left wondering where the actual numbers lie.
Come on, if even slashdot can come up with applications that are far more marketable then "advertise on my back", why can't Philips?
I'm not sure anyone here has really come up with any applications more marketable than advertising. If you think they have, you're likely underestimating advertising expenditures. In an age where even packing materials are printed with marketing material, it's a massive source of revenue.
How come they aren't warning Apple about their iPod naming?
Because unlike Apple, they don't have a history of being overly litigious. Apple has sued or threatened to everyone from their own customers, to Google.
Ichigo-
Fair enough.
Cheers,
The definition of "store value" refers to the ability of an entity as a deposit for later financial recoup. Specifically, this is a feature of negotiable currency, which is referred to as its "store of value" nature. Since the article specifically uses the phrase "store value", the article is referring to a negotiable financial store. If the value were a perceived value by the owner, the phrase "store value" would not have been used.
In other words, it's not perceived value, it's a specific value of a monetary nature. You're referring to what could be ambiguous syntax, but the use of a specific fiscal term is what I'm referring to.
Cheers,
The quote reads as I stated, not as you claim.
It specifically says there is more store value to the account than to the credit card used to pay the subscription fees. Store value, not perceived worth by the customer themselves.
'For a lot of the customers out there, there is more store value on their MMO characters than there is on the credit card with which they pay for the account,'
If that was really true, MMO's would let users pay their monthly fees with virtual gold.Take for example, expose's ability to show you every window you have open at the same time. This is trivial to do. But it's such an amazingly useful thing and it's implemented elegantly.
Those of us who've been using 3DDesktop under *nix for the past four or five years would agree.
While I'm not a regular OS X user these days I really haven't seen a single thing in any release that was a completely original idea from Apple, except for the bits they took from their previous OSes (System7-9, especially). Implementing other people's idea in a visually appealing fashion has been Apple's only strength. Now if they could just make it *efficient* as well...
Man, I read this on BitTorrent like, two weeks ago.
I see many comments remarking on how our boneheaded legislators, courts, and members of the executive imperium are "stupid" for creating these sorts laws. I'd suggest that these laws are rarely result of stupidity (although there certainly is no shortage of that particular commodity in DC), but part of a larger concerted effort to monitor, restrict, and control Americans' access and content on the Internet.
Certainly, this may have been voted for by the bulk of legislators in an unwitting fashion, but the individuals who crafted the bill are almost certainly aware of the issues it raises and precedents it sets.
It's subtle, slow, and nefarious. The most effective tyrannies aren't installed via coup, but produced through erosion. Add this into the lump of wiretaps, data mining, network data snooping, and "secret" CIA prisons detaining individuals (including American citizens) without acknowledgement of their existence, and you start to get a pretty clear piture of where all this is headed.
I dearly love my country, but I fear that what the government has already become is far from what most of us beleive it is, and is a mockery of what we learned in your civics class back in high school.
For a company that has a guiding creed of "Don't do evil", I wonder why I keep smelling traces of sulphur when their name comes up. Not all evil involves point-blank fraud, or requires a malicious nature.
We have indeed paid licensing fees, but we're not a commercial enterprise, and fit under the free use license. We even support MySQL because we use it in several places, and it's the right thing to do, not because we have to. :)
That's a good observation.
Regards-
You wanted a custom build, of your preferred tools, rather than using the existing tools. This is a problem with *any* "Enterprise Level" scenario.
RHEL includes MySQL and Postfix as part of the install images. It offered by RH as a supported product. Perhaps this is a "if we didn't at least include it, no one would use RHEL" inclusion, but if that is the case, it should have been included in the extras channel, not in the core distribution. This is MySQL and Postfix we're talking about, neither of which is esoteric tech.
Beyond this, I stated in the original post that every route offered to us by the default packages included with RHEL failed to offer a working solution. It's a far different thing to support custom-built pacakges than it is to edit configurations. The latter is what RHEL advertises, really (enterprise-readiness). The former is what it delivers.
I'm wasn't trying to roll out some radical new service here, it's email. Rolling out a robust, flexible, capable email service under an enterprise linux should have been so well implemented that a monkey with a fascination for shiny red buttons could have rolled it out.
Enterprise Server (ES, which was chosen for this solution) is specifically marketed by RH as their "solution for small to mid-range servers used for the majority of today's business computing". Application Server (AS) is the large-scale offering, where I'd expect to be steered towards LDAP, but not in ES. We're not serving millions of users, just several hundred with that one server.
It's quite possible that you are one of the very few users who wanted to run a mail server architecture based on a slower *database* technology metaphor,
I'd disagree with you there. While the bulk of email accounts in the world are bound to be on large scale services, the bulk of the email *systems* are almost certainly going to tilt towards a smaller median size. I can't give any numbers to corroborate this, but logic leads me to that conclusion.
In my book, we've got the right solution for our size. Lookup info is stored in a fast (yes, not as fast as LDAP, but infinitely more accessible by existing tools) database. Mailboxes are handled virtually, with maildirs under XFS on the back end. LDAP would be faster, yes, but far more setup and management intensive (I'd end up doing all of the account management or writing a significant number of webapps to let people do it, instead of just dropping in an off-the-shelf solution).
In any case, the particular server in question wasn't mail for the entire enterprise I work with, but instead a department within the larger organization. I should have been more clear about that, I suppose. We do have an LDAP directory available (NDS), but it's organization-wide and doesn't provide support as we need it for department or workgroup level needs, only for the enterprise-level ones (depending on who you ask).
Yes, I know. If I could fix that, I would. *grumble grumble*
Regards, and thanks for the response.
While I'm confident in my abilities, I am not assuming I know better than you do because I'm well educated, highly experienced in my field (12 years of enterprise systems engineering and support), intelligent, experienced, hard-working and rational.
I do believe though that after working on a rather complex system (complex enough that the two previous implementations during the past four years by competent and well-experienced persons had problematic issues), finding and implementing a stable, robust, and responsive system which requires little hands-on maintenance, that I certainly know IT better than YOU do.
By your comments, you work for a web hosting company. You provide services to people who provide services to users, and handle the end-user support. I work providing services directly to clients in an enterprise environment. YOUR work environment is nothing like MINE. I can say THAT with confidence, because from late 2000 to early 2002 I was an engineer for an international enterprise-level hosting company, and honestly, it was far more cut and dried than what I work with now.
You have never seen nor do you know the environment, requirements, or history of the system I have only briefly discussed, and yet you assume that I've built something of duct-tape and cardboard. Nothing could be further from the truth. From the backing hardware to the end-user tools, every part of that mail system was chosen after careful consideration and testing. Every step was discussed, tested, and approved by the client. It's also working beautifully.
I'm sorry you take affront to my signing posts with 'Regards', it wasn't intended with any intent in either direction. I sign my personal correspondence the same way, so it's a natural closing for me when conversing with another person. Although I think you're behaving boorishly, I don't feel compelled to respond in kind. It could just be that you're having a bad day (who doesn't), or that Postfix shot your dog and MySQL stole your wife.
While it's become apparent that you do not wish me the same, I do wish you regards, and may you be happy with your work, choices, opinions, and whatever else it takes to let you sleep well at night.
Cheers- (no affront intended).
We did investigate this as a possibility, but as of our last look (about 4 montsh ago) the only third party commercial package support for Postfix with MySQL enabled that we found was for RHEL3 (two different vendors). This could have changed by this point, but since I have the system stable and in production, it's unlikely to get revisited any time soon with enough priority to receive funding.
Although it would have made things easier at the time, now it would just be reimplementing a working solution.
I will stop trolling people just because they have experience in the area I am referring to, and do not agree with them.
There, fixed that for you.
Regards,
Keeping a server running isn't difficult, it's the amount of time it takes to keep them ALL going that gets to be a bother.
The nature of my work (as is the case with most of us, I'd guess) is that there are always new services and systems needing to be built (or rebuilt, as they age) while existing services rarely get mothballed, and so even a modicum of building packages easily snowballs over time into an all-consuming task. The less time I have to spend looking backwards, the more I can keep us moving forward.
It boils down to time. If maintaining that single mail system was my only job, I'd be on easy street, but at best that systems encompasses but a sliver of my job responsibilities. I prefer to avoid spending hours each week building and pushing custom packages to servers, if I can implement a solution which is more hands-off.
The big selling point of enterprise systems for large organizations is the centralized management and administration tools, which often become useless when you aren't using prebuilt packages from the vendor.
The other problem here is that every environment is different, and the environment a server works in can significantly change the requirements, as well as the time investment, for installing and maintaining.
While I'm very experienced with Linux and very at-ease in most *nix environments, I'm not a one-person shop, and while I can build and maintain complex, custom systems doesn't mean the guy who's running that server six months from now has my skill set. Part of being a good administrator is making the job easy for whoever gets called to fix a server when you're on vacation, or after you leave.
Regards-
I'm at a loss as to why you think I have no argument, my case is stated clearly. I provided a direct reference to my original post which stated an exact answer to your comment.
Neither Exim nor Sendmail provided an out-of-the-box solution which met our specific our needs under RHEL4. I never claimed that setting up systems shouldn't take work, I merely stated that RHEL did not support basic functionality which we desired, that was written into the packages themselves but not enabled at compile time.
My reference to you being a troll is that you assume that what I built is a "POS" that is on the verge of a breakdown. If you do not wish to be categorized as a troll, perhaps you should stop cursing travelers from underneath your bridge.
Regards-
I would ask you to reread the paragraph in my original post in which I stated that no matter which route I took (sendmail, exim, or postfix), in order to get the features we needed, I would have been stuck in the same boat.
Although I'm guessing this was just a troll, the server is working beautifully, with no unexpected downtime in eight months (the only downtime came from two reboots following kernel updates).
I'd ask though that you please refrain from using your broad brush to paint me as incompetent simply because you do not understand the mechanics of a real-world environment of which you are not a part.
I work for a large organization which has supported services including computer-based mail since the mid-70's. We have a lot of standing requirements to meet in order to replace existing systems. Most of the choices we've made are quite possibly the same ones you would have made, if faced with the environment, resources, and needs we have.
I'm also pretty certain if we paid one of the many companies which provide commercial Debian support the amount of money we're paying Red Hat, we would receive satistfactory service. We've done it before.
Regards-
With Ellison... Red Hat is unfortunately not meeting the needs of its users. Although we agree, our reasoning is different.
A significant part of my job is Linux sysadmin work, using licensed Red Hat Enterprise products. The tools are (for the most part) useful, reliable, and complete. The problem is, the enterprise distros are severely lacking in their packages and features.
Recently, while building a distributed mail system (multiple servers in the mail chain, multidomain support and virtual mailboxes) on RHEL4,
The recommended version for mail and database servers (Enterprise Server) does indeed have packages for Postfix (our preferred mail app) and MySQL available, but none of the Postfix packages have MySQL support enabled (Postfix has good MySQL support, including DB connection caching through a proxy interface). This effectively meant that none of the dozens of excellent mail administration tools out there would be available to us, and we couldn't put together a mail system that didn't rely on flat files in some fashion or another, without setting up parallel services (LDAP) solely to support mail services.
I built the server once on Red Hat ES and when all was said and done, I ended up with seven major components having to be compiled either from source, or rebuilt RPMs with modified spec files and/or compile flags. This doesn't bother me, except for the fact that the whole reason my employer pays thousands upon thousands of dollars for an enterprise Linux was so that we could stick to standard packages, so that if a particular machine has issues, we don't have to rely on one person to know what's going on.
I can't imagine we're the only paying client Red Hat has that wants to run a mail server that relies on a database server. It wouldn't chagrin me to change mail server or database packages (I've used most of the common ones), but looking deeper just led me to the realization that no matter which packages or paths I took, I'd still be stuck with the same issues.
Until Red Hat gains better flexibility, timeliness, and awareness of their client needs, perhaps Ellison is on the ball with his visions of supporting the clients directly. I'm guessing he won't be supporting MySQL, though. And after rebuilding the server on Debian stable, with all features we desired being available in the core distro, we're happier.
And I'm the only guy here who groks Debian well enough to run it, sigh.
...before the gaming industry gets stuck using the same material over... and over... and....
(too late)
Oops, always read twice before posting. Second sentence in the second paragraph should have read:
"They haven't completed a single assessment of their own efficacy, and the last note about this is that in 2005, the project to determine how to assess their own operations was begun, but has not been completed."
This is called the Air Marshall system (yes, I know they're not FBI), and nobody has ever griped about it being an invasion of privacy or a waste of money.
0 001070.2005.htmlS ervicem l
Well, I'd certainly complain if they started rifling through my luggage mid-flight.
The biggest complaint one could really have is that a rather expensive program at $660 million dollars a year of funding, with very little to show for it. They haven't completed a single assessment of their own efficacy, and the last note about this is that in 2005, the project to determine how much less completed guidelines one how to assess their own operations.
Attacks between 1990 and September 10, 2001 involving terrorists aboard U.S. aircraft: 0
Federal Air Marshals in active commercial flight duty, same period: max. 50 (33 agents on 9/11/2001)
Attacks following September 11, 2001 involving terrorists aboard U.S. aircraft: 0
Federal Air Marshals in active commercial flight duty, same period: "thousands" (numbers no longer released)
Indeed, the only real news about FAM operations seems to be when they mistakely shot and killed a passenger who was distressed over a spousal argument and stormed off of the plane upon their arrival in Miami, in the mistaken belief he was a terrorist.
So hey, for millions of added dollars, we've gotten the same efficacy we had before the single milestone event that caused the agency's expansion. Zero. But on the plus side, there's one less tourist in Miami.
I suppose the moral of this is the same as ever other post: for the right price, your government can certainly instill in you an illusion of security. The most effective ways of fighting crime tend to assume everyone is a criminal to begin with, and work from there.
Sources:
http://www.whitehouse.gov/omb/expectmore/detail.1
http://en.wikipedia.org/wiki/Federal_Air_Marshal_
http://www.colorado.edu/hazards/wp/wp107/wp107.ht
MMPOG's are all so successful.
Up next: The Donald takes on MMPOG's, and every day, another player gets an email letting them know they've been fired from the game.
http://www.microsoft.com/hardware/mouseandkeybo
Yeah yeah, but hey, I use it under Linux too.
If you're a lefty, you're out of luck as far as I know, because I've not seen any good trackballs which are left-hand specific. Trackballs (more to the point, thumb-balls) are great... I used to like the Logitech ones, but the MS ones fit my hand much better.