Re: [osol-discuss] upgrading to solaris 10 10/05 from 03/05
Debian GNU/Solaris will offer similar options as a standard Debian Update feature. It will also bring full set of graphical tools, such as integrated into GNOME desktop update-notifier, Synaptic, etc. First Alpha release is planned at November. Erast On Sun, 2005-10-23 at 16:13 +0530, Nikhil wrote: Hello I had earlier installed OpenSolaris 03/05 x86 platform system, but now I am planning to upgrade it to Solaris 10/05 release without any installation . Is there anyway where I can upgrade without disturbing the existing system. much like the way of up2date/yum on Linux systems. Regards, Nikhil ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: SchilliX-0.2 ready, but SchilliX (the project) needs help
Guys, let me clarify a little bit on what GNU/Solaris distro is. The idea behind it is simple: do not re-invent the wheel and try to re-use existing 17000 high quality Debian packages, Debian infrastracture(read Dpkg, APT repositories, Debootstraps, installation program, utilities, developer's policy and so on) and Debian developer's if you will. GNU/Solaris distribution uses OpenSolaris kernel and runtime(libc). So, it runs any existing Solaris software without modifications. In addition to that(and this is what differes it from SchiliX and BeliniX), it greatly simplifies porting effort for pure Linux applications and packages, since it provides real Debian environment. As you might know, Debian(as of today) is the engine for 30+ child projects. GNU/Solaris is practically based on latest Ubuntu/Breezy bits (except few imporant packages derived directly from Debian) and basically offers similar options for novice users. GNU/Solaris has been a private project for the last 8 months and will be publically available(including source code for everything) in early November, once we are done with more/less functional web-portal. We will probably enable early access for developers next week. If you would like to get guest password and participate in further development you could send me a request e-mail. Erast On Sun, 2005-10-23 at 14:07 -0600, [EMAIL PROTECTED] wrote: Jake Maciejewski [EMAIL PROTECTED] wrote: Let us face reality... Belenix has been developped by starting with SchilliX and modifying it. Um ... I'd strongly object to this statement! It is correct that 2 ideas were taken from the earlier discussions on this list: * Using the math library from FreeBSD * Using the aperture driver as a replacement for xsvc But that is all there is to it. Apart from this I have NOT touched a single bit of work coming out of the SchilliX project. I did not base my work on the SchilliX binaries. When I started there was no documentation available on how to create an OpenSolaris LiveCD. No build tools or scripts were available that can generate an ISO image from OpenSolaris binaries. I have spent countless hours of effort starting with understanding x86 boot from scratch. So please do not state misconceptions. Because both the projects have, to some extent, similar aims and started from the same base they are bound to end up with similar approaches to solve the same issues, especially where options are limited. But to say that one project has depended on the other just because of these similatrities is wrong. In fact I started my work with the official Nevada builds that go into Solaris Express and built an initial ramdisk-only boot environment. Later on I moved to OpenSolaris. If one reads my blog one will immediately see to what extent I investigated the issues and how I arrived at solutions and subsequently improved them. GNUSolaris is currently no more than an annunced distro. www.gnusolaris.org is unreachable and the announcement was not clear enough to understand what GNUSolaris will be. Once we know more about GNUSolaris, we will be able to judge based on it's real features. I would asume that they take the Solaris kernel and use the same Debian userland than Debian uses for Debian/Linux. If this is true, then it is still uncler whether they use glibc or the standard libc. If they use the Debian userland, GNUSolaris will most likely not what Solaris users expect and GNUSolaris will not pass an OpenSolaris compliance test A GNU/Solaris distro is just that. It is not intended to be a Solaris compatible distro. There is a lot of interest in this sort of an environment as well. If they use the Solaris userland, and only add other free software, GNUSolaris will be nothing different than SchilliX except that is less probable that it will pass an OpenSolaris compliance test and key features from Solaris (e.g. zones) will probably never work. Zones can be made to work. Obviously even a GNU/Solaris distro cannot throw away core OpenSolaris features like Zones or SMF. One of the aims of BeleniX is to also provide the option of a GNU userland environment or even that of a GNU Zone. Regards, Moinak. With these constraints, it is obvious that there is a need to create an own X package for SchilliX in the near future. J?rg -- EMail:[EMAIL PROTECTED] (home) J?rg Schilling D-13353 Berlin [EMAIL PROTECTED] (uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: SchilliX-0.2 ready, but SchilliX (the project) needs help
On Tue, 2005-10-25 at 15:20 +0200, Joerg Schilling wrote: Erast Benson [EMAIL PROTECTED] wrote: let me clarify a little bit on what GNU/Solaris distro is. Thank you! The idea behind it is simple: do not re-invent the wheel and try to re-use existing 17000 high quality Debian packages, Debian infrastracture(read Dpkg, APT repositories, Debootstraps, installation program, utilities, developer's policy and so on) and Debian developer's if you will. It depends on how we define re-invent the wheel I try to avoid to re-invent the wheel for SchilliX by not using a different package system than the one used by Solaris and I don't try to replace standard UNIX tools by GNU clones. Well, this is the idea behind of GNU/Solaris: to be as much GNU centric as possible, but do not break sunw* core. GNU/Solaris trying to find gold middle and trying to do it right. As a result of the missing pkg system, I need to wait and to create a simple intermediate method for packaging. In addition, I look at the quality of the debian packages and I see that Debian publishes a version of cdrtools that is broken because of the patches that are applied by Debian. For this reason, I believe that it may be similar with other tools and the only way to have guaranteed quality is to create your own compile environment for the free software you linke or need to package together with OpenSolaris. GNU/Solaris distribution uses OpenSolaris kernel and runtime(libc). So, it runs any existing Solaris software without modifications. In addition to that(and this is what differes it from SchiliX and BeliniX), it greatly simplifies porting effort for pure Linux applications and packages, since it provides real Debian environment. And how do you include these Debian packages? If you put them into /usr/bin, you will overwrite existing standard UNIX tools and then you will not be able to benefit from e.g. smf because you are forced to use the init process that Debian uses on Linux. If you would like to get guest password and participate in further development you could send me a request e-mail. If you are willing to participate in further SchilliX development, I would be happy to help your project too. virtually, all our distros based on the same core bits - sunw*. We are planning quite a bit of work there. So, all these beginnings, (i.e. SchiliX, BeliniX) are very good for overall progress. After all, thanks to GPL/CDDL. It forces/stimulates developers to exchange patches between the projects. We will launch pilot GNU/Solaris developer's program by the end of this week. So, if you didn't get invitation yet, send e-mail to me, and hold your breath a little longer. Thank you. Erast ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: SchilliX-0.2 ready, but SchilliX (the project) needs help
Very valid point. Would be nice if all opensolaris-based distros could guarantee to run unmodified C binaries. There are quite a few ways to achive that. Erast On Tue, 2005-10-25 at 11:22 -0700, John Plocher wrote: Erast Benson and Joerg Schilling were discussing GNU/Solaris: GNU/Solaris distribution uses OpenSolaris kernel and runtime(libc). So, it runs any existing Solaris software without modifications. If you put them into /usr/bin, you will overwrite existing standard UNIX tools This points out some large differences in people's perceptions of what is a Solaris app? One perspective is a minimalist one, concerned with syscalls in libc; another is broader and takes into account the utilities and other commands that are part of the system. Still others focus on middle ware and libraries, Java, web services, etc... That is, runs any existing Solaris Software without modifications is more difficult to do than it is to say. It is safe to say that the ARC process at Sun spends much of its time ensuring that changes to the system don't negatively impact this area. The Solaris Binary Compatibility effort (see appcert(1)) grapples with this issue as well. Going forward with OpenSolaris distros, a simple expectation might be If it runs on Solaris AND it passes appcert(1), then it should also run on any Solaris Compatible system. (Noting that appcert focuses on shared libraries and does not address system()'d or exec()'d utilities...) -John ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: SchilliX-0.2 ready, but SchilliX (the project) needs help
On Tue, 2005-10-25 at 23:10 +0200, Joerg Schilling wrote: John Plocher [EMAIL PROTECTED] wrote: If you put them into /usr/bin, you will overwrite existing standard UNIX tools This points out some large differences in people's perceptions of what is a Solaris app? One perspective is a minimalist one, concerned with syscalls in libc; another is broader and takes into account the utilities and other commands that are part of the system. Still others focus on middle ware and libraries, Java, web services, etc... The biggest compatibility problem of OpenSolaris (compared to Sun Solaris) is the fact that libm is not part of OpenSolaris. In case you don't know, it took me a full month already to work on FreeBSD's libm in order to be halfway compatible with Sun Solaris and I am not even shure about the effort that would be needed for a mostly 100% compatibility. I am definitely interested in a UNIX centric OpenSolaris distro. Do not expect people who work on Linux centric Open Solaris distros to put a similar amount of work into compatibility issues. They will. Simply becase not everything in this world is open-source... Also I do not see big advantages of creating yet another copy of Solaris Express. SchiliX and BeliniX over time will offer thier own features. This will create incompatabilities anyways. We should not expect fully 100% compatability between distros. Compatability to some extent ... yes. This we could achive. We probably might need to create some sort of Solaris Distributions Foundation(SDF) which will control the spec similar to LSB. Erast ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: SchilliX-0.2 ready, but SchilliX (the project) needs help
On Wed, 2005-10-26 at 18:42 +0200, Joerg Schilling wrote: virtually, all our distros based on the same core bits - sunw*. We are planning quite a bit of work there. So, all these beginnings, (i.e. SchiliX, BeliniX) are very good for overall progress. After all, thanks to GPL/CDDL. It forces/stimulates developers to exchange patches between the projects. Do you use the patches I provide at ftp://ftp.berlios.de/pub/schillix/patches/ lseek.patch looks like we could take. But somehow sunw* stuff works for us as is or with little changes. GNU/Solaris actually will bring 1000+(literally) usability patches applied for GNU software all over the place. We derive them from Ubuntu/Breezy world mostly. Some patches came from Debian directly. See, for Debian GNU/Solaris, proportion is different. We have just 120 sunw* core packages and 3500+ Ubuntu/Debian packages. So, we mostly concentrating on Debian part right now. But we have quite a few plans for sunw* stuff in the near future. Erast ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] community proposal: Linux Immigrants
On Fri, 2005-10-28 at 09:07 -0700, Adam Leventhal wrote: On Fri, Oct 28, 2005 at 12:32:42PM +1300, Glynn Foster wrote: I'm not sure it's so urgent that we need to have a temporary solution. Let's make the community, start the discussion and then build the wiki as a result of that discussion. Ok - sounds sane enough. Does this fall under the Approachability community in any way? I suppose we could shoe horn it in, but it seems like an odd fit and it will probably a community which will grow in an entirely different direction. It's not about making Solaris easier to use in itself or even making it more like Linux (or whatever), it's about understanding how the other half lives. Nice idea overall. But I saw FAQ somewhere on the net, shouldn't it be enough for Linux immigrants? I mean what else this community would like to resolve besides talks around this FAQ? Linux immmigrants most likely will be redirected to GNU/Solaris forums, wiki, blogs or mailing lists sooner or later. Since GNU/Solaris not just a talks, it is a real solution. my 3.14 cents. Erast ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: [gnu-sol-discuss] Debian based GNU/Solaris: pilot program
On Tue, 2005-11-01 at 23:25 -0600, James Dickens wrote: 3) Developer's portal at http://www.gnusolaris.org - fully functional, with downloads, APT repository, discussion forums, developer's hack zone, bug database, blogs, and numerous Solaris and free software resources. something is setup incorrectly, it requests username and passwd to gain entry? you have to send a request e-mail to Alex Ross, he will send you a login/password. Erast ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: [gnu-sol-discuss] Debian based GNU/Solaris: pilot program
On Wed, 2005-11-02 at 01:29 -0600, James Dickens wrote: On 11/2/05, Erast Benson [EMAIL PROTECTED] wrote: On Tue, 2005-11-01 at 23:25 -0600, James Dickens wrote: 3) Developer's portal at http://www.gnusolaris.org - fully functional, with downloads, APT repository, discussion forums, developer's hack zone, bug database, blogs, and numerous Solaris and free software resources. something is setup incorrectly, it requests username and passwd to gain entry? you have to send a request e-mail to Alex Ross, he will send you a login/password. perhaps i'm tired... but that just comes off as LAME! how does that come off as fully functional ... this is opensource software... no need for secrets this started out as an opensource project, no hidden closed sourced secrets, guess i will be skipping this project, untill they are really open. the pilot program created specifically for web-portal polishing before it is actually opened for public. I do not see anything secret in this action. *Everybody* can get an early account if they want to. This pilot program also invites developers on this very early stage to participate. Erast ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Debian based GNU/Solaris: pilot program
Now we put some more information on the authentication dialog. We are sorry we didn't do that at the first place... well. We were too busy with other issues. So, next time you click on http://www.gnusolaris.org you will see Welcome to GNU/Solaris pilot program! banner and information on how to obtain member's account. First Nexenta ISO images will be available for pilot members tonight or worst case tomorrow morning. Erast On Thu, 2005-11-03 at 10:41 +0800, James Lick wrote: I think what most people are frustrated with is that there is a disconnect between announcing the project far and wide, but then saying the site needs to be locked down because it's not quite ready for everyone. If it's not ready, don't go announcing it everywhere. If it is ready enough for wide announcements, don't lock it down. If you want to announce it and make it registration only, provide clear registration instructions. Two replies here have been made saying contact Alex Ross to register, but no mention of how to contact him. I appreciate the complexity of launching a product like this, but so far it is just too frustrating to participate. I would humbly suggest that someone from the project post how to get in touch with Alex Ross to register. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Genunix Nexenta Mirror
Fast mirror is up: http://www.genunix.org/distributions/gnusolaris/ Both images (LiveCD and Install) are there. Thanks a lot! We have propagated link on /Download page as well as through the auto-balancer script. Erast ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Rebooting system when PS2 mouse plugged
Someone opened a bug at NBTS: http://www.gnusolaris.org/cgi-bin/trac.cgi/ticket/52 Any ideas or workarounds? Just hoping that this issue is well know and got fixed in recent builds. PS: I don't know which mailing lists to use in case of bug reports like this one, so, I'm posting here. Thanks, Erast ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Anyone succeded in porting xine to Nevada?
In Nexenta we have it: % apt-cache search xine libxine1c2 - the xine video/media player library, binary files xdmx - Distributed Multi-head X server libxinerama-dev - X11 Xinerama extension library (development headers) libxinerama1-dbg - X11 Xinerama extension library (debug package) libxinerama1 - X11 Xinerama extension library libxine-dev - the xine video player library, development packages totem-xine - A simple media player for the Gnome desktop based on xine totem-gstreamer - A simple media player for the Gnome desktop based on gstreamer x11proto-panoramix-dev - X11 panoramiX extension wire protocol x11proto-xinerama-dev - X11 Xinerama extension wire protocol totem - A simple media player for the Gnome desktop (dummy package) though, it is not tested well... Erast On Sun, 2005-11-13 at 17:39 -0300, Alfredo Peña wrote: I'm trying to run xine-ui in Nevada b25 (Solaris Express build 25) without success. Here is what I have right now: - xinelib should be compiled with gcc and linked with gld, Solaris native ld doesn't work (lots of relocation problems) - there are several glibc functions used by xinelib and xine-ui that doesn't have an implementation in Solaris libc and the xine configuration step doesn't check for. These are strsep, strndup and getline. I replaced them with implementations I found in the web. - gxine cannot be built with the gnome version shipped, as it requires gnome 2.10, so I tried xine-ui xine-ui dumps core after initialising the xshm extension, this is the stack trace: #0 0xce3ff4f8 in resolve_object () from /usr/lib/libX11.so.4 #1 0xce3ff854 in _XsunOsDynamicLoad () from /usr/lib/libX11.so.4 #2 0xce3a2763 in _XOpenLC () from /usr/lib/libX11.so.4 #3 0xce3b5cf7 in _XlcCurrentLC () from /usr/lib/libX11.so.4 #4 0xce3ed917 in _XkbGetCharset () from /usr/lib/libX11.so.4 #5 0xce3eb879 in _XkbLoadDpy () from /usr/lib/libX11.so.4 #6 0xce3b77b8 in XKeysymToKeycode () from /usr/lib/libX11.so.4 #7 0x080c2d7f in xitk_init () Can anybody give me a tip on what is wrong? Thanks, Alf ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] App porting forum?
Alfredo, One of the goals of GNU/OpenSolaris project is to track all changes and bugs progress on porting/enhancing OSS projects which are not distributed by SUN but part of any regular GNU/Linux distribution like Ubuntu, Fedora, etc. GNU/OpenSolaris web development portal provide Subversion hosting and integrated Trac (Nexenta Bug Tracking System, i.e. NBTS) available for HackZone developers. (one should aquire account first) Latests development will bring future Launchpad(a collection of services for projects in the open source universe) integration, so any security fixes released by Ubuntu, RedHat, Debian, Gentoo, etc will be automatically tracked by NBTS and vice-versa. https://launchpad.net/distros/nexenta GNU/OpenSolaris web portal provides read/write Subversion access for HackZone interface. This interface is described at: http://www.gnusolaris.org/gswiki/HackZone Bugs can be tracked/viewed at here: http://www.gnusolaris.org/gswiki/Bugs HackZone forum: http://www.gnusolaris.org/phpbb/viewforum.php?f=4 just an idea... Erast On Mon, 2005-11-14 at 16:31 -0300, Alfredo Peña wrote: Hi, I remember some talk about the creation of a application porting discussion forum. I can't find that list in http://www.opensolaris.org/os/discussions/ Is there plans to have that list? Is it ok to send app port questions to opensolaris-discuss meanwhile? Alf ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Is 'forking' inevitable here too?
Very good point and a right concern (to some degree) IMHO... As J.S. mentioned before, in the future we should expect at least 2 types of OpenSolaris-based distros: a) GNU-centric, those who trying to re-use GNU/Linux as much as possible b) Solaris-centric, those who trying to mimic Solaris as much as possible But I'm hoping that both (a) and (b) will be *much more* compatable than any two distros in GNU/Linux world. And the reason for my hope is that we are using the same Least Common Denominator(LCD) - OpenSolaris(tm) which is not just a kernel but userland too and developed under the single roof. In my sense, LCD will preserve inter-distro compatability. The amount of OpenSolaris code that big that I really doubt it is possible to successfuly fork OpenSolaris. Which is a good thing too. Erast On Tue, 2005-11-15 at 00:31 -0800, Scott N. wrote: What concerns me about the ramifications of Sun having an OpenSolaris and the subsequent distro's that will, or have come out, is that Forking and eventually all the stuff I hate about modern linux will plague OpenSolaris. Nexenta is the one I am most excited about and it runs fine on my other PC at work, but it is so different from Solaris already that I feel I am not even learning Solaris. I understand the reasoning behind Nexenta in having an opensolaris distro based on GNU userland, but fear seeing opensolaris turn into a distrowatch type mess in a few years. In its infancy I already had a huh? when I went to go manually configure Xorg with xorgconfig like I would in Solaris or Solaris Express but noticed the location of Xorg was slightly different as was xorgconfig not even being there. I am assuming because Nexenta was built using Debian source and hence is using the linux filesystem layout? Why? Why not at least stick with standard Solaris layout so relative newbies can have consistency in going to one opensolaris based machine to possibly a Solaris Server he might run across, etc. This is what I hate about Linux (major forking, 100's of distro's, incompatibilities between most of them. If I take a liking to one linux distro and have to go administer someone elses linux server which would be based on their chosen distro, I have to take unnessary time to relearn subtle differences, etc. I came to Solaris expecting this to NOT happen. Is it inevitable? Not to mention how much development energy is deflected as everyone seems to migrate towards there chosen distro instead of say one common kernel/userland that is then rolled out to all the distro's who then just add their touches. How come BSD's don't suffer from this problem and have remained consistent and have not forked enough to be different nor even gone into distro hell? Thanks This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] App porting forum?
On Tue, 2005-11-15 at 10:46 -0300, Alfredo Peña wrote: Erast, Thanks for your offer, but I'm trying to target Sun Solaris distro. Probably for most software developing in Nexenta is the same than developing in Solaris, but for something like xine that is very dependent on the specific versions of various libs (gnome, Xorg, libjpeg/tiff/etc...) that are not part of OpenSolaris yet, I assume that using Nexenta would be very different than using Solaris. Should work actually. Nexenta provides different versions of the same library. i.e. for instance libneon: lrwxrwxrwx 1 root root 17 Oct 22 23:14 /usr/lib/libneon.so.23 - libneon.so.23.0.9 lrwxrwxrwx 1 root root 17 Sep 24 10:57 /usr/lib/libneon.so.24 - libneon.so.24.0.7 the same true for libgnome, libjpeg and others. If some of the libraries missing, we will package it and package will co-exists with existing packages, i.e. for instance neon: $ dpkg -s libneon23 libneon24 | grep ^Package: Package: libneon23 Package: libneon24 Erast Please correct me if I'm wrong. Regards, Alf Erast Benson wrote: Alfredo, One of the goals of GNU/OpenSolaris project is to track all changes and bugs progress on porting/enhancing OSS projects which are not distributed by SUN but part of any regular GNU/Linux distribution like Ubuntu, Fedora, etc. GNU/OpenSolaris web development portal provide Subversion hosting and integrated Trac (Nexenta Bug Tracking System, i.e. NBTS) available for HackZone developers. (one should aquire account first) Latests development will bring future Launchpad(a collection of services for projects in the open source universe) integration, so any security fixes released by Ubuntu, RedHat, Debian, Gentoo, etc will be automatically tracked by NBTS and vice-versa. https://launchpad.net/distros/nexenta GNU/OpenSolaris web portal provides read/write Subversion access for HackZone interface. This interface is described at: http://www.gnusolaris.org/gswiki/HackZone Bugs can be tracked/viewed at here: http://www.gnusolaris.org/gswiki/Bugs HackZone forum: http://www.gnusolaris.org/phpbb/viewforum.php?f=4 just an idea... Erast On Mon, 2005-11-14 at 16:31 -0300, Alfredo Peña wrote: Hi, I remember some talk about the creation of a application porting discussion forum. I can't find that list in http://www.opensolaris.org/os/discussions/ Is there plans to have that list? Is it ok to send app port questions to opensolaris-discuss meanwhile? Alf ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Is 'forking' inevitable here too?
On Tue, 2005-11-15 at 11:26 -0600, David Schanen wrote: On 11/15/05, Joerg Schilling [EMAIL PROTECTED] wrote: Erast Benson [EMAIL PROTECTED] wrote: Very good point and a right concern (to some degree) IMHO... As J.S. mentioned before, in the future we should expect at least 2 types of OpenSolaris-based distros: a) GNU-centric, those who trying to re-use GNU/Linux as much as possible b) Solaris-centric, those who trying to mimic Solaris as much as possible But I'm hoping that both (a) and (b) will be *much more* compatable than any two distros in GNU/Linux world. And the reason for my hope is that we are using the same Least Common Denominator(LCD) - OpenSolaris(tm) which is not just a kernel but userland too and developed under the single roof. In my sense, LCD will preserve inter-distro compatability. If you move all binaries from /usr/bin/ to /usr/sun/, like Nexenta is doing, there is not much user space compatibility with Solaris left over. I haven't used the pre-alpha, but I think this actually wouldn't be such a big deal. Assuming things are done intelligently, there is the 'alternatives' mechanism on Debian and by default you could have symlinks to make rather than gmake and tar rather than gtar, et al. by default. You could even create a package indicating Solaris compatability that requires all the basic stuff kind of like Linux standard base is done. very true. dpkg's alternatives is a good thing. Also there are other ways to achive that, i.e. playing with execv() for instance. Using absolute paths (like some Makefile's obnoxious tendency to assume /bin/bash does something, grrr!), is not something I would want to encourage. Of course, maybe there are a lot of applications for Solaris out there that make assumptions about paths, I don't know. Those applications which are CDDL'ed will be fixed over time. Erast ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Is 'forking' inevitable here too?
On Wed, 2005-11-16 at 18:36 +0100, Joerg Schilling wrote: Erast Benson [EMAIL PROTECTED] wrote: very true. dpkg's alternatives is a good thing. Also there are other ways to achive that, i.e. playing with execv() for instance. Did you hack libc to do this? No. not yet. But at least we've discussed it a lot back in July. There was some other solutions, like sunsh wrapper with LD_LIBRARY_PATH tricks and so on. Erast ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] App porting forum?
On Wed, 2005-11-16 at 17:09 +0100, Joerg Schilling wrote: Alfredo Peña [EMAIL PROTECTED] wrote: Erast, Thanks for your offer, but I'm trying to target Sun Solaris distro. Probably for most software developing in Nexenta is the same than developing in Solaris, but for something like xine that is very dependent on the specific versions of various libs (gnome, Xorg, libjpeg/tiff/etc...) that are not part of OpenSolaris yet, I assume that using Nexenta would be very different than using Solaris. Please correct me if I'm wrong. There is a big difference between developing on Nexenta and doing the same on Sun Solaris or SchilliX. On the latter, you get full compatibility even for the build system. On Nexenta, it may be that you will get into trouble while compiling because there are no UNIX tools in /usr/bin but GNU tools. So be careful with assumptions on compatibility. For a software dveloper, SchilliX is currently the best platform because it gives better compatibility to Sun Solaris and because the developer tools, libraries and include files are more complete. Actually regarding xine and alike, Nexenta would be a better option for developers because of availability of libraries which does not exists on Solaris or blastwave.org. I'm talking about various plugins, language bindings and so on. All these extra libraries are part of Nexenta core. So, whether SchiliX or Nexenta better for developers is all pretty much depends on developers and their tasks. And just to notice, I think compilation of OpenSolaris on Nexenta is very possible, and will be available in Alpha 2 time frame. Erast ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] App porting forum?
On Wed, 2005-11-16 at 19:59 +0100, Joerg Schilling wrote: Erast Benson [EMAIL PROTECTED] wrote: And just to notice, I think compilation of OpenSolaris on Nexenta is very possible, and will be available in Alpha 2 time frame. If you believe this, you did obviously never actually try it out.. I think Mac tried it out. There was many issues all over... But all this is doable. Of course, if you delay Alpha 2 for several weeks you may be right ;-) Right. :-) No rush. After all, some bits are not even available yet. Erast ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: Is 'forking' inevitable here too?
Scott, I think /usr/X11 and missing xconfigure should be considered as a packaging bug or not-yet implemented feature. Nexenta Xorg should support 3td party drivers like recent Nvidia additions, etc. This could be easily entered as a feature request in NBTS. And someone will address it sooner or later. We are working on some of the Xorg bugs discovered during pre-Aplha1. And hopefully will fix them in Alpha1 (which is due these weekends, btw). Erast Could you explain your problems with the X location? I'll probably do something similar from your view as I don't know what's important for you... I was frustrated that I went to /usr to try and use /user/X11/xconfigure and noticed that Nexenta had /usr/X11R6 instead PLUS xconfigure was not even there. This is not where Solaris and Solaris Express put their X as it is in /usr/X11. So right from the getgo, I felt like I was back in linux camp. I know it is probably stupid to even complain about such minor details, but to me it is important and makes things feel more polished and better. I don't understand why there has to be a difference. I want to be able to use Solaris and get comfortable with it and be able to go to Solaris Express install or a 'distro' and be able to find everything the same underneath. CONSISTENCY. Like I said many times already, this is what eventually made me ditch linux completely and eventually what brought me to Solaris10/OpenSolaris. This is how I feel when I use BSD. Whether FreeBSD, DragonflyBSD,PC-BSD, etc I have no problem knowing where everything is layed out, everything works the same and is in the same location and I feel consistent. As a user, I appreciate that immensely. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Nexenta OS (elatte) Alpha 1 released 2005-11-18 mini-review
Good review. Thanks ken! One little thing, Nexenta Alpha 1 comes with non-debug kernel which makes Nexenta perfect platform for performance investigations. Erast On Mon, 2005-11-21 at 09:06 -0800, ken mays wrote: ref: http://www.gnusolaris.org/gswiki/Getting_Started Nexenta OS (elatte) Alpha 1 released I just spent a day reviewing a few trial loads of the latest release of Nexenta OS (elatte) Alpha 1 LIVE-CD. Oddly, it has taken up to an hour for the LIVE CD to get most of the desktop loaded on my two test machines (Compaq Presario S5000V and a custom Intel P4 2.5GHZ, 256MB RAM). I noticed that Nexenta doesn't provide the MGA_HAL driver for Matrox video card users. Now, the Knoppix 4.0.2 and older Gnoppix Live CD worked fine on both of my test machines and several older distros of Knoppix and other LIVE CDs/DVDs. Maybe some clues to 'streamline' Nexenta loading of the GNOME desktop, necessary apps, and better RAMDISK usage may help Nexenta on systems with less than 512 MB of RAM. The nice point about this release of Nexenta is the improvements to X and the additional network drivers. Also, over 90 bug fixes and several other issues were resolved. As far as languages and the sessions, I was only able to pick POSIX-C English and various GNOME sessions from the GDM. One of the best features is that you can load up Nexenta in Single user CLI mode and begin doing programming work immediately. This may be something worth reviewing for educational Unix programming and beginner classes. I'll try to review more of the Nexenta OS system inthe upcoming days as I upgrade the RAM in my test systems. ~Ken Mays __ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.com ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] application porting forum?
On Sun, 2005-11-06 at 23:46 -0800, Dan Price wrote: On Thu 03 Nov 2005 at 07:39AM, Richard L. Hamilton wrote: Since I'm going to ask a question about some problems porting a particular app to [Open]Solaris (in another thread), it occurred to me: why not have a forum for that topic in general? The more apps run on [Open]Solaris, the better it is for everyone. Further, in some Richard, Kudos. I've been meaning to start such a community for some time now, but have been too busy. I strongly agree with this idea, and I think it would be good to investigate a multi-pronged approach: - Create a place for porters to ask and answer technical questions. [EMAIL PROTECTED] with integrated Trac. - Create a master wish list of open source apps we'd like to port: - What the app is, what it does [EMAIL PROTECTED] Also, HackZone, HackZoneTeams. - What needs porting (is it fine tuning? major functionality? clean integration with SMF?... what's the issue?) www.gnusolaris.org's Wiki and Bugs pages - Possible funding, bounties, etc. www.gnusolaris.org/gswiki/Bugs integrated with https://launchpad.net/distros/nexenta Launchapd is distribution independent issue tracker. supports bounties and many other features. well founded. - Educational materials/articles about porting. www.gnusolaris.org's Wiki - A list of identified problems with OS which are inhibiting porting. Again /Bugs or /Wiki - Porting challenges: In other words-- December's challenge to the group is to port Audacity Further thoughts? -dp My thoughts are: lets re-use what we have and make it better instead of reinventing the wheel again. All porting problems are generic and once porting is done, what do you do next with the package? Right... future upstream sync-ups and security bug fixes. This is where community interoperability is highly required. PS: Initial idea with www.gnusolaris.org was: Web portal for centralized porting efforts and *not* Nexenta specific. It integrates Wiki, Blogs, Forums, mailing lists, Subversion and Trac+Launchpad in single place sutable for Solaris developers. Erast ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Why not to use pkgsrc package system ?
On Tue, 2005-11-22 at 00:29 +0100, Joerg Schilling wrote: Alan DuBoff [EMAIL PROTECTED] wrote: On Monday 21 November 2005 06:37 am, Patrick Mauritz wrote: On Thu, 2005-11-17 at 21:50, Alan DuBoff wrote: This is currently a problem with all of the distributions on Solaris/OpenSolaris. Blastwave, pkgsrc, (I suspect) gentoo, sunfreeware, etc...all build their own userland. GNU/OpenSolaris does the same in it's own way. this is why I built my own Right. But ultimately if we want to really work together, it would be nice if we had a common set of libraries that everyone could use, and so that we shouldn't have so many sets of libs floating around our directories. I am not sure if a cooperation with a Debain oriented Solaris distribution would be feasable. I expect just too many incompatibilities. To some degree. Why not? Also putting too much in OSOL LCD(OpenSolaris least common denominator) will break distribution's individuality. So, please lets be careful here. Erast ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Hacking Nexenta article
Guys, I just finished this article: http://www.gnusolaris.org/gswiki/Hacking_Nexenta it explains how to start hacking package with absolutely minimal efforts involved on Nexenta OS. Erast ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Is 'forking' inevitable here too?
To me, it sounds like you lost the ground... Where are you? On Mars? So, how is the craters? :-) Have you ever noticed that GNU/Linux is everywhere? I'm still not so sure in bright OpenSolaris future because of 2 main non-thechnical reasons: a) mind set shift (GNU/Linux = */OpenSolaris) might not happen at all or will take too much time to happen and than GNU/Linux will close the gap on server side too. And people like you will scare existing GNU/Linux user base which is very bad for OpenSolaris community in general. b) SUN Microsystems still do not care to explain their oficial position on CDDL vs. GPL compatability issue in terms of shipping GPL apps on single media as Solaris Express, Nexenta, BeleniX and others do or will do. This is purely publiciy thing, but it *must* be clarified ASAP. So, users will not be afraid to jump on OpenSolaris-based distros. In regard to (b). One simple thing SUN could do is to dual license SUN libc as GPL and CDDL. The way FreeBSD, Mozilla and many others resolved it. This will immediately resolve publicity issue. But at the same time I *LOVE* OpenSolaris and very much would like to continue on conquer existing GNU/Linux users hearts and believe in our final success! Erast On Wed, 2005-11-23 at 07:46 -0800, UNIX admin wrote: As J.S. mentioned before, in the future we should expect at least 2 types of OpenSolaris-based distros: a) GNU-centric, those who trying to re-use GNU/Linux as much as possible b) Solaris-centric, those who trying to mimic Solaris as much as possible But I'm hoping that both (a) and (b) will be *much more* compatable than any two distros in GNU/Linux world. And the reason for my hope is that we are using the same Least Common Denominator(LCD) - OpenSolaris(tm) which is not just a kernel but userland too and developed under the single roof. In my sense, LCD will preserve inter-distro compatability. That is unlikely to happen, although I hope that Moinak G. will make it possible. Why? Because someone who really knows and understands UNIX won't give GNU five minutes. GNU is all about the hype and brute force and none of the quality/snandards. UNIX people (and don't tell me that there are no UNIX people!) that could bring it together will spring for b) because they know that's the right way of doing things (sorry, but that's just the way it is). Those who don't yet know UNIX and have grown up on GNU diet as Moinak puts it (rightly so), will be pushing for GNU. With a few notable exceptions, those people don't have the necessary experience to bring it all together properly, and if they keep pushing GNU, they're not likely to get that experience either. So, with a few exceptions, things will stay as they are. I can't really say that I'm sorry about that, GNU tools are very poor in every respect. I'd much rather be using Sun Studio compilers than GCC, for example. Good/usable/quality applications from GNU land will find their way into Solaris. Yet, there is some hope left. If Solaris attracts critical enough mass of developers (and it looks poised to do so), those people may start using Solaris as their main development platform. This, I hope, would eventually lead to extinction of GNU in its present form. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Is 'forking' inevitable here too?
On Wed, 2005-11-23 at 12:23 -0800, Rich Teer wrote: a) mind set shift (GNU/Linux = */OpenSolaris) might not happen at all or will take too much time to happen and than GNU/Linux will close the I agree that the mindset shift will take time. Right. that is precisely my point gap on server side too. And people like you will scare existing Please. That assumes that OpenSOlaris is going to stand still, giving other OSes a chance to catch up. That ain't gonna happen. I'm pretty sure that ain't gonna happen. But history tells us that technical superiority is not a gold key to success. Remember IBM OS/2 vs. M$ Windows 95 story? i.e. we need something more than just thechnical advances. To me, there are 2 main reasons(aside of technical advantages) for GNU/Linux user to migrate: a) OpenSolaris kernel and core userland interface stability. Long time Solaris users do not appreciate this, but this is exactly what is missing in todays GNU/Linux. So, lets keep it this way. b) Availability of the Distributions which he used to work with in the past. Debian/Ubuntu = Nexenta OS is a perfect solution for their problems. So, lets help and use Nexenta as the best migration path for the newcommers. Erast ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: OpenSolaris - Why should I care? More questions.
On Sun, 2005-11-27 at 11:11 +0100, [EMAIL PROTECTED] wrote: 3. So far the discussion has only been about Solaris 10 or OpenSolaris. What about new distros such as Nexenta and BeleniX that retain only the Solaris kernel and core libraries? Pure Solaris is renowned for its stability; part of the reason presumably is the fact that Sun Q/A applies to every single aspect of the entire OS. Does this quality and stability necessarily carry over into a hybrid OS with Solaris kernel and GNU utilities, applications, etc.? Potentially such an OS could be incredibly buggy and unstable, completely negating the advantages of a very stable Solaris kernel, couldn't it? Can such a hybrid indeed be made as stable as Solaris itself? The GNU utilities carry both a stability and compatibility risk. Nothing in Solaris proper can fix that. This statement true for any software in general, unless development is pretty much dead. :-) Solaris 8,9,10,11 are different, and therefore carry the same risk for end user's apps. Talking about Nexenta and Others: once distro reaches major release, i will be stabilized(i.e. no major changes) and supported for a longer periods of time. And in fact, GNU utilities rock stable and pretty compatible across the versions and platforms. So, I woudn't buy your statement.. Erast ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: OpenSolaris - Why should I care? More questions.
On Sun, 2005-11-27 at 12:44 +0100, [EMAIL PROTECTED] wrote: The GNU utilities carry both a stability and compatibility risk. Nothing in Solaris proper can fix that. This statement true for any software in general, unless development is pretty much dead. :-) Perhaps I should have quantified that: when used as default in a Solaris environment.. The GNU utilities are not compatible with their Solaris equavalent and in some cases violate standards, best practices or have bugs which their authors refuse to fix. don't you agree that any software has some bugs anyways? I'd say this is part of software industry. violate standards sounds very funny to me. Microsoft violates standards all over, still everybody using it. But my point is: GNU tools are slightly incompatible with SUN tools. But because GNU tools has x1000 times wider usage, I think, this is SUN tools which are violates GNU standards. :-) Guys, this GNU vs. SUN tools discussion leading to nowhere. Decent OpenSolaris-based distro must support both. One way or another. Erast ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: OpenSolaris - Why should I care? More questions.
On Sun, 2005-11-27 at 11:10 -0800, Rich Teer wrote: On Sun, 27 Nov 2005, Erast Benson wrote: Solaris 8,9,10,11 are different, and therefore carry the same risk for end user's apps. You're forgetting a rather important detail: Sun places a big emphasis on backwards compatibility, so migrating to newer versions of Solaris carries much less risk than migrating to a new version of Linux. Linus has specifically stated that not only is backwards compatibilty not a requirement for him, but that he (and the other Linux developers) will deliberately break compatibility with previous releases to discourage binary-only software. Because of this policy, how long do you think it will be before companies like Nvidia take a look at their Linux vs Solaris maintenance costs, and decide to srop support for the former as a cost saving measure? Hey, I do not disagree. :-) This is the reason why we started Nexenta OS development after all. And btw, Nexenta OS is as stable at its core as Solaris. Nexenta OS as compatible (core userland and kernel) with Solaris as SchiliX. Moreover, we are working on the solution which will allow users to switch personalities dynamically. So, if someone wants pure Solaris-like behavior, it is going to be very easy possible. Erast ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [desktop-discuss] Re: [osol-discuss] Re: [gnu-sol-discuss] Incorporating open-source cmds/libs into OpenSolaris
On Tue, 2005-11-29 at 18:08 -0800, Alan Coopersmith wrote: Bryan Cantrill wrote: Suffice it to say that we have learned the hard way: put it in /usr/bin unless there's a conflict that prevents it. Though I still get complaints about GNOME being in /usr/bin, since it makes it harder to install another version and without breaking all the existing bits of the OS that depend on Sun's version. I see it like this: GNOME's /usr/bin stuff should correspond to the latest installed one and /usr/lib should has older libraries so, closed sourced user apps will not break. Erast ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Is distribution neutral application compatibility feasible?
On Wed, 2005-11-30 at 15:24 -0800, Alan Coopersmith wrote: Brian Nitz wrote: I have a Nexenta elatte gnusolaris partition alongside my NV_27a with a GNOME 2.12 JDS build. Nexenta is based on the same kernel code and also contains a GNOME 2.12 desktop. Unfortunately the binaries for the gnusolaris versions of these applications aren't easily interchangable with the binaries in Nevada. For example when I try to run gnusolaris zenity on Nevada, it fails because it expects libXi.so.6 and we have libXi.so.5. If I set LD_LIBRARY_PATH to include /gnusolaris/usr/lib and /gnusolaris/lib, the gnusolaris binaries run O.K. I was also told that libXi.so.6 and libXi.so.5 are probably the same library with a different name! The real solution for that specific problem is to get all the distributions using the same source for X libraries - unfortunately, that's currently impossible, as Sun Solaris uses a X code base that's closed source and would break binary compatibility with older Solaris versions if we just cut over to the Xorg open source release.I really am working to get as much as we can of Solaris X released via OpenSolaris as soon as possible (and libraries like libX11 and libXi won't be in the first set of code released), but unfortuantely have a day job competing with that work, so it's going slower than anyone wants. Here is some more information on this library: http://www.gnusolaris.org/archive/elatte-unstable/x11/libxi6 % dpkg -s libxi6 Package: libxi6 Status: install ok installed Priority: optional Section: x11 Installed-Size: 41 Maintainer: Daniel Stone [EMAIL PROTECTED] Architecture: solaris-i386 Source: libxi Version: 1:1.3.0-2 Depends: libgcc1 (= 1:3.4.4), libx11-6, libxext6, sunwcslr, x-common Description: X11 Input extension library libXi provides an X Window System client interface to the XINPUT extension to the X protocol. . The Input extension allows setup and configuration of multiple input devices, and will soon allow hotplugging of input devices; to be added and removed on the fly. . More information about X.Org can be found at: URL:http://xorg.freedesktop.org URL:http://lists.freedesktop.org/mailman/listinfo/xorg . This module can be found as the module 'lib/Xi' at :pserver:[EMAIL PROTECTED]:/cvs/xorg Nexenta's Xorg using 6.8.2 + CVS HEAD fixes. I guess, once Solaris will move to Xorg 7.0, this problem will be resolved. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: Opera 9 also works...
Yep, this is what you get when you have stable API at the core and well builded and configured GNU userland. Welcome to Nexenta world! :-) I also cross-posting opensolaris-discuss@, so other folks will look at your screenshots and will see how fast Nexenta OS progressing! Thanks Pedro! On Thu, 2005-12-08 at 00:26 -0800, Pedro Gracia wrote: A new screenshot at my home page... http://www.gnusolaris.org/gswiki/lasarux This is a good surprise to me... :-) Pedro ___ GNU/Solaris Development mailing list gnusol-devel@gnusolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] i nstalling opersolaris
On Sun, 2005-12-18 at 10:58 -0800, thomas rinehart wrote: i have a p3 750 with 384 mb a 20 gig hd with win98,ubuntu5.10 and debian sarge all installed and working fine however when i try to install opensolaris the schllix distro it tells me i dont have enough memory im new to solaris and could use some help try Nexenta OS's install CD at http://www.gnusolaris.org/gswiki/Download ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] KDE, GNOME, etc.
On Sun, 2005-12-18 at 15:53 -0500, Bill Rushmore wrote: On Sun, 2005-12-18 at 13:02, Gary Gendel wrote: Anyway, Linus has just opened another can of worms that directly effects OpenSolaris and JDS. I really don't see how this effects JDS or OpenSolaris. It just one guy's opinion not some edict from above. I woudn't underestimate Linus's Torvalds opinion... A lot of OSS developers looking at what he is saying and following him no matter what. I agree it will not change picture much, but KDE will definetly benefit from newcomers.. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] i nstalling opersolaris
On Sun, 2005-12-18 at 13:15 -0800, Matt Ingenthron wrote: Erast Benson wrote: On Sun, 2005-12-18 at 10:58 -0800, thomas rinehart wrote: i have a p3 750 with 384 mb a 20 gig hd with win98,ubuntu5.10 and debian sarge all installed and working fine however when i try to install opensolaris the schllix distro it tells me i dont have enough memory im new to solaris and could use some help try Nexenta OS's install CD at http://www.gnusolaris.org/gswiki/Download Erast: Are you saying there is a known issue with Schillix, or just advocating a different distro? I advocating different distro since I know that Nexenta InstallCD do not have this problem. And it should work with 256MB installed. So, by trying Nexenta he will get another data point to look at. LiveCD and alike has this problem since they require ramdisk preallocated for root partition. For instance, its a known fact for Nexenta Alpha1 LiveCD. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] KDE, GNOME, etc.
On Mon, 2005-12-19 at 16:52 +0100, Joerg Schilling wrote: Erast Benson [EMAIL PROTECTED] wrote: I woudn't underestimate Linus's Torvalds opinion... A lot of OSS developers looking at what he is saying and following him no matter what. I agree it will not change picture much, but KDE will definetly benefit from newcomers.. How many catholics will avoid to use the pill just because the pope recommends not to use it? Who knows? But the point is, KDE is quite mature and widely used, and decent OpenSolaris-based distro must have it *integrated* (i.e. not just like third-party /opt/csw...). btw, NexentaOS Alpha 2 will have it integrated and derived from Kubuntu/Breezy. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] KDE, GNOME, etc.
On Thu, 2005-12-22 at 00:47 +1100, Glynn Foster wrote: Hey, On Wed, 2005-12-21 at 02:30 -0800, Alan DuBoff wrote: On Tuesday 20 December 2005 08:37 pm, Glynn Foster wrote: Interesting. So you're going to swap your user base over to the KDE desktop? Or are you going to try and retro fit both into Nexenta? Won't that be a bit hard for a single CD? :/ Can't the bulk of packages be installed over the net? That's what I've always liked about Debian, install the smallest amount of needed code and then apt-get the rest that you need. It just works. Yeah, it just wasn't obvious from the comments in the email, that I thought it would be good to clarify. For the purposes of a Live CD though, you have to be careful about what default set of packages you make available to entice people to play around with and install afterwards - certainly not an easy task my any means. Oh, no. Nexenta LiveCD is not going to change. I was talking about InstallCD which has 350MB free space, so it should fit KDE as well. The rest will be downloadable through the APT repository. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] KDE, GNOME, etc.
On Wed, 2005-12-21 at 15:05 -0800, Alan DuBoff wrote: If you're missing something, an apt-get grabs it with the dependancies. This system works very well. The problem with Nexentra is that many of the standard packages of Debian are not ported at this time. They seem to have taken quite a leap, and are well on their way. true. but we are getting there. Nexenta Alpha 2 will likely have 3500+ packages available for immediate download. Meanwhile, one could search package sources at http://packages.ubuntu.com download *.tar.gz and *.diff.gz extract it, and do dpkg-buildpackage. Example with mplayer: $ wget -c http://archive.ubuntu.com/ubuntu/pool/multiverse/m/mplayer/mplayer_1.0-pre7cvs20050716.orig.tar.gz $ wget -c http://archive.ubuntu.com/ubuntu/pool/multiverse/m/mplayer/mplayer_1.0-pre7cvs20050716-0.1ubuntu9.diff.gz $ tar xzvf mplayer*.tar.gz $ cd mplayer-1.0-pre7 $ gzcat ../mplayer*.diff.gz | patch -p0 $ dpkg-buildpackage (coffe time) $ cd .. $ dpkg -i *.deb Note: all steps above assuming that you have working build environment and compiled and installed all mplayer requirements (see mplayer*/debian/control meta). i.e. pretty much any package from 18000+ packages of Ubuntu/Breezy will work *as is* or with minimal changes. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] NetBSD's pkgsrc on OpenSolaris
On Wed, 2005-12-28 at 05:31 -0800, Roman wrote: OpenSolaris is pretty much useless on desktop if you can't run your favourite web browser, email client, etc. There are a few sites that offer precompiled Solaris native packages, but they are not as good as pkgsrc. Also Solaris native packaging system sucks, compared to pkgsrc. Actually, native Solaris's PKG system is quite advanced but not eye candy and hard to use. But today OpenSolaris users has another option besides pkgsrc. Its Debian's based Nexenta OS with 18000+ packages avaialable in source form and 3000+ in binary form. (as of today). And number packages is growing. Debian repository has everything latest/greates. And pretty much all of available Debian packages compiles on NexentaOS quite easily. (remember that Debian is platform-independent technology, i.e. it has ports on Linux, FreeBSD, Darwin and now SunOS). Its actually really cool to find out that on the second day after new version of mplayer is released, corresponding Debian package gets updated to the latest. Check out http://www.gnusolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] NexentaOS GUI configuration tools fully ported
Hi Guys, Just wanted to let you know that with help of system-tools-backends maintainers I was working on system-tools-backends and gnome-system-tools frontends to bring GUI tools up to the level when average user could easy configure NexentaOS, new exciting Ubuntu GNU/Solaris based operating system! I ported almost all system-tools-backends components and did quite a lot of bug fixing and SunOS-awareness fixes in gnome-system-tools frontends. Specific OpenSolaris/Nexenta features fully supported: * SMF management (start,stop,view) * dfstab NFS and Samba shares * native OpenSolaris Wifi network locator and configuration using wificonfig and native wireless drivers * native NIC interfaces configuration which utilizes existing configuration schema, i.e. /etc/netmasks, /etc/networks, /etc/hostname.$dev, etc * native NTP client and timezone support * disk administration with UFS partition support Backends are fully integrated into Nexenta desktop, for instance, missing NTP or Samba packages will be requested via Synaptic package manager and will be downloaded via popup GUIs. Nautilus integrated with disks-admin as well as the rest of tools spread out through the GNOME's menu and options. Check out screenshot at my homepage: http://www.gnusolaris.org/gswiki/ErastBenson If you are not Nexenta OS user yet, than become one and help us make it the best OS environment available around! Enjoy and happy new year!!! Erast ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] NetBSD's pkgsrc on OpenSolaris
On Thu, 2005-12-29 at 12:08 +, Roman Duka wrote: On Wed, 28 Dec 2005 09:40:20 -0800 Erast Benson [EMAIL PROTECTED] wrote: On Wed, 2005-12-28 at 05:31 -0800, Roman wrote: OpenSolaris is pretty much useless on desktop if you can't run your favourite web browser, email client, etc. There are a few sites that offer precompiled Solaris native packages, but they are not as good as pkgsrc. Also Solaris native packaging system sucks, compared to pkgsrc. Actually, native Solaris's PKG system is quite advanced but not eye candy and hard to use. But today OpenSolaris users has another option besides pkgsrc. Its Debian's based Nexenta OS with 18000+ packages avaialable in source form and 3000+ in binary form. (as of today). And number packages is growing. Debian repository has everything latest/greates. And pretty much all of available Debian packages compiles on NexentaOS quite easily. (remember that Debian is platform-independent technology, i.e. it has ports on Linux, FreeBSD, Darwin and now SunOS). Its actually really cool to find out that on the second day after new version of mplayer is released, corresponding Debian package gets updated to the latest. Check out http://www.gnusolaris.org Does this mean I have to install Nexenta, or I could keep on running Sun's Solaris and simply adopt your package framework? As of now, you have to install Nexenta Alpha 1 (which is build27 based). May be there is a simple way to adopt packages. I'll think about it. Its known fact that dpkg and apt-get totally independent from the system and could be executed on Solaris without modifications or recompilations. Also, how do you build packages from source? Are there options for using SunPro compilers and custom optimisation flags? Right now we have gcc-3.x and gcc-4.x. Majority of FOSS requires gcc to build. But nobody stops you to run SunPro compiler on NexentaOS since in core NexentaOS is just yet another OpenSolaris based distribution but GNU-centric. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: NetBSD's pkgsrc on OpenSolaris
On Mon, 2006-01-02 at 08:53 +0530, Moinak Ghosh wrote: Eric Boutilier wrote: pkgsrc on solaris looks very interesting to me, out of all the systems we have to choose from it seems to hit the sweet spot as far as my limited knowledge of pm goes... In light of all the recent work that's been done to bring Debian PM (apt) and Debian source repository support to Solaris, what would be the advantage to using pkgsrc over Debian? (That is, unless you're talking about having two package registries -- e.g. Sun SVR4 + pkgsrc -- inter-operating with each other.) In other words, if there is interest in having OpenSolaris systems that completely supplant the SVR4 package registry/system with something else, wouldn't it be more effective to forgo pkgsrc in favor of Debian/apt at this point? A couple of doubts: There were issues/concerns with the Debian community regarding the use of dpkg/apt in OpenSolaris. Have those been resolved ? Sure: http://lists.debian.org/debian-dpkg/2005/11/msg00017.html http://lists.debian.org/deity/2005/11/msg00139.html This would determine future upstream acceptance of dpkg OpenSolaris port. I think changes already accepted. At any rate, changes we did are quite trivial and could be easily maintained as a set of separate patches. The current dpkg repository that is available (Nexenta) is built for a GNU/Solaris setup and is not suitable for a Solaris compatible OpenSolaris distro. that is not true. dpkg and apt-get are highly configurable software and could be easilly used in native Solaris enviornment. I actually tried it myself and managed some Nevada software with dpkg quite succesfully. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Companion CD [ was: KDE, GNOME, etc. ]
On Mon, 2006-01-02 at 11:44 -0500, Stefan Teleman wrote: On 1/2/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: So can we change this now to Studio? One thing is C++ ABIs (and the complete lack of stability at the g++ side of the fence) but also the problem with gcc compiled shared libraries in general: they often do not work easily when you don't use gcc ( symbol __eprintf: referenced symbol not found ). But code compiled with gcc intermingles with Sun Studio compiled libraries just fine. Casper Sun Studio: Yes!! GCC: don't you guys want a snappy, fast, KDE ? :-( gcc-4.x branch has reworked optmizer for C++ and generates quite fast objects. By any chance, do you have comparision links between Studio and gcc-4.x ? In C++, GCC and SunStudio do not get along at all. And sometimes not in C either. You mean binary incompatability? Example please? ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: NetBSD's pkgsrc on OpenSolaris
On Mon, 2006-01-02 at 23:01 +0530, Moinak Ghosh wrote: Erast Benson wrote: On Mon, 2006-01-02 at 08:53 +0530, Moinak Ghosh wrote: The current dpkg repository that is available (Nexenta) is built for a GNU/Solaris setup and is not suitable for a Solaris compatible OpenSolaris distro. that is not true. dpkg and apt-get are highly configurable software and could be easilly used in native Solaris enviornment. I actually tried it myself and managed some Nevada software with dpkg quite succesfully. Well, for sure you folks have ported apt/dpkg to OpenSolaris and it works fine. I have used dpkg in the past and of course it is among the best. But my point was about the the repository used by Nexenta. Since it is a repository built for a complete GNU userland, the packages will fail to work 100% for a distro which uses the complete OpenSolaris userland and GNU/OSS add-on software. Oh, sure. Software in Nexenta's APT repository needs to be fixed and rebuild in that case. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: NetBSD's pkgsrc on OpenSolaris
On Wed, 2006-01-04 at 17:19 -0800, Mike Ditto wrote: Joerg Schilling wrote: Dave Miner [EMAIL PROTECTED] wrote: I'm not sure what an OpenSolaris compliant sticker would be designed to achieve, though, or why SVR4 packages are necessarily a part of it. Well I hope that the proliferation of OpenSolaris-based distros doesn't create a proliferation of binary/packaging compatibility standards for off-the-shelf and downloadable software. OK, let us call it Solaris compliant. People like to know whether things that work on Sun Solaris would also work on an OpenSolaris based distro. So Solaris compatible is one ABI/packaging standard that a distro can offer. (Actually it should be a particular release, like Solaris 10 compatible.) There may be room for other ABI/packaging standards, too (but as I said, not too many). For example, I'd be interested in a reduced historical compatibility OpenSolaris ABI that is willing to forgo all compatibility with system administration interfaces and other expensive burdens and maybe even use new packaging formats, such that this new ABI could be supported by future releases of Sun Solaris as well as alternative OpenSolaris distros that might or might not choose to implement the Solaris 10 ABI. I don't know what package-level compatability you are talking about... Today, *Solaris software distributes in next ways: 1) source tarball 2) binary tarball 3) autoextracting scripts .sh 4) SVR4 packages 5) custom installers I think it will be unfortunate if SVR4 packaging will be a requirement for OpenSolaris compatability... Neither distribution vendors nor software vendors should not be forced by this. IMHO. If software vendor decides to release .deb packages for Nexenta GNU/Solaris, why not? On another hand, in Nexenta we have alien technology which could potentially convert between SVR4 = Debian formats on the fly. The only thing is dependencies, i.e. some software might require Nexenta, Belenix or Solaris specific software to be pre-installed, which complicates the picture a bit... But if we expect to buy or download pre-packaged software there needs to be some kind of virtual sticker for each ABI that lets us know whether the software and the OS work together. Again, look at M$ Windows. It does not have any package management built-in, and it is still OK. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: NetBSD's pkgsrc on OpenSolaris
On Thu, 2006-01-05 at 14:41 +0100, Joerg Schilling wrote: Erast Benson [EMAIL PROTECTED] wrote: I don't know what package-level compatability you are talking about... Today, *Solaris software distributes in next ways: 1) source tarball 2) binary tarball 3) autoextracting scripts .sh 4) SVR4 packages 5) custom installers I think it will be unfortunate if SVR4 packaging will be a requirement for OpenSolaris compatability... Neither distribution vendors nor software vendors should not be forced by this. IMHO. If software vendor decides to release .deb packages for Nexenta GNU/Solaris, why not? If a software vendor releases SVr4 packages for Solaris and you cannot install these packages on Nexenta, I would call Nexenta non-Solaris compliant. If a software vendor releases .deb packages only, they cannot be for Solaris as the related packaging software is not part of the 'on-board software' on Solaris. ... and if software vendor releases custom installer and you can install software on any OpenSolaris based distro, how would we call those distros than, compliant or still not? I guess we need to spell out what OpenSolaris compliant distro is. i.e. to which degree distro could be different and still we can call it to be compliant. I don't think SVr4 compatability is the requirement. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Mono .NET available on GNU/OpenSolaris!
I spent some time on syncing/porting Mono friends from Ubuntu/Dapper and now we have all parts working and integrated into Nexenta GNU/OpenSolaris! Enjoy Mono .NET screenshot (at the bottom): http://www.gnusolaris.org/gswiki/ErastBenson You will see some popular latest/greatest C# applications running on GNU/OpenSolaris like F-Spot, Blam, Muine, MonoDoc, MonoDevelop, Beagle and others... All packages fully integrated into Nexenta APT repository and available at binary pre-compiled format. Its about 100+ packages (including non-Mono dependencies), some of them are: mono-utils - Mono utilities libmono-dev - libraries for the Mono JIT - Development files mono-jay - LALR(1) parser generator oriented to Java/.NET mono-devel - Mono CLI (.NET) runtime with development tools libikvm-native - Native library for IKVM Java virtual machine for .NET (Mono) libmono0 - libraries for the Mono JIT libdbus-1-cil - .NET binding for D-BUS interprocess messaging system libevolution-cil - CLI bindings for Evolution mono-common - common files for Mono mono - Mono CLI (.NET) runtime mono-jit - fast CLI (.NET) JIT compiler for Mono blam - an RSS aggregator for GNOME monodoc-gtk-manual - compiled XML documentation for Gtk# monodoc-gecko-manual - compiled XML documentation for Gecko# monodoc-nunit-manual - compiled XML documentation for Nunit monodoc-manual - compiled XML documentation from the Mono project monodoc-gtk2.0-manual - compiled XML documentation for Gtk# 2.4 monodoc-gecko2.0-manual - compiled XML documentation for Gecko#2 monodoc-gtksourceview2.0-manual - compiled XML documentation for GtkSourceView#2 monodoc - Mono documentation viewer mono-gac - Mono GAC tool mono-gmcs - Mono C# 2.0 compiler mono-mcs - Mono C# compiler monodoc-http - MonoDoc http based viewer monodoc-base - shared MonoDoc binaries ikvm - Java virtual machine/compiler implemented in .NET (Mono) monodoc-browser - MonoDoc GTK+ based viewer monodevelop - C#/Boo/Java/Nemerle/ILasm Development Environment monodevelop-versioncontrol - VersionControl plugin for MonoDevelop monodevelop-nunit - NUnit plugin for MonoDevelop monodevelop-java - Java plugin for MonoDevelop monodevelop-boo - Boo plugin for MonoDevelop mono-classlib-1.0-dbg - Mono class library (1.0) - debug symbols mono-classlib-2.0-dbg - Mono class library (2.0) - debug symbols mono-assemblies-base - Mono class library - transistion package mono-classlib-1.0 - Mono class library (1.0) mono-classlib-2.0 - Mono class library (2.0) libgalago-cil - CLI bindings for libgalago libgtk-cil - CLI binding for the Gtk+ toolkit libglib-cil - CLI binding for the GLib utility library libglade-cil - CLI binding for the Glade libraries libgnome-cil - CLI binding for GNOME libgtk2.0-cil - CLI binding for the GTK+ toolkit 2.4 libvte2.0-cil - CLI binding for VTE 0.11 libglade2.0-cil - CLI binding for the Glade libraries 2.4 libgnome2.0-cil - CLI binding for GNOME 2.6 libglib2.0-cil - CLI binding for the GLib utility library 2.4 libdbus-1-cil - .NET binding for D-BUS interprocess messaging system libevolution-cil - CLI bindings for Evolution libgmime2.1-cil - CLI binding for the MIME library, unstable version libnunit-cil - Unit test framework for .NET libgconf-cil - CLI binding for GConf libvte-cil - CLI binding for VTE libgecko-cil - CLI binding for the GtkMozEmbed library libgconf2.0-cil - CLI binding for GConf 2.6 libgecko2.0-cil - CLI binding for the GtkMozEmbed library, unstable version libgtksourceview2.0-cil - CLI binding for the gtksourceview library python-beagle - python bindings for beagle beagle-dev - library for accessing beagle (development files) beagle - indexing and search tool for your personal data beagle-backend-evolution - evolution data backend for beagle muine - Simple playlist based music player muine-plugin-trayicon - TrayIcon Plugin for the Muine music player f-spot - personal photo management application ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Idea for a nice OpenSolaris project - HCL client
On Sun, 2006-01-15 at 16:24 +1300, Glynn Foster wrote: Hey, So I recently installed Ubuntu 5.10 [Breezy], mostly as a way of playing with the Nokia 770 that I got sent. It's a pretty nice polished distribution, and would definitely be my Linux distribution of choice at the moment. Having played around a little bit, one of the neat little features is the Ubuntu Device Database. It's a simple python application that collects data about your system and sends it to http://hwdb.ubuntu.com. What's clever about it is that it gives the Ubuntu guys an opportunity to see what types of hardware people are trying to run the distribution, and cunningly come up with a HCL [hardware compatibility list] which is useful at an enterprise level. It's currently groking information from the following places - o Output of HAL HAL is the hardware abstraction layer, that we'll hopefully port to Solaris and ship in the near future. In fact Artem has already done some great stuff with HAL and plans for vold o X Server Grabs the xorg.conf config file and the current Xorg.0.log file o Kernel Grabs dmesg output o Additional data Takes any additional comments or data that you've filled in from the user interface It occurs to me, that this would be *extremely* useful in an OpenSolaris context - perhaps something that we could upload onto opensolaris.org? Maybe the Nexenta guys have ported this already [1], or there's some similar already available. partially ported. The upload part doesn't work yet, i.e. it will require modifications on www.gnusolaris.org and setting up server-side script which will process data and present results in HTML. Either way, I think it's a nice idea for a project if anyone is keen to give it a go. Right. Erast ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Idea for a nice OpenSolaris project - HCL client
On Sun, 2006-01-15 at 23:21 +1300, Glynn Foster wrote: Hi, On Sun, 2006-01-15 at 03:04 -0800, Erast Benson wrote: partially ported. The upload part doesn't work yet, i.e. it will require modifications on www.gnusolaris.org and setting up server-side script which will process data and present results in HTML. Are the patches available online for anyone who might like to pick up the task? Sure: http://www.gnusolaris.org/cgi-bin/trac.cgi/browser/gnusolaris1/hwdb-client/trunk All other GNU OSS software and patches: http://www.gnusolaris.org/cgi-bin/trac.cgi/browser/gnusolaris1 ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Idea for a nice OpenSolaris project - HCL client
On Sun, 2006-01-15 at 19:41 -0500, Bruce Riddle wrote: How about a really intelligent parser of prtconf -pv output. and we have it packaged within NexentaOS core packages, its called lspci which utilizes sf.net pci ids database. but the point of having nice GUI which interacts with user... ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] First Draft of GPLv3
On Mon, 2006-01-16 at 13:41 -0500, Stefan Teleman wrote: Disclaimer: This Post Is Not An Open Invitation For Yet Another GPL Flamewar. If you feel the irresistible urge to engage in such activity, please go to Slashdot. Thank you. The first draft of GPL v3 has been made public at: http://gplv3.fsf.org/draft On my first reading, it would appear that the linking with non-GPL code restrictions from GPL v2 have been removed. Also, accompany wording in system runtime exception has been removed too! I guess it is a good thing. :-) ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Idea for a nice OpenSolaris project - HCL client
On Tue, 2006-01-17 at 11:50 +0100, Joerg Schilling wrote: Erast Benson [EMAIL PROTECTED] wrote: On Mon, 2006-01-16 at 14:38 +0100, Joerg Schilling wrote: Bruce Riddle [EMAIL PROTECTED] wrote: How about a really intelligent parser of prtconf -pv output. Dan Micks prtpci does already a lot I know about this wrapper. But lspci is what every GNU/Linux system has today and it is fully ported to Solaris, which makes prtpci obsolete. IMHO I cannot find a port for Solaris. you could grab it from Nexenta SVN. And BTW: I would guess that lspci (in contrary to prtpci) needs root privileges.. True. But main point is popularity: Google: lspci - 611,000 prtconf - 79,100 prtpci - 201 ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] NexentaOS (elatte) Alpha 2 released
On Mon, 2006-01-30 at 15:36 -0800, ken mays wrote: Thanks for a wonderful OpenSolaris distro. i only have two concerns right now: 1. Mesa 6.4.1 If you do not see it at http://packages.ubnutu.com than we don't have it yet... We are planning to move on Xorg 7.0 in the next few months or so as of Ubuntu/Dapper will stabilize its packaging a bit. 2. LiveCD ? Should be available soon, but who needs it anyway when our installer is so cool these days? You could even play Tetris in the middle of installation process. Just kidding... :-) -- Erast ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Google OS should be OpenSolaris
On Wed, 2006-02-01 at 12:22 +1300, Glynn Foster wrote: Out of curiousity, anyone keeping track of what Ubuntu have done to become the Linux distribution of choice? From every conversation I've had with Jeff, he indicates they're not a development team [1] and they've only been doing some smart integration. An interesting marketing study at the very least. As always, there is no simple answer. But I think the keys of today's Ubuntu popularity are: * GNU and Debian-based with 2000+ free developers doing just packaging and integration work; * Great Humanity idea; * Lucky Mark Shuttleworth with his team of the best Debian folks; * Right timing. We have almost all the technology in Solaris too, we probably just need to do a better job at a) integrating it b) making it look good c) talking about it. Its not enough... IMHO. -- Erast ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Google OS should be OpenSolaris
On Tue, 2006-01-31 at 20:49 -0300, Ignacio Marambio Catán wrote: The last part of the puzzle are little projects like roseta, they make those users without programming skills feel like they are usefull to the community while saving the tedious work of for example translating to a new language some of the system components. I think this last part is the key, they make their users feel usefull and it's also the main reason I think the Article project is important too It is very could be the key. Let me share page of our new HackZone member: http://www.gnusolaris.org/gswiki/EdwardCho He did contribution via integrated Launchpad translations (i.e. you left click on GNOME panel or go to Help - Translate via Launchpad). Also he is interested in NexentaOS mostly because of DTrace and just out of curiosity... -- Erast ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] NexentaOS running OpenOffice 2.0.1
OpenOffice 2.0.1 Screenshot: http://www.gnusolaris.org/gswiki/ErastBenson?action=AttachFiledo=gettarget=ooo2screenshot.png Other screenshots: http://www.gnusolaris.org/gswiki/ErastBenson OpenOffice suite is fully integrated with MIME and NexentaOS GNOME/KDE menus. For Alpha 2 users to install OpenOffice2 complete next command: $ sudo apt-get install openoffice.org2-nevada Enjoy! -- Erast ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Bellinix Distro for Linux Format Magazine promotion
On Thu, 2006-03-02 at 01:44 +0530, Moinak Ghosh wrote: Eric Boutilier wrote: My 2 cents: We (Sun and the opensolaris community) should be impartial and treat BeleniX, SchilliX, and Nexenta equally in this regard. I realize there are space constraints, but... True. An idea that has been used effectively in the Linux community is to have a Multiboot DVD that contains all the 3 OpenSolaris distros. Since all three are single CD ones, all of them will fit into less than 2GB space leaving the remaining for other stuff. I already have mental map of the process to create this Multiboot DVD and can help with creating this. I like the idea and agreed that all Baby OpenSolaris distros needs this sort of promotion among Linux users. -- Erast ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Bellinix Distro for Linux Format Magazine promotion
NexentaOS LiveCD will take less than 700MB(extracted) of DVD space. Thanks. On Wed, 2006-03-01 at 19:54 -0500, Laura Ramsey wrote: +1 Question: Can we get an estimate of how big that would be? Need to find out about space on DVD, constraints, etc. Anyone got a SWAG? And would we have some room to include install notes from Dennis Clarke... LKR Erast Benson wrote: On Thu, 2006-03-02 at 01:44 +0530, Moinak Ghosh wrote: Eric Boutilier wrote: My 2 cents: We (Sun and the opensolaris community) should be impartial and treat BeleniX, SchilliX, and Nexenta equally in this regard. I realize there are space constraints, but... True. An idea that has been used effectively in the Linux community is to have a Multiboot DVD that contains all the 3 OpenSolaris distros. Since all three are single CD ones, all of them will fit into less than 2GB space leaving the remaining for other stuff. I already have mental map of the process to create this Multiboot DVD and can help with creating this. I like the idea and agreed that all Baby OpenSolaris distros needs this sort of promotion among Linux users. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org -- Erast ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Bellinix Distro for Linux Format Magazine promotion
btw, Laura, what is the deadline for this brothers DVD? And thanks for doing this! On Wed, 2006-03-01 at 19:54 -0500, Laura Ramsey wrote: +1 Question: Can we get an estimate of how big that would be? Need to find out about space on DVD, constraints, etc. Anyone got a SWAG? And would we have some room to include install notes from Dennis Clarke... LKR Erast Benson wrote: On Thu, 2006-03-02 at 01:44 +0530, Moinak Ghosh wrote: Eric Boutilier wrote: My 2 cents: We (Sun and the opensolaris community) should be impartial and treat BeleniX, SchilliX, and Nexenta equally in this regard. I realize there are space constraints, but... True. An idea that has been used effectively in the Linux community is to have a Multiboot DVD that contains all the 3 OpenSolaris distros. Since all three are single CD ones, all of them will fit into less than 2GB space leaving the remaining for other stuff. I already have mental map of the process to create this Multiboot DVD and can help with creating this. I like the idea and agreed that all Baby OpenSolaris distros needs this sort of promotion among Linux users. -- Erast ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Driver Porting Question
On Thu, 2006-03-09 at 16:49 +, Darren J Moffat wrote: GPL as a standalone driver written to the Solaris DDI shouldn't be a problem as long as it stays under the GPL. However there isn't much change of that becoming part of the official OpenSolaris source tree unless someone discovers how to combine GPL and CDDL sources (one being project based the other being file based) without breaking the licenses. And this brings an interesting topic. Whether GPL-licensed OpenSolaris driver could be legally shipped as a separated package within an OpenSolaris-based distribution like NexentaOS? My wild guess is that it would be OK. If Sun wants more contribution from folks who ports GPL drivers = OpenSolaris, I think it needs to be clarified by Sun lawyers somewhere in the publicly available FAQ. -- Erast ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Fresh man from ShenYang China
Usually fresh man loves to start hacking OpenSolaris at http://www.gnusolaris.org Just follow download instructions, setup the machine and enjoy! On Tue, 2006-03-14 at 05:45 -0800, Zhigang Yao wrote: I want to attend into the Open Solaris Projects.But,I am a fresh man.So I have a simple problem---What can i do for this?Hope reply.Thank you. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org -- Erast ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Driver Porting Question
On Thu, 2006-03-16 at 16:22 +0100, Joerg Schilling wrote: Erast Benson [EMAIL PROTECTED] wrote: On Thu, 2006-03-09 at 16:49 +, Darren J Moffat wrote: GPL as a standalone driver written to the Solaris DDI shouldn't be a problem as long as it stays under the GPL. However there isn't much change of that becoming part of the official OpenSolaris source tree unless someone discovers how to combine GPL and CDDL sources (one being project based the other being file based) without breaking the licenses. And this brings an interesting topic. Whether GPL-licensed OpenSolaris driver could be legally shipped as a separated package within an OpenSolaris-based distribution like NexentaOS? Why do you still believe that there is a difference between things distributed together with OpenSolaris and things distributed separately? You removed my other statement from original e-mail: My wild guess is that it would be OK. i.e. as I said, I do believe that it would be OK. i.e. no difference. :-) The only limitation for such a driver would be the fact that it will never become part of ON bits. Which is totally OK (taking in account of existence and stability of Solaris DDI interfaces). As a side note: for Linux kernel this code separation will *never* work since Linux and its development team doesn't care about such a drivers. Maintaining separated drivers for Linux kernel is extremely painful work and requires a lot of workers (examples VMware drivers) which small OSS project just can not afford. -- Erast ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Driver Porting Question
On Thu, 2006-03-16 at 13:29 -0800, Rich Teer wrote: On Thu, 16 Mar 2006, Erast Benson wrote: As a side note: for Linux kernel this code separation will *never* work since Linux and its development team doesn't care about such a drivers. Maintaining separated drivers for Linux kernel is extremely painful work and requires a lot of workers (examples VMware drivers) which small OSS project just can not afford. ALl the more reason for those driver developers to abandon Linux and target OpenSolaris! Indeed! The question is what we can do to speed up the conversion? I feel like not all of Linux kernel folks even understand the beauty of stable kernel interfaces. I feel like we (OpenSolaris community) need to educate independent Linux developers in this regard. What if Sun will start thinking about organization of some sort of free kernel seminars or summits like OpenSolaris Kernel Summits, where in addition to discussing future kernel development, developers could be educated for free, etc. -- Erast ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Driver Porting Question
On Mon, 2006-03-20 at 12:16 +1200, Glynn Foster wrote: Hi, On Thu, 2006-03-16 at 14:40 -0800, Erast Benson wrote: ALl the more reason for those driver developers to abandon Linux and target OpenSolaris! Indeed! The question is what we can do to speed up the conversion? I feel like not all of Linux kernel folks even understand the beauty of stable kernel interfaces. I feel like we (OpenSolaris community) need to educate independent Linux developers in this regard. What, are you kidding me? ;) http://lwn.net/Articles/173209/ Stable: Interfaces classified as stable will not break 'for at least two years', and probably quite a bit longer. The Linux system call interface is classified in this way [see the ABI stability documentation section] So, what? :-) What is your point exactly? these talks on lkml to make kernel API stable been for years... so far little really happening in this regard, especially when you start to consider to write driver for multiple distros, i.e. SuSE, RedHat, Ubuntu, etc.. May be LSB 3.x will change this? But I think it will take quite a bit of time before every single distro vendor will follow the LSB instructions. -- Erast ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Features found in other OS you'd like to see in Solaris
On Wed, 2006-03-22 at 08:17 -0800, Alan Coopersmith wrote: Nenad Cimerman wrote: I'd like to have virtual consoles like the ones Linux has (at least on x86). There's a team at Sun working on this - they should be submitting an OpenSolaris project proposal soon to bring this out into the open. Sounds promissing! And I always wanted to have a mouse support in console, ala gpm(Linux) and moused(BSD). Kernel support is needed. Description: General Purpose Mouse Interface This package provides a daemon that captures mouse events when the system console is active, and delivers events to applications through a library. . The default when no application is running is to emulate selection, that is, to allow cut-and-paste with the mouse on the console the same way as it is done under X. -- Erast ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Features found in other OS you'd like to see in Solaris
On Wed, 2006-03-22 at 12:08 -0500, Bill Rushmore wrote: OK, not really a feature necessarily of Solaris but more of an application. I really want VMware (or its equivalent), especially since the SUNpci card is becoming obsolete on Sparc and there really isn't an alternative on x64 yet. BrandZ is a nice idea but I need to run a popular non-Unix like OS. QEMU 0.7.x? though it is too slow. To speed it up, we might need to develop a kernel acceleration module for solaris. -- Erast ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Features found in other OS you'd like to see in Solaris
On Wed, 2006-03-22 at 10:53 -0800, Alan Coopersmith wrote: Erast Benson wrote: And I always wanted to have a mouse support in console, ala gpm(Linux) and moused(BSD). Kernel support is needed. It's already there in Solaris SPARC, where graphics cards have in kernel frame buffers with ioctls to draw the cursor - it's just not well known and pretty much only used by the X server. I've got a bit of code tucked away here that I used to test the hwc (hardware cursor) module from console mode to load the cursor and have it track the mouse around the SPARC console screen - you could also do it without hwc by having the application be responsible for the cursor updates itself. (hwc is just an optimization - it's a streams module that Xsun pushes on top of the mouse module that takes the movement events from the mouse and makes direct calls to the frame buffer driver to move the hardware cursor image, completely in kernel space without having to wait for the mouse event to go up to the X server, wait for the X server process to get a time slice and then to get to the right point in the code to process it and then send it back down to the fb driver in the kernel. It won't be in the initial OpenSolaris X code drop, but may be in a later one.) This is a nice feature. But this is not what I wanted. I'd like to have some way to distribute cooked mouse events to text only applications, like screen, ncurses-based apps, generic console, etc. -- Erast ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Features found in other OS you'd like to see in Solaris
On Wed, 2006-03-22 at 11:29 -0800, Alan Coopersmith wrote:
Erast Benson wrote:
This is a nice feature. But this is not what I wanted. I'd like to have
some way to distribute cooked mouse events to text only applications,
like screen, ncurses-based apps, generic console, etc.
You'ld just need to put code into curses or another library to read the
VUID events from /dev/mouse, which are pretty cooked already. All the
details of handling USB vs. PS2 vs. SPARC serial mouse are hidden in the
kernel modules, as is handling multiple mice in S10U1 Nevada, and all
you need to know is to open /dev/mouse and read the motion and button
events.
For example, if you look in Xorg 6.9's Solaris mouse code in
xc/programs/Xserver/hw/xfree86/os-support/sunos/sun_mouse.c
the event decoding is simply reading from /dev/mouse in chunks
the size of the Firm_event defined in sys/vuid_event.h and
parsing the simple event types:
if (pVuidMse-event.id = BUT_FIRST pVuidMse-event.id =
BUT_LAST)
{/* button */
int butnum = pVuidMse-event.id - BUT_FIRST;
if (butnum 3)
butnum = 2 - butnum;
if (!pVuidMse-event.value)
buttons = ~(1 butnum);
else
buttons |= (1 butnum);
} else if (pVuidMse-event.id = VLOC_FIRST
pVuidMse-event.id = VLOC_LAST) {
/* axis */
int delta = pVuidMse-event.value;
switch(pVuidMse-event.id) {
case LOC_X_DELTA:
dx += delta;
break;
case LOC_Y_DELTA:
dy -= delta;
break;
case LOC_X_ABSOLUTE:
if (absXset) {
vuidFlushAbsEvents(pInfo, absX, absY, absXset,
absYset);
}
absX = delta;
absXset = TRUE;
break;
case LOC_Y_ABSOLUTE:
if (absYset) {
vuidFlushAbsEvents(pInfo, absX, absY, absXset,
absYset);
}
absY = delta;
absYset = TRUE;
break;
}
}
Should be trivial to translate into the appropriate code in curses or similar
libraries. There's even events for wheels on wheel mice.
Thanks a lot for explanation of implementation internals!
It seems like to make majority of console applications happy and avoid
their code modifications, we might want to add solaris support to gpm or
moused package.
Is somebody on the list willing to hack on it? I will be happy to try to
push a proposed solution to the next release of NexentaOS.
--
Erast
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: VMWare (Was: Features found in other OS you'd like to see in Solaris)
On Fri, 2006-03-24 at 11:35 -0600, Eric Boutilier wrote: http://freshmeat.net/projects/parallels/?branch_id=60855release_id=223137 It's not free though -- costs $50.00. OTOH there's a free trial version. Their product only supports Solaris/Guest, AFAIK. What if we will send a community on-line petition to them and ask about Solaris/Primary OS version of the product? I doubt VMware will do that, but Prallels looks like a competitor of VMware, so they might be interested. So, lets use our chance. :-) -- Erast ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] hwdb is ported to NexentaOS
Hi Guys, I just wanted to let you know that I fully ported (fixed some bugs, added some features) and integrated HWDB client and server backend into NexentaOS. It will be an integral part of upcoming Alpha 4 release. Screenshots: http://www.gnusolaris.org/gswiki/ErastBenson/HWDB_screenshots -- Erast ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Nexenta Alpha 4 ZFS
On Thu, 2006-03-30 at 14:50 -0800, ken mays wrote: The latest release of Nexenta sports Nevada b36 which contains the newer patches to ZFS as well as 52 bug fixed since the previous Alpha 3 release. yeah... for ZFS, we need to fix GNU du http://www.gnusolaris.org/cgi-bin/trac.cgi/ticket/280 may be someone from ZFS team willing to take a look? Thanks. -- Erast ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: Why LSB filesystem layout is bad, part 1 ... / was: Re: [osol-discuss] Re: Re: Re: Proposal to remove /usr/sfw anditsdependencies from the bas
On Fri, 2006-03-31 at 15:36 -0500, Chris Ricker wrote:
On Fri, 31 Mar 2006, Roland Mainz wrote:
My personal complaint is that they stuff everything into /usr/bin/. Unix
had some kind of namespace support via the elements in ${PATH} so
having package groups seperated into /usr/dt/bin/ (CDE), /usr/kde3/bin
(KDE3), /usr/xpg4/bin/ (XPG4 personality) and so on is a much cleaner
approach than stuffing everything into /usr/bin/. Same applies to
${MANPATH}.co. There is no real way anymore to set/override/disable
things since it's now all in /usr/bin/. In my experience as an
adminstrator with many users (who all have different requirements) this
design is VERY VERY bad in real life.
1000s of programs in /usr/bin sucks, but it does offer two benefits over
the Solaris shove everything in a different obscure dir style:
may I ask what is wrong with 1000+ programs in /usr/bin ? As far as
performance is concerned, this directory usually cached out. What else?
--
Erast
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Why LSB filesystem layout is bad,part 1 ...
On Mon, 2006-04-03 at 10:47 +0200, Joerg Schilling wrote: Erast Benson [EMAIL PROTECTED] wrote: On Sun, 2006-04-02 at 16:32 +0200, Joerg Schilling wrote: Erast Benson [EMAIL PROTECTED] wrote: There is more than disliking it. If e.g. 'rsh' is linked to 'ssh', people do not get what they expect. this is depends on alternative's weight... if rexec tools are not installed, ssh may still provide rsh functionality. It is not. it may be configured differently, but ssh definitely provides you a basic rsh functionality. I am not sure whether you understand the effects of these alternatives. Sure it might create an ambiguity effect, but there are mechanisms which helps you to avoid that. (alternative's weight in this case) In your example, most likely, rsh been created because it didn't exist at the time when ssh were installing. rsh has a higher weight, therefore, once you install rsh package, it will overwrite rsh alternative to the one with higher priority, i.e. real rsh. There are other management mechanisms, like alternative's slaves, which also quite handy and help you to avoid ambiguity but now for slave things like dependent directories with similar names, etc. The end result of alternatives is better user and developer experience and this is what makes Debian-based systems most suitable for developers. I still do not understand your concerns, and positive that alternatives is a good thing, but it takes time till people actually will start to appreciate it. -- Erast ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Project proposal: Nevada Companion Software
On Mon, 2006-04-17 at 16:23 -0700, Alan DuBoff wrote: However, what I personally would like to see is the same thing I've always invisioned from the days of yesteryear...That we could have a full distribution that rivaled any of the open source distributions with Solaris as our core, rather than Linux (Debian specific, or shall we say apt functionality). Who would have thought Solaris would become open sources, the thought was laughable 4+ years when the topic surfaced. OK. Just to prevent an idea of splintering of Debian+OpenSolaris (i.e. NexentaOS) community. :-) Lets try to avoid a creation of yet another Debian+OpenSolaris community at the moment. Instead work with Nexenta guys to implement what you want. Here is what is going on in NexentaOS camp. Our package database now contains 3800 Debian packages out of 2 available. We soon planning automated import-recompile of huge chunk of missing packages at the point when core main packages will be fully integrated. The process could be monitored[6]. It might happen with Alpha 5 release, but nobody knows at this point. Last month we made significant progress with Debian/Ubuntu communities cooperation. With Debian we are pushing[1] solaris-i386,sparc architecture upstream for dpkg, apt-get, debhelper, debianutils, etc. With Ubuntu we are sharing the same web-portal to track cross-distro-bugs[2]. Launchpad has 300.000+ registered users and developers which contributes to Ubuntu community. Launchpad trying to coordinate development efforts among various distributions. With Ubuntu we are initiated SMFication project[3] which intention to come up with database of manifests script for Ubuntu(and eventually Debian) packages. The project found a warm support from Ubuntu developers community[4]. The was a proposal to come up with GNU/Linux SMF port. Join[5] Debian+OpenSolaris community today and help us to build a distro of your dream! [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=361866 [2] https://launchpad.net/distros/nexenta [3] https://launchpad.net/projects/smf-nexenta [4] http://archives.free.net.ph/thread/20060414.201222.b0bd44c4.en.html [5] http://www.gnusolaris.org/gswiki/UserPreferences [6] http://www.gnusolaris.org/dapper.status -- Erast ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Project proposal: Nevada Companion Software
On Tue, 2006-04-18 at 13:26 +1200, Glynn Foster wrote: Hi, On Thu, 2006-04-13 at 14:52 -0500, Eric Boutilier wrote: Another +1 here. And for another huge reason why it's important to go hash it out ASAP, consider the build systems that the other distros are planning/doing for freeware apps: - The SchilliX project plans to implement the SchilliX build system (SPS) - The Belenix project plans to implement the pkgsrc build system. - The Nexenta project already implements a Debian build system (with _huge_ success I might add). IMO, these distros are critically important to a goal we all share; namely, to increase the popularity of OpenSolaris among the broader worldwide open-source/UNIX/Linux community. Yet none of them has endorsed either the Companion or Blastwave. +1 I personally believe its fundamentally important to have a shared infrastructure available that allows people to easily create a tailor made distribution of their own choice based on OpenSolaris technology. What Debian/Ubuntu have done is freaking cool, and we have an ideal opportunity to implement something similar with less complication. From my experience, I found that real value behind Debian is NOT dpkg/apt-get/etc, but its huge, growing and successful community. -- Erast ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Project proposal: Nevada Companion Software
On Tue, 2006-04-18 at 14:50 -0700, Philip Brown wrote: On Mon, Apr 17, 2006 at 11:02:20PM -0700, Erast Benson wrote: On Mon, 2006-04-17 at 22:08 -0700, ken mays wrote: Going back to the comments about Nexenta build system: Nexenta build system == Debian build system The equation above means that NexentaOS following Debian Policy[1] as close as possible. This is done on purpose. Since a) we now can collaborate with Debian community and push our changes upstream; b) we can easily migrate huge amount of packages under NexentaOS APT repository. The thing about all that, is that it forces the machine to be closer and closer to a linux machine, until eventually, it becomes nothing more than a linux machine with a user-invisible solaris kernel. with DTrace, ZFS, Zones/BrandZ, Kernel DDI... nope. it will not be that user-invisible as you might think. In constrast, one of the core (unwritten, I guess) principles about packaging at blastwave, is to provide all the free stuffs, while still keeping everything firmly sticking to SOLARIS/SVR4 policy. Not Debian policy. We are talking about build system here. SVR4 is not something which is covered by Debian Policy. And after all, it is you personal opinion, so I'm fine with it. -- Erast ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Project proposal: Nevada Companion Software
On Tue, 2006-04-18 at 16:14 -0700, Philip Brown wrote: On Tue, Apr 18, 2006 at 05:54:15PM -0500, Eric Boutilier wrote: Philip Brown wrote: The thing about all that, is that it forces the machine to be closer and closer to a linux machine, until eventually, it becomes nothing more than a linux machine with a user-invisible solaris kernel. Gong! -- You violated my pet peeve -- one of the two[1] flagrant abuses of the word Linux. Your punishment: 1000 sentences: Nexenta boxes are Debian/Nevada machines, they are not Linux machines. Nexenta boxes are Debian/Nevada machines, they are not Linux machines. Pffft... everyone here understands what is meant, and it's a lot easier than trying to describe, closer to 'one of those types of machines that is based around what is commonly called a linux distribution, and/or a Linux Standards Base compliant system in addition to adhering to all the system-administration admin level issues, which may or may not be specified in the LSB mentioned hereabove Yes, NexentaOS will be a bit closer to LSB than Solaris. But this is a *good* thing taking into account how popular GNU/Linux platform today. Meanwhile, SVR4-compliant apps/scripts will run too, since underneath we still have a shiny OpenSolaris core. -- Erast ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Project proposal: Nevada Companion Software
On Tue, 2006-04-18 at 18:19 -0700, Alan DuBoff wrote: On Monday 17 April 2006 05:20 pm, Erast Benson wrote: On Mon, 2006-04-17 at 16:23 -0700, Alan DuBoff wrote: However, what I personally would like to see is the same thing I've always invisioned from the days of yesteryear...That we could have a full distribution that rivaled any of the open source distributions with Solaris as our core, rather than Linux (Debian specific, or shall we say apt functionality). Who would have thought Solaris would become open sources, the thought was laughable 4+ years when the topic surfaced. OK. Just to prevent an idea of splintering of Debian+OpenSolaris (i.e. NexentaOS) community. :-) Lets try to avoid a creation of yet another Debian+OpenSolaris community at the moment. Instead work with Nexenta guys to implement what you want. Sure, and blastwave would like us to work with them so there is no loss in their camp either, as would the gentoo folks, the pkgsrc folks, and others as well. It looks like there is a bit of misunderstanding here. Blastwave problem has little to do with NexentaOS. In fact, we don't even have those problems at all since NexentaOS developed from ground up whereas Blastwave pretty much relying on Solaris. Join[5] Debian+OpenSolaris community today and help us to build a distro of your dream! You folks have done a great job at merging Debian with OpenSolaris, I commend you for that. We need to think about the big picture, and that includes a lot of other players. If it is at all possible to create a system that would not only please you folks, but Blastwave, pkgsrc, or gentoo as well, all the better IMO. Sounds impossible at first glance... What do you have in mind? -- Erast ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] OpenSolaris distros collaboration by using launchpad.net
Guys, I were thinking on what would be beneficial for every camp involved into OpenSolaris and related development? What would be useful for NexentaOS, BeleniX, SchilliX, marTux, SCXR, etc ? I think having centralized place (bugzilla, bounty, project management, calendar, etc) for OSS packages would be really beneficial for every camp involved. I came across launchpad.net[1] and I think it could be a really great idea to utilize it for OpenSolaris community. NexentaOS is already registered[2] there, the same way we could register opensolaris-generic and other distros where we could collect all our patches and together collaborate on ongoing issues. Few great things about launchpad (as I see it): 1) It could coexist with existing bug-tracking systems, i.e. we don't have to change NBTS to Malone for instance and re-integrate our internal stuff; 2) It provides integrated bounty[3] system. So end user potentially could pay cache for particular fix in his favorite distro; 3) Its well done. [1] http://launchpad.net [2] http://launchpad.net/distros/nexenta [3] http://launchpad.net/bounties -- Erast ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Google Summer of Code idea
On Thu, 2006-04-20 at 18:15 -0400, Roberto J. Dohnert wrote: Im about to say a cuss word in the Solaris world and Im prepared for whatever flak, insults and grenades that happen to come my way. Is there any interest at all to port Mono, yes the Novell .NET Framework implementation, to OpenSolaris and Solaris x86? This would be helpful in the desktop push and leverage many .NET developers who may want to make their software work in OpenSolaris as well without having to port the code to Java. It runs[1] on NexentaOS - Debian-based GNU/OpenSolaris[2]. In Alpha 5 we are integrating beagle into nautilus and gnome-applets, Alpha 5 is going to based on Ubuntu/Dapper Beta1[3]. [1] http://www.gnusolaris.org/gswiki/ErastBenson [2] http://www.gnusolaris.org [3] https://wiki.ubuntu.com/DapperBeta -- Erast ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] OpenSolaris distros collaboration by using launchpad.net
On Tue, 2006-04-25 at 13:52 -0500, Eric Boutilier wrote: Moinak Ghosh wrote: Erast Benson wrote: Guys, I were thinking on what would be beneficial for every camp involved into OpenSolaris and related development? What would be useful for NexentaOS, BeleniX, SchilliX, marTux, SCXR, etc ? I think having centralized place (bugzilla, bounty, project management, calendar, etc) for OSS packages would be really beneficial for every camp involved. I came across launchpad.net[1] and I think it could be a really great idea to utilize it for OpenSolaris community. NexentaOS is already registered[2] there, the same way we could register opensolaris-generic and other distros where we could collect all our patches and together collaborate on ongoing issues. I browsed through the launchpad.net site. It looks like a very useful resource. In fact I have to put up a open subproject page and track status. I guess launchpad will provide a good framework for doing this rather than having to maintain and keep updating a static HTML page. In general there are bugs that will be common to distros. These can be tracked to avoid duplication of effort by the various distros. This is a good opportunity to collaborate. I will register the BeleniX project. Regards, Moinak. Erast, Moinak -- Is launchpad maybe a place where participating projects could work on standardizing auxilliary[1] FOSS libraries? Standardizing FOSS libraries? An example? AFAIK, its a good place to keep track changes across various distros. But not only for libs, for apps too, like security fixes for Firefox, Mozilla, OpenOffice, Gaim, etc.. Another attractive thing is its Bounty system. Basically, end user could assign his price for particular bug or feature in particular package/distro. After that, developer and user will get in touch, and once feature implemented, developer will be paid off. Eric [1]: A set of key libraries that are currently being maintained separately by most (all?) distros and ports systems because they are not part of Nevada -- or they are in Nevada but deemed unsatisfactory. Few great things about launchpad (as I see it): 1) It could coexist with existing bug-tracking systems, i.e. we don't have to change NBTS to Malone for instance and re-integrate our internal stuff; 2) It provides integrated bounty[3] system. So end user potentially could pay cache for particular fix in his favorite distro; 3) Its well done. [1] http://launchpad.net [2] http://launchpad.net/distros/nexenta [3] http://launchpad.net/bounties ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org -- Erast ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Project proposal: GUI SMF Tools
On Tue, 2006-04-25 at 22:40 -0700, changho.kim wrote:
Solaris have tools to control service by system.
That's called SMF
This is important role of self healing but every solaris beginner have
difficulty in input command by keyboard.
if user don't familiar with keyboard, they want GUI program.
So I propose this project
Make GUI SMF program!!
How about to extent gnome-system-tools system-tools-backends which
been integrated into NexentaOS recently? The are already provide
simplistic GUI[1] for SMF and other configuration management stuff like
Wifi/LAN confiugration, NFS/Samba, etc with unified {front,back}ends.
I know some folks porting GST STB to Solaris now.
[1] http://www.gnusolaris.org/gswiki/ErastBenson/STB_screenshots
--
Erast
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Project proposal: GUI SMF Tools
On Wed, 2006-04-26 at 01:31 -0700, Bob Palowoda wrote: On Tue, Apr 25, 2006 at 10:40:18PM -0700, changho.kim wrote: Solaris have tools to control service by system. That's called SMF This is important role of self healing but every solaris beginner have difficulty in input command by keyboard. if user don't familiar with keyboard, they want GUI program. So I propose this project Make GUI SMF program!! Though the ultimate goal is to do a lot more, the prototype for the Visual Panels project (screenshots, demo, and source at http://www.opensolaris.org/os/project/vpanels/ currently contains a basic SMF GUI. Please check it out and let us know what you think. This stuff looks great. And it's a good candidate for the justification of the ARC case to be public for OpenSolaris. Don't you think using Java for this kind of things a bit of overhead? Its not like this app will be running on OSX or Windows.. why bother with Java then? Besides to do simple management thingy natively you need an extra layer, like JNI... I don't think its the right way to go frankly... :-) -- Erast ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: Project proposal: GUI SMF Tools
On Wed, 2006-04-26 at 02:22 -0700, Bob Palowoda wrote: Don't you think using Java for this kind of things a bit of overhead? Its not like this app will be running on OSX or Windows.. why bother with Java then? Besides to do simple management thingy natively you need an extra layer, like JNI... I don't think its the right way to go frankly... :-) Define overhead. Lack of performance, memory footprint, startup runtime, or just plain something not written in C is considered overhead. It's not like startup runtime is a big factor as you don't run system maintance all the time. Memory is cheap, look at KDE written in C++ and it's nice performance but memory consumption might be a little more. In fact the java framework might be more advantagoues to any gui desktop and more flexable in managing a enterprise remotely. Something has got to change because SMC is *NOT* accpetable from a usablity standpoint. Could SMC be improved like Darren pointed out? Maybe but that would be resolved in the ARC case. Also note that in the discussions a few times the project was refered to as a Solaris project when it should have been refered to as a OpenSolaris project with a well known path of source distribution for all OpenSolaris distributions. Either that or a roadmap. Hey! I didn't want to start this flame.. :-) But I really do not see how Java fits in OS management GUI were you don't really need its multi-platform capabilities and associated difficulties. -- Erast ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [osol-mktg] Upcoming Anniversary Activities for OpenSolaris User Groups
Oh, another thing I'd like to add. Ubuntu community very concerned about whether to ship their ISOs as DVD or as CD media. They claim (and I think it is very true) that a lot of their potential users still do not have DVD drive and will not have for a long time. I think the requirement would be to ship only distributions which fits on a single CD media, otherwise we will automatically loose some percentage(may be significant) of audience. Erast On Wed, 2006-04-26 at 14:36 -0500, Sara Dornsife wrote: I like the idea a lot. We don't have the Band of Brothers ISO yet though. We do have what Stephen Lau has been handing out which is based on the Solaris Express Community Edition. Would that work? Any ideas on how many we might go through in a given month? We can make the ISO and DVD artwork available on line so that they can be produced anywhere by anyone who would like to. Is this proposal in addition to the other suggestions, or in place of? Laura had suggested a worldwide user group effort. Are you thinking that that isn't a good idea? Any of the others? Sara Erast Benson wrote: On Wed, 2006-04-26 at 02:19 -0300, Ignacio Marambio Catán wrote: I think we should do what we do best, give away software, I know what I'm about to say is a bit impossible because of the time constraints, cost and others. Do we still have that band of brothers DVD? I was thinking about giving it away, shipping it even, everywhere, for free, yes, ubuntu like to everyone that visits the www.opensolaris.org web site. We could even include in the DVD the happy birthday song and change the cover of the DVD to something more suitable for the ocation :) ohh, and we need a birthday banner for the site :P +7 :-) That is the best idea to promote OpenSolaris so far I heard on this forum. It works really really well for promoting Ubuntu and I don't see why it will not work for us. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org -- Erast ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Project proposal: GUI SMF Tools
On Wed, 2006-04-26 at 15:19 -0700, David Powell wrote: On Wed, Apr 26, 2006 at 01:45:35AM -0700, Erast Benson wrote: Don't you think using Java for this kind of things a bit of overhead? Its not like this app will be running on OSX or Windows.. why bother with Java then? We actually think it would be really valuable for people to be able to configure an OpenSolaris box from another machine using the same interface they're accustomed to using on console. You could accomplish this with a web-based interface, but that'd be pretty unfriendly to the original desktop user. Why not just to use VNC or similar simple stuff for that matter? Besides to do simple management thingy natively you need an extra layer, like JNI... I don't think its the right way to go frankly... :-) Have you ever tried using libscf? Some sort of layer is needed; making it a Java layer means it's useful to a much broader audience. We actually have two layers: a set of SMF classes, and a layer of JMX. This means other management tools can theoretically plug into what we've done without a lot of additional effort (more importantly, without needing to duplicate work we've already done). (All of this is covered on the Visual Panels page, BTW.) If Java would be a part of ON, than it would probably will make sense. Until that time, I'm not sure it fits nicely. IMO -- Erast ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: where to start?
On Tue, 2006-05-23 at 17:24 +1200, Matthew Gardiner wrote: On Monday 22 May 2006 21:13, you wrote: Matthew Gardiner [EMAIL PROTECTED] wrote: If you expect a nice OS with a rich set of features, Solaris is the right way to go but then you should not expect everything from the GUI at the same time. Once the growing acceptance of Solaris did attract more developers, you will see the GUI features too, but I expect this to happen in 1-3 years and not on 2006. I don't expect everything to be available via a GUI, but I do expect that there is a decent printer configuration tool; that SUN get with the programme, lynch that POS that is lp, and replace it with something from the 21st century, namely CUPS coupled with GIMP-Print and friends. Did you ever try JDS? It includes what you are looking for. Ah, the wonderful, buggy, slow and problem prone Java based printer manager - no thank you. It might also help if SUN updated their drivers as well. Also, it would be nice to be able to sync up music - I mean, I know this 'ipod' thing is a bit of a 'niche market' - I mean, there are only a few million of them out there, but if SUN programmers could spare a bit of time from their, well, what ever they do, could they atleast *attempt* to provide a way for this to be a possibility. Geeze, when I see the deficiencies in Solaris 10, I am tempted to write a thesis on 'why Solaris sucks' - it seem that out of the 30,000 people employed at SUN, there isn't even *ONE* person with a *CLUE* about designing and operating system that is pleasent to use! If you believe to know hot to do it, do it I've got better things to do with my time that pointing out the bloody obvious to a company who is unwilling to listen. When in a company of 30,000 there isn't a single person trying to grab Solaris by the balls and dragging it kicking and screaming into 2006 in terms of end user usability, its a sad day indeed. Hey, don't be sad! OpenSolaris is open at last... join distribution you like and help us make it better. Want usability... this is Nexenta's goals, wants compatibility, this is SchilliX goals, wants idealistic perfection, this is BeleniX goals... or create something you will like. I don't think blaming Sun will help at this point. OpenSolaris code is ours now. Go ahead use it. Make it better and enjoy the life. -- Erast ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Software for Solaris (was Re: Adobe Acrobat for Solaris x86)
On Sun, 2006-05-28 at 03:49 -0700, ken mays wrote: Hello, Seems like the previous post from Matty mentions more of the 'commercial' applications moreso than the open source ones. This is more of a developer support stance from the corporate 'commercial' ISVs/IHVs. Getting Solaris into the hands of the right commercial developers, supporting those developers, and making sure the developers have enough developer-type documentation to get the job done [i.e. to port/migrate the apps to Solaris with minimal fuss]. Right. The question is how to attract developers to start porting their apps on OpenSolaris? I think documentation and Sun-support forums are not enough. In addition, we need to create(and populate) a truly developer-oriented environment. i.e. Operating System for OpenSolaris developers. Where developer will enjoy creating its art while spending big chunk of his life. I think it is important to understand. From this stand point, GCC-like and GNU-like environments are must to have and we are moving this road... aka NexentaOS GNU/OpenSolaris. A few ISVs for Sun Solaris x86 ported 'commercial' software and application suites to Solaris - yet it takes time to get build environments in place. Also, the conflict of interest in which frameworks/APIs to use over the other. Saying you want certain application suites and application software for Solaris is really saying you want the software/hardware dependencies taken care of as well. Then, there is the software maintenance issues... Yet, a lot of this was discussed between Solaris developers/consultants and Sun many times over at developer conferences, forums, and web talks. Basically, it is the corporate companies hiring and/or training their developers to migrate their products to Sun Solaris (all platforms) which they might deem as 'profitable' or just supportive to their customers. Sun may just provide influence and portfolios on Solaris end-users that are requesting certain commercial applications on Solaris. There are the other issues in play, yet I'll let someone else elaborate on those ~ Ken Mays Hi Kaiwai et al, If you want to see software for Solaris x86/x64 you should consider having a look to NexentaOS http://www.gnusolaris.org Erast and Alex are working really hard to build all software using GCC. 9000+ packages now... I must confess that i started to build/patching/porting OpenOffice.org using GCC and encountered several problems in GCC (3.4.x)... so i ended up building OpenOffice.org using Sun Studio 10 instead. I believe that apart from OpenOffice.org the rest of the packages including Gnome have been rebuild... Ideally I will like to build OpenOffice.org using only GNU development tools. If anyone if it is interested to join this effort, drop me or NexentaOS a line. Having GCC 4.1 bug-free in Solaris x86 is an important milestone. Alberto On Sun, 2006-05-28 at 18:53 +1200, Kaiwai Gardiner wrote: On 5/28/06, Alan DuBoff [EMAIL PROTECTED] wrote: On Saturday 27 May 2006 11:27 pm, Kaiwai Gardiner wrote: The sad part, these people think from quarter to quarter, where as I prefer looking 5 years time; where are the products, where is the marketing heading, and are we going to meet those market changes? I'm not sure I understand. Are you saying that in the past 5 years there hasn't been much gain with software for Solaris x86/x64? Nope, I'm saying that, in general terms, when executives made decisions, they're more concerned about the immediate profits rather than long terms sustainable revenue and profitability - its like cutting RD, might give a boost in profits in the near term, but in terms of the long term, the competitiveness of the company falls behind, thus impacting on the long term profitability of a company. Hence the reason I admired Scott when he and his company refused to buckle under the pressure of cutting RD. As for the last 5 years - name 5 high profile, main stream, software titles that have come to Solaris x86 - not drivers like OSS, or plugins like Flash/Shockwave or Real, but application suites like MYOB, Peachtree accounting etc. etc. You're not going to grow the adoption of Solaris x86 either as a workstation operating system or as an operating system for centralised processing, aka SUN Ray, if there are no mainstream software titles available for it, and the problem is made worse by the fact that no move by making JDS not only the official blessed desktop of Solaris, but the API and platform to which application vendors should write their applications to. Matty ___ __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: [osol-discuss] Re: Software for Solaris (was Re: Adobe Acrobat for Solaris x86)
On Mon, 2006-05-29 at 00:28 -0700, UNIX admin wrote: If you want to see software for Solaris x86/x64 you should consider having a look to NexentaOS http://www.gnusolaris.org Erast and Alex are working really hard to build all software using GCC. 9000+ packages now... And while Nexenta is a nice publicity stunt for OpenSolaris, if I wanted to use Linux, I'd just be running RedHat ES / CentOS, thank You very much. I want to run Solaris because it's Solaris, because of his userland tools, not run some GNU grafted stuff on top of the Solaris kernel. The point should be not to keep PORTING Linux software to Solaris, but to start using Solaris as THE main development platform for open source software (and freeware). Few comments: a) too late for wishes like that; b) majority of developers using GNU userland all over, even on Windows they prefer Cygwin over anything else; c) OSS upstreams are willing to run their babies everywhere and not just Linux, the problem is lack of OSS developers on other than Linux platforms, see (b); d) we do not port Linux-only software. i.e. which is not design to work on any platform other than Linux, such us kernel-specific software. FYI, Debian new package acceptance policy saying that software which willing to be accepted to the main should run at least on two architectures. Usually it is Linux and FreeBSD... -- Erast ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Software for Solaris (was Re: Adobe Acrobat for Solaris x86)
On Mon, 2006-05-29 at 00:40 -0700, UNIX admin wrote: From this stand point, GCC-like and GNU-like environments are must to have and we are moving this road... aka NexentaOS GNU/OpenSolaris. I just happen to be working on porting a GCC written application to Sun Studio 11. And all I can say is, GCC is one of the worst, brain dead compilers in existence. If it were up to me, I'd lock all the GCC developers up on criminal charges for the rest of their lives, and explicitly forbid them to ever touch a computer by a means of a court order. I'd give them shovels and pickaxes, that's what. Those guys are only good to do road work, not work on compilers. To state my point, the Sun Studio C and C++ compilers picked a TON of warnings and just plain BAD CODE, that the braindead GCC compiler didn't even detect. And I didn't even get to the fact that Sun Studio 11 is now available for Linux, for free, so there is NO EXCUSE for using that GCC junk any more. On top of all that, Sun Studio can do just unbelievable optimizations like code reordering, binary optimizations and many other things on x86, x64 and SPARC that GCC can't even touch. Plus it just generates faster, better and tighter code. So when I read statements like the one you just made, my hair stands up on my head. This is horrible, just horrible. You sure do not like GCC... :-) Well, I like it, even I know it is buggy sometimes.. btw, do you know by any chance how to say Sun C compiler to always respect inlines statements? I tried different switches, never worked for me... -- Erast ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Software for Solaris (was Re: Adobe Acrobat for Solaris x86)
On Mon, 2006-05-29 at 17:55 +0200, Joerg Schilling wrote: Erast Benson [EMAIL PROTECTED] wrote: btw, do you know by any chance how to say Sun C compiler to always respect inlines statements? I tried different switches, never worked for me... You are trying to get non-POSIX behavior. So, what? I don't care if this is non-POSIX. I want this feature. Sometimes I'm seeing significant improvements when inlines are widely respected. POSIX allows to always iognore the inline keyword. But I'm asking how to make Sun C compiler do what I want? It is unfortunate that Sun C compiler is not CDDL-licensed... OpenSolaris needs Open Sun C compiler, IMHO. -- Erast ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Software for Solaris (was Re: Adobe Acrobat for Solaris x86)
On Mon, 2006-05-29 at 12:34 -0400, Laszlo (Laca) Peter wrote: On Mon, 2006-05-29 at 20:50 +1200, Kaiwai Gardiner wrote: No, I think the thing worse than that, are those who develop applications as if the whole world revolved around Linux - take the gnome-cd application, its link to a linux cdrom.h header - now wouldn't it be smarter to create an abstraction layer between the devices and applications that that applications don't directly link to the system, thus make portability that wee bit easier? It's called HAL (hardware abstraction layer) and it will land in nevada shortly. ..and committed to upstream CVS. this would be cool. Here is the original proposal: http://opensolaris.org/os/project/tamarack/proposal.txt which developers seems to be following. -- Erast ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Software for Solaris (was Re: Adobe Acrobat for Solaris x86)
On Mon, 2006-05-29 at 09:36 -0700, Rich Teer wrote: On Mon, 29 May 2006, UNIX admin wrote: The point should be not to keep PORTING Linux software to Solaris, but to start using Solaris as THE main development platform for open source software (and freeware). I agree that the latter is the ultimate goal, but the former would be a good starting point. Regardless of what I think of some of the GNU tools, if Nexenta gets more people to try and use OpenSolaris, then it is a worthy project IMHO. Right. In addition I'd like to add that porting (C, C++ code) to Nexenta == porting to Solaris. Zero differences for both drivers and apps. So, it doesn't really matter where developers will settle at Nexenta or at Solaris. Besides, all SUN userland is provided at /usr/sun/bin, so SUN personality could be provided/enabled too. -- Erast ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Software for Solaris (was Re: Adobe Acrobat for Solaris x86)
On Mon, 2006-05-29 at 12:51 -0400, Stefan Teleman wrote: On 5/29/06, Erast Benson [EMAIL PROTECTED] wrote: But I'm asking how to make Sun C compiler do what I want? The compiler is doing what you want, within the limits of it being explicitly allowed to ignore what you want. :-) OK. Than how to disable it? :-) I'm seeing that one could specify explicit names of functions to always inline. How to make it a default policy for all my inlined functions? -- Erast ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Software for Solaris (was Re: Adobe Acrobat for Solaris x86)
On Mon, 2006-05-29 at 19:15 +0200, Joerg Schilling wrote: Erast Benson [EMAIL PROTECTED] wrote: It's called HAL (hardware abstraction layer) and it will land in nevada shortly. ..and committed to upstream CVS. this would be cool. Here is the original proposal: http://opensolaris.org/os/project/tamarack/proposal.txt which developers seems to be following. If it breaks CD/DVD writing (as it does on Linux) I would not call it cool. Not sure what you are talking about. HAL is an abstraction layer. It doesn't re-implements anything. Let us see how it has been implemented on Solaris One thing I don't get yet is why vold been dropped (was it?) over rmvolmgr? And will vold co-exist with rmvolmgr? But may be I just misread the document... -- Erast ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] To enable inlines with Sun C
On Mon, 2006-05-29 at 13:19 -0400, Stefan Teleman wrote: On 5/29/06, Erast Benson [EMAIL PROTECTED] wrote: On Mon, 2006-05-29 at 12:51 -0400, Stefan Teleman wrote: On 5/29/06, Erast Benson [EMAIL PROTECTED] wrote: But I'm asking how to make Sun C compiler do what I want? The compiler is doing what you want, within the limits of it being explicitly allowed to ignore what you want. :-) OK. Than how to disable it? :-) I'm seeing that one could specify explicit names of functions to always inline. How to make it a default policy for all my inlined functions? ISO/IEC 9899:1999:6.7.4 says: [ ... ] 5. A function declared with an *inline* function specifier is an _inline function_. The function specifier may appear more than once; the behavior is the same as if it appeared only once. Making a function an inline function suggests that calls to the function be as fast as possible[118]. The extent to which such suggestions are effective is implementation-defined[119]. 6. Any function with internal linkage can be an inline function. For a function with external linkage, the following restrictions apply: If a function is declared with an *inline* function specifier, then it shall also be defined in the same translation unit. If all of the function file scope declarations for a function in a translation unit include the *inline* function specifier without *extern*, then the definition in that translation unit is an _inline definition_. An inline definition does not provide an external definition for the function, and does not forbid an external definition in another translation unit. [ ... ] It is unspecified whether a call to the function uses the inline definition or the external definition[120]. [118] By using, for example, an altermative to the usual function call mechanism, such as inline substitution. Inline substitution is not textual substitution, nor does it create a new function. [...] [119] For example, an implementation might never perform inline substitution, or might only perform inline substitutions to calls in the scope of an *inline* declaration. [120] Since an inline definition is distinct from the corresponding external definition and from any other corresponding inline definitions in other translation units, all corresponding objects with static storage duration are also distinct in each of the definition. You can try: - set the optimization level to -xO4 or higher - pass -xinline=%auto However: A function is not inlined if any of the following apply (no warning is issued): o Optimization is less than -xO3 o The routine cannot be found o Inlining the routine does not look profitable or safe to iropt o The source for the routine is not in the file being compiled (however, see -xcrossfile). --Stefan Yes, Stefan, I read this doc and tried all these settings. Not all of my inline functions (some of them really small like pointer casting only) been inlined. Tried xcrossfile too, not helping much. I did comparision with gcc-4.0.2 and noticed that GCC inlined all I wanted, as the result I got ~20% performance gain... (x86). I'll try to come up with simple example to show what I wanted to do later and dig into a problem a bit further.. Thanks! -- Erast ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: Software for Solaris (was Re: Adobe Acrobat for Solaris x86)
On Mon, 2006-05-29 at 13:22 -0700, UNIX admin wrote: Right. In addition I'd like to add that porting (C, C++ code) to Nexenta == porting to Solaris. Zero differences for both drivers and apps. So, it doesn't really matter where developers will settle at Nexenta or at Solaris. Besides, all SUN userland is provided at /usr/sun/bin, so SUN personality could be provided/enabled too. While I can certainly see that for apps that depend on drivers, would you please mind explaining how are you porting to Solaris when you compile and link against GNU / Ubuntu userland? I missed the point completely... :-) -- Erast ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: Software for Solaris (was Re: Adobe Acrobat for Solaris x86)
On Tue, 2006-05-30 at 04:28 -0700, UNIX admin wrote: yep. And lets be real here, it is much easier for us to fix GCC compiler to work properly on OpenSolaris than to fix or change mentality of those lazy programmers... Let's be even more realistic then -- those people should not be programming then, period. Those people could be students who may be writing their first program... Or scientists who cares about the result and not the process... At any rate, I woudn't blame them, instead I would greatly appreciate what they doing at their free time. Erast ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: Software for Solaris (was Re:
On Tue, 2006-05-30 at 11:40 -0700, Artem Kachitchkine wrote: One thing I don't get yet is why vold been dropped (was it?) over rmvolmgr? And will vold co-exist with rmvolmgr? But may be I just misread the document... As I replied to you earlier, section 8, Vold EOF and backward compatibility describes this in detail. vold and HAL cannot co-exist. vold will be removed, but some level of backward compatibility will be preserved as much as practical. Not sure what you are talking about. HAL is an abstraction layer. It doesn't re-implements anything. Joerg is talking about polling of the CD/DVD devices. HAL needs to maintain a consistent view of hardware, it does so by consuming asynchronous kernel events. There are cases, however, when events are not available, so HAL has to poll. One such case is media insertion/removal. In Solaris, this can be done either with the DKIOCSTATE ioctl (in which case the kernel does polling for you) or directly via uscsi interface. We are currently using the former, but are likely to transition to the latter in order to detect hardware eject button presses. In respect to CD/DVD writing, it is our high priority not to break it. I know cdrecord found a way to coexist with it, but it works more by coincidence than by design; whatever vold workarounds are out there, they never broke simply because noone dared to touch vold for many years. There is a risk that some things will break now, but it's an attribute of change and, as others pointed out, vold had to go sooner or later. In respect to things being similar to Linux, the Tamarack proposal has section 2.2 Why HAL specifically to address this. In short, if Sun is serious about making GNOME its primary desktop, Solaris has to have HAL, there's just no way around it. It doesn't mean, however, that HAL *implementation* has to be similar to Linux, deviations are inevitable, though we do strive to share a lot of code. BTW, FreeBSD is also getting HAL very soon. Cool. You guys doing a great job! Appreciated. Will Tamarack beat Utopia? I guess it will. :-) Finally, I'd like to invite those interested to the tamarack-discuss mailing list. I tend to have to ignore runaway threads on opensolaris-discuss. I'm in. Erast ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
