In what _possible_ way is stock trading a zero-sum game? Every transaction has a cost: like even the most efficient transfers of energy cause some gain in entropy. The idea that "oh, it will average out for individual investors" is ludicrous, because large scale "investment gorups" do, indeed, favor certain types of transactions and can have their assets completely ruined by such losses, and the businesses whose stocks are being traded can be destroyed by such chaos. The idea that other investors will gain those assets neglects both the destruction of the livelihood of the losers, but the loss of abilities to invest or loan further caused by the uncertainty.
The slow disk is why you use rsync or other such efficient mirroring technologies. The tapes have a limited lifespan, they require significant maintenance, and have been prone to far too many mechanical failures and expensive downtime in my experence. The disks can actually be simultaneously connected for casual "read" access with a reasonable USB hub and possibly an additional USB card.
You've also left out the cost of recovery time for users. Swapping tapes to get recovery of arbitrary files is rather awkward. and requires physical access to the server. Either you invest in a tape library that can hold that 24 TB of tape online and provide user access to the tape library (which means two drives in the library, one for backup activity and one for read activity), or you invest in onsite manpower to swap tapes. If you've staff already in the computer room to swap tapes for you, that's workable, but it's very expensive in a small environment, and it interferes with backup operations if you've only the one tape drive.
Swapping USB ports, or even leaving the multiple backup drives constantly on, is much quicker to access the same data, and leaves the full backed up systems or designated pieces of it directly accessible for network exporting, such as with a read-only NFS mount or read-only CIFS mount, for clients to easily recover their own files rather than requiring backup system access. You do have to be cautious with export configurations for performance and security reasons, and to leave the drives easy to swap out, but it's workable.
Actually handling all those tapes and recovering data from them is very expensive in manpower and time, and can be very awkward for recovering data. Those tapes, and tape drives, are also _expensive_. They're useful for sites that require secure off-site storage, or encrypted off-site storage, but for most environments today they are pointless. Easily detachable physical storage has become very inexpensive, far more economical, and is far less vulnerable to the vulnerabilities of mishandling SCSI connections. I've seen far, far too many SCSI setups for tape drives and external media fail due to misconfiguration, miscabling, and the very poor driver integration of SCSI controllers in far too many operating systems. USB has proven startlingly simple, resilient, and _cheap_ to manage.
I use the external drive approach very frequently for data center migration and virtualization OS image migration, though usually I only back up the configuration files from the virtualized hosts, not the complete images. It's very effective. 24 TB is bigger than I've personally done this way, but it's certainly feasible if it's not treated as a single lump. If the the data can be factored reasonably before transferring, don't simply duplicate it every time. Split it up into reasonably sized chunks and _mirror_ it onto the USB drives, so the first backup is lengthy but following backups are far more efficieint.
Assuming that the backup system is Linux based, the ""rsync" tool can be written into a script to see which media is attached, to mount those media, and to mirror the contents of a set of directories to those media.. It's also reasonable to use a USB hub to allow mounting multiple USB devices simultaneously so it can be done all at one time, rather than having to swap media.
The article is excellent. It's publishing guidelines very similar to those I use, and my colleagues use, when dealing with our business partner's accumulated software projects, and covers it very well: I intend to use it as a checklist for spaghetti code integration projects.
I'd emphasize the switch to good source control management (SCM). too many workgroups have undocumented workflows, and benefit profoundly from switching to or learning to properly use a robust system. This process also helps identify who is the primary spaghetti code author. In such a project, there is often a particular developer or "architect" who has been carrying around the functional map of this project in their head. Their time and commitment to get that map into documentation so others can work with it is absolutely necessary to such projects, SCM is often the first step towards this. And if that core developer or architect doesn't agree with the project, _fire them as fast as possible_, because they will hamstring every effort to move to any cleaned up architecture.
Also note that most such core developers or architects have actually been wanting to do something like this cleanup for _years_, and simply haven't been allocated the time and resources to do it. There are risks: repairs are often much cheaper and safer than the kind of large scale this kind of cleanup represents, and the actual benefits have to be presented to the managers or clients to get them to invest manpower, so that core developer often has a huge emotional frustration with the original code. Working with them to get their buy-in, and being willing to trade minor points of disagreement with them to get their cooperation with big issues are priceless on such large projects. Otherwise, they can and often do backstab every integration effort as "wasted time" or "not sufficient", even claiming both at the same time.
Probably not, for you. For companies that host complex websites, and that go through complex load balancing and proxy setups, it's invaluable for assigning SSL keys to particular IP addresses and using IP based virtual hosting instead. This solves an enormous number of complex and subtle configuration conflicts with web servers and load balancers.
I've no idea where you get the idea that in a nomadic culture, "everyone is going to know everything about everyone else". Even in a small family or among roommates, some personally owned space and possessions is vital. It's reflected in other species, so it's certainly part of how we evolved, socially if not physically. To say that a nomadic group "knows everything about everyone else" is as strange a concept as to say that nomadic groups "live in tune with nature". It's not borne out by observation, or by observing other species with similar practices.
The complexities of privacy that are common in civilizations, where people in cities have high population density, are greater. I'll certainly agree with that that. Bringing it back around to SSH and system security, a tight knit physical and social community can have lower privacy standards because it's so easy to simply "peer over the cubicle wall", so excess privacy is a pointless waste of resources. But the existence of predators, or of vermin who will nest in one person's personal workspace and reach out to infest the entire group, is a given. The previous lack of expensive privacy is now an opening for attack vectors, and they are constantly being probed.
Oh, it certainly exists in other species. Even unsophisticated animals have dens or hunting grounds, turf that they protect from members of their own species and try to conceal both from other members of that species.
For your own safety and piece of mind, do not do this. As a part-time support person in a small environment, you don't have the time to master the subtleties of effectively rootkitting a commercial server and maintaining special, out-of-band, non-vendor supported services on it. It's likely to break down at unpredictable times with basic system updates and network firewall changes associated with the NAS services themselves.
Strongly, strongly consider fragmenting the functions. A VPN and firewall box, running on a small physical applicance, is generally much safer to expose to the Internet than a Windows server that will requirely monthly major updates and possible reboots and possibly daily vital security updates that are too late to salvage the system from what it's _already_ been exposed to.
Oh, yes. Lose the FTP server, unless it's only for upload from your clients and there is no "browsing" function for the files already uploaded. FTP packets are sniffed on a frequent basis on poorly manged, publicly exposed routers and network switches for login names and passwords. It exposes you and your clients to all sorts of security issues if they're using their Windows login names and passwords for FTP access. There are numerous ways to do this better: gather your requirements first, and you can assess whether HTTPS, SFTP, FTPS, or something else might be better. The only reasons to use FTP now are obsolete clients that cannot be upgraded, technical people who refuse to be educated, and publicly accessible download sites with anonymous access.
I've got bulk rates for you: a set of/16 addresses at 127.1.0.0/16, 127.2.0.0/16, 127.3.0.0/16, etc. Only $50,000 each, and each is guaranteed reachable from every machine you own, even if the wireless isn't working.
Don't use them. Get behind a reasonably effective NAT and firewall, and block external traffic from ever entering your local network. The fragility and instability of hand-maintaining your own individual host firewalls is a constant drain on your personal time and your system resources. I've not seen a single company in the last 5 years use IPv6 internally, and very few bother with firewalls on individual hosts for Linux or UNIX systems.
For laptops or firewall devices, yes, firewalls are very handy and deserve some use and attention.
Look for the key word "ISV" in the transcript, it's at the core of the problems and multiple violations of commercial agreements with Novell as a business partner, and is core to Microsoft using its monopoly position to lock out competitors from office suite products. Microsoft had a contractual obligation with Novell to publish those API's, and suddenly stopped doing so shortly before release, when Novell had already committed their engineers and project plans to working with those API's.
That's not "changing from the BETA", that's bait and switch.
While PJ, the original creator of Groklaw, has stepped aside and let someone else run it, they're still very good about providing the actual court documents and testimony from relevant court rooms. Even a casual examinatiion of the court documents reveals some astounding rulings in Microsoft's favor by this particular judge, including rulings that have already been overturned on appeal.
A judge who's already been overturned on appeal would seem to have every reason to be cautious and _not_ make other strange ruliings that would provide grounds for appeal, at least if that judge is honest and does not with to waste people's time. And this ruling does seem very strange.
Only if you want it to fail completely at the worst possible moments, buy expensive clients, and run headlong into the built-in limitations with no possibility to extend or work around them without hiring 3 people to support Sharepoint. I just dealt with a company that had gone this route, and it was very difficult to extract any information to usable configuration or scanning information, especially for security surveys.
What you need depends on the scale. Large environments might benefit from commercial tools like OpsManager, which is quite expensive, and for which 90% of the features are unwanted and not useful. But the 10% that are useful include very effective configurable auto-mapping and Visio plugins for shops that like Visio.
I'm afraid it's worse than this. I spent a long time discussing this last week with a colleague who'd been diagnosed last year, and who's lost 30 pounds and gotten off medication. Early Type 2 diabetes can cause elevated insulin levels, which triggers hunger, which gets you to eat more, which puts on weight, which reduces your willingness to exercise and aggravates the diabetes and raises insulin levels (beause exercise makes insulin more effective), and this colleague suffered from a realy positive feedback loop they hadn't even noticed. A quick Wikipedia search shows that it's not a universally accepted model, but neither is the idea that obesity causes diabetes: to quote an excellent rule of statistics, "correlation is not causation".
Soome people with Type 2 diabets are quite touchy about ithe obesity correlation: we had to have a quiet chat about people who'd heard they were diabetic and asked if they should be eating certain things. Given the slices of party cake the colleague had been eating, the concern was understandable, but construed as being "food police" and very unwelcome indeed.
It's completely reasonable for you, with orders, to investigate. But if you pull this behind the back of the existing infrastructure maintainers, you could be in a a great deal of trouble for violating security policies that no one here is equipped to help you follow. Contact the IT personnel at your main base, and find out what they've already got in place, and what policies you need to work with.
As a deployed ship, every communications should be encrypted: even casual email to your families about when you're coming back might be considered military intelligence, and I've seen commercial cases where personnel were not _allowed_ to pre-encrypt their communications before it hit the local proxies, precisely so it could be checked for confidential material. I've explained to clients and partners that this allows local monitoring to intercept the communications between their private machines and the proxy, and for anyone who cracks the proxy to read it all, and then they had to factor in _those_ issues.
You're also going to face potential issues with people taking "unsecured" machines for any "social" network and cross-connecting them to secure communications. That's just what the IT personnel at your home base should be able to help you assess. Even if you wind up doing most of the work, keeping them informed will mean that the pitfalls or incompatible tools can be recorded for anyone else who needs to do this.
Another group that might be able to help is the USO: They've been involved in helping communications for active military throughout their existence, and they might be aware of others who've faced just these questions and whom your normal chain of command might not be aware of.
Hotmail didn't even deserve the level of use it had: it was competing with AOL, and had the kind of ubiquitous "auto-installed with your computer as as default, and we'll keep trying to re-install it" that AOL used to have. Both services attempted to replace the rest of your desktop and were unusable without very specific clients.
Google's approach of working well, inside your normal web browsers, has been extremely effective. They've also been vastly more reliable than almost any in-house mail server for a lot of reasons: they were able to effectively implement basic spam filtering, they're big enough to survive denial of service attacks, and their distributed and well scaled architectures survive disasters most mail servers can only imagine being able to cope with. Also, they've avoided the religious wars about supported clients and usage models by keeping their systems off-site and their services well defined. The Exchange OWA, and the dozens of "plug-ins" connected to it to support other email clients, have driven people directly to GMail.
Hotmail, and Exchange, _never_ worked well with non-Microsoft clients, whether browsers or IMAP access. Google always did, Google always actually published and followed their API's so other people could integrate with it, and Microsoft _never_ published or followed their own API's. What little Microsoft published was always incomplete when it was not a blatant lie.
Google's use of and investment in open standards paid off.
Hold it there, please. Many of the core, better paying computer related jobs in finance are not in fiscal analysis. They're in support technologies, such as storage, low latency networking, and virtualization. If our original poster wants to get into the data analysis part of the work, he's got a good start with two degrees, but that field is dominated by very educated people in business theory and statistics. It's also where the criminal and insider trading part of finance starts to become common, and it's very vulnerable to layoffs when somone with a "big vision" changes company or is let go.
High frequency trading, where a lot of finance computing went over the last 10 years, is in deep trouble. Stay away from it: legislation to protect the markets from the inevitable positive feedback loops built into such low latency, high gain feedback systems is inevitable and is already being felt, and the use of FPGA's right at the stock market feeds to pre-process the data and transmit only purchase orders is eliminating the need for the very expensive low latency network technologies that were in vogue. (http://www.highfrequencytraders.com/featured/1191/high-frequency-trading-and-rise-fpga)
If you go this route, do learn to think about how your API's affect other people's work. Very minor differences in the format of data passwd can have _tremendous_ impact on performance, especially when doing database interactions.
fsf.org is not a Microsoft partner, and does not have contract relationship with Microsoft. Expect whitelisting to be slow and require excessive steps of confirmation through an outsourced support line where "your call is very important to us", they insist on having the registration number of your copies of Windo2ws software, and they are unable to spell "fsf.".
There was an Ig Nobel award in 2010 for a mathematical model showing that random promotion can actually be _better_ than carefully organized evaluations and gradual promotions. I'm having difficulty finding a copy of the original paper, since it was in a magazine and many of the links have expired, but there's an abstract here.
Start with the early episodes, coupled with Alan Dean Foster's published collections of the episodes. They backfill dialogue and plot that was "left on the cutting room floor" with the limited filming capacity and weekly expense of a weekly television show, material that expands the stories well. And if you can, help fil in the historical background: the kiss between Uhura and Kirk was the first televised kiss between a white man and a black woman, and I recently saw an interview with the actress that discussed it.
"Uhura" inspired a generation of black women to think of themselves as more than props: she was _exactly_ why Whoopi Goldberg leapt at the chance, in the height of her movie career, to join The Next Generation and try to inspire the next generation of youngsters as "Guinan".
How much greater is your income because you received those loans and could go to a much better school? How much more skilled and productive are your work colleagues because they took similar loans to attend a better school? And let's not pretend that either social security or medicare will "go broke". There are going to be drastic cuts in benefits, but they've _always_ been "broke". They're not designed to hold a reserve fund, they're designed to churn their taxes pretty directly into the benefits allocated at the moment.
This doesn't automatically make these loans or programs loans a good investment or justified, but it seems important to provide the basic counter so people are reminded what the real issues are when someone makes a confused, self-serving claim like this. After all, the anonymous poster probably isn't on fire right now: why is he paying taxes for a fire department he's unlikely to need?
If you're only setting up a few systems with modest weight and heat production, in an out of the way corner, consider a half-hight rolling rack if you can find one from a company going out of business, or a local auction house. When my clients have been short of cash for glamorous data centers, I'm helped them find local dealers or even used temporary shelving from a local hardware store, such as Home Depot, for short term and very inexpensive shelving.
Just be careful not to overload such shelving, and be careful to protect your floors. If you start loading it with equipment, it be heavier than a refrigerator on flooring that isn't designed for that kind of load and damage the floors.
I highly recommend the opera at http://www.youtube.com/watch?v=JhEH00rlmz8, from the Ig Nobel prizes a few years ago. It captured the most recent banking crisis rather well, and without the need to blame human greed on misused mathematical formula.
As long as the charges are for a distinct offense, double jeopardy does not apply. Review the definition of double jeopardy carefully. And double jeopardy hardly applies to US courts for UK convictions.
Slashdot Mirror
In what _possible_ way is stock trading a zero-sum game? Every transaction has a cost: like even the most efficient transfers of energy cause some gain in entropy. The idea that "oh, it will average out for individual investors" is ludicrous, because large scale "investment gorups" do, indeed, favor certain types of transactions and can have their assets completely ruined by such losses, and the businesses whose stocks are being traded can be destroyed by such chaos. The idea that other investors will gain those assets neglects both the destruction of the livelihood of the losers, but the loss of abilities to invest or loan further caused by the uncertainty.
The slow disk is why you use rsync or other such efficient mirroring technologies. The tapes have a limited lifespan, they require significant maintenance, and have been prone to far too many mechanical failures and expensive downtime in my experence. The disks can actually be simultaneously connected for casual "read" access with a reasonable USB hub and possibly an additional USB card.
You've also left out the cost of recovery time for users. Swapping tapes to get recovery of arbitrary files is rather awkward. and requires physical access to the server. Either you invest in a tape library that can hold that 24 TB of tape online and provide user access to the tape library (which means two drives in the library, one for backup activity and one for read activity), or you invest in onsite manpower to swap tapes. If you've staff already in the computer room to swap tapes for you, that's workable, but it's very expensive in a small environment, and it interferes with backup operations if you've only the one tape drive.
Swapping USB ports, or even leaving the multiple backup drives constantly on, is much quicker to access the same data, and leaves the full backed up systems or designated pieces of it directly accessible for network exporting, such as with a read-only NFS mount or read-only CIFS mount, for clients to easily recover their own files rather than requiring backup system access. You do have to be cautious with export configurations for performance and security reasons, and to leave the drives easy to swap out, but it's workable.
Actually handling all those tapes and recovering data from them is very expensive in manpower and time, and can be very awkward for recovering data. Those tapes, and tape drives, are also _expensive_. They're useful for sites that require secure off-site storage, or encrypted off-site storage, but for most environments today they are pointless. Easily detachable physical storage has become very inexpensive, far more economical, and is far less vulnerable to the vulnerabilities of mishandling SCSI connections. I've seen far, far too many SCSI setups for tape drives and external media fail due to misconfiguration, miscabling, and the very poor driver integration of SCSI controllers in far too many operating systems. USB has proven startlingly simple, resilient, and _cheap_ to manage.
I use the external drive approach very frequently for data center migration and virtualization OS image migration, though usually I only back up the configuration files from the virtualized hosts, not the complete images. It's very effective. 24 TB is bigger than I've personally done this way, but it's certainly feasible if it's not treated as a single lump. If the the data can be factored reasonably before transferring, don't simply duplicate it every time. Split it up into reasonably sized chunks and _mirror_ it onto the USB drives, so the first backup is lengthy but following backups are far more efficieint.
Assuming that the backup system is Linux based, the ""rsync" tool can be written into a script to see which media is attached, to mount those media, and to mirror the contents of a set of directories to those media.. It's also reasonable to use a USB hub to allow mounting multiple USB devices simultaneously so it can be done all at one time, rather than having to swap media.
The article is excellent. It's publishing guidelines very similar to those I use, and my colleagues use, when dealing with our business partner's accumulated software projects, and covers it very well: I intend to use it as a checklist for spaghetti code integration projects.
I'd emphasize the switch to good source control management (SCM). too many workgroups have undocumented workflows, and benefit profoundly from switching to or learning to properly use a robust system. This process also helps identify who is the primary spaghetti code author. In such a project, there is often a particular developer or "architect" who has been carrying around the functional map of this project in their head. Their time and commitment to get that map into documentation so others can work with it is absolutely necessary to such projects, SCM is often the first step towards this. And if that core developer or architect doesn't agree with the project, _fire them as fast as possible_, because they will hamstring every effort to move to any cleaned up architecture.
Also note that most such core developers or architects have actually been wanting to do something like this cleanup for _years_, and simply haven't been allocated the time and resources to do it. There are risks: repairs are often much cheaper and safer than the kind of large scale this kind of cleanup represents, and the actual benefits have to be presented to the managers or clients to get them to invest manpower, so that core developer often has a huge emotional frustration with the original code. Working with them to get their buy-in, and being willing to trade minor points of disagreement with them to get their cooperation with big issues are priceless on such large projects. Otherwise, they can and often do backstab every integration effort as "wasted time" or "not sufficient", even claiming both at the same time.
Probably not, for you. For companies that host complex websites, and that go through complex load balancing and proxy setups, it's invaluable for assigning SSL keys to particular IP addresses and using IP based virtual hosting instead. This solves an enormous number of complex and subtle configuration conflicts with web servers and load balancers.
I've no idea where you get the idea that in a nomadic culture, "everyone is going to know everything about everyone else". Even in a small family or among roommates, some personally owned space and possessions is vital. It's reflected in other species, so it's certainly part of how we evolved, socially if not physically. To say that a nomadic group "knows everything about everyone else" is as strange a concept as to say that nomadic groups "live in tune with nature". It's not borne out by observation, or by observing other species with similar practices.
The complexities of privacy that are common in civilizations, where people in cities have high population density, are greater. I'll certainly agree with that that. Bringing it back around to SSH and system security, a tight knit physical and social community can have lower privacy standards because it's so easy to simply "peer over the cubicle wall", so excess privacy is a pointless waste of resources. But the existence of predators, or of vermin who will nest in one person's personal workspace and reach out to infest the entire group, is a given. The previous lack of expensive privacy is now an opening for attack vectors, and they are constantly being probed.
Virtualization works very well against it.
Oh, it certainly exists in other species. Even unsophisticated animals have dens or hunting grounds, turf that they protect from members of their own species and try to conceal both from other members of that species.
For your own safety and piece of mind, do not do this. As a part-time support person in a small environment, you don't have the time to master the subtleties of effectively rootkitting a commercial server and maintaining special, out-of-band, non-vendor supported services on it. It's likely to break down at unpredictable times with basic system updates and network firewall changes associated with the NAS services themselves.
Strongly, strongly consider fragmenting the functions. A VPN and firewall box, running on a small physical applicance, is generally much safer to expose to the Internet than a Windows server that will requirely monthly major updates and possible reboots and possibly daily vital security updates that are too late to salvage the system from what it's _already_ been exposed to.
Oh, yes. Lose the FTP server, unless it's only for upload from your clients and there is no "browsing" function for the files already uploaded. FTP packets are sniffed on a frequent basis on poorly manged, publicly exposed routers and network switches for login names and passwords. It exposes you and your clients to all sorts of security issues if they're using their Windows login names and passwords for FTP access. There are numerous ways to do this better: gather your requirements first, and you can assess whether HTTPS, SFTP, FTPS, or something else might be better. The only reasons to use FTP now are obsolete clients that cannot be upgraded, technical people who refuse to be educated, and publicly accessible download sites with anonymous access.
I've got bulk rates for you: a set of /16 addresses at 127.1.0.0/16, 127.2.0.0/16, 127.3.0.0/16, etc. Only $50,000 each, and each is guaranteed reachable from every machine you own, even if the wireless isn't working.
Don't use them. Get behind a reasonably effective NAT and firewall, and block external traffic from ever entering your local network. The fragility and instability of hand-maintaining your own individual host firewalls is a constant drain on your personal time and your system resources. I've not seen a single company in the last 5 years use IPv6 internally, and very few bother with firewalls on individual hosts for Linux or UNIX systems.
For laptops or firewall devices, yes, firewalls are very handy and deserve some use and attention.
This is why Groklaw's excellent, direct publication of the relevant court documents is so very useful to understand the case. the trial transcripts are available, starting at http://www.groklaw.net/article.php?story=20120602215245555&query=microsoft+novell+api, and your claim is not consistent with _either_ side's claims.
Look for the key word "ISV" in the transcript, it's at the core of the problems and multiple violations of commercial agreements with Novell as a business partner, and is core to Microsoft using its monopoly position to lock out competitors from office suite products. Microsoft had a contractual obligation with Novell to publish those API's, and suddenly stopped doing so shortly before release, when Novell had already committed their engineers and project plans to working with those API's.
That's not "changing from the BETA", that's bait and switch.
While PJ, the original creator of Groklaw, has stepped aside and let someone else run it, they're still very good about providing the actual court documents and testimony from relevant court rooms. Even a casual examinatiion of the court documents reveals some astounding rulings in Microsoft's favor by this particular judge, including rulings that have already been overturned on appeal.
A judge who's already been overturned on appeal would seem to have every reason to be cautious and _not_ make other strange ruliings that would provide grounds for appeal, at least if that judge is honest and does not with to waste people's time. And this ruling does seem very strange.
Only if you want it to fail completely at the worst possible moments, buy expensive clients, and run headlong into the built-in limitations with no possibility to extend or work around them without hiring 3 people to support Sharepoint. I just dealt with a company that had gone this route, and it was very difficult to extract any information to usable configuration or scanning information, especially for security surveys.
What you need depends on the scale. Large environments might benefit from commercial tools like OpsManager, which is quite expensive, and for which 90% of the features are unwanted and not useful. But the 10% that are useful include very effective configurable auto-mapping and Visio plugins for shops that like Visio.
I'm afraid it's worse than this. I spent a long time discussing this last week with a colleague who'd been diagnosed last year, and who's lost 30 pounds and gotten off medication. Early Type 2 diabetes can cause elevated insulin levels, which triggers hunger, which gets you to eat more, which puts on weight, which reduces your willingness to exercise and aggravates the diabetes and raises insulin levels (beause exercise makes insulin more effective), and this colleague suffered from a realy positive feedback loop they hadn't even noticed. A quick Wikipedia search shows that it's not a universally accepted model, but neither is the idea that obesity causes diabetes: to quote an excellent rule of statistics, "correlation is not causation".
Soome people with Type 2 diabets are quite touchy about ithe obesity correlation: we had to have a quiet chat about people who'd heard they were diabetic and asked if they should be eating certain things. Given the slices of party cake the colleague had been eating, the concern was understandable, but construed as being "food police" and very unwelcome indeed.
It's completely reasonable for you, with orders, to investigate. But if you pull this behind the back of the existing infrastructure maintainers, you could be in a a great deal of trouble for violating security policies that no one here is equipped to help you follow. Contact the IT personnel at your main base, and find out what they've already got in place, and what policies you need to work with.
As a deployed ship, every communications should be encrypted: even casual email to your families about when you're coming back might be considered military intelligence, and I've seen commercial cases where personnel were not _allowed_ to pre-encrypt their communications before it hit the local proxies, precisely so it could be checked for confidential material. I've explained to clients and partners that this allows local monitoring to intercept the communications between their private machines and the proxy, and for anyone who cracks the proxy to read it all, and then they had to factor in _those_ issues.
You're also going to face potential issues with people taking "unsecured" machines for any "social" network and cross-connecting them to secure communications. That's just what the IT personnel at your home base should be able to help you assess. Even if you wind up doing most of the work, keeping them informed will mean that the pitfalls or incompatible tools can be recorded for anyone else who needs to do this.
Another group that might be able to help is the USO: They've been involved in helping communications for active military throughout their existence, and they might be aware of others who've faced just these questions and whom your normal chain of command might not be aware of.
Hotmail didn't even deserve the level of use it had: it was competing with AOL, and had the kind of ubiquitous "auto-installed with your computer as as default, and we'll keep trying to re-install it" that AOL used to have. Both services attempted to replace the rest of your desktop and were unusable without very specific clients.
Google's approach of working well, inside your normal web browsers, has been extremely effective. They've also been vastly more reliable than almost any in-house mail server for a lot of reasons: they were able to effectively implement basic spam filtering, they're big enough to survive denial of service attacks, and their distributed and well scaled architectures survive disasters most mail servers can only imagine being able to cope with. Also, they've avoided the religious wars about supported clients and usage models by keeping their systems off-site and their services well defined. The Exchange OWA, and the dozens of "plug-ins" connected to it to support other email clients, have driven people directly to GMail.
Hotmail, and Exchange, _never_ worked well with non-Microsoft clients, whether browsers or IMAP access. Google always did, Google always actually published and followed their API's so other people could integrate with it, and Microsoft _never_ published or followed their own API's. What little Microsoft published was always incomplete when it was not a blatant lie.
Google's use of and investment in open standards paid off.
Hold it there, please. Many of the core, better paying computer related jobs in finance are not in fiscal analysis. They're in support technologies, such as storage, low latency networking, and virtualization. If our original poster wants to get into the data analysis part of the work, he's got a good start with two degrees, but that field is dominated by very educated people in business theory and statistics. It's also where the criminal and insider trading part of finance starts to become common, and it's very vulnerable to layoffs when somone with a "big vision" changes company or is let go.
High frequency trading, where a lot of finance computing went over the last 10 years, is in deep trouble. Stay away from it: legislation to protect the markets from the inevitable positive feedback loops built into such low latency, high gain feedback systems is inevitable and is already being felt, and the use of FPGA's right at the stock market feeds to pre-process the data and transmit only purchase orders is eliminating the need for the very expensive low latency network technologies that were in vogue. (http://www.highfrequencytraders.com/featured/1191/high-frequency-trading-and-rise-fpga)
If you go this route, do learn to think about how your API's affect other people's work. Very minor differences in the format of data passwd can have _tremendous_ impact on performance, especially when doing database interactions.
fsf.org is not a Microsoft partner, and does not have contract relationship with Microsoft. Expect whitelisting to be slow and require excessive steps of confirmation through an outsourced support line where "your call is very important to us", they insist on having the registration number of your copies of Windo2ws software, and they are unable to spell "fsf.".
There was an Ig Nobel award in 2010 for a mathematical model showing that random promotion can actually be _better_ than carefully organized evaluations and gradual promotions. I'm having difficulty finding a copy of the original paper, since it was in a magazine and many of the links have expired, but there's an abstract here.
http://oldweb.ct.infn.it/cactus/peter_principle_sup_material.html
Start with the early episodes, coupled with Alan Dean Foster's published collections of the episodes. They backfill dialogue and plot that was "left on the cutting room floor" with the limited filming capacity and weekly expense of a weekly television show, material that expands the stories well. And if you can, help fil in the historical background: the kiss between Uhura and Kirk was the first televised kiss between a white man and a black woman, and I recently saw an interview with the actress that discussed it.
"Uhura" inspired a generation of black women to think of themselves as more than props: she was _exactly_ why Whoopi Goldberg leapt at the chance, in the height of her movie career, to join The Next Generation and try to inspire the next generation of youngsters as "Guinan".
How much greater is your income because you received those loans and could go to a much better school? How much more skilled and productive are your work colleagues because they took similar loans to attend a better school? And let's not pretend that either social security or medicare will "go broke". There are going to be drastic cuts in benefits, but they've _always_ been "broke". They're not designed to hold a reserve fund, they're designed to churn their taxes pretty directly into the benefits allocated at the moment.
This doesn't automatically make these loans or programs loans a good investment or justified, but it seems important to provide the basic counter so people are reminded what the real issues are when someone makes a confused, self-serving claim like this. After all, the anonymous poster probably isn't on fire right now: why is he paying taxes for a fire department he's unlikely to need?
If you're only setting up a few systems with modest weight and heat production, in an out of the way corner, consider a half-hight rolling rack if you can find one from a company going out of business, or a local auction house. When my clients have been short of cash for glamorous data centers, I'm helped them find local dealers or even used temporary shelving from a local hardware store, such as Home Depot, for short term and very inexpensive shelving.
Just be careful not to overload such shelving, and be careful to protect your floors. If you start loading it with equipment, it be heavier than a refrigerator on flooring that isn't designed for that kind of load and damage the floors.
I highly recommend the opera at http://www.youtube.com/watch?v=JhEH00rlmz8, from the Ig Nobel prizes a few years ago. It captured the most recent banking crisis rather well, and without the need to blame human greed on misused mathematical formula.
As long as the charges are for a distinct offense, double jeopardy does not apply. Review the definition of double jeopardy carefully. And double jeopardy hardly applies to US courts for UK convictions.