> Well yeah, but each time - so I got FB 3 approved, but now that I have this > memory > problem, to fix it you're saying upgrade Eclipse. Well guess what? That > means another > lengthy approval process and review (time and resources) to approve a newer > version of a > piece of software that should have worked in the first place.
I suggested a variety of things to try. If you can't do one of them, try the others instead. But I don't see how this is any different from telling someone that a feature didn't work right in DW CS3 and does work right in CS4. That said, the FlexBuilder integrated install works fine in the vast majority of cases without any configuration after install. > > In any case, I strongly suspect that your Tivoli package was the problem. > > Yes, I would almost bet money on that. But I really think the reason it was > so hard to > package and how it got messed up was because of the complexity of how Adobe > made it > an integrated part of Eclipse - not a single piece of software. On my > machine, Flexbuilder 3 > and Eclipse exist in two different directories, I'm not sure how that > happened or if that is > how Adobe set it up. That's not the integrated install. That's Eclipse, with the FlexBuilder plugin installed separately. I would recommend that you try building a Tivoli package with just the integrated install. Everything will end up in c:\program files\adobe\flex builder. > > Open source is a security risk? Really? That's just a bizarre statement to > > make > > Uh, YEAH! And that's not a "bizarre" statement. Maybe you don't agree with > it, but it's > certainly not bizarre. This is a known issue in large corporations. Here is a > very recent > article on a study that explains it better than I can: > http://www.networkworld.com/news/2008/072108-open-source-security-risk.html > - and > another take on the same article: > http://news.zdnet.com/2100-3513_22-123151.html the > first paragraph reads, "Open source software is a significant security risk > for corporations > that use it because in many cases, the open source community fails to adhere > to minimal > security best practices, according a study released Monday." Yes, with open > source, you > don't have business relationships with the "company" - anyone could be part > of the > development, from anywhere, and because any almost Joe Schmoe can contribute > to the > codebase if they sign up and have skills, they don't necessarily adhere to > guidelines. Yes, > it is a higher security risk to use open source rather than using software > developed by > Microsoft, Apple, Cisco, IBM or Adobe for example. An entity with a proven > track record, > including a record of security measures, and business relationships with my > company. > And you're right, not having someone to sue IS a risk. OK. I'm not much of an open source zealot, but the vast majority of that is pure bunk. First, there is no single "open source community", just like there is no single community that encompasses closed-source vendors. The security practices of development groups vary from one group to the next, just like the security practices of Microsoft and IBM are almost certainly different. Most successful large open source projects don't just let "Joe Schmoe" contribute. If you take a look at a lot of the Apache projects, you can see that the developers are being subsidized by companies like ... Adobe! The primary salient difference between open source and closed source is simply this - open source code can be reviewed. Closed source code cannot. And, you have to evaluate security concerns from the appropriate perspective. Eclipse is, at its base, a text editor. The threat profile for a text editor is very, very low. If you take a look at your first link, you'll notice that the products in the study are all application servers, which have a much higher threat profile. Application servers, by their very nature, allow remote execution of code, which is a very dangerous thing! Text editors, on the other hand, can't do much except edit files. Adobe Acrobat is a much more dangerous product to have installed. With the latest vulnerability that was open for about a month and fixed a few weeks ago - one that would allow a malformed PDF to gain control of the entire machine - I sure hope you've patched that! And as for that second link, I would recommend that you ignore it; it's pure propaganda, bought and paid for by Microsoft. http://www.sourcewatch.org/index.php?title=AdTI-Funding They also work for Big Tobacco! It's a small world, I guess. Finally, the "problem" of mixing open source with proprietary solutions is becoming more common, so you will simply have to get used to this - many proprietary software packages contain open source components. For example, Adobe ColdFusion includes Apache Axis (among many other things). One of the lead Axis developers was Tom Jordahl - an Adobe employee. Adobe LiveCycle ES comes with JBoss and MySQL. > > From the end-user's perspective, when you install it with the integrated > > installer > > you just run setup.exe and click next over and over again just like any > > other Windows > > application, and all the files get dumped in one directory. > > Dave, you make it sound so simple, it's not that simple. They tear open the > installer before > it even gets to me. They look at all the files involved, what types they are, > what they do, > how they interact, etc. Remember, I work for one of the world's largest > companies and IT > security is one of our top priorities. When they guy called me on the phone, > he asked about > Eclipse, and was confused why that was getting installed when what was being > approved > was "Flexbuilder". When I tried to explain that its essentially all one app > - that Flex uses > Eclipse as a base, he didn't get it. When I said Eclipse was an open source > application > that Adobe built Flex on, he was further confused and concerned about > security. You can > see the headaches that causes. Well, maybe not, but it did. I should have said "from the typical end-user's perspective". If you're just manually installing FlexBuilder, you don't have to worry about Eclipse or see it, etc. As far as "tearing open the installer", the typical way I've seen deployment packages built is to use an install manager to capture changes that happen during an install. You then install the application, then use the install managers to capture all the changes to the machine. If you do that with the integrated install, you'll end up with one directory with everything in it. So, I suspect they didn't use the integrated install, which meant they had to install Eclipse first, etc. But in any case, building deployment packages around Eclipse is not generally difficult. While I don't work for a large company, many of my clients - I'll say government clients and leave it at that - are very security-conscious, and are using FlexBuilder and other Eclipse plugins, and have similar deployment issues. So I'm at least aware of security issues within the enterprise. None of these things should be that big of a hurdle for you. I would recommend that you install FlexBuilder on a home computer just to see where everything goes, and that'll give you an idea of what the deployment package should be doing. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ Fig Leaf Software provides the highest caliber vendor-authorized instruction at our training centers in Washington DC, Atlanta, Chicago, Baltimore, Northern Virginia, or on-site at your location. Visit http://training.figleaf.com/ for more information! _______________________________________________ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
