I've hung out with female feds at two different events. Alas, nobody tried to grab them. That would have been fun to watch.
Isn't part of the hacker ethos that the code rules? Who cares the age, sex, color, national origin, or creed of the writer? Do any of these factors make for better or worse code? If not, then differentiators based on those factors have no place in the hacker culture.
Any type of harassment needs to be dealt with rapidly, firmly, and appropriately. At the hacker cons I've attended, I've been fortunate to attend sessions with female presenters. I've also had the opportunity to interact with female attendees and found them to be logical, intelligent, and well spoken. I go to such cons to learn, network, and have some fun. Playing grabass just isn't on the menu. Such things are the province of small minds with no social skills. I'm all for harassers getting a swift kick - or several. I have a feeling though that the goons wouldn't be enamored with that idea.
I'm old enough to have been in the military before, during, and after the 1991 Tailhook incident. Hopefully the pendulum won't swing so far in the other direction that personnel are tossed and/or banned based on unsubstantiated allegations. There are very real incidents that need to be dealt with firmly. There are also invented incidents that should result in sanctions against the person making the false allegations.
No they're serious, and don't call me Shirley.
Some classes are enhanced by interaction with the professor, other students, and invaluable hands-on lab time. Other classes can be completed online without losing any of the value. Take for example the common core classes of mathematics, liberal arts, history, etc. Does the student gain anything by physically sitting in a classroom? If these classes can be taken care of online for little cost then the student's scarce time and treasure can be leveraged to attend only the courses which benefit from interaction and lab time in a physical university setting.
The key is to select the appropriate tool for the appropriate task. Online isn't always the answer. In residence isn't always the answer. Having additional tools and methods available can make things more efficient.
When it comes to Netflix competitors, there are two main issues in the game:
1) Will they exempt Netflix content from their data caps - No. For as long as possible, providers with competing VoD services will continue to count the Netflix content against data caps while exempting their own offerings. This one is a no-brainer.
2) Will they provide the space, power, and cooling to host the boxes within their networks - Yes. Whatever their competing offerings, bandwidth still costs money. At the very least, peering with Netflix at the listed exchange points will likely reduce transit costs. Given the somewhat sparse availability of peering points, I expect to see large metro ISPs consider putting the devices in their datacenters.
Now you have a DSA with 10 customers on it, 5 wanted 3MB service, the feds paid to have 2 T1 lines installed. That will work, and they likely wont have any bandwidth problems. Fast forward 3 years. You now have 10 customers on the DSA, they ALL have 5MB service and ALL have netflix accounts. Hence the situation you are in. The customers demand the ISP upgrade. Those 10 customers combined are paying about $350/month total. To add more trunks to the DSA will cost $300k. It's not hard to do the math there... it's not going to happen. So then they go to the local government and ask them to complain again... the local government says "You have internet, what are you complaining about?" and the feds? They got their 95%+ served number for the next election, they don't care about you.
Having worked for a DLEC and a couple of CLECs, Charliemopps very likely hit the nail on the head. The DSLAM or DSA (equivalent in this case) is likely fed with 2-4 DS1s on an IMUX. During the day, you have little contention for the 3-6Mbps of bandwidth. In the evening, when everyone else comes home, your speed drops significantly. This is normal and expected. It only takes a few customers running bandwidth intensive apps to consume the available bandwidth. There are solutions to prevent a few piggy users from consuming almost all the bandwidth. Those solutions require deployment of either hardware or software and additional management. Given that the ISP/telco is almost certainly losing money on the service they are currently providing, they are unlikely to deploy those capabilities to the local CO.
If you do some digging and troubleshooting, is there a pingable address on the DSLAM or does it pass through at Layer-2? If you can ping the DSLAM and beyond it, you can figure out whether the slowdown is on your subscriber loop or on the connection from the DSLAM deeper into the ISPs network. Opening trouble tickets on your subscriber loop isn't going to fix a bandwidth contention issue. While it is possible there is an issue on the subscriber loop, my money is on bandwidth contention from the DSLAM. You might get some attention to a bandwidth contention issue with the trouble tickets. The IMUX equipment I'm familiar with ranges from 4-8 DS1s. If the IMUX isn't already maxed out on DS1 interfaces, you may see some relief. If the IMUX is already maxed out, you're probably not going to see much change. In a money losing situation, you're unlikely to see an upgrade to DS-3 backhaul or anything faster for a rural DSLAM.