Echo! Jim - W4YXU
Jim Rogers, W4ATK wrote: > I have been a developer since before most of you were born. > > The SVNs are alpha releases. Get over it. Rebuild the database. How > long does it take? I am so tired of hearing all of this bitching and > complaining. In the first place, all of us knew or should have known, > this is new territory. New data is being put in place with each new > release. Sometimes the old fields may be sufficient. At other times > additional fields or a reconfiguration of the fields for that new > feature may be required. > > What makes this product unique is that we are able to advance the > state of the system without a reconfiguration of the hardware. There > is a price to be paid and I for one gladly pay it. I am very, very, > glad we have developers who are advancing the state of the art like > Frank Bickle and Bob McGwier and others who have contributed. Some of > you that are always dissatisfied and have all of this great advice on > development might want to get off your high horse and start coding a > sophisticated DSP engine and its surrounding environment. > > For starters occupy yourself reading DSP for Engineers. It is free and > you can find it on the internet. By the time you finish reading that > and understand it, the rest of us will have move on and you will still > be behind. > > And that is the end of my rant! > > Jim, W4ATK > > > On Jan 7, 2008, at 7:17 PM, Mark Amos wrote: > > >> Jim, >> >> Yes, I agree that this was a reasonable trade as long as this design >> decision doesn't get carried forward to the new >> product. (I have to plead ignorance regarding how the new design >> will implement the storage of user settings.) >> >> Though I am generally pessimistic about fixes that are promised in >> "next release" of most software products, so far my >> pessimism has proven unwarranted for most Flex software releases. >> >> Mark >> >> At 03:03 PM 1/7/2008, Mark Amos wrote: >> >>> Alan, >>> >>> [begin rant] >>> >>> I've had a similar question, but phrased it less delicately: "Is it >>> just me or is the requirement to build a new database just a bad >>> design >>> decision that doesn't improve with age?" >>> >>> In a previous incarnation as a software developer, I would not have >>> been able to foist off such a design decision on my boss much less a >>> consumer products customer (it would never have got past a design >>> review.) I can hear his first question: "What do you mean you've >>> designed it so that the customer has to save the database and use a >>> third-party utility to re-import settings? I can think of 5 >>> different >>> ways to do this better [he would list them while beating me with a >>> rolled up copy of the design spec...] Now, go back and re-design >>> this >>> piece!" >>> >>> So, now that I'm no longer a developer but rather an unruly >>> customer, I >>> get to ask questions like this! In this case, however, it's one of >>> those things that seems so obvious, I am embarassed to even ASK. >>> >>> I can understand it with beta releases -- so I just rebuild it each >>> time and don't complain (much) because beta users got no right to >>> complain about nothin'. But really, for production versions of >>> consumer software. Geez, as da kids would say, WTF? (kidspeak for >>> "That >>> is a bad idea.") >>> >>> [end rant] >>> >> Production versions of PowerSDR are fairly infrequent >> (notwithstanding that lots of folks, on this list anyway, do >> retrieve frequent alpha releases). (Oddly, I couldn't find a list of >> official releases, but my gut feel is that they're >> about every six months to a year apart.) >> >> I would imagine that the logic behind not fixing it runs something >> along the lines of: >> >> We have 2.0 architecture coming out soon, and that will have a >> totally different database mechanism, since it won't be >> using MS Access as the underlying engine. Why deal with migrating >> 1.x to 1.1+x, now, since we'll have to write some >> sort of utility to migrate from 1.x database to 2.x database anyway. >> >> Not such a bad decision, at that time. Put the resources towards the >> new version, rather than the legacy. >> >> >> The fact that the transition is pushed out some 3 years(*) or more >> for a variety of reasons just makes it seem like a terrible decision >> in retrospect. PowerSDR is by no means unique this way. >> >> (*)Yep, it really has been more than 3 years in the making. A couple >> comments from the mailing list archives (which only goes back to May >> 2005.. before that it would be the forums): >> >> "This will come with the new architecture >> that is currently being revised for the 1.5 Beta >> branch of the source." >> [EMAIL PROTECTED], 30 Aug 2005, 16:35 >> >> "..As you may have followed in the >> discussions this week, we are in the process of restructuring the >> current code in the interest of enabling people like yourself to >> contribute more easily. .." >> [EMAIL PROTECTED], 1 Sep 2005, 14:21 >> >> >> Hey Eric, >> Has it really been 4 years? Time flies, etc. >> >> >> >> >> >> _______________________________________________ >> FlexRadio Systems Mailing List >> FlexRadio@flex-radio.biz >> http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz >> Archives: http://www.mail-archive.com/flexradio%40flex-radio.biz/ >> Knowledge Base: http://kb.flex-radio.com/ Homepage: >> http://www.flex-radio.com/ >> >> > > > _______________________________________________ > FlexRadio Systems Mailing List > FlexRadio@flex-radio.biz > http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz > Archives: http://www.mail-archive.com/flexradio%40flex-radio.biz/ > Knowledge Base: http://kb.flex-radio.com/ Homepage: > http://www.flex-radio.com/ > > > > _______________________________________________ FlexRadio Systems Mailing List FlexRadio@flex-radio.biz http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz Archives: http://www.mail-archive.com/flexradio%40flex-radio.biz/ Knowledge Base: http://kb.flex-radio.com/ Homepage: http://www.flex-radio.com/
