Well, the one you should be listening to is "The Who - Won't Get Fooled Again". CSI Miami's theme song is awesome and only Lt. Horatio Caine can only deliver the line, "You have no idea..."
Since Outlook 2007 does have this feature, it would be the likely candidate for prior art, since it would have been release somewhere in that time frame.
"ISVs were more than willing to work with Sun because they saw Sun as a neutral hardware platform," he said. "But when the Sun platform becomes part of Oracle, and Oracle has a reputation for acquiring companies and replacing the products with Oracle products, then ISVs get nervous. You don't need to be a rocket scientist to figure that out."
Ah yes... Oracle has a pretty good reputation of replacing its acquired products... But what is worse (and I have first hand experience as one of those ISVs), is that Oracle likes to leave these acquired products in limbo until the replacements are ready... Support on the old product is virtually non-existent, and migration to the new product (when it actually does come) is like a shot in the dark; then can never give you reliable documentation on how to make the transition and Oracle engineers always insist that it is far easier than it actually is.
I can understand why people would run from Sun products. This is Oracle's first acquisition outside of a software-only company. If a company has to depend on Sun fulfilling their provisioning and support contracts, Oracle's reputation would probably scare away customers that are concerned with potential supplier problems.
Clients are just betting based upon Oracle's reputation with respect to their acquisitions...
Even though they say that they can give you more perks, the call center jobs still sucks...
Why?
Because when a company is proud that it's turnover rate is only 45% (less than half the industry's average), it tells me that this job is something I would never want to touch with a five foot pole (as opposed to a ten foot one).
A company with 45% turnover on 11000 employees means approximately 4950 employees get churned out in a year. That still isn't very good...
Honestly, did your company perform any "due diligence" on the outsourcing company before engaging them in that contract? Any security audits, risk assessments, business impact studies. Did you perform any sort of checks on them, or did you simply engage them on cost alone?
I know startups don't always have the resources to perform the required "due diligence" before handing over the keys, but if you didn't perform these checks, you would be primarily responsible if you've opened up this level of risk and something wrong would occur. I'm sure this is not what you wanted to hear, but CYA (cover your ass) is especially important if you hand over the keys to an outsider and it could involve a significant loss to the company.
If you don't have enough confidence in your decision on behalf of the company, why should the company have confidence in you making decisions for them?
Unfortunately, the publishers won't clue into the fact that they are mostly to blame for the used games market. If they looked at some of their practices as of late, they would see that...
1. Retailers don't enough of a cut from new product sales. That is because retailers get squeezed when the publisher enforces a retail price of $50 or $60 on new product and allow the retailer to barely break even when selling it.
2. Games tend to lose value as they sit on shelves. For example, if you didn't buy the game for $50 when it was new, you probably won't do so 3+ months later unless the price drops. As a retailer, that means I'm losing more money as time goes on; again another reason why not to sell new. Publishers aren't taking any real steps to absorb that decrease in value over time.
Trying to bite the hand that feeds you is certainly going to be counterproductive in the long term, especially when you already bitten off a whole arm.
If only the publishers would realign their take with the supposed value of their product, they would probably be able to sell more copies via retail rather than complain about piracy and used game sales...
Hmm, I've worked with RHN satellite quite a bit, and it does have some nice features. My biggest complaint about it is that the interface isn't intuitive as it should be; if you need to find things, some of them are hidden well enough so you have to memorize stuff...
But to answer your question about OSAD, the RHN satellite server uses this to automatically push instructions to its clients. Without OSAD, the only way that the client verifies that it has tasks to do is through a script called rhn-check. That runs periodically via crontab on the managed system; it initiates a connection to the satellite server and executes any tasks that are listed in its scheduled tasks. If you want to change how often the system checks in with the satellite server, just change the timing on rhn-check in the crontab.
The OSAD service is a tool that allows you to automatically push changes from the satellite server to the managed systems immediately. You run the osad service on the managed system and the osa-dispatcher service on the satellite server and once you use the webUI on the satellite server to do something (like upgrade a package for example), the managed system will update immediately, rather than wait for the next check in (rhn-check) to run on the managed system. A gross simplification of what OSAD does is that it performs actions in real time, rather than on a regular scheduled check-in basis.
The CRTC already has rules that would require Bell Canada to provide other ISPs with last mile access, since there is no viable competitive infrastructure options available. Bell Canada must also provide that last mile at cost to the ISPs as per the CRTC regulations.
Unfortunately, these rules don't appear to cover anything with regards to bandwidth throttling. However, I'm pretty sure that a case can be made with regards to the anti-competitive factors associated with this practice. The CRTC rules were set in place to encourage competition and I'm wondering if anyone affected has brought a complaint to the CRTC.
Hmm, the last time I installed a Trend Micro product was about 18 months ago. I know that back in that time, Trend was using postfix on their SMTP gateway anti-virus products implemented on Linux systems.
If Trend Micro is really trying to prevent other companies from offering cheap solutions for anti-virus/anti-spam gateways, I would take a long hard look at how they themselves got to where they did at this point in time.
The reason you're not seeing the 95% is because the study doesn't take the content per individual mailbox. It counts the 95% based upon what mail servers (and their anti-spam systems) see.
Honestly, if you were seeing 95% of the content in your mailbox as SPAM, you would have ditched e-mail by now.
Usually, the 95% does include e-mail sent to a bad recipient. The logic used by most anti-spam solutions is if that an e-mail got sent to mail server where the sender didn't know your e-mail address, the e-mail get filed as spam. It is far more likely that a spammer was trying to guess the e-mail of someone rather than someone forgetting or mis-spelling an e-mail address (you do use your address book, right?).
Since I do run a few domains (and they are relatively small), I usually see between 85-95% spam. Since these domains are typical office hour businesses, the 95% usually hits on weekends and non-business hours, while 85% is typical of the Monday-Friday business hour time periods...
YSlow analyzes web pages and tells you why they're slow based on the rules for high performance web sites.
This criteria can be subjective (as to what a high performance web site is). I would certainly expect that Yahoo's tool would likely grade sites that have the same magnitude of number of hits that they would get. I don't even think that slashdot.org would even qualify in that category.
Their tips definitely do make sense if you have a site in the "millions of hits" scale. But they are definitely overkill for anything below that mark.
I have the opposite situation. I have a Linksys 802.11n router and usually I hookup two laptops to it. When the router has the 802.11n mode enabled (in mixed mode so people should still able to connect with 802.11b and 802.11g), the one laptop that has a Linksys 802.11g PC Card usually will drop to the lowest speed possible (1-2 Mbit/s) while the laptop with the builtin 802.11n card chugs along nicely. As soon as I disable 802.11n on the router, the 802.11g card works at full speed again.
Now, I really haven't spent much time trying to figure out why this is the case (I'm guessing a firmware upgrade on the router will help). Right now, I leave the router in mixed-G mode to keep both users happy.
I have to agree here. I have worked as a technician and as a manager within IT/IS departments and I certainly recommend that every IT department understands the basics of a Service Level Agreement.
If your IT/IS Department doesn't have a Service Level Agreement, then benchmarks are generally irrelevant as they can be easily taken out of context to make your department look incompetent or as a waste of money.
The good thing about an SLA:
1. It basically defines what your group is responsible for. It's the perfect tool to use with your manager when he/she wonders what you do there.
2. It defines what resources and budget you will get in order to fulfill the responsibilities you are given.
3. It helps protect your group from being blamed for issues that are out of your control, such as a supplier who cannot provide the replacement parts for a business critical system. Of course, your IT department should also have SLAs with your suppliers in order to assist your group in these situations. You need to make sure that such issues, and the conditions that trigger them, are contained with the SLA.
4. It defines the benchmarks as to which your group will be evaluated.
The bad thing about an SLA:
1. Once your SLA is agreed upon, you now have to deliver upon what was agreed. So, if the task your were doing is applicable within your SLA, get to it and stop reading Slashdot you fool!
2. Don't think that management will not pressure you continuously with an SLA in hand. Some people make it their work to haggle with the other parties in an SLA, so don't exepct a blanket of protection in this case. Make it flexible enough to adjust with the company in question, but don't let them roll over you with unreasonable requests.
3. Tracking and reporting. Get ready to do a lot of this stuff, especially with those people who haggle you about the SLA or try to cheat you out of the terms (especially when it comes to money and/or resources). This can save your ass.
4. People do lie, cheat and steal... Just because you have a SLA in place, don't expect this behavior to change with the parties in question.
Once you have your SLA, you should then have your benchmarks. Good luck!
A lot of projects have benefitted from having some money behind them. The article cites several examples, so I don't have to. But, if a open source project is really going to be threatened, it is likely not only because of the money, but also because of greed.
Do we need a better reminder than SCO to demonstrate that greed is what would kill open source? And while their recent actions seem limited to their legal battle against Linux, this same company used to be called Caldera (and was selling a Linux distribution of their own).
So, if there is an issue of too much money in open source, it really comes down to whether that money is being justly used to support the development of open source products or if that money is being used to line a greedy manager's/executive's pockets.
That's right. Essentially, the CCA policy server can be configured to accept different anti-virus packages on the client. As to why it was only configured to accept McAfee, I can only assume that either this was part of their policy, or someone administering the CCA policy server misconfigured it that way.
In this case, the student in question created a program to fool the CCA and used it for seven months before being caught and using the excuse that he was doing security research. Unfortunately, that justification just doesn't work as it is very unlikely the university gave him permission to do any security research on their network and he distributed his exploit tool to staff and other students on that network.
A lot of problems associated with thin client computing have little to do with the computers and terminals themselves; if you ignore the fact that your dependancy on the network is going to be an important part of keeping your thin clients working properly, it will likely cause more problems than solve them.
Redundant switches and network cards in servers will help increase the available bandwidth and avoid leaving possible single points of failure. Also, if your budget allows, try to seperate the network the users access the servers on from the one that serves file shares, backups and administrator access. It will go a long way to improve the service available to users of the thin clients.
... perhaps we should take a step back and look at the reason the CEO had to resort to such tactics in the first place.
I figure either the person in question is either a sociopath or just plain incompetent. Because when a CEO has to resort to such tactics, he/she has already failed to do their job...
That's the question that needs to be answered... A security-minded entity (corporate, government, personal) has to ask that question and seriously look at the risk vs. reward of storing the data on a portable device. If the entity in question doesn't look at this perspective of the issue, they ultimately don't care about security in general or enforcing a data storage policy in particular.
When I do consulting work (especially with regards to security), I often compare putting sensitive data on a laptop to putting the company's main database directly accessible on the Internet and hoping that whoever attacks it can't exploit it or guess a username/password combination. That will usually scare a few people into thinking about what they are doing, and the others who think that it is alright probably deserve nothing less than getting hacked.
As for disk encryption, it works well IF it is transparent to the user and IF the overall security is indeed strengthened by such encryption, because a weak link like a poor password adds no actual security value where it is expected.
Actually, you can address a lot of those types of problems (like playlist management, etc.) with one of the many mplayer frontends on their related projects page. All you need to do is choose whichever one you prefer and mplayer is your best friend for video playback.
In general, publishers do like their sequels for the reasons stated above. Since they are dealing with a relatively known quantity of sales they can push by rehashing an idea or extending it somehow, it's like a guaranteed return on their investment.
But it's not just that. We "seem" to prefer sequels becauses these sequels are continually pushed in our faces by their marketing/advertising firms and all the spin and hype that the publishers (and developers to some extent) build up leading to their next release. When the gaming industry spends so much to push their sequels, the new and innovative games are but mutes in a convention hall full of sequels shouting simultaneously at the top of their lungs to get your attention. It's no wonder that the innovative games are generally unheard of until release and generally rely on less traditional ways of getting their own popularity.
So, it's a very simple equation to the publishers...
I personally think that the hardware manufacturers are a part of the problem rather than the unfortunate victims here...
What makes consoles attractive is that the upgrade cycle is measured in periods of years. If your only purpose is to play games, the low price (discounted hardware recouped through game licensing) and the idea that the game platform will still be the same in a few years means that the cost of having a gaming platform is relatively cheap in comparison to...
PC gaming, which has been trying to distinguish itself as a viable gaming platform by pushing the envelope of hardware and software, has been pushing itself towards niche because of the cost. Graphic card cycles are at best 6 to 9 months, and these cycles just don't allow for the prices to come down. When you compare the costs, the top of the line video card is usually more expensive than the equivalent top of the line gaming console.
Of course, it doesn't help the situation that PC game developers are pushing the envelope also. Better hardware begets more compute intensive software games and vice-versa.
The fact that the PC gaming industry is leading to differentiate itself from the console market by outperforming it in terms of technology is the cause. In terms of lasting value, console gaming is far less costly than its PC counterpart.
If you are going to try to go with Cisco for VPN, I'd recommend going with an ISR (Integrated Services Router) before going with a PIX. You can get a good 830 series (for a really small setup) or an 1811/1812 for the same price as the PIX 506E, but it offers a lot more features. Firewall, VPN, IPS, built-in switch, router, and wireless (on the 1811/1812). It can't all be bad.
Oh, and to answer the cross-platform question, there are VPN clients for Windows, Solaris, Linux and Mac OS X.
Hmm, I guess you're talking about something like Mondex. Unfortunately, it hasn't seen much of any implementation in North America because it is simply way too expensive to deploy the terminals and electronic wallets to make these sorts of electronic cash transactions.
... due to a lack of installed users for the impending next generation of consoles.
Does it really take an analyst to realize that "impending" means that the next generation of consoles isn't out yet. Of course there won't be a base of users installed with the next generation of gear...
Maybe these analysts should wait for the PS3 and the Revolution to come out before they make these reports.
In an ideal world, the bank would be responsible for protecting your money. However, here are the reasons why they don't do it as well as they should...
1) Cost: It simply would cost the banks and the Payment Card Industry way too much money to provide extra security to prevent this kind of fraud from occuring in the first place. Even over a long period of time, it is simply cheaper to pay out whenever fraud does occur (a.k.a. we'll end the torture and hell you are going through by refunding you the amount that was stolen), rather than secure the system in the long run.
2) Shift the blame: When they (banks) do pay out to cover fraud, it's not the banks or the credit card companies that take the loss. The loss is shifted onto the merchants, who end up paying for it through higher transaction processing fees. If you get carded at the store, they are trying to be vigilant at their end. In essence, the banks put the merchants up s*** creek without a paddle. Either the merchants learn to craft their own paddle or they go further downstream.
3) Convenience: Have to remember an extra password, carry a token, etc.? If using a bank card or credit card becomes more difficult, people will generally shy away from using them. The less people buy with credit cards, the less the payment card industry makes in profits. In other words, securing the cards may be against their best interests (profits). In all honesty, some people don't even know how to properly use an ATM. If you make that job more difficult, it will take longer to process transactions, or they will simply pay cash (again, it hurts profits). And this convenience is what makes that fraud so tantilizing to the crooks in the first place too.
One last note. Banks will gladly protect your money. They just make everyone else (including yourself) pay in order to get at that money.
Slashdot Mirror
Well, the one you should be listening to is "The Who - Won't Get Fooled Again". CSI Miami's theme song is awesome and only Lt. Horatio Caine can only deliver the line, "You have no idea..."
Yeah!
Patent filing date is September 7th, 2006.
Since Outlook 2007 does have this feature, it would be the likely candidate for prior art, since it would have been release somewhere in that time frame.
Quoted from the article...
"ISVs were more than willing to work with Sun because they saw Sun as a neutral hardware platform," he said. "But when the Sun platform becomes part of Oracle, and Oracle has a reputation for acquiring companies and replacing the products with Oracle products, then ISVs get nervous. You don't need to be a rocket scientist to figure that out."
Ah yes... Oracle has a pretty good reputation of replacing its acquired products... But what is worse (and I have first hand experience as one of those ISVs), is that Oracle likes to leave these acquired products in limbo until the replacements are ready... Support on the old product is virtually non-existent, and migration to the new product (when it actually does come) is like a shot in the dark; then can never give you reliable documentation on how to make the transition and Oracle engineers always insist that it is far easier than it actually is.
I can understand why people would run from Sun products. This is Oracle's first acquisition outside of a software-only company. If a company has to depend on Sun fulfilling their provisioning and support contracts, Oracle's reputation would probably scare away customers that are concerned with potential supplier problems.
Clients are just betting based upon Oracle's reputation with respect to their acquisitions...
Even though they say that they can give you more perks, the call center jobs still sucks...
Why?
Because when a company is proud that it's turnover rate is only 45% (less than half the industry's average), it tells me that this job is something I would never want to touch with a five foot pole (as opposed to a ten foot one).
A company with 45% turnover on 11000 employees means approximately 4950 employees get churned out in a year. That still isn't very good...
Honestly, did your company perform any "due diligence" on the outsourcing company before engaging them in that contract? Any security audits, risk assessments, business impact studies. Did you perform any sort of checks on them, or did you simply engage them on cost alone?
I know startups don't always have the resources to perform the required "due diligence" before handing over the keys, but if you didn't perform these checks, you would be primarily responsible if you've opened up this level of risk and something wrong would occur. I'm sure this is not what you wanted to hear, but CYA (cover your ass) is especially important if you hand over the keys to an outsider and it could involve a significant loss to the company.
If you don't have enough confidence in your decision on behalf of the company, why should the company have confidence in you making decisions for them?
Unfortunately, the publishers won't clue into the fact that they are mostly to blame for the used games market. If they looked at some of their practices as of late, they would see that...
1. Retailers don't enough of a cut from new product sales. That is because retailers get squeezed when the publisher enforces a retail price of $50 or $60 on new product and allow the retailer to barely break even when selling it.
2. Games tend to lose value as they sit on shelves. For example, if you didn't buy the game for $50 when it was new, you probably won't do so 3+ months later unless the price drops. As a retailer, that means I'm losing more money as time goes on; again another reason why not to sell new. Publishers aren't taking any real steps to absorb that decrease in value over time.
Trying to bite the hand that feeds you is certainly going to be counterproductive in the long term, especially when you already bitten off a whole arm.
If only the publishers would realign their take with the supposed value of their product, they would probably be able to sell more copies via retail rather than complain about piracy and used game sales...
Hmm, I've worked with RHN satellite quite a bit, and it does have some nice features. My biggest complaint about it is that the interface isn't intuitive as it should be; if you need to find things, some of them are hidden well enough so you have to memorize stuff...
But to answer your question about OSAD, the RHN satellite server uses this to automatically push instructions to its clients. Without OSAD, the only way that the client verifies that it has tasks to do is through a script called rhn-check. That runs periodically via crontab on the managed system; it initiates a connection to the satellite server and executes any tasks that are listed in its scheduled tasks. If you want to change how often the system checks in with the satellite server, just change the timing on rhn-check in the crontab.
The OSAD service is a tool that allows you to automatically push changes from the satellite server to the managed systems immediately. You run the osad service on the managed system and the osa-dispatcher service on the satellite server and once you use the webUI on the satellite server to do something (like upgrade a package for example), the managed system will update immediately, rather than wait for the next check in (rhn-check) to run on the managed system. A gross simplification of what OSAD does is that it performs actions in real time, rather than on a regular scheduled check-in basis.
This isn't required...
The CRTC already has rules that would require Bell Canada to provide other ISPs with last mile access, since there is no viable competitive infrastructure options available. Bell Canada must also provide that last mile at cost to the ISPs as per the CRTC regulations.
Unfortunately, these rules don't appear to cover anything with regards to bandwidth throttling. However, I'm pretty sure that a case can be made with regards to the anti-competitive factors associated with this practice. The CRTC rules were set in place to encourage competition and I'm wondering if anyone affected has brought a complaint to the CRTC.
Hmm, the last time I installed a Trend Micro product was about 18 months ago. I know that back in that time, Trend was using postfix on their SMTP gateway anti-virus products implemented on Linux systems.
If Trend Micro is really trying to prevent other companies from offering cheap solutions for anti-virus/anti-spam gateways, I would take a long hard look at how they themselves got to where they did at this point in time.
The reason you're not seeing the 95% is because the study doesn't take the content per individual mailbox. It counts the 95% based upon what mail servers (and their anti-spam systems) see.
Honestly, if you were seeing 95% of the content in your mailbox as SPAM, you would have ditched e-mail by now.
Usually, the 95% does include e-mail sent to a bad recipient. The logic used by most anti-spam solutions is if that an e-mail got sent to mail server where the sender didn't know your e-mail address, the e-mail get filed as spam. It is far more likely that a spammer was trying to guess the e-mail of someone rather than someone forgetting or mis-spelling an e-mail address (you do use your address book, right?).
Since I do run a few domains (and they are relatively small), I usually see between 85-95% spam. Since these domains are typical office hour businesses, the 95% usually hits on weekends and non-business hours, while 85% is typical of the Monday-Friday business hour time periods...
Well, from the YSlow web page itself...
YSlow analyzes web pages and tells you why they're slow based on the rules for high performance web sites.
This criteria can be subjective (as to what a high performance web site is). I would certainly expect that Yahoo's tool would likely grade sites that have the same magnitude of number of hits that they would get. I don't even think that slashdot.org would even qualify in that category.
Their tips definitely do make sense if you have a site in the "millions of hits" scale. But they are definitely overkill for anything below that mark.
I have the opposite situation. I have a Linksys 802.11n router and usually I hookup two laptops to it. When the router has the 802.11n mode enabled (in mixed mode so people should still able to connect with 802.11b and 802.11g), the one laptop that has a Linksys 802.11g PC Card usually will drop to the lowest speed possible (1-2 Mbit/s) while the laptop with the builtin 802.11n card chugs along nicely. As soon as I disable 802.11n on the router, the 802.11g card works at full speed again.
Now, I really haven't spent much time trying to figure out why this is the case (I'm guessing a firmware upgrade on the router will help). Right now, I leave the router in mixed-G mode to keep both users happy.
I have to agree here. I have worked as a technician and as a manager within IT/IS departments and I certainly recommend that every IT department understands the basics of a Service Level Agreement.
If your IT/IS Department doesn't have a Service Level Agreement, then benchmarks are generally irrelevant as they can be easily taken out of context to make your department look incompetent or as a waste of money.
The good thing about an SLA:
1. It basically defines what your group is responsible for. It's the perfect tool to use with your manager when he/she wonders what you do there.
2. It defines what resources and budget you will get in order to fulfill the responsibilities you are given.
3. It helps protect your group from being blamed for issues that are out of your control, such as a supplier who cannot provide the replacement parts for a business critical system. Of course, your IT department should also have SLAs with your suppliers in order to assist your group in these situations. You need to make sure that such issues, and the conditions that trigger them, are contained with the SLA.
4. It defines the benchmarks as to which your group will be evaluated.
The bad thing about an SLA:
1. Once your SLA is agreed upon, you now have to deliver upon what was agreed. So, if the task your were doing is applicable within your SLA, get to it and stop reading Slashdot you fool!
2. Don't think that management will not pressure you continuously with an SLA in hand. Some people make it their work to haggle with the other parties in an SLA, so don't exepct a blanket of protection in this case. Make it flexible enough to adjust with the company in question, but don't let them roll over you with unreasonable requests.
3. Tracking and reporting. Get ready to do a lot of this stuff, especially with those people who haggle you about the SLA or try to cheat you out of the terms (especially when it comes to money and/or resources). This can save your ass.
4. People do lie, cheat and steal... Just because you have a SLA in place, don't expect this behavior to change with the parties in question.
Once you have your SLA, you should then have your benchmarks. Good luck!
A lot of projects have benefitted from having some money behind them. The article cites several examples, so I don't have to. But, if a open source project is really going to be threatened, it is likely not only because of the money, but also because of greed.
Do we need a better reminder than SCO to demonstrate that greed is what would kill open source? And while their recent actions seem limited to their legal battle against Linux, this same company used to be called Caldera (and was selling a Linux distribution of their own).
So, if there is an issue of too much money in open source, it really comes down to whether that money is being justly used to support the development of open source products or if that money is being used to line a greedy manager's/executive's pockets.
That's right. Essentially, the CCA policy server can be configured to accept different anti-virus packages on the client. As to why it was only configured to accept McAfee, I can only assume that either this was part of their policy, or someone administering the CCA policy server misconfigured it that way.
In this case, the student in question created a program to fool the CCA and used it for seven months before being caught and using the excuse that he was doing security research. Unfortunately, that justification just doesn't work as it is very unlikely the university gave him permission to do any security research on their network and he distributed his exploit tool to staff and other students on that network.
A lot of problems associated with thin client computing have little to do with the computers and terminals themselves; if you ignore the fact that your dependancy on the network is going to be an important part of keeping your thin clients working properly, it will likely cause more problems than solve them.
Redundant switches and network cards in servers will help increase the available bandwidth and avoid leaving possible single points of failure. Also, if your budget allows, try to seperate the network the users access the servers on from the one that serves file shares, backups and administrator access. It will go a long way to improve the service available to users of the thin clients.
I figure either the person in question is either a sociopath or just plain incompetent. Because when a CEO has to resort to such tactics, he/she has already failed to do their job...
That's the question that needs to be answered... A security-minded entity (corporate, government, personal) has to ask that question and seriously look at the risk vs. reward of storing the data on a portable device. If the entity in question doesn't look at this perspective of the issue, they ultimately don't care about security in general or enforcing a data storage policy in particular.
When I do consulting work (especially with regards to security), I often compare putting sensitive data on a laptop to putting the company's main database directly accessible on the Internet and hoping that whoever attacks it can't exploit it or guess a username/password combination. That will usually scare a few people into thinking about what they are doing, and the others who think that it is alright probably deserve nothing less than getting hacked.
As for disk encryption, it works well IF it is transparent to the user and IF the overall security is indeed strengthened by such encryption, because a weak link like a poor password adds no actual security value where it is expected.
Actually, you can address a lot of those types of problems (like playlist management, etc.) with one of the many mplayer frontends on their related projects page. All you need to do is choose whichever one you prefer and mplayer is your best friend for video playback.
In general, publishers do like their sequels for the reasons stated above. Since they are dealing with a relatively known quantity of sales they can push by rehashing an idea or extending it somehow, it's like a guaranteed return on their investment.
But it's not just that. We "seem" to prefer sequels becauses these sequels are continually pushed in our faces by their marketing/advertising firms and all the spin and hype that the publishers (and developers to some extent) build up leading to their next release. When the gaming industry spends so much to push their sequels, the new and innovative games are but mutes in a convention hall full of sequels shouting simultaneously at the top of their lungs to get your attention. It's no wonder that the innovative games are generally unheard of until release and generally rely on less traditional ways of getting their own popularity.
So, it's a very simple equation to the publishers...
Previously successful title + upcoming sequel + aggressive marketing = huge profit.
Innovative title + low key marketing (to reduce possible losses on a flop) = relative unknown title + possible gaming gem.
You only seem to enjoy game sequels because they outnumber the fresh innovative ones by a factor of 10:1.
I personally think that the hardware manufacturers are a part of the problem rather than the unfortunate victims here...
What makes consoles attractive is that the upgrade cycle is measured in periods of years. If your only purpose is to play games, the low price (discounted hardware recouped through game licensing) and the idea that the game platform will still be the same in a few years means that the cost of having a gaming platform is relatively cheap in comparison to...
PC gaming, which has been trying to distinguish itself as a viable gaming platform by pushing the envelope of hardware and software, has been pushing itself towards niche because of the cost. Graphic card cycles are at best 6 to 9 months, and these cycles just don't allow for the prices to come down. When you compare the costs, the top of the line video card is usually more expensive than the equivalent top of the line gaming console.
Of course, it doesn't help the situation that PC game developers are pushing the envelope also. Better hardware begets more compute intensive software games and vice-versa.
The fact that the PC gaming industry is leading to differentiate itself from the console market by outperforming it in terms of technology is the cause. In terms of lasting value, console gaming is far less costly than its PC counterpart.
If you are going to try to go with Cisco for VPN, I'd recommend going with an ISR (Integrated Services Router) before going with a PIX. You can get a good 830 series (for a really small setup) or an 1811/1812 for the same price as the PIX 506E, but it offers a lot more features. Firewall, VPN, IPS, built-in switch, router, and wireless (on the 1811/1812). It can't all be bad.
Oh, and to answer the cross-platform question, there are VPN clients for Windows, Solaris, Linux and Mac OS X.
Hmm, I guess you're talking about something like Mondex. Unfortunately, it hasn't seen much of any implementation in North America because it is simply way too expensive to deploy the terminals and electronic wallets to make these sorts of electronic cash transactions.
Does it really take an analyst to realize that "impending" means that the next generation of consoles isn't out yet. Of course there won't be a base of users installed with the next generation of gear...
Maybe these analysts should wait for the PS3 and the Revolution to come out before they make these reports.
In an ideal world, the bank would be responsible for protecting your money. However, here are the reasons why they don't do it as well as they should...
1) Cost: It simply would cost the banks and the Payment Card Industry way too much money to provide extra security to prevent this kind of fraud from occuring in the first place. Even over a long period of time, it is simply cheaper to pay out whenever fraud does occur (a.k.a. we'll end the torture and hell you are going through by refunding you the amount that was stolen), rather than secure the system in the long run.
2) Shift the blame: When they (banks) do pay out to cover fraud, it's not the banks or the credit card companies that take the loss. The loss is shifted onto the merchants, who end up paying for it through higher transaction processing fees. If you get carded at the store, they are trying to be vigilant at their end. In essence, the banks put the merchants up s*** creek without a paddle. Either the merchants learn to craft their own paddle or they go further downstream.
3) Convenience: Have to remember an extra password, carry a token, etc.? If using a bank card or credit card becomes more difficult, people will generally shy away from using them. The less people buy with credit cards, the less the payment card industry makes in profits. In other words, securing the cards may be against their best interests (profits). In all honesty, some people don't even know how to properly use an ATM. If you make that job more difficult, it will take longer to process transactions, or they will simply pay cash (again, it hurts profits). And this convenience is what makes that fraud so tantilizing to the crooks in the first place too.
One last note. Banks will gladly protect your money. They just make everyone else (including yourself) pay in order to get at that money.