It's not unusual to be allowed to install software, as long as it
doesn't require root access or conflict with anything existing. I've
been using rexx on the freeshell servers, which is fine with non-root
access, and I just work without using features that require root
access.
Maybe a compromise
This is my fault. I was just going to boot up a Linux to make sure
the last change I did works on Linux.
Give me a little time René, I'm doing 3 things at once. Looks like I
forgot a cast.
--
Mark Miesfeld
On Tue, Jul 14, 2009 at 4:25 PM, René Jansen wrote:
> Actually, it also fails to compile
Well, it looks like Rick already fixed it.
--
Mark Miesfeld
On Tue, Jul 14, 2009 at 4:31 PM, Mark Miesfeld wrote:
> This is my fault. I was just going to boot up a Linux to make sure
> the last change I did works on Linux.
>
> Give me a little time René, I'm doing 3 things at once. Looks like I
Okay, I'm willing to compromise, if it makes it easier for René to get
a Mac package going.
But, really, at any place I've worked, at this stage of a release the
code base would be locked down and you'd have to convince the CEO that
the world was going to end without a code change to unlock it.
Actually, it also fails to compile on Intel MacOSX
./extensions/rexxutil/platform/unix/rexxutil.cpp: In function
'_RexxObjectPtr* SysCreateEventSem_impl(RexxCallContext*, const char*,
const char*)':
./extensions/rexxutil/platform/unix/rexxutil.cpp:2387: error: invalid
conversion from 'RXSEMD
I think that is a good solution.
best regards,
René Jansen.
On 15 jul 2009, at 01:19, Rick McGuire wrote:
> How about a compromise? We make the code changes to enable rxapi to
> run as a normal process, but keep the install procedures the same for
> now. The code is already in place to auto-l
Mark,
the problem is not having to su - to install (and it actually does run
without doing this) but to have the process running as root - for no
reason.
best regards,
René Jansen/
On 15 jul 2009, at 01:13, Mark Miesfeld wrote:
> On Tue, Jul 14, 2009 at 4:03 PM, David Ashley > wrote:
>
>>
How about a compromise? We make the code changes to enable rxapi to
run as a normal process, but keep the install procedures the same for
now. The code is already in place to auto-launch rxapi if it is not
running, but currently this only works if you're running as root. If
we can eliminate that
Hi guys,
this happens in trunk 4918:
./extensions/rexxutil/platform/unix/rexxutil.cpp: In function
`_RexxObjectPtr* SysCreateEventSem_impl(RexxCallContext*, const char*,
const char*)':
./extensions/rexxutil/platform/unix/rexxutil.cpp:2387: error: invalid
conversion from `RXSEMDATA*' to `ui
On Tue, Jul 14, 2009 at 4:03 PM, David Ashley wrote:
> Ok, I'm convinced. rxapi does not need to run as the root user on *nix
> systems. It has nothing it needs to do which would require root privileges.
>
> So the question becomes should we implement this change prior to the
> release of 4.0 or w
I suspect most of the issues will not be in the code itself, but
rather the different installs. I suspect we probably should do this,
the biggest reason being it would allow unix systems to do memory
stick based operations like Windows users can do. If there is a
resulting chain of bad side effec
All -
Ok, I'm convinced. rxapi does not need to run as the root user on *nix
systems. It has nothing it needs to do which would require root privileges.
So the question becomes should we implement this change prior to the
release of 4.0 or wait until the next release? The code changes are
smal
David Ashley wrote:
> I thik that Mark's main point was that if you do not have root access
> to a machine (physical or virtual) then it would not be ethical to
> attempt to install software on that machine.
That is simply not true.
Depending on the environment and security policies in place you
I thik that Mark's main point was that if you do not have root access to
a machine (physical or virtual) then it would not be ethical to attempt
to install software on that machine.
David Ashley
On 07/14/2009 08:54 AM, Mike Cowlishaw wrote:
Interesting ethics. Even when the user's access to
> > Interesting ethics. Even when the user's access to the computer is a
> > virtual machine? :-)
>
> Hmm, well maybe I don't know much about virtual machines.
>
> As far as ethics goes, it seems pretty black and white to me.
> Someone is in charge of who can install software on a machine,
nope, be my guest. I won't be able to look at this until later this
evening, at the earliest. I just looked at the unix versions, and
they have been converted to the new format, returing a uintptr_t
value. Those will need to have the return type changed to
RexxObjectPtr and return either a null
Okay,
I'll assign this to myself and do the work, if you haven't already started?
--
Mark Miesfeld
On Tue, Jul 14, 2009 at 6:52 AM, Rick McGuire wrote:
> I think this just needs to be the latter, which is fairly trivial to
> implement. The Windows versions of these
> functions haven't even been
I think this just needs to be the latter, which is fairly trivial to
implement. The Windows versions of these
functions haven't even been converted to the new APIs, but there was
some cleanup done for 64-bit
considerations that didn't take into account the failure scenarios.
The hardest part of th
Rick,
What are your thoughts on how to deal with the Windows RexxUtil
functions that return handles, when the function fails?
The docs say, returns a handle or 0 on failure for some of the
functions. Unfortunately, some of them say returns a handle or the
empty string on failure.
In ooDialog, i
19 matches
Mail list logo
