We didn't have bad winds here in Vermont, but 10" of rain in several hours caused flash floods 7 or 8 times the volume of normal spring flooding. Almost every major road in the state has been washed out in at least one place and there are dozens of bridges gone or damaged. See: http://www.burlingtonfreepress.com/article/20110829/NEWS02/110829007/Governor-Vermont-seeing-worst-flooding-century

As one example, my local New Haven River normally flows at ~200 cubic-feet/second (cfs) through the summer and winter and floods to 2,000-3,000 cfs each spring. Last night it flash flooded to 20,000 cfs and took out several sections of roads and bridges. In southern VT, the Williams river flashed from 80 cfs to 50,000 cfs (normal spring flooding of 5,000-8,000 cfs).

I live on a hill, so we slept through much of the storm without worry. Those in the valleys had to be evacuated.

If Apple and MS would allow installing of applications via mechanisms other than the App Store (e.g. side-loading), then there wouldn't be any conflict with the GPLv3 (which requires that recipients be able to install the software (and derivatives) without proprietary keys or distribution-control mechanisms.

This is not about lawsuit trolls, but about keeping an iron grip on the distribution channel.

Exactly what part of the GPLv3 prevents distribution via an "app store"? The only thing I can find is a restriction on only allowing distribution via an app-store. If MS and/or Apple allow 'side-loading' of applications, then as far as I can tell they would be perfectly in the clear with regard to the GPLv3 (as the Android store is). Its not the concept of the app-store, but enforcing a single app-store as the only way to distribute any applications that is the problem.

During the past 3 years I have developed several applications with the Zend framework (which I really like as MVC frameworks go). Earlier in my career my team developed its own MVC framework which turned out to operate well, but wasn't worth the immense development effort. Recently I've worked on several "sites" and one "application" based on Drupal.

What I have found in this process is that Drupal is not a content management system, but rather a framework for building a content management system. It doesn't do much out of the box with no community modules (unlike Joomla or WordPress), but its plugin system works well for developing a very wide variety of CMS platforms for many uses. Just as Drupal is not so specialized as a particular CMS, neither is it so general as an MVC framework. For example, Zend's 'router' is much more flexible than Drupal's 'menu' system and Zend's configuration system blows away anything in Drupal.

A great use case for Drupal is a "site" with lots of "articles". Adding an additional data field (say an address), theming it, and using it to filter a dynamic selection of content is about a 15 minute job that requires a few clicks in the Content-Type UI, a few clicks in the Views UI for the filter, and maybe a few template lines for theming if the field will be displayed. The user-input forms, content validation, data storage, and default theme are all handled. Contrast this to using an MVC framework where you have to add properties to your model (and update the database schema if not using an ORM), then add some lines to your edit-form view to add the fields to the HTML, then update the form-save controller action to pass off the submitted form data to the model after validating it, then update the display view to show the new field, then add a new action that filters based on your new field. This is certainly not the end of the world, but it requires a significant bit of programming.

At the end of the day it is all about using the right tool for the job. If I am going to develop an application with a custom database and data model (or based on an existing database) and just want to put a front-end on it, I'll use the Zend framework for the front end. If however, I'm going to build something that looks like a CMS with something like "content nodes", user-comments, tagging/categorization, a variety of user-roles, etc, then it is going to be much easier and more supportable to build such a system in Drupal.

With every framework there is an explicit or implicit vision baked into how it is designed. If your project fits into this vision then the framework will work smoothly and be a fabulous help over starting from scratch. If your project doesn't fit the framework's vision then you will find yourself fighting with the baked in assumptions and ultimately frustrated by all of the workarounds you have to write.

Another here who loves the AwesomeBar!

I don't have mod-points, so I'll just follow the trend and make this thread an ad-hoc poll.

According to this page, the last patents for h264 may not expire until 2028:

http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-July/020737.html

While 100Mb/s may be excessive give usage patterns based on slower network speeds, the vastly higher speed opens up completely new usage paradigms. For example, I currently keep my all of my photos and and many videos on my laptop's hard drive so that I can use them at home, a friend's house, or elsewhere. Were 100Mb/s to be the norm, I'd just keep everything on a massive home NAS and just stream it as needed to my laptop or other computing device.

Given a fast enough connection, one wouldn't even have to bother with making a local copy of a high-def video owned by a friend, just stream it as you watch it.

Amen. Living in Vermont I often take the "Montrealer" down the NY side of Lake Champlain to NYC. The freight-track is slow, bumpy, and generally in terrible condition. One trip a few years ago took 12 hours to get from Port Henry NY to NYC (about a 5-hour drive).

This past summer I took the TGV from Lyon to Paris and had my GPS running for the trip. We topped out at 195mph for a few sections and with several stops averaged 150mph for the 2.5 hour trip. It was quite a blast (especially at 110 euros) and I wish I could do that kind of trip around New England and the mid-Atlantic.

My last Amtrak trip from Vermont to NYC (a 5-hour drive) took 12 hours because of two break-downs of trains ahead of us. I love the train and not having to deal with parking in NYC, but that trip was exhausting.

Note that the policy allows for exceptions to be made by submitting a waver request to the provost.

If I remember correctly, one of the other articles on this policy mentioned that requests would likely be automatically approved. The waver request submission was simply added to make open-access the default rather than something faculty would have to opt-in to.

No billboards here in Vermont either.

As well, all business signs must be less than 1-story tall. No gas station signs or golden arches on giant towers here.

To make up for the lack of billboards all businesses can get standardized road-sign-sized directional markers just before their turn off the main road. These have the same font as road signs, an arrow, and an optional miniature business logo. I personally find these directional markers very useful for finding and discovering businesses. Its wonderful to have timely and consistent directional information without being constantly bludgeoned with it.