The current status of OSProcess

> On Sat, Mar 12, 2011 at 11:34:11AM -0800, nullPointer wrote:
>> Please, I need know the actual status of OSProcess; what I can wit it and
>> cannot:
>>
>> -Works in main platforms? Mac, Windows Linux? works of same way on all
>> places?
>
> OSProcess works on unix platforms, including Mac and Linux. Windows
> support is incomplete.
>
>> -I could execute external executable files?
>> -I could execute commandline tools?
>
> Yes. You should also load CommandShell in addition to OSProcess.
>
>> -Which will be the next steps of development?
>
> Well I probably should get Windows support working one of these days ;)
>
>> -OsProcess will be integrated in Core?
>
> No, OSProcess and CommandShell are external packages.
>
>> -Exists some place with deep doc?
>
> See class CommandShell, method category "documentation" on the class
> side, as well as class and method comments throughout. Many classes
> provide examples, and the unit tests may be helpful for understanding
> usage.
>
> Additional information is at:
>
> http://wiki.squeak.org/squeak/708
> http://wiki.squeak.org/squeak/1914
> http://wiki.squeak.org/squeak/2153
> http://wiki.squeak.org/squeak/6023
>
> Dave
>
>
>

> David,
> i don't remember the outcome of last discussion about it,
> but i heard some people proposed to add the OSProcess plugin
> to be built as internal one.
> Or at least ship it with every VMs, same as FFI plugin.
>
> On 12 March 2011 20:53, David T. Lewis <[hidden email]> wrote:
> > On Sat, Mar 12, 2011 at 11:34:11AM -0800, nullPointer wrote:
> >> Please, I need know the actual status of OSProcess; what I can wit it and
> >> cannot:
> >>
> >> -Works in main platforms? Mac, Windows Linux? works of same way on all
> >> places?
> >
> > OSProcess works on unix platforms, including Mac and Linux. Windows
> > support is incomplete.
> >
> >> -I could execute external executable files?
> >> -I could execute commandline tools?
> >
> > Yes. You should also load CommandShell in addition to OSProcess.
> >
> >> -Which will be the next steps of development?
> >
> > Well I probably should get Windows support working one of these days ;)
> >
> >> -OsProcess will be integrated in Core?
> >
> > No, OSProcess and CommandShell are external packages.
> >
> >> -Exists some place with deep doc?
> >
> > See class CommandShell, method category "documentation" on the class
> > side, as well as class and method comments throughout. Many classes
> > provide examples, and the unit tests may be helpful for understanding
> > usage.
> >
> > Additional information is at:
> >
> > http://wiki.squeak.org/squeak/708
> > http://wiki.squeak.org/squeak/1914
> > http://wiki.squeak.org/squeak/2153
> > http://wiki.squeak.org/squeak/6023
> >
> > Dave
> >
> >
> >
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.

> Hi Igor,
>
> I think it is good to make OSPP (and AioPlugin and XDisplayControlPlugin
> where appropriate) available in all distributed VMs, but in some applications
> they provide too much access to the operating system, so it is good to
> have them as external modules so that people who do not want them on
> the system can delete the modules. So I think it is best to treat it
> like FFI, it is there if you want it but can be removed if you are doing
> some sort of application where the user should not have easy access to
> the OS functions.
>

> On 13 March 2011 00:19, David T. Lewis <[hidden email]> wrote:
>> Hi Igor,
>>
>> I think it is good to make OSPP (and AioPlugin and XDisplayControlPlugin
>> where appropriate) available in all distributed VMs, but in some applications
>> they provide too much access to the operating system, so it is good to
>> have them as external modules so that people who do not want them on
>> the system can delete the modules. So I think it is best to treat it
>> like FFI, it is there if you want it but can be removed if you are doing
>> some sort of application where the user should not have easy access to
>> the OS functions.
>>
>
> Well, i think for making a secure 'appliance' sort of, a better
> approach to not rely on
> prebuilt VM , but build your own where you can always decide what is
> secure enough and what's not,
> and should be removed/disabled.
>
> Btw, we discussed a bit of this today with Henrik, and first thing i
> think people should do, in order to make it more secure
> is to disable external module loading mechanism.
> Declaring that standard VM is more secure if you don't ship it with
> _external_ modules (like FFI) sounds like a joke.
>
> So, what i'd like to ask is, that if everyone feel a day-to-day need
> for using things like FFI or OSProcessPlugin
> we should make it available by default and out of the box. And for
> those, who concerned with low security there is always
> an options to improve it, like hiring people to develop a custom VM
> based on default one, where all security problems is
> addressed properly.
>
> So, i don't see why we should constrain ourselves with things we use
> and need, only because in eyes of someone
> it doesn't looks secure enough.
>
>> Dave
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>

> +1
>
> OSProcess is really important for us.
> Like a good FFI
>
> Stef
>
> On Mar 13, 2011, at 1:11 AM, Igor Stasenko wrote:
>
>> On 13 March 2011 00:19, David T. Lewis <[hidden email]> wrote:
>>> Hi Igor,
>>>
>>> I think it is good to make OSPP (and AioPlugin and XDisplayControlPlugin
>>> where appropriate) available in all distributed VMs, but in some applications
>>> they provide too much access to the operating system, so it is good to
>>> have them as external modules so that people who do not want them on
>>> the system can delete the modules. So I think it is best to treat it
>>> like FFI, it is there if you want it but can be removed if you are doing
>>> some sort of application where the user should not have easy access to
>>> the OS functions.
>>>
>>
>> Well, i think for making a secure 'appliance' sort of, a better
>> approach to not rely on
>> prebuilt VM , but build your own where you can always decide what is
>> secure enough and what's not,
>> and should be removed/disabled.
>>
>> Btw, we discussed a bit of this today with Henrik, and first thing i
>> think people should do, in order to make it more secure
>> is to disable external module loading mechanism.
>> Declaring that standard VM is more secure if you don't ship it with
>> _external_ modules (like FFI) sounds like a joke.
>>
>> So, what i'd like to ask is, that if everyone feel a day-to-day need
>> for using things like FFI or OSProcessPlugin
>> we should make it available by default and out of the box. And for
>> those, who concerned with low security there is always
>> an options to improve it, like hiring people to develop a custom VM
>> based on default one, where all security problems is
>> addressed properly.
>>
>> So, i don't see why we should constrain ourselves with things we use
>> and need, only because in eyes of someone
>> it doesn't looks secure enough.
>>
>>> Dave
>>>
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>
>

> +1
>
>
>
> ________________________________________
> From: [hidden email] [[hidden email]] On Behalf Of Casimiro de Almeida Barreto [[hidden email]]
> Sent: Monday, March 14, 2011 11:37 AM
> To: [hidden email]
> Subject: Re: [Pharo-project] The current status of OSProcess
>
> +1
>
> OSProcess important
> FFI and/or "Alien running Ok in Linux and Windows" important
>
> CdAB
>
> Em 13-03-2011 06:46, Stéphane Ducasse escreveu:
>> +1
>>
>> OSProcess is really important for us.
>> Like a good FFI
>>
>> Stef
>>
>> On Mar 13, 2011, at 1:11 AM, Igor Stasenko wrote:
>
>
>
>