"Inteligent" Shrink?
Locked
12
12
 
|
Given the current state of things, it is important to have tools for
shrinking. I've been programming in Smalltalk for 20 years, and I've seen lots of different tools. My conclusion is that the "shrinking" model is flawed, and it would be better to focus on making Squeak "growable". If you develop in an image and have no way of getting all your code out of an image then you are in trouble. Images are fragile. You can't merge images. If you want to give your code to someone else, or if they want to give it to you, one of you has to move code out of the image and give it to someone else. So, it is important to keep your code in files, whether as .cs files or in Monticello. If your code is in files, there is no argument against growing an image. Sure, you will develop in a huge "dev" image. But it is built out of components and many of those components are not used by your application. It is a lot easier to shrink a build script than to shrink an image. You could have a tool that automatically shrinks your build script by deleting packages one by one and seeing if your application still runs all its tests. Shrinking an image is hard work and not for the faint of heart. I always tell my students to build their application first and worry about shrinking at the end. That is because they will be a lot better at Smalltalk at the end of the project than at the beginning, and so they will be better able to learn to shrink their image. -Ralph |
|
|
Having packaged Smalltalk apps in the past, I agree with this, and would
remind people that the whole "shrink" metaphor arose out of commercial goals -- that is, in order to deploy a Smalltalk "application" built on a proprietary platform you needed to remove the compiler and development tools to comply with a vendor's license. Since Squeak does not have such licensing issues for deployment, the whole "shrink" idea is obsolete IMHO. Why take a perfectly working application and start potentially introducing all sorts of random errors into it at the last minute just to save a bit of storage space and network bandwidth (especially these days)? And if storage space and bandwidth does matter in your situation even now, then building up from a small base (including a text based one) is a much more reliable way to produce quality deployable applications. --Paul Fernhout Ralph Johnson wrote: > Given the current state of things, it is important to have tools for > shrinking. I've been programming in Smalltalk for 20 years, and I've > seen lots of different tools. My conclusion is that the "shrinking" > model is flawed, and it would be better to focus on making Squeak > "growable". > > If you develop in an image and have no way of getting all your code > out of an image then you are in trouble. Images are fragile. You > can't merge images. If you want to give your code to someone else, or > if they want to give it to you, one of you has to move code out of the > image and give it to someone else. So, it is important to keep your > code in files, whether as .cs files or in Monticello. > > If your code is in files, there is no argument against growing an > image. Sure, you will develop in a huge "dev" image. But it is built > out of components and many of those components are not used by your > application. It is a lot easier to shrink a build script than to > shrink an image. You could have a tool that automatically shrinks > your build script by deleting packages one by one and seeing if your > application still runs all its tests. > > Shrinking an image is hard work and not for the faint of heart. I > always tell my students to build their application first and worry > about shrinking at the end. That is because they will be a lot better > at Smalltalk at the end of the project than at the beginning, and so > they will be better able to learn to shrink their image. |
|
|
On Mon, 26 Feb 2007 11:26:07 -0800, Paul D. Fernhout
<[hidden email]> wrote: > Why take a perfectly working application and start potentially > introducing all sorts of random errors into it at the last minute just > to save a bit of storage space and network bandwidth (especially these > days)? Security? |
|
|
In reply to this post by Ralph Johnson
I agree
And what is an image if not a clever cache. So why the following scenario would not work (dave thomas was describing it somehow at ESUG in 2002 ) and dave simmons S# was basically it (certainly GNU Smalltalk bootstrap too): - have a tiny core - load the packages from a script - save your cache to deploy remove the tools and other development packages. On 26 févr. 07, at 13:18, Ralph Johnson wrote: > Given the current state of things, it is important to have tools for > shrinking. I've been programming in Smalltalk for 20 years, and I've > seen lots of different tools. My conclusion is that the "shrinking" > model is flawed, and it would be better to focus on making Squeak > "growable". > > If you develop in an image and have no way of getting all your code > out of an image then you are in trouble. Images are fragile. You > can't merge images. If you want to give your code to someone else, or > if they want to give it to you, one of you has to move code out of the > image and give it to someone else. So, it is important to keep your > code in files, whether as .cs files or in Monticello. > > If your code is in files, there is no argument against growing an > image. Sure, you will develop in a huge "dev" image. But it is built > out of components and many of those components are not used by your > application. It is a lot easier to shrink a build script than to > shrink an image. You could have a tool that automatically shrinks > your build script by deleting packages one by one and seeing if your > application still runs all its tests. > > Shrinking an image is hard work and not for the faint of heart. I > always tell my students to build their application first and worry > about shrinking at the end. That is because they will be a lot better > at Smalltalk at the end of the project than at the beginning, and so > they will be better able to learn to shrink their image. > > -Ralph > > |
|
|
In reply to this post by Blake-5
A good question, but if you are serious about security, a much more secure
system is going to come from building a system up (especially up from a textual description), and understanding what each component you include does, and testing all their interactions, rather than just accepting what results from some random shrink command that may or may not remove code with various security problems. Security is not an add-on -- if you want a secure application, the idea of security needs to be woven throughout everything you do -- initial image or source, code development processes, deployment approach, update streams, and so on. --Paul Fernhout Blake wrote: > On Mon, 26 Feb 2007 11:26:07 -0800, Paul D. Fernhout > <[hidden email]> wrote: > >> Why take a perfectly working application and start potentially >> introducing all sorts of random errors into it at the last minute >> just to save a bit of storage space and network bandwidth (especially >> these days)? > > > Security? > > > |
|
|
In reply to this post by Blake-5
Blake wrote:
> On Mon, 26 Feb 2007 11:26:07 -0800, Paul D. Fernhout > <[hidden email]> wrote: > >> Why take a perfectly working application and start potentially >> introducing all sorts of random errors into it at the last minute just >> to save a bit of storage space and network bandwidth (especially these >> days)? > > Security? There is hardly any goal for which shrinking is a more decidedly unsuited approach than security. While it may be possible to plug a few holes that way (which is probably what you were thinking, e.g., "remove the dangerous code" somehow) a truly secure system is one that never had that dangerous code in the first place, e.g., was built without it. The main problem with shrinking is that it's usually not predictable, e.g., driven by some sort of heuristics like messages not sent anywhere, and unless you unload entire modules (in which case shrinking is effectively equivalent to building the system from scratch [*1]) a non-predictable result is about the worst thing one can imagine for a secure system. [*1] Except for side-effects which is another reason for building it from scratch instead of shrinking - that "dangerous" code may leave artifacts in the image even after it has been unloaded. Cheers, - Andreas |
|
|
In reply to this post by Paul D. Fernhout
On Mon, 26 Feb 2007 12:21:07 -0800, Paul D. Fernhout
<[hidden email]> wrote: > A good question, but if you are serious about security, a much more > secure system is going to come from building a system up (especially up > from a textual description), and understanding what each component you > include does, and testing all their interactions, rather than just > accepting what results from some random shrink command that may or may > not remove code with various security problems. Security is not an > add-on -- if you want a secure application, the idea of security needs > to be woven throughout everything you do -- initial image or source, > code development processes, deployment approach, update streams, and so > on. Perhaps I had not followed closely enough the discussion, but I thought we were talking about options in the absence of being able to grow from nothing. So: >>> Why take a perfectly working application and start potentially >>> introducing all sorts of random errors into it at the last minute >>> just to save a bit of storage space and network bandwidth (especially >>> these days)? I thought you were offering the option of: a) Leave all code in. b) Shrink, causing potential problems. In which case, (b) is, if not more secure, easier to check, presumably. If we have another option: c) Build, adding only what's needed. Well, sure, I'll take (c). But I don't think we can ever escape (b) entirely, since our development image includes all our development tools, as opposed to simply being created by them. In fact, I wonder if that wouldn't resolve some issues: Having a development image which is used to build on a target image. ===Blake=== |
|
|
In reply to this post by Andreas.Raab
On Mon, 26 Feb 2007 12:27:03 -0800, Andreas Raab <[hidden email]>
wrote: > There is hardly any goal for which shrinking is a more decidedly > unsuited approach than security. While it may be possible to plug a few > holes that way (which is probably what you were thinking, e.g., "remove > the dangerous code" somehow) a truly secure system is one that never had > that dangerous code in the first place, e.g., was built without it. As I said to Paul, I thought the discussion had already remoevd building-from-scratch as an option, and the question was, "Given the vast bandwidth and disk space we all have, why bother with shrinking at all?" |
|
|
Blake wrote:
> On Mon, 26 Feb 2007 12:27:03 -0800, Andreas Raab <[hidden email]> > wrote: > >> There is hardly any goal for which shrinking is a more decidedly >> unsuited approach than security. While it may be possible to plug a >> few holes that way (which is probably what you were thinking, e.g., >> "remove the dangerous code" somehow) a truly secure system is one that >> never had that dangerous code in the first place, e.g., was built >> without it. > > As I said to Paul, I thought the discussion had already remoevd > building-from-scratch as an option, and the question was, "Given the > vast bandwidth and disk space we all have, why bother with shrinking at > all?" And the above is the answer: If security is your goal, don't bother shrinking. It's not worth it. Rather than shrinking, rethink your lines of defense and which threat model you need to defend against and how. Which can of course include the removal of certain methods or classes but you are then no longer randomly "shrinking" but rather performing an explicit process of securing your image against attacks which has much more in common with building it up, since it has explicit goals and isn't one of them "oh, lemme see if I can just remove this class" approaches. [BTW, I think there is some confusion with various posters what "shrinking" means. For me it is the process of applying a heuristic to determine which classes and methods can be removed. In other words, it is NOT a process where a developer decides explicitly what gets removed, which is why there is a certain amount of unpredictability and randomness to it]. Cheers, - Andreas |
|
|
On Mon, 26 Feb 2007 13:51:08 -0800, Andreas Raab <[hidden email]>
wrote: > [BTW, I think there is some confusion with various posters what > "shrinking" means. For me it is the process of applying a heuristic to > determine which classes and methods can be removed. In other words, it > is NOT a process where a developer decides explicitly what gets removed, > which is why there is a certain amount of unpredictability and > randomness to it]. You're correct. I don't know that I'd trust an algorithm to do it. In fact, I'm rather sure I wouldn't. |
|
|
In reply to this post by Andreas.Raab
Andreas Raab wrote:
> > [BTW, I think there is some confusion with various posters what > "shrinking" means. For me it is the process of applying a heuristic to > determine which classes and methods can be removed. In other words, it > is NOT a process where a developer decides explicitly what gets removed, > which is why there is a certain amount of unpredictability and > randomness to it]. So the inverse conclusion is that if a developer writes an application there is "a certain amount of unpredictability and randomness to it" what it actually contains? No wonder we have so many bugs in our programs ;-) Michael |
|
|
In reply to this post by Paul D. Fernhout
The idea isn't obsolete at all. Look at many of the major applications from
Squeak: all slimmed down versions of Squeak and in some cases you wouldn't even realize it was Squeak if you didn't know what to look for. And I don't understand all the talk about it being so hard to do. Dolphin does it and it works wonderfully afaik. The bottom line is, Linux and (I think) Mac are a market that is open for someone who can build GUI applications very quickly. Who ever can make the nicest apps the fastest will win these markets. But if you come thumping the blue book saying "stand alone apps are obsolete, just use the image" then don't even waste your time. If Alan Kay's new project works out maybe this will change some-what, but for the existing OS'es, deployed applications will be stand alone if they want any acceptance. >From: "Paul D. Fernhout" <[hidden email]> >Reply-To: The general-purpose Squeak developers >list<[hidden email]> >To: The general-purpose Squeak developers >list<[hidden email]> >Subject: Re: "Inteligent" Shrink? >Date: Mon, 26 Feb 2007 14:26:07 -0500 > >Having packaged Smalltalk apps in the past, I agree with this, and would >remind people that the whole "shrink" metaphor arose out of commercial >goals -- that is, in order to deploy a Smalltalk "application" built on a >proprietary platform you needed to remove the compiler and development >tools to comply with a vendor's license. Since Squeak does not have such >licensing issues for deployment, the whole "shrink" idea is obsolete IMHO. > >Why take a perfectly working application and start potentially introducing >all sorts of random errors into it at the last minute just to save a bit of >storage space and network bandwidth (especially these days)? And if storage >space and bandwidth does matter in your situation even now, then building >up from a small base (including a text based one) is a much more reliable >way to produce quality deployable applications. > >--Paul Fernhout > >Ralph Johnson wrote: >>Given the current state of things, it is important to have tools for >>shrinking. I've been programming in Smalltalk for 20 years, and I've >>seen lots of different tools. My conclusion is that the "shrinking" >>model is flawed, and it would be better to focus on making Squeak >>"growable". >> >>If you develop in an image and have no way of getting all your code >>out of an image then you are in trouble. Images are fragile. You >>can't merge images. If you want to give your code to someone else, or >>if they want to give it to you, one of you has to move code out of the >>image and give it to someone else. So, it is important to keep your >>code in files, whether as .cs files or in Monticello. >> >>If your code is in files, there is no argument against growing an >>image. Sure, you will develop in a huge "dev" image. But it is built >>out of components and many of those components are not used by your >>application. It is a lot easier to shrink a build script than to >>shrink an image. You could have a tool that automatically shrinks >>your build script by deleting packages one by one and seeing if your >>application still runs all its tests. >> >>Shrinking an image is hard work and not for the faint of heart. I >>always tell my students to build their application first and worry >>about shrinking at the end. That is because they will be a lot better >>at Smalltalk at the end of the project than at the beginning, and so >>they will be better able to learn to shrink their image. > _________________________________________________________________ With tax season right around the corner, make sure to follow these few simple tips. http://articles.moneycentral.msn.com/Taxes/PreparationTips/PreparationTips.aspx?icid=HMFebtagline |
|
|
In reply to this post by Andreas.Raab
>From: Andreas Raab <[hidden email]>
>Reply-To: The general-purpose Squeak developers >list<[hidden email]> >To: The general-purpose Squeak developers >list<[hidden email]> >Subject: Re: "Inteligent" Shrink? >Date: Mon, 26 Feb 2007 13:51:08 -0800 > >[BTW, I think there is some confusion with various posters what "shrinking" >means. For me it is the process of applying a heuristic to determine which >classes and methods can be removed. In other words, it is NOT a process >where a developer decides explicitly what gets removed, which is why there >is a certain amount of unpredictability and randomness to it]. For me, the term "shrinking" is what Dolphin does to generate a windows app from a package in the image. I'm not sure how the dependencies are determined, but there is a dependency pane in the browser that shows you what classes your package depends on. You can manually add more if you need to, do scripts and things. But I guess the key point is, you know what is going to happen when you press the "shrink" button: everything not in the package or the dependencies list will not be written into the next EXE. _________________________________________________________________ Win a Zunemake MSN® your homepage for your chance to win! http://homepage.msn.com/zune?icid=hmetagline |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |