C. Bergström wrote:
Hi Tim..
Tim Spriggs wrote:
Hi Christopher,
Some comments below...
C. Bergström wrote:
I'm not sure if the bounties page is up date? There's two that seem
interesting..
1) building onnv-gate on NCP2
2) building an alternative "distro"
It's hard to find, but I know exact requirements for building
onnv-gate.. The details on this seem kinda fuzzy, because even
something small like changing the postgresql version from 8.2 to 8.3
could require a patch (eg..src/libs/mms/) and nightly would just
show the missing lib.. so for $150 what exactly are you hoping for?
What's the current state?
Good question! There is a nexenta-on source package that is started.
I think the idea is that developers can download nexenta-on and get
it to work if they are interested in doing so. To me, the prize seems
kinda like a cherry on top of a dessert.
I don't consider making onnv-gate/nexenta-on compile to be a dessert
of any sort.. :P I still don't understand what exactly needs to be
done or the current state.. I'd have to undeb it to se what's in the
nexenta-on package.. I mean.. is there a problem with onbld tools..
missing headers.. patchadd is broken because of zfs root and needs
patching.. it could be simple or a gob of work.. The point was to get
it done and reward a bounty.. I hope not to just stir noise..
No, but having it done and behind you has got to be a sweet thing. The
nexenta-on source "package" is just a tar.gz and a diff.gz. It also
happens to have a .dsc that describes the package a little bit. No
un-deb'ing needed. The binaries on the other hand, yes... you would need
to unwrap the deb in order to get at it, but even that is not so
difficult as it's essentially a compressed tar as well.
For the other part of this email.. I'm sure many people appreciate
trying to get new developers interested with small cash rewards, but
unless you're offering chunks like gsoc I'm not sure it'll really
attract much attention. (I could be wrong) Just a thought.. What
about actually trying to push some sort of innovation? I know you
guys have some CIFS workgroup patches that are interesting, but what
else is Nexenta really doing? I don't mean this sarcastically, but
why should anyone even really care?
Seems people do (care) already. Nexenta is doing apt/dpkg and a whole
bunch of pre-packaged GNU software. I can't speak for everyone but I
do enjoy this combination as it saves me time in upgrades and also
offers all of the benefits (and drawbacks) of the debian packaging
system.
Innovation happens here as well. apt-clone was the first package
upgrade mechanism that allows OpenSolaris users to rollback from a
failed upgrade. Nexenta also attracts users who are familiar with
apt/dpkg and want to try out OpenSolaris. In this way, Nexenta is one
of many distributions that can provide a first "welcome" to the
community.
Ok. you answered people do care, but not sure I'm clear on why..
Then use Nexenta and find out! ;)
Nexenta provides pre-packaged gnu software and it provides the
apt/dpkg interface..?
So what's the value if I make a wrapper script around foo package
manager to provide that same interface and have the same gnu software
in the repositories?
Sure, you could certainly do that. I find that the apt/dpkg suite is
extensive enough that I don't need to write scripts to get what I need
done. Restating that, apt/dpkg fulfills my needs quite well.
For what it's worth.. some of my project would make it a lot easier
for you guys to build onnv-gate and or highly customize it to your
needs. If you simply follow the 20 year old monolithic Sun style
packaging.. You'll always be stuck like this. If anyone out there
is /really/ interested in entirely open source OpenSolaris
technology I'd love to hear back. So far with the help of others
the *only* thing with closed bits is libc.. Which boils down to how
to implement wide char support.. there's options for it and all are
obtainable.. Anil.. maybe you could help and put a decent bounty on
this?
For the un-initiated, this is a new project that has ambitious goals.
If someone feels that Nexenta can leverage from this development
effort I would love to see collaboration between Nexenta and ospkg.
Honestly.. I think it would be more personal preference than technical
which causes people to not want to work together, but why not stay
optimistic.. :)
I don't see the distribution as stuck, perhaps you can clarify what
is meant by that? Many packages that are well known in the
Solaris/OpenSolaris world are easy to find for those who are familiar
with them. For those that aren't, the package descriptions help to
bridge the gap. "apt-cache search {keyword}" searches both package
names and descriptions.
stuck.. as in besides you.. what Nexenta developer has shipped
something original and usable? (Honest question..) I don't consider
repackaging original work.. (It doesn't mean it's not challenging..
It's just not original)
Personally, I've developed devzone and then shared it for all
distributions to use. The autobuilder is specific to apt/dpkg but it's
been developed for Nexenta from the ground up. I think it's slightly
novel in design. apt-clone is definitely Nexenta specific. I'm probably
missing something but this is what is close to home for the moment.
With a lot of the simple stuff out of the way (re-packaging effort) then
developers are free to work on more interesting things and develop this
"original stuff" we all know and love.
When I mean fully open.. I mean from bootstrapping jamvm so you can
build icedtea6 to using small tricks like ksh93's built-in
tail/printf..
Fully open is the goal. Work has been done towards an open libc.
I'm a skeptic.. the glibc port is cool and fun, but maybe the author
can add a comment on if it's actually a viable route.
I would love to see various JVMs implemented under Nexenta. Currently
most of the java packages are not being built because gcj is missing.
It's possible that another JVM can be put in its place but the work
still needs to be done to do this.
gcc 4.x comes with gcj.. that builds on OpenSolaris.. or there another
reason this is blocked on Nexenta? Anyway.. the much more simple
approach is probably to try to bootstrap with cacao or jamvm
Yeah, the vast majority of package dependencies are setup explicitly for
gcj. It may be possible to modify all of these but I think it makes more
sense to get gcj going. It's disabled in the current build and I think
the compile breaks somewhere. I haven't dug deep into the issue though,
it's just another thing on the list.
Anyway those are just the larger examples of the problems for a fully
open OpenSolaris technology distribution.. Then you start to get into
compiler compatibility issues.. exact version dependencies.. private
headers.. external non-released libs as deps.. etc..
This is a pain. I run into these types of issues with binaries that are
shipped out (like old JVMs that are bundled with software) Yes, there
are open versions of the software in most cases, no they don't with the
closed versions so there is no migration path yet.
Thanks for the feedback!
You're the kind of guy that makes open source fun.. Hopefully I don't
ruffle any feathers..
./C
Well thank you. My feathers are hard to ruffle but I can see where
others might be upset. I think it's good to have hard questions posed,
otherwise people slip into "group think" and things slowly turn to mush.
-Tim
_______________________________________________
gnusol-users mailing list
[email protected]
http://lists.sonic.net/mailman/listinfo/gnusol-users
