I thought I made it clear that googling for obscure error codes was a windows thing....

They're sitting on billions because they know how to market to the people holding the purse strings (non-technical executives). Nobody ever got fired for buying Microsoft...even if its not the best tool for the job (and I will give it to them...some of their stuff is genuinely the best). That said, You'd be surprised how little "compiling" of software is required these days with linux-based solutions. Also, my biggest gripe about Microsoft is having to look for non-descript error codes online to figure out what's broken vs Iooking at an error log with some verbosity. Having access to the code also makes it easier to implement a bug fix since I can be more precise on my bug reporting, saving everybody time.

So, yes...milenials are more immersed in technology, and have a better handle on how to use it, but that doesn't mean they have an understanding of how it works. To call every 20 year old with a cell phone an expert in mobile communications devices is a gross exaggeration. If they're more demanding its because they're used to it just being there...like water or electricity.

Just do it! Tech is one of those areas where you can gain experience and knowledge on your own with minimal financial outlay. So, study up. Play with things. I'm not sure what the climate is like in your district, but perhaps you can also take on some more technical responsibility in your school district? Through reading, tinkering, and applying your learned knowledge, you'll eventually get to a point where you can legitimately do this sort of thing full time. It's a process, but it's totally doable.

I've used Twonky Media Server for a while as a UPnP server, and been reasonably pleased. Plex is great for all the metadata it gives you along with the other features (particularly the ability to stream iPlayer content with the plugin that's available), but is really really finicky about file naming conventions and directory structures. Twonky seems to just list and transcode without much fuss.

Converting the existing POTS network to an IP network (even for voice) is far more complicated than you make it out to be. The main reason its tougher is SIGNAL DEGREDATION OVER DISTANCE.

Every wire carrying an electrical signal over distance is subject to signal attenuation due to electromagnetic forces interfering with the signal (e.g. other cables, electrical wires, etc). This is why you can only run a cat-5e ~1500 feet before you need to insert a repeater. The way the phone company got around this for serving POTS to far points is by inserting load coils at strategic points to boost the signal enough to go where it needed to go. That said, load coils are not suitable when carrying anything other than voice. This is why DSL availability is limited to places close to the CO, or places with a heavy business presence (as there are usually satellite distribution facilities from which your DSL can originate). Additionally, telephone cables typically contain several hundred to several thousand pairs, each serving a client. The shielding for a pair towards the outside of a cable is far less than the shielding for a pair towards the core of the cable. Not all pairs in a cable are even viable for DSL.

To make this happen, the phone company needs to substantially increase the presence of fiber EVERYWHERE: This is similar to the way cable does it, in that fiber is usually run to every street, and the "last mile" is carried over RG6, which in turn is branched off of for every customer. There would of course be other implications for using the existing infrastructure for the last-mile, and last-mile really means something more like "last couple of feet".

In summary, this isn't happening any time soon since it involves substantial investment in the existing infrastructure. While FTTP is promissing, it still has a long way to go.

As somebody who spent a lot of time and energy helping acquire such a device for his father who suffered from ALS, I would like to highlight some important facts.

Many of the devices that the insurance companies cover are actually modified PC's. Before you say that people are better off buying a computer and having insurance foot the bill, look at the facts:

1. These PC's come modified with software and other interfaces which are specially designed based on years of research to meet the needs of the disabled for communication in the most intuitive way possible.

2. Often times the software is placed on an embedded windows system so that its harder to "break" with malware, and the like. Very few PC owners apart from the tech savy can say they've never gotten a computer virus or some form of malware. Even us techies slip up sometimes. Can you imagine if your lifeline were disabled by a virus? This is exactly what these devices are. Lifelines. People rely on them every day for the basic things we take for granted. Having the software embedded keeps the device functioning. Having functionality limited to...well....speaking...that makes the device far less daunting to those who might not be as computer savvy.

