[Pharo-project] Towards Pharo 1.0
Hi all, Marcus, Stef and I have been meeting today and we discussed how to proceed for the first release (version 1.0). On the issue tracker we tagged issues that we think should be fixed with "milestone-1.0". See the following list: http://code.google.com/p/pharo/issues/list?q=milestone:1.0 If we missed something critical, please let us know. Furthermore, we updated the high-level milestones list that is on the wiki (http://code.google.com/p/pharo/wiki/Milestones). The most notable change is that we removed Alien FFI and moved it to milestone 1.1. FUNCTIONAL REQUIREMENTS ⢠(x) Integrate Polymorph ⢠(x) Integrate TrueType? ⢠(x) Refactor Traits API ⢠( ) default in-image font(s) ⢠( ) Main EToys removal, reorganize MorphicExtras?- ⢠( ) Package management system with stable and unstable distributions ⢠( ) Remove SqueakMap? and Installer from core NON-FUNCTIONAL REQUIREMENTS ⢠(x) First consistent version of the website ⢠( ) All tests green ⢠( ) Clean up package and class category organization ⢠( ) License clean (check OLPC changes) ⢠( ) Pharo one-click image (including developer tools, GettingStarted information, screenshots, ...) ⢠( ) New sources file INFRASTRUCTURE ⢠(x) Increase efficiency of producing new updates ⢠( ) Prepare second update stream to maintain released version Cheers, Adrian ___________________ http://www.adrian-lienhard.ch/
Adrian Lienhard wrote:
Hi all,
Marcus, Stef and I have been meeting today and we discussed how to proceed for the first release (version 1.0). On the issue tracker we tagged issues that we think should be fixed with "milestone-1.0". See the following list:
http://code.google.com/p/pharo/issues/list?q=milestone:1.0
If we missed something critical, please let us know.
I would vote for the full unicode support. I'm currently battling with ParagraphEditor and friends (don't ask...), but I think we are getting there. I will look at Andreas fixes in that area and integrate them into my changes as well. Michael
On 23.02.2009, at 20:45, Adrian Lienhard wrote:
Hi all,
Marcus, Stef and I have been meeting today and we discussed how to proceed for the first release (version 1.0).
One note to everyone who submitted a bugreport... no, note at the end of the mail. First a story. In Squeak, people submitted lots of improvements and bugs, first with the funky [TAGS] to the list, later via the bugtracker. But then, a curious thing happened: they never, ever, looked at that bug-report again. Maybe the image side code changed, and the submission needed a trivial change so that the changeset could be loaded. Or there was some question posted by a harvester. Or after 1000 applied changesets, there might be the possibility that a bug is already fixed. Kind of obvious, that the submitter of a report can help a lot in these situations. But they don't. I have *no clue* why. In the end, I closed lots (really lots!) of entries in Squeak over the years after a question to the original submitter was not anwered after 1 year(!) of waiting. I really wonder what the problem was... the submitter cared a lot when submitting the bug or improvement in the first place. But then, just answering a question or re-do a changeset (maybe 30min of work for the original author) was too much... a mystery. Thus: As we are nearing 1.0, I kindly ask everyone who submitted something to look at the report. Maybe you can make it easier to have it integrated? e.g. exactly describing the action needed is better than making it a riddle (some people think that it is a sign of intelligence to not give the solution to a problem after describing the cause). A changeset (or mcz) is the best. Even for a one-line triviality. You reported a bug half a year ago? Try to recreate it and add a comment: This is still a problem in #10243 and the way I re-created the problem is this. In the end, the question is: If you don't care, why should we? Marcus - Marcus Denker -- denker@acm.org http://www.marcusdenker.de
Marcus Denker wrote:
of a report can help a lot in these situations. But they don't. I have *no clue* why.
First a mea culpa, I'm one of those on occasions... One problem is (was?) notification. When you signed up for notifications from the Squeak bug tracker you got drowned in emails to the point where I just filtered them to the trash unread, thus never seeing any updates even on my own reports. If there is a reasonably easy way to be only notified when "interesting" bug reports are changed (or set up email filters), that would go a long way IMHO. Michael
Notification seems to work very well with Google Code. I think, by default you get mail notifications for issues that you created or that you are in CC or that you starred (by clicking on the star). You can change this if you log in and go to Settings. I also subscribed to the RSS feed to monitor all changes to issues and wiki pages. Cheers, Adrian On Feb 23, 2009, at 21:48 , Michael Rueger wrote:
Marcus Denker wrote:
of a report can help a lot in these situations. But they don't. I have *no clue* why.
First a mea culpa, I'm one of those on occasions...
One problem is (was?) notification.
When you signed up for notifications from the Squeak bug tracker you got drowned in emails to the point where I just filtered them to the trash unread, thus never seeing any updates even on my own reports.
If there is a reasonably easy way to be only notified when "interesting" bug reports are changed (or set up email filters), that would go a long way IMHO.
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
You reported a bug half a year ago? Try to recreate it and add a comment: This is still a problem in #10243 and the way I re-created the problem is this.
How can I close an issue? ( i want to close Issue 472, it has been fixed) I do not see an option for this. Thanks for reminding us to go over previous issues. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On 24.02.2009, at 11:25, Alexandre Bergel wrote:
You reported a bug half a year ago? Try to recreate it and add a comment: This is still a problem in #10243 and the way I re-created the problem is this.
How can I close an issue? ( i want to close Issue 472, it has been fixed) I do not see an option for this.
Maybe one needs some special status to close bugs on the tracker? No idea... Marcus -- Marcus Denker -- denker@acm.org http://www.marcusdenker.de
On Tue, Feb 24, 2009 at 11:25 AM, Alexandre Bergel <alexandre@bergel.eu> wrote:
How can I close an issue? ( i want to close Issue 472, it has been fixed) I do not see an option for this.
You need to have administrative rights (which you have now). You have to go to Status field and choose a closed status -- Damien Cassou http://damiencassou.seasidehosting.st
Thanks Alexandre On 24 Feb 2009, at 13:33, Damien Cassou wrote:
On Tue, Feb 24, 2009 at 11:25 AM, Alexandre Bergel <alexandre@bergel.eu
wrote: How can I close an issue? ( i want to close Issue 472, it has been fixed) I do not see an option for this.
You need to have administrative rights (which you have now). You have to go to Status field and choose a closed status
-- Damien Cassou http://damiencassou.seasidehosting.st
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
What happens with the requirements () which are not marked with (x) to be included in milestone version 1.0? Or are the (x) mandatory release requirements and () optional? If the "default in-image font(s)" requirement is possible it may be a good idea since it is all part of the first impression. Anyhow, great job so far is all I can say :) -- View this message in context: http://n2.nabble.com/Towards-Pharo-1.0-tp2373983p2374656.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On 23.02.2009, at 23:02, Geert wrote:
What happens with the requirements () which are not marked with (x) to be included in milestone version 1.0? Or are the (x) mandatory release requirements and () optional?
no, (x) is done, () will be done :-)
If the "default in-image font(s)" requirement is possible it may be a good idea since it is all part of the first impression. Anyhow, great job so far is all I can say :)
thanks! -- Marcus Denker -- denker@acm.org http://www.marcusdenker.de
Both are "mandatory": ( ) means not done yet (x) means completed For some reason, [ ] has some special meaning with the wiki syntax IIRC Cheers, Adrian On Feb 23, 2009, at 23:02 , Geert wrote:
What happens with the requirements () which are not marked with (x) to be included in milestone version 1.0? Or are the (x) mandatory release requirements and () optional?
If the "default in-image font(s)" requirement is possible it may be a good idea since it is all part of the first impression. Anyhow, great job so far is all I can say :) -- View this message in context: http://n2.nabble.com/Towards-Pharo-1.0-tp2373983p2374656.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
⢠( ) New sources file
I do not get this one.
⢠( ) Prepare second update stream to maintain released version
Why would you need a second update stream? PharoInbox2 ? Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On 23.02.2009, at 23:07, Alexandre Bergel wrote:
⢠( ) New sources file
I do not get this one.
Do we ship Pharo with Squeak39.sources or Pharo1.sources?
⢠( ) Prepare second update stream to maintain released version
Why would you need a second update stream? PharoInbox2 ?
No. that what happens when you press "update"... 1.0 will get important bugfixes even while 1.1 is under development. (There are some serious users involved in Pharo, e.g. companies that plan to use it in production, or university people who want to torture their students with it). Marcus -- Marcus Denker -- denker@acm.org http://www.marcusdenker.de
Milestone 3 includes - closures (may be with the changes of mathieu with a new image format) Didn't we pickup Eliot's recent closure work? If so, how do the two relate? On Mon, Feb 23, 2009 at 1:45 PM, Adrian Lienhard <adi@netstyle.ch> wrote:
Hi all,
Marcus, Stef and I have been meeting today and we discussed how to proceed for the first release (version 1.0). On the issue tracker we tagged issues that we think should be fixed with "milestone-1.0". See the following list:
http://code.google.com/p/pharo/issues/list?q=milestone:1.0
If we missed something critical, please let us know.
Furthermore, we updated the high-level milestones list that is on the wiki (http://code.google.com/p/pharo/wiki/Milestones). The most notable change is that we removed Alien FFI and moved it to milestone 1.1.
FUNCTIONAL REQUIREMENTS ⢠(x) Integrate Polymorph ⢠(x) Integrate TrueType? ⢠(x) Refactor Traits API ⢠( ) default in-image font(s) ⢠( ) Main EToys removal, reorganize MorphicExtras?- ⢠( ) Package management system with stable and unstable distributions ⢠( ) Remove SqueakMap? and Installer from core
NON-FUNCTIONAL REQUIREMENTS ⢠(x) First consistent version of the website ⢠( ) All tests green ⢠( ) Clean up package and class category organization ⢠( ) License clean (check OLPC changes) ⢠( ) Pharo one-click image (including developer tools, GettingStarted information, screenshots, ...) ⢠( ) New sources file
INFRASTRUCTURE ⢠(x) Increase efficiency of producing new updates ⢠( ) Prepare second update stream to maintain released version
Cheers, Adrian
___________________ http://www.adrian-lienhard.ch/ _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 24.02.2009, at 00:40, David Pennell wrote:
Milestone 3 includes ⢠closures (may be with the changes of mathieu with a new image format) Didn't we pickup Eliot's recent closure work?
Yes. (so either this is an error or for confusing the enemy ;-)
If so, how do the two relate?
Very similar. Marcus
On Mon, Feb 23, 2009 at 1:45 PM, Adrian Lienhard <adi@netstyle.ch> wrote: Hi all,
Marcus, Stef and I have been meeting today and we discussed how to proceed for the first release (version 1.0). On the issue tracker we tagged issues that we think should be fixed with "milestone-1.0". See the following list:
http://code.google.com/p/pharo/issues/list?q=milestone:1.0
If we missed something critical, please let us know.
Furthermore, we updated the high-level milestones list that is on the wiki (http://code.google.com/p/pharo/wiki/Milestones). The most notable change is that we removed Alien FFI and moved it to milestone 1.1.
FUNCTIONAL REQUIREMENTS ⢠(x) Integrate Polymorph ⢠(x) Integrate TrueType? ⢠(x) Refactor Traits API ⢠( ) default in-image font(s) ⢠( ) Main EToys removal, reorganize MorphicExtras?- ⢠( ) Package management system with stable and unstable distributions ⢠( ) Remove SqueakMap? and Installer from core
NON-FUNCTIONAL REQUIREMENTS ⢠(x) First consistent version of the website ⢠( ) All tests green ⢠( ) Clean up package and class category organization ⢠( ) License clean (check OLPC changes) ⢠( ) Pharo one-click image (including developer tools, GettingStarted information, screenshots, ...) ⢠( ) New sources file
INFRASTRUCTURE ⢠(x) Increase efficiency of producing new updates ⢠( ) Prepare second update stream to maintain released version
Cheers, Adrian
___________________ http://www.adrian-lienhard.ch/ _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Marcus Denker -- denker@acm.org http://www.marcusdenker.de
On 23-Feb-09, at 11:15 PM, Marcus Denker wrote:
On 24.02.2009, at 00:40, David Pennell wrote:
Milestone 3 includes ⢠closures (may be with the changes of mathieu with a new image format) Didn't we pickup Eliot's recent closure work?
Yes. (so either this is an error or for confusing the enemy ;-)
Ok, well Eliot pushed the closure code out the door, we need to build VMs to exploit it. I've not been able to build the macintosh os-x carbon VM based on it yet. Spent the day trying to integrate Craig's Spoon work with most current VMMaker. Tomorrow (tuesday) I'll see about building a new closure VM. I note this will be a 4.0.0 VM to note the change from a non-closure to closure VM PS Some bright person might want to code up some RB find templates to look for methods where if you use the closure VM it will possibly give you different behaviour than with the current VM. Unless of course everyone feels comfortable in turning block closures on, and assuming nothing will change? -- = = = ======================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================
PS Some bright person might want to code up some RB find templates to look for methods where if you use the closure VM it will possibly  give you different behaviour than with the current VM.
Wouldn't it also require to recompile all methods to get closures? Have a look at the senders of #fixTemps. I have 37 senders in the latest Pharo image. These are all places where people had to work around the shortcomings of the Squeak blocks. With block closures enabled these blocks should behave the same without fixing their temps. For more examples the Seaside code base has a vast collection of places where it has to work around missing closures. For portability reasons this is done using #fixCallbackTemps.
Unless of course everyone feels comfortable in turning block closures on, and assuming nothing will change?
It could be that some code breaks, because closures behave subtly different. However if people depend on such code, then it is ambiguous and buggy in the first place. I think that closures should be included into mainstream VMs and images as fast as possible. It is a **major** annoyance that Squeak has no full block closures even in 2009. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
Well the current macintosh VM has the support code in it. I can't speak for the windows or unix version. Oomeone *has* to review the alien compiler changes and confirm they are ok, Yesterday I realized there were three class vars missing from ParseNode and 1 method from MethodNode. That I have fixed. The Pharo team has to decided if they want to make Alien (or some FFI) product part of the base system, versus the current thought of only loading FFI if you understand you need it. For Sophie loading FFI in to the base app then let us build components subclassed by operating system to provide functionality faster than doing primitives, and of course modifiable by any smalltalker. On 24-Feb-09, at 5:36 AM, Stéphane Ducasse wrote:
Hi john
what is the work to be done to get alien in pharo?
Stef
-- = = = ======================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================
FFI has (it seems to me) long been viewed as an evil in the Squeak community. I have no idea whether that is justified, but I have to say that the analogous features in Dolphin have been essential. Unless there is a very good reason to exclude it, I would ask for FFI in 1.0. For myself, the next big hurdle is underscores, largely because so many of the external entities to which I would be mapping contain them. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of John M McIntosh Sent: Tuesday, February 24, 2009 12:53 PM To: Stéphane Ducasse Cc: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Towards Pharo 1.0 Well the current macintosh VM has the support code in it. I can't speak for the windows or unix version. Oomeone *has* to review the alien compiler changes and confirm they are ok, Yesterday I realized there were three class vars missing from ParseNode and 1 method from MethodNode. That I have fixed. The Pharo team has to decided if they want to make Alien (or some FFI) product part of the base system, versus the current thought of only loading FFI if you understand you need it. For Sophie loading FFI in to the base app then let us build components subclassed by operating system to provide functionality faster than doing primitives, and of course modifiable by any smalltalker. On 24-Feb-09, at 5:36 AM, Stéphane Ducasse wrote:
Hi john
what is the work to be done to get alien in pharo?
Stef
-- = = = ======================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ======================================================================== _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Schwab,Wilhelm K wrote:
FFI has (it seems to me) long been viewed as an evil in the Squeak community. I have no idea whether that is justified, but I have to say that the analogous features in Dolphin have been essential.
The motiviation behind not including FFI in the "standard" image was security. FFI allows you to circumvent the Squeak sandbox. Which is only really interesting for Squeak applications that download untrusted code from somewhere (e.g. etoys projects).
Unless there is a very good reason to exclude it, I would ask for FFI in 1.0. For myself, the next big hurdle is underscores, largely because so many of the external entities to which I would be mapping contain them.
I would support that, if it wasn't for Alien, which should be replacing FFI any time now :-) Michael
Michael, Alien vs. FFI - it's all the same to me - I think??? Whatever you guys want to do, as long as we can connect to the outside world. The less we get tripped up by underscores in doing it, the better. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Michael Rueger Sent: Tuesday, February 24, 2009 3:24 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Towards Pharo 1.0 Schwab,Wilhelm K wrote:
FFI has (it seems to me) long been viewed as an evil in the Squeak community. I have no idea whether that is justified, but I have to say that the analogous features in Dolphin have been essential.
The motiviation behind not including FFI in the "standard" image was security. FFI allows you to circumvent the Squeak sandbox. Which is only really interesting for Squeak applications that download untrusted code from somewhere (e.g. etoys projects).
Unless there is a very good reason to exclude it, I would ask for FFI in 1.0. For myself, the next big hurdle is underscores, largely because so many of the external entities to which I would be mapping contain them.
I would support that, if it wasn't for Alien, which should be replacing FFI any time now :-) Michael _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Feb 24, 2009, at 9:23 PM, Michael Rueger wrote:
Schwab,Wilhelm K wrote:
FFI has (it seems to me) long been viewed as an evil in the Squeak community. I have no idea whether that is justified, but I have to say that the analogous features in Dolphin have been essential.
The motiviation behind not including FFI in the "standard" image was security. FFI allows you to circumvent the Squeak sandbox.
by sandboxing you mean protected from squeak. You cannot access the file system if you do not have FFI Because one day we will have also to think about sandboxing pharo from its own downloaded code.
Which is only really interesting for Squeak applications that download untrusted code from somewhere (e.g. etoys projects).
Unless there is a very good reason to exclude it, I would ask for FFI in 1.0. For myself, the next big hurdle is underscores, largely because so many of the external entities to which I would be mapping contain them.
I would support that, if it wasn't for Alien, which should be replacing FFI any time now :-)
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Concerning FFI sandboxing.. why not just add -noffi option at startup time (and similar flag to Interpreter) then simply fail all prims which trying to use FFI callouts. Then regardless of what you doing (loaded ffi code or not) you can't escape sandbox. 2009/2/24 Stéphane Ducasse <stephane.ducasse@inria.fr>:
On Feb 24, 2009, at 9:23 PM, Michael Rueger wrote:
Schwab,Wilhelm K wrote:
FFI has (it seems to me) long been viewed as an evil in the Squeak community. Â I have no idea whether that is justified, but I have to say that the analogous features in Dolphin have been essential.
The motiviation behind not including FFI in the "standard" image was security. FFI allows you to circumvent the Squeak sandbox.
by sandboxing you mean protected from squeak. You cannot access the file system if you do not have FFI Because one day we will have also to think about sandboxing pharo from its own downloaded code.
Which is only really interesting for Squeak applications that download untrusted code from somewhere (e.g. etoys projects).
Unless there is a very good reason to exclude it, I would ask for FFI in 1.0. Â For myself, the next big hurdle is underscores, largely because so many of the external entities to which I would be mapping contain them.
I would support that, if it wasn't for Alien, which should be replacing FFI any time now :-)
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
Igor Stasenko wrote:
Concerning FFI sandboxing.. why not just add -noffi option at startup time (and similar flag to Interpreter) then simply fail all prims which trying to use FFI callouts. Then regardless of what you doing (loaded ffi code or not) you can't escape sandbox.
The core issue about having FFI or Alien available in the standard system is that then people start coding against it. One you go down that road, it is hard to reverse that and make a system "sandboxable". Michael
2009/2/25 Michael Rueger <m.rueger@acm.org>:
Igor Stasenko wrote:
Concerning FFI sandboxing.. why not just add -noffi option at startup time (and similar flag to Interpreter) then simply fail all prims which trying to use FFI callouts. Then regardless of what you doing (loaded ffi code or not) you can't escape sandbox.
The core issue about having FFI or Alien available in the standard system is that then people start coding against it. One you go down that road, it is hard to reverse that and make a system "sandboxable".
sound like: a) isolationists tactics b) teaching others how to write good code i really don't like when people deciding upfront what is good or bad and don't providing any choice how to change this. This is against the spirit of smalltalk. Use java then, with its sealed classes :)
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
Igor Stasenko wrote:
The core issue about having FFI or Alien available in the standard system is that then people start coding against it. One you go down that road, it is hard to reverse that and make a system "sandboxable".
sound like: a) isolationists tactics b) teaching others how to write good code
i really don't like when people deciding upfront what is good or bad and don't providing any choice how to change this. This is against the spirit of smalltalk. Use java then, with its sealed classes :)
I think you are missing the point. An example: in order to get the MIME type of a file on a Mac you can use a certain system call to do that. There two choices: you write or extend a plugin (sandbox safe, but a lot of work) or you use FFI/Alien (not sandbox safe, but quick to do and maintain). If FFI is not default, then people tend to do the extra work to work with a plugin. If it is available, people will avoid that extra work and I think that is absolutely legitimate and has nothing to do with good or bad code. Michael
2009/2/25 Michael Rueger <m.rueger@acm.org>:
Igor Stasenko wrote:
The core issue about having FFI or Alien available in the standard system is that then people start coding against it. One you go down that road, it is hard to reverse that and make a system "sandboxable".
sound like: a) isolationists tactics b) teaching others how to write good code
i really don't like when people deciding upfront what is good or bad and don't providing any choice how to change this. This is against the spirit of smalltalk. Use java then, with its sealed classes :)
I think you are missing the point. An example: in order to get the MIME type of a file on a Mac you can use a certain system call to do that. There two choices: you write or extend a plugin (sandbox safe, but a lot of work) or you use FFI/Alien (not sandbox safe, but quick to do and maintain).
I think you miss the point. :) If VM in control whether allow or disallow FFI calls then you get much more security than leaving it to be handled by OS and hoping that there is no squeakFFI library in same directory where VM located or in one of the search dirs.
If FFI is not default, then people tend to do the extra work to work with a plugin. If it is available, people will avoid that extra work and I think that is absolutely legitimate and has nothing to do with good or bad code.
can't take it as a strong argument. Maybe Croquet doing it in wrong way by using FFI to make GL calls. But it was ultimately their own choice. To encourage people to write a plugins instead of use of FFI, a better way would be to improve VMMaker tool and simplify VM building procedure. But limiting people from use of FFI in hope that they eventually start writing plugins i think is spoiled idea.
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
What about more generic security rule: - allow/deny to use external modules ? then VM could simply check this flag at attempt of loading ANY external module - be it plugin or something else. Then, it is safe to ship VM with FFI built-in, and you can even run FFI tests, because test functions will be sitting inside a VM but not in an external library. But once you try to make a call which requires loading new dynamic library - you will have a primitive failure. As you maybe know, in windows, when you loading a .dll, OS calling a DllMain function. And there are a chance that it can do something evil, what may crash VM and your sandbox is no longer a sandbox :) -- Best regards, Igor Stasenko AKA sig.
Sig, If I am following, then the command line flag you describe is the only way to be certain anyway. Otherwise, one could fall victim to an FFI library that happens to be visible to the vm, and one's head is in the sandbox at that point - fair?? Of course, there are evils, and then there are evils. Things like openssl are unlikely to go wrong in my experience, and they offer functionality that is hard to replace, and stature that might be impossible to replace (we want _that_ library...). Besides, if you don't want things crashing, what are you doing on Windows? :) Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko Sent: Tuesday, February 24, 2009 7:02 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Towards Pharo 1.0 What about more generic security rule: - allow/deny to use external modules ? then VM could simply check this flag at attempt of loading ANY external module - be it plugin or something else. Then, it is safe to ship VM with FFI built-in, and you can even run FFI tests, because test functions will be sitting inside a VM but not in an external library. But once you try to make a call which requires loading new dynamic library - you will have a primitive failure. As you maybe know, in windows, when you loading a .dll, OS calling a DllMain function. And there are a chance that it can do something evil, what may crash VM and your sandbox is no longer a sandbox :) -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2009/2/25 Schwab,Wilhelm K <bschwab@anest.ufl.edu>:
Sig,
If I am following, then the command line flag you describe is the only way to be certain anyway. Â Otherwise, one could fall victim to an FFI library that happens to be visible to the vm, and one's head is in the sandbox at that point - fair??
Yes (except that i can't parse 'and one's head is in the sandbox at that point').
Of course, there are evils, and then there are evils. Â Things like openssl are unlikely to go wrong in my experience, and they offer functionality that is hard to replace, and stature that might be impossible to replace (we want _that_ library...). Â Besides, if you don't want things crashing, what are you doing on Windows? :)
who said that my Windows is crashy? ;) My box crashing only on power grid failures, which happens maybe once in a month. My old UPS is dead and i'm too lazy to buy new one.
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko Sent: Tuesday, February 24, 2009 7:02 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Towards Pharo 1.0
What about more generic security rule: - allow/deny to use external modules ?
then VM could simply check this flag at attempt of loading ANY external module - be it plugin or something else. Then, it is safe to ship VM with FFI built-in, and you can even run FFI tests, because test functions will be sitting inside a VM but not in an external library. But once you try to make a call which requires loading new dynamic library - you will have a primitive failure.
As you maybe know, in windows, when you loading a .dll, OS calling a DllMain function. And there are a chance that it can do something evil, what may crash VM and your sandbox is no longer a sandbox :)
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
Sig, "Head in the sandbox" is a play on words on "head in the sand." Perhaps it is a cultural thing - it refers to the (mythical) comforting yet pointless behavior of an ostrich: http://www.phrases.org.uk/meanings/80800.html Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko Sent: Tuesday, February 24, 2009 8:24 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Towards Pharo 1.0 2009/2/25 Schwab,Wilhelm K <bschwab@anest.ufl.edu>:
Sig,
If I am following, then the command line flag you describe is the only way to be certain anyway. Â Otherwise, one could fall victim to an FFI library that happens to be visible to the vm, and one's head is in the sandbox at that point - fair??
Yes (except that i can't parse 'and one's head is in the sandbox at that point').
Of course, there are evils, and then there are evils. Â Things like openssl are unlikely to go wrong in my experience, and they offer functionality that is hard to replace, and stature that might be impossible to replace (we want _that_ library...). Â Besides, if you don't want things crashing, what are you doing on Windows? :)
who said that my Windows is crashy? ;) My box crashing only on power grid failures, which happens maybe once in a month. My old UPS is dead and i'm too lazy to buy new one.
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko Sent: Tuesday, February 24, 2009 7:02 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Towards Pharo 1.0
What about more generic security rule: - allow/deny to use external modules ?
then VM could simply check this flag at attempt of loading ANY external module - be it plugin or something else. Then, it is safe to ship VM with FFI built-in, and you can even run FFI tests, because test functions will be sitting inside a VM but not in an external library. But once you try to make a call which requires loading new dynamic library - you will have a primitive failure.
As you maybe know, in windows, when you loading a .dll, OS calling a DllMain function. And there are a chance that it can do something evil, what may crash VM and your sandbox is no longer a sandbox :)
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2009/2/25 Schwab,Wilhelm K <bschwab@anest.ufl.edu>:
Sig,
"Head in the sandbox" is a play on words on "head in the sand." Â Perhaps it is a cultural thing - it refers to the (mythical) comforting yet pointless behavior of an ostrich:
:)
 http://www.phrases.org.uk/meanings/80800.html
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko Sent: Tuesday, February 24, 2009 8:24 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Towards Pharo 1.0
2009/2/25 Schwab,Wilhelm K <bschwab@anest.ufl.edu>:
Sig,
If I am following, then the command line flag you describe is the only way to be certain anyway. Â Otherwise, one could fall victim to an FFI library that happens to be visible to the vm, and one's head is in the sandbox at that point - fair??
Yes (except that i can't parse 'and one's head is in the sandbox at that point').
Of course, there are evils, and then there are evils. Â Things like openssl are unlikely to go wrong in my experience, and they offer functionality that is hard to replace, and stature that might be impossible to replace (we want _that_ library...). Â Besides, if you don't want things crashing, what are you doing on Windows? :)
who said that my Windows is crashy? ;) My box crashing only on power grid failures, which happens maybe once in a month. My old UPS is dead and i'm too lazy to buy new one.
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko Sent: Tuesday, February 24, 2009 7:02 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Towards Pharo 1.0
What about more generic security rule: - allow/deny to use external modules ?
then VM could simply check this flag at attempt of loading ANY external module - be it plugin or something else. Then, it is safe to ship VM with FFI built-in, and you can even run FFI tests, because test functions will be sitting inside a VM but not in an external library. But once you try to make a call which requires loading new dynamic library - you will have a primitive failure.
As you maybe know, in windows, when you loading a .dll, OS calling a DllMain function. And there are a chance that it can do something evil, what may crash VM and your sandbox is no longer a sandbox :)
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
participants (12)
-
Adrian Lienhard -
Alexandre Bergel -
Damien Cassou -
David Pennell -
Geert -
Igor Stasenko -
John M McIntosh -
Lukas Renggli -
Marcus Denker -
Michael Rueger -
Schwab,Wilhelm K -
Stéphane Ducasse