Sorry to revive an old thread, but did anything ever come of this? The
project pages exist, but only minimally.
On 5/11/06, Rainer Orth <[EMAIL PROTECTED]> wrote:
We propose the creation of an NTP project on OpenSolaris.ORG, affiliated
with the Nevada and Device Driver communities.
While histor
Thank you all for the info. I upgrade my Solaris by using the 1 method
described above. I'll try to setup luupgrade later on.
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
[EMAIL PROTECTED] wrote:
>
> >Linux started to support openat() recently and for this reason,
> >the best way of implementing a portable way of directory search without
> >path length limitation is to use:
> >
> >ndfd = openat(dfd, "dname", O_RDONLY);
> >close(dfd);
> >dfd = ndfd;
> >dp = fdopendi
>Linux started to support openat() recently and for this reason,
>the best way of implementing a portable way of directory search without
>path length limitation is to use:
>
>ndfd = openat(dfd, "dname", O_RDONLY);
>close(dfd);
>dfd = ndfd;
>dp = fdopendir(dup(dfd));
Interesting is, of course, th
[EMAIL PROTECTED] wrote:
>
>
> >Either approach (opendir()/dirfd() or open()/fdopendir())
> >might be handy on Solaris or anything else that has openat(),
> >for use with multithreaded programs.
>
>
> (To be honest, our next revision of rm will store both an fd and a DIR*;
> with dirfd() it would
"Richard L. Hamilton" <[EMAIL PROTECTED]> wrote:
> >
> > A function like dirfd() is probably needed for
> > completeness and
> > compatibility, though I wonder what people are using
> > it for
>
> Supposedly to do an opendir() then convert the result to
> something they could use with fchdir(
> Horvath writes:
> > How to update to Nevada b60 ?
>
> Your best option is LU. It allows you to continue to
> use the system
> normally during the upgrade process, then you can
> quickly switch over
> after the upgrade is done (and back if you find
> problems).
*raises hand* Is an online live u
On 24/03/07, Martin Bochnig <[EMAIL PROTECTED]> wrote:
John Sonnenschein wrote:
>Incorrect.
>The site just sometimes doesn't update properly for some reason. Latest is
always here: http://opensolaris.org/sxce_dvd
>
The latest available is always there, but releases are sometimes
skipped. This
but I admit I don't know the technical reasons why we have
the requirements we have today to begin with.
Because responsible folks don't listen to Moinak Ghosh's Belenix
minimize_Grub_bootImage - approach?
The primary requirements are internationalization (only easy for
western alphabets wi
I don't know what "Storage Management Utilities" includes, but I think that,
from the GUI side, there needs to be consideration for home AND enterprise
users.
IMHO Sun should be launching a Windows Home Server competitor in 2007. Ride
the back of their home server marketing and offer an even b
"Richard L. Hamilton" <[EMAIL PROTECTED]> wrote:
> > Strictly conformant to the above would therefore be:
> >
> > #define dirfd(dp) ((dp) ? (dp)->dd_fd : -1)
> >
> > You'd still crash if you pass an invalid pointer,
> > though.
>
> Regardless of one's opinion on checks for NULL args,
>John Sonnenschein wrote:
>
>>Incorrect.
>>The site just sometimes doesn't update properly for some reason. Latest is
>>always here: http://op
ensolaris.org/sxce_dvd
>>
>>
>
>Thank you.
>
>BTW, the reason why I prefer the dvd image is this: I never burn any
>SXCR disk, I just use lofiadm and
John Sonnenschein wrote:
Incorrect.
The site just sometimes doesn't update properly for some reason. Latest is always here: http://opensolaris.org/sxce_dvd
Thank you.
BTW, the reason why I prefer the dvd image is this: I never burn any
SXCR disk, I just use lofiadm and set up an install s
Incorrect.
The site just sometimes doesn't update properly for some reason. Latest is
always here: http://opensolaris.org/sxce_dvd
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
14 matches
Mail list logo