3. There are lots of different attachments available for these devices that let pretty much anyone with any level of disability use them. Each attachment is geared towards using the functionality a person has left. These are niche items that are pretty hard to come by at WalMart.

4. These computers are generally ruggedized (usually a toughbook, or something similar). The ruggedization is critical when the device goes everywhere with you.

The bottom line, really, is that these devices are designed to work any time anywhere for anyone. These are really custom solutions. Also, a whole lot of vendor support comes with the device, which is critical to making the most of it. This entire package, including the support, the level of customization in terms of input devices and software tools, and the level of quality and reliability seem to justify the high price in my eyes.

Your insurance company, believe it or not, has your best interest in mind as well as their own when they decide what is and isn't covered. These costly specialized devices are the best option for a whole lot of people. By only covering a solution like this, the insurance company knows you're getting what you need, which is tough to do if you're talking about building a system yourself.

I could have created a home-brew solution, but it would have been without the benefit of years of research into the progression of various diseases and the capabilities of somebody paralyzed from the neck down. Why should a patient have to deal with debugging a home-brew solution or trying to use a conventional mouse or keyboard when they can barely move their fingers? Being paralyzed is frustrating enough as it is...they don't need the extra stress.

On a side note, you can in fact work with the vendor and the insurance company to have an "add-on" placed in the computer-turned-medical device to allow you to use it as a computer as well. The expense is out of pocket, but is usually far less than the cost of a computer.

Here's how it works, at least for Verizon on the east coast... Depending on the arrangements between Verizon, your electric company, and your town, Verizon either owns the poles, leases space on the poles, or jointly owns the poles with the electric company. Verizon lays and maintains the cable for their copper and fiber networks. In the case of the copper network and their legacy (non-FiOS) fiber network, they are obligated by law to lease the pairs out to CoLocators, or more simply, mom and pop telco's and other telcos without a presence in the area that still wish to supply service (like AT&T local service). For every cable, fiber, pole, anchor, guy wire, conduit, and duct placed or owned by Verizon, Verizon is taxed above and beyond the regulatory fees they might pass on to you in your bill. It functions much like property taxes. In essence, Verizon is leasing space within the town's right of way. Anyone can use the right of way, including gas, electric, and sewage, subject to the same regulations. In rare cases where Verizon needs to extend beyond the right of way, they will arrange an agreement with a property owner known as an easement. This agreement grants Verizon the right to extend beyond the right of way within an agreed apon area in exchange for monetary or other compensation. The bottom line is that Verizon (or more generically, your local telephone company) owns the network. They are taxed to high heavens on the network. Due to antitrust rulings of old, they are required to share their network at a reasonable cost to prevent them from establishing any sort of monopoly. The antitrust rulings apply to the copper network as well as their last-mile fiber. These laws do not however apply to their up and coming FiOS network. Now, what they happen to charge for the right to use their network is their choice, but that being said, it must be fair and may not be anti-competitive, which is what this court case seems to be about. One thing must be made certain though...Verizon is NOT getting a free ride by any stretch of the imagination. They pay through the nose for every piece of plant they deploy. For more information on regulations for your area, check out your public library, city hall (the town engineer's office), and maybe even your telephone company. >cue the "The More you Know!" screen graphics...

I understand your frustration. One workaround I've seen uses the Spring framework's annoyingly-named AbstractTransactionalDataSourceSpringContextTests. Your test classes subclass that monstrosity, and after each test method is run the transaction is rolled back to avoid mucking up the DB for subsequent tests. When you test DAOs, you have to have a custom method for inserting test data before or during each test. Once you get above the data access layer, you just use your now-tested DAOs.

It requires you to define the way you get your database connection through Spring, but that abstraction is necessary for unit testing DB-driven apps anyway. On one of my projects, I have one set of bean descriptions for unit testing which connects right to the DB and one set of beans for when the app is running in a Tomcat container. It's not a perfect method, that's for sure, but it allows me to unit test my code pretty painlessly once it's set up.