Hi,
Sorry if this comes a bit late, but I found this thread by searching around
and would like to point out a pair of details.
On Fri, 2008-09-19 at 09:27 -0400, Michael Casadevall wrote:
[...], I'm not sure if
its work having a ksolaris port since configure will no longer
identify the
The amd64 issue you raise is an interesting one. Something we should
care quite a bit about, actually. We already have computers with 4 GB of
RAM being a common thing. With 8 GB and more, 32-bit will be more and
more of a problem - and amd64 is the only really serious way forward.
I don't know
The amd64 issue you raise is an interesting one. Something we should
care quite a bit about, actually. We already have computers with 4 GB of
RAM being a common thing. With 8 GB and more, 32-bit will be more and
more of a problem - and amd64 is the only really serious way forward.
I don't
Per Lundberg schrieb:
It is not Solaris, but it is GNU/kOpenSolaris. :-)
If I might state my opinion, I believe diversity is a strength and choice is
a good thing. If some people want to go for Solaris libc, let them do so;
likewise for those who prefer an even more GNU-styled userland (with
Michael Casadevall [EMAIL PROTECTED] wrote:
This poses an interesting question then. With this, we could, in
theory dump the ON userland, and go pure GNU, more inline with the
other Debian/Ubuntu ports. That being said, I still feel diversity is
a strength, and is it still Solaris if we dump
Erast Benson [EMAIL PROTECTED] wrote:
Yes, such port makes sense and solves some of the issues (mostly GNU
libc portability) but unfortunately creates new issues, which I'm sure,
could be worked out and soon we should have more or less working first
ISO available with support for this new
Right. And in addition to autotools, such port complicates further ON
merges which will unavoidably lead to higher rate of errors/bugs.
But because GNU/kFreeBSD exists, I do not see why GNU/kOpenSolaris can't
be...
On Fri, 2008-09-19 at 09:27 -0400, Michael Casadevall wrote:
-BEGIN PGP
To me, this development is just yet another Debian architecture and
sure, some in Debian community will like. It also connects to Nexenta in
many ways - which is good for us. We can't stop such port from happening
- so I think we should embrace it as a secondary lefty architecture.
On Fri,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Debian's main issue is that parts of Sun's libc are not open (mostly
libc_i18n; they require all bits to be open). Having seen the issues
kFreeBSD has had with using glibc with their kernel, I'm not sure if
its work having a ksolaris port since
The kFreeBSD port has had a lot of considerable issues with porting
software. Remember, we'd need to port the ON tools such as the ZFS
admin tools to glibc.
http://wiki.debian.org/ArchiveQualification/kfreebsd-i386
They also haven't been able to get things like the wifi tools for
FreeBSD
On Fri, Sep 19, 2008 at 11:37 AM, Michael Casadevall
[EMAIL PROTECTED] wrote:
The kFreeBSD port has had a lot of considerable issues with porting
software. Remember, we'd need to port the ON tools such as the ZFS
admin tools to glibc.
I already have zfs and zpool binaries linked and working
This poses an interesting question then. With this, we could, in
theory dump the ON userland, and go pure GNU, more inline with the
other Debian/Ubuntu ports. That being said, I still feel diversity is
a strength, and is it still Solaris if we dump the userland (and with
it, binary and script
It is not Solaris, but it is GNU/kOpenSolaris. :-)
If I might state my opinion, I believe diversity is a strength and choice is
a good thing. If some people want to go for Solaris libc, let them do so;
likewise for those who prefer an even more GNU-styled userland (with GNU
libc being the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I don't have a problem with two separate ports. Like for people who
want Solaris based system for stability and ZFS, and a solaris based
one. A nice and practical upshot of this is the possibility of a
kopensolaris-amd64 port which has been a bit of
Back in '05 (years fly) we actually started from trying to port glibc
and a bunch of core libraries outside glibc. We then relatively
quickly, having spent about 3 weeks on it, realized the size and
complexity of the exercise. At this time, as well as at any other time
since then, we were
Hi David,
Great work!
Yes, such port makes sense and solves some of the issues (mostly GNU
libc portability) but unfortunately creates new issues, which I'm sure,
could be worked out and soon we should have more or less working first
ISO available with support for this new exciting architecture!
16 matches
Mail list logo
