Those 60's and 70's tracks are the big earners. Go look at how much a copy of pink floyd's The Wall is, and think how long ago it recouped any costs. Or examine how much it costs to download anything by Abba onto your phone as a ringtone. Now, a lot has (thankfully) fallen by the wayside, but the stuff that survived is so very, very profitable.
This is different from games ($5 bargain basement within 3 years), even most DVDs. The record companies love their back catalogue, and dont want to let go. This is why they have been pushing for longer copyrights on live recordings across the EU and US.
It also has to have well documented code, and be designed so that you can get in and fiddle with a bit without spending two years understanding the app first. It also ought to have a community process that accepts well written code (with tests) from outsiders.
That's one issue I have with Open Office there - I am fed up with the "do you really want to save this.doc file as a.doc file" dialogs, but cannot face setting up the build process or the 5 hour build times to do it. And I have the (probably unfounded) fear that with all the sun and ibm staffers on it, they'll ignore submissions from a random like myself.
Another area of difference is decision making. companies have meetings then act on them; OSS projects have email discussions which get resolved one way or another -leaving a searchable archive of the discussion for later. Eventually those mail archives become the group memory.
OSS projects need to be open, to end users, and to develoeprs. -steve
hey, if you are happy with make, stick with it. Use the time you have saved by migrating to write unit tests. CppUnit, for example, although you'll find that the first test that fails probably corrupts memory so badly you need to ignore the rest of the results.
In the little niche that is Java, Ant has managed to replace make. Yes, it is a little niche, but it has become so common that you assume projects have build files, people know how to write them to different levels of competence, and ides handle it. Indeed, the latest IDEs have ant debuggers. I dont know if that constitutes a success or a failure:(
The underlying problems we are trying to solve? Scale. Change. Complexity. The common ones of software engineering. In this respect, the next generation systems like Maven/maven2 may do even better, even though they are much less mainstream. Maven will happily pull down maven modules and the libraries your app needs from the big repositories out there (ibiblio.org and cvs.apache.org), so you can declare your library dependencies in a little xML file, the tools will pull them down, build your app, run your tests and then publish the built artifacts with the dependency files (.pom files). When someone else builds with your artifact, they get the things you built with too. I'm personally against such transitive logic, but it interests me.
the other interesting thing that all this stuff has enabled is apache gump: http://gump.apache.org/
it checks out and builds all the OSS java projects, in one giant dependency graph. My projects are generating failure mail today, because some other project has done a backwards incompatible change between their release and SVN head. hopefully they will fix that before they ship; the automated blame mail will help motivate them.
That kind of collaborative development is something that platform neutral languages and build tools enable. Ant works in Java land because it self contained: everyone downloading and using Java apps has the underlying software needed to do a build. If you could only build OSS Java apps on a single platform, say Linux, the number of contributors would be that much less.
if you are only targeting a single platform, specifically linux/unix, and are targeting C++, then yes, native build tools make more sense. I just wish we could move beyond make.
Ant is more java-centric; it understands more about testing and deployment. It is also designed to be portable.
C/C++ build processes are all about complile-link-(test)-release. compilation takes forever, so you have to minimise rebuilds through all the dependency declarations. Then linking is so painful because of all the compiler options.
In java compilation is fast; a complete rebuild of a project takes under a minute, leaving you plenty of time to run tests. One thing that really has taken off in java-land (but not everywhere; too many projects still need to look at it), is junit-based unit testing. Ant manages testing and report generation as part of the build process.
IMO, test-driven-development, which in java mostly means junit, is the most important transformation in dev processes of recent years.
Where autoconf+make+the Gnu toolchain is great at is for compiling down C/C++ apps to native code. That is hard, and autoconf and gcc do wonders there. You also need the full suite of gnu tools for a big project, if you start doing things like sed editing of code, piping results of a command into a grep and then mail. Given that the unix command set is essentially infinite, make+unix is inherently more powerful than ant, which has sacrificed power for portability.
Now, if you move to languages that dont have any compilation -python, perl and ruby- for example, the build process changes once again. Compilation? Gone. Linking? gone. all you need is testing, distribution and deployment.
In a world like that, both the dev process -and the build tools that reflect that process- are transformed once again. you still need ubquitous testing and automating that is excellent, but much of the classic build is over.
As a member of the Ant team, I also have to bemoan their use of a non-standard build tool, given that there is pretty good support for C++ compiles in ant-contrib's , and with extra work C++ support could be improved.
without something portable like Ant or SCons, you end up needing either to
-build your own tools (this is what Microsoft's shared source version of.NET does; it builds things like NMAKE, their worst-in-class make tool, then builds the rest of the system)
-require a common toolchain on every box (e.g. Unix make+the unix commands; cygwin on windows)
The trouble with IDEs, is that they are either platform specific, or use their own configuration files to control the build. In Java Ant has finally become common enough (after 5 years) that it is broadly supported in IDEs, so you get the best of both worlds.
In C++ land, most people resort to the common toolchain, because only the ambitious fools with time on their hands bother to write their own build system. Does that mean it should't be done? No, just that it would be silly if every fairly large project came up with their own build tools. Instead every few years, we really ought to revisit the build processes and tools of the OSS projects, and see how they can be improved.
I do standards work: Hawaii, Chicago, Berlin, next month Boston.
Why? To standardise a system (http://smartfrog.org/) that is already available as an LGPL product, but is being reimplemented by others.
But most of those expenses paid trips end up sitting in meeting rooms, discussing issues of XML namespaces, the umpteen WS-something web service standards that are internally inconsistent, or trying to come up with compromise designs that work less well than those of the individual groups. Also, there isnt enough test-centric thinking going on. I'm trying to fix the latter; our test suite is BSD-licensed and hosted on Sourceforge, but we are only one project out of many.
I am not convinced that standards bodies are the right thing for OSS projects. Too much committee work, you have to be a funded developer to take part, more focus on neatness of the document or the power of the vendor rather than the quality of the code.
I understand some of the goals of mono -language independent library linking is great...even linking C++ applications has always been a bit hit and miss.
But too much of Mono's focus has been on doing a clone of the windows APIs, letting people port.NET code to Linux. Which helps legitimise.NET. They even do things like XBuild, which is a clone of the MSBuild build tool, which is itself nothing but a ripoff of Nant/Ant. Better to embrace NAnt as the mono build tool, instead of trying to mirror every single feature of the.NET system. Particularly because the Microsoft runtime exposes its windows underpinnings everywhere. The semantics of many CLR calls are exactly those of the windows things underneath, be it::OpenFile or::CreateProcess, which makes it hard to be truly portable...
Im use MSword to update a book and find that it has truly awful features; Bad x-referencing (compare with LaTeX), quirky font handling, inconsistent handling of embedded stuff. I have some docs with visio inserts that crash word on on some vmware images of mine, yet the same doc is readable by others,
But OOo has had some awful usability features that get in the way of the fact that its core functionality is pretty good. Example: its auto-collect words for autocompletion adds words that are not spelled right. It should be vagely smart and only add correct words, otherwise you end up replicating spelling errors. Example: its "do you really want to save this as MS word" complaints, repeated automatically when you have autosave turned on. I dont think the IDE is ready (with 1.1; I have hopes for 2.0 but bemoan its java dependencies)
The alternative i would like (esp on Linux), is framemaker, but it is very expensive on windows and not currently available on linux. A cheap -$100-$150 version of frame would have me buy a copy for the linux box and the windows laptop.
I do have high hopes for OOo, in particular, I hope its cost ($/£/0) will overcome its usability defects.
the book (I have a copy) goes into detail on extending lucene with handlers for different formats, filters, and things like stem rules (language specific rules for stemming words).
It also talks about the indexing format; how the indexes are stored and searched. If that aint enough, well, the source is up on apache.org
Lucene is an Apache licensed java project; there is a.NET version that may work on Mono too.
The nice thing about Lucene is it adds indexing and searching to anything you want -some search plugin for outlook (blech) is built on lucene.net; imagine an equivalent for the unix mail systems -thunderbird , evolution or emacs, for example.
Overall, I think the whole TCK stuff sucks. Secret compliance tests indeed. How can I make my own redist of something like Axis (with javax.xml classes) without making the statement about compliance, and how can I do that without the TCK.
We need to do better. That is why things like ruby and python appeal to me: no sun in charge. And the grid related standard that I am working on? Its test suite is BSD-licensed and hosted on sourceforge; part of the gump nightly build.
the thing is, GPL already has a "sue someone over the software and your rights go away clause". The apache #2 license just explicitly says "and that includes patent infrigements", and also takes away the need for the credits in the docs.
I understand why you dont need a plethora of licenses, and think that there are far too many OSS licenses out there, that together blur the distinction between closed-source and open-source, as they remove the gap between shared-source things (MS, vmware) and corporate-open-source (sun stuff). I just think that patents are a potential troublespot. Is the ASF license a step in the right direction? I dont know -I do think unity across the main product lines (apache, GNU, BSD) would be good.
yeah, but at least we can say bad things about sun and not get fined:)
You dont need to sign NDAs to implement the Java APIs, but the conditions say "dont add or remove anything", primarily to stop MS subverting it again. What you do need NDAs for is for the test kit to prove compliance. NDAs and OSS are so incompatible it hurts -you cannot discuss what tests are failing on a public mailing list, which is silly.
I think Olympic is only allowed as a tradename of companies based in the Olympic Peninsula, WA.
If the IOC had their way, that bit of the mountain range would probably be renamed, or DRM in cameras would stop you photographing the mountains from seattle.
what is new is an attempt to control phrases like "summer 2012" or "london 2012" that dont have the word olympic in. Well, serves them right for using a campaign "London 2012" that didnt have the word olympic in; now they have to live by the consequences.
All apache2.0 adds is patent lawsuit indemnity "sue a project about a patent, you cannot that app yourself" , and takes away the "you need to credit apache".
I dont see this as non-free; it was designed to be GPL-compatible.
i am finding laptop linux much better than before. There are still some obscure USB based WLAN adapters to sort out, but it is much better.
Bluetooth support is pretty good too; the bluez stack is good for low level bluetooth stuff. one thing you cannot (currently) appear to do with it is route audio I/O to a bluetooth headset, which stops me running suse hands free...you can do this with windows, but only with a custom bluetooth stack.
I find some bits of Suse9.3 a backward step than before. Both the sound server and cups keep crashing on me (daily), which could be down to race conditions on my multicpu box. Some other things feel a bit raw too. but it is mostly stable, and runs well on laptops.
Vmware 4.5 runs nicely on suse9.2, but I didnt get it working on Suse9.3 until monday. You need some patch file vmware-any-any that modifies/replace the vmnet driver to build against the recent kernels. Its been up and running since then.
yes, the more frequent an event, the better tested it is. Events have to happen at least once during the dev phase of an app to stand a chance of being tested.
Remember that early version of netscape that screwed up its caching after summer time came along? They wrote their code during winter, shipped immediately, and things broke in spring.
Frequent leap-seconds would increase software quality, whereas having a leap hour every 500 years would be an epic on a par with the y2K problem.
Civilian GPS is subvertable, because the datastream is not signed. anyone with the right hardware can become a new GPS base station...that would be a fun exercise for a hacker convention.
But there is one thing GPS does do, and that is omit leap seconds from its clock. There are no leap seconds in its time sequence. instead, the time signals include data on the current offset from WGS-84 time to UTC time. This causes all receivers to display UTC time to users, while remaining accurate internally. It also makes it easy to propagate changes round the world, just by changing the offset value.
One thing I dont know is what happens if a (subverted) GPS unit were to send out a big offset, like +3600 seconds, or maybe just gradually increase the offset over a few days. This may let you subvert the clock of a computer that drew its time off a GPS receiver, which could be the prelude to some other attack.
It is biased towards java though. All the stuff related to testing and executing and packaging is built around ant. And as most of the volunteer developers work on java projects, it is the java centric tools that get maintained the most. Same goes for the SCM tasks; the SVN and CVS tasks get much more effort invested than, say, the SourceSafe ones.
Apachecon had a session where speakers were picked on a lottery, 5 minutes talk, no slides.
rich cheated on the slideware by unplugging the clock laptop, sticking in his mac and flipping through the slides, getting through it with 20s to spare. So it wouldnt be too big a download to see the presentation, which was primarily a brief critique of the configuration options of httpd, aimed at many of the developers in the room. Who all laughed.
I was stuck in slow moving traffic at 30m west of the launch pad when it got cancelled; I had to turn round and come back. Too bad I won't be in the area next week...that was my one and only chance to catch a shuttle launch.
There have been thunderstorms every night over orlando, which must be the concern.
Slashdot Mirror
Those 60's and 70's tracks are the big earners. Go look at how much a copy of pink floyd's The Wall is, and think how long ago it recouped any costs. Or examine how much it costs to download anything by Abba onto your phone as a ringtone. Now, a lot has (thankfully) fallen by the wayside, but the stuff that survived is so very, very profitable.
This is different from games ($5 bargain basement within 3 years), even most DVDs. The record companies love their back catalogue, and dont want to let go. This is why they have been pushing for longer copyrights on live recordings across the EU and US.
I have to agree here.
"much sucessful OSS software is structured well".
It also has to have well documented code, and be designed so that you can get in and fiddle with a bit without spending two years understanding the app first. It also ought to have a community process that accepts well written code (with tests) from outsiders.
That's one issue I have with Open Office there - I am fed up with the "do you really want to save this
Another area of difference is decision making. companies have meetings then act on them; OSS projects have email discussions which get resolved one way or another -leaving a searchable archive of the discussion for later. Eventually those mail archives become the group memory.
OSS projects need to be open, to end users, and to develoeprs.
-steve
hey, if you are happy with make, stick with it. Use the time you have saved by migrating to write unit tests. CppUnit, for example, although you'll find that the first test that fails probably corrupts memory so badly you need to ignore the rest of the results.
:(
In the little niche that is Java, Ant has managed to replace make. Yes, it is a little niche, but it has become so common that you assume projects have build files, people know how to write them to different levels of competence, and ides handle it. Indeed, the latest IDEs have ant debuggers. I dont know if that constitutes a success or a failure
The underlying problems we are trying to solve? Scale. Change. Complexity. The common ones of software engineering. In this respect, the next generation systems like Maven/maven2 may do even better, even though they are much less mainstream. Maven will happily pull down maven modules and the libraries your app needs from the big repositories out there (ibiblio.org and cvs.apache.org), so you can declare your library dependencies in a little xML file, the tools will pull them down, build your app, run your tests and then publish the built artifacts with the dependency files (.pom files). When someone else builds with your artifact, they get the things you built with too. I'm personally against such transitive logic, but it interests me.
the other interesting thing that all this stuff has enabled is apache gump: http://gump.apache.org/
it checks out and builds all the OSS java projects, in one giant dependency graph. My projects are generating failure mail today, because some other project has done a backwards incompatible change between their release and SVN head. hopefully they will fix that before they ship; the automated blame mail will help motivate them.
That kind of collaborative development is something that platform neutral languages and build tools enable. Ant works in Java land because it self contained: everyone downloading and using Java apps has the underlying software needed to do a build. If you could only build OSS Java apps on a single platform, say Linux, the number of contributors would be that much less.
if you are only targeting a single platform, specifically linux/unix, and are targeting C++, then yes, native build tools make more sense. I just wish we could move beyond make.
Ant is more java-centric; it understands more about testing and deployment. It is also designed to be portable.
C/C++ build processes are all about complile-link-(test)-release. compilation takes forever, so you have to minimise rebuilds through all the dependency declarations. Then linking is so painful because of all the compiler options.
In java compilation is fast; a complete rebuild of a project takes under a minute, leaving you plenty of time to run tests. One thing that really has taken off in java-land (but not everywhere; too many projects still need to look at it), is junit-based unit testing. Ant manages testing and report generation as part of the build process.
IMO, test-driven-development, which in java mostly means junit, is the most important transformation in dev processes of recent years.
Where autoconf+make+the Gnu toolchain is great at is for compiling down C/C++ apps to native code. That is hard, and autoconf and gcc do wonders there. You also need the full suite of gnu tools for a big project, if you start doing things like sed editing of code, piping results of a command into a grep and then mail. Given that the unix command set is essentially infinite, make+unix is inherently more powerful than ant, which has sacrificed power for portability.
Now, if you move to languages that dont have any compilation -python, perl and ruby- for example, the build process changes once again. Compilation? Gone. Linking? gone. all you need is testing, distribution and deployment.
In a world like that, both the dev process -and the build tools that reflect that process- are transformed once again. you still need ubquitous testing and automating that is excellent, but much of the classic build is over.
As a member of the Ant team, I also have to bemoan their use of a non-standard build tool, given that there is pretty good support for C++ compiles in ant-contrib's , and with extra work C++ support could be improved.
.NET does; it builds things like NMAKE, their worst-in-class make tool, then builds the rest of the system)
without something portable like Ant or SCons, you end up needing either to
-build your own tools (this is what Microsoft's shared source version of
-require a common toolchain on every box (e.g. Unix make+the unix commands; cygwin on windows)
The trouble with IDEs, is that they are either platform specific, or use their own configuration files to control the build. In Java Ant has finally become common enough (after 5 years) that it is broadly supported in IDEs, so you get the best of both worlds.
In C++ land, most people resort to the common toolchain, because only the ambitious fools with time on their hands bother to write their own build system. Does that mean it should't be done? No, just that it would be silly if every fairly large project came up with their own build tools. Instead every few years, we really ought to revisit the build processes and tools of the OSS projects, and see how they can be improved.
I do standards work: Hawaii, Chicago, Berlin, next month Boston.
Why? To standardise a system (http://smartfrog.org/) that is already available as an LGPL product, but is being reimplemented by others.
But most of those expenses paid trips end up sitting in meeting rooms, discussing issues of XML namespaces, the umpteen WS-something web service standards that are internally inconsistent, or trying to come up with compromise designs that work less well than those of the individual groups. Also, there isnt enough test-centric thinking going on. I'm trying to fix the latter; our test suite is BSD-licensed and hosted on Sourceforge, but we are only one project out of many.
I am not convinced that standards bodies are the right thing for OSS projects. Too much committee work, you have to be a funded developer to take part, more focus on neatness of the document or the power of the vendor rather than the quality of the code.
I understand some of the goals of mono -language independent library linking is great...even linking C++ applications has always been a bit hit and miss.
.NET code to Linux. Which helps legitimise .NET. They even do things like XBuild, which is a clone of the MSBuild build tool, which is itself nothing but a ripoff of Nant/Ant. Better to embrace NAnt as the mono build tool, instead of trying to mirror every single feature of the .NET system. Particularly because the Microsoft runtime exposes its windows underpinnings everywhere. The semantics of many CLR calls are exactly those of the windows things underneath, be it ::OpenFile or ::CreateProcess, which makes it hard to be truly portable...
But too much of Mono's focus has been on doing a clone of the windows APIs, letting people port
Im use MSword to update a book and find that it has truly awful features; Bad x-referencing (compare with LaTeX), quirky font handling, inconsistent handling of embedded stuff. I have some docs with visio inserts that crash word on on some vmware images of mine, yet the same doc is readable by others,
But OOo has had some awful usability features that get in the way of the fact that its core functionality is pretty good. Example: its auto-collect words for autocompletion adds words that are not spelled right. It should be vagely smart and only add correct words, otherwise you end up replicating spelling errors. Example: its "do you really want to save this as MS word" complaints, repeated automatically when you have autosave turned on. I dont think the IDE is ready (with 1.1; I have hopes for 2.0 but bemoan its java dependencies)
The alternative i would like (esp on Linux), is framemaker, but it is very expensive on windows and not currently available on linux. A cheap -$100-$150 version of frame would have me buy a copy for the linux box and the windows laptop.
I do have high hopes for OOo, in particular, I hope its cost ($/£/0) will overcome its usability defects.
the book (I have a copy) goes into detail on extending lucene with handlers for different formats, filters, and things like stem rules (language specific rules for stemming words).
It also talks about the indexing format; how the indexes are stored and searched. If that aint enough, well, the source is up on apache.org
Lucene is an Apache licensed java project; there is a .NET version that may work on Mono too.
The nice thing about Lucene is it adds indexing and searching to anything you want -some search plugin for outlook (blech) is built on lucene.net; imagine an equivalent for the unix mail systems -thunderbird , evolution or emacs, for example.
aah, forgot about that bit of bollocks.
Overall, I think the whole TCK stuff sucks. Secret compliance tests indeed. How can I make my own redist of something like Axis (with javax.xml classes) without making the statement about compliance, and how can I do that without the TCK.
We need to do better. That is why things like ruby and python appeal to me: no sun in charge. And the grid related standard that I am working on? Its test suite is BSD-licensed and hosted on sourceforge; part of the gump nightly build.
the thing is, GPL already has a "sue someone over the software and your rights go away clause". The apache #2 license just explicitly says "and that includes patent infrigements", and also takes away the need for the credits in the docs.
I understand why you dont need a plethora of licenses, and think that there are far too many OSS licenses out there, that together blur the distinction between closed-source and open-source, as they remove the gap between shared-source things (MS, vmware) and corporate-open-source (sun stuff). I just think that patents are a potential troublespot. Is the ASF license a step in the right direction? I dont know -I do think unity across the main product lines (apache, GNU, BSD) would be good.
yeah, but at least we can say bad things about sun and not get fined :)
You dont need to sign NDAs to implement the Java APIs, but the conditions say "dont add or remove anything", primarily to stop MS subverting it again. What you do need NDAs for is for the test kit to prove compliance. NDAs and OSS are so incompatible it hurts -you cannot discuss what tests are failing on a public mailing list, which is silly.
I think Olympic is only allowed as a tradename of companies based in the Olympic Peninsula, WA.
If the IOC had their way, that bit of the mountain range would probably be renamed, or DRM in cameras would stop you photographing the mountains from seattle.
what is new is an attempt to control phrases like "summer 2012" or "london 2012" that dont have the word olympic in. Well, serves them right for using a campaign "London 2012" that didnt have the word olympic in; now they have to live by the consequences.
All apache2.0 adds is patent lawsuit indemnity "sue a project about a patent, you cannot that app yourself" , and takes away the "you need to credit apache".
I dont see this as non-free; it was designed to be GPL-compatible.
i am finding laptop linux much better than before. There are still some obscure USB based WLAN adapters to sort out, but it is much better.
Bluetooth support is pretty good too; the bluez stack is good for low level bluetooth stuff. one thing you cannot (currently) appear to do with it is route audio I/O to a bluetooth headset, which stops me running suse hands free...you can do this with windows, but only with a custom bluetooth stack.
I find some bits of Suse9.3 a backward step than before. Both the sound server and cups keep crashing on me (daily), which could be down to race conditions on my multicpu box. Some other things feel a bit raw too. but it is mostly stable, and runs well on laptops.
-steve
Vmware 4.5 runs nicely on suse9.2, but I didnt get it working on Suse9.3 until monday. You need some patch file vmware-any-any that modifies/replace the vmnet driver to build against the recent kernels. Its been up and running since then.
I have a patent that predates your code
:)
int isCricketExciting() {
return 0;
}
thus it and the MS patent are void
-steve
yes, the more frequent an event, the better tested it is. Events have to happen at least once during the dev phase of an app to stand a chance of being tested.
Remember that early version of netscape that screwed up its caching after summer time came along? They wrote their code during winter, shipped immediately, and things broke in spring.
Frequent leap-seconds would increase software quality, whereas having a leap hour every 500 years would be an epic on a par with the y2K problem.
-steve
Civilian GPS is subvertable, because the datastream is not signed. anyone with the right hardware can become a new GPS base station ...that would be a fun exercise for a hacker convention.
But there is one thing GPS does do, and that is omit leap seconds from its clock. There are no leap seconds in its time sequence. instead, the time signals include data on the current offset from WGS-84 time to UTC time. This causes all receivers to display UTC time to users, while remaining accurate internally. It also makes it easy to propagate changes round the world, just by changing the offset value.
One thing I dont know is what happens if a (subverted) GPS unit were to send out a big offset, like +3600 seconds, or maybe just gradually increase the offset over a few days. This may let you subvert the clock of a computer that drew its time off a GPS receiver, which could be the prelude to some other attack.
It is biased towards java though. All the stuff related to testing and executing and packaging is built around ant. And as most of the volunteer developers work on java projects, it is the java centric tools that get maintained the most. Same goes for the SCM tasks; the SVN and CVS tasks get much more effort invested than, say, the SourceSafe ones.
steve
(ant developer)
Apachecon had a session where speakers were picked on a lottery, 5 minutes talk, no slides.
rich cheated on the slideware by unplugging the clock laptop, sticking in his mac and flipping through the slides, getting through it with 20s to spare. So it wouldnt be too big a download to see the presentation, which was primarily a brief critique of the configuration options of httpd, aimed at many of the developers in the room. Who all laughed.
yeah, and have the other httpd people were in the room: nobody disagreed. It was one of the funniest and best presentations all week.
I was stuck in slow moving traffic at 30m west of the launch pad when it got cancelled; I had to turn round and come back. Too bad I won't be in the area next week...that was my one and only chance to catch a shuttle launch.
There have been thunderstorms every night over orlando, which must be the concern.