Re: [osol-discuss] [distribution-discuss] Community distro
On Wed, Jul 14, 2010 at 9:54 AM, Moinak Ghosh moin...@belenix.org wrote: On Wed, Jul 14, 2010 at 7:26 PM, Rob McMahon rob.mcma...@warwick.ac.uk wrote: So, let's get positive here. Where do we get started to form a Community Distro, based on the latest sources including IPS. Not a cut down version, or replacing the userland (no offence there, that's good work too), just a take on Solaris Next based on the latest available bits. We have Rich Lowe's work for starters, but I wouldn't know how to take that and form a repository. Can we talk about this and get something started ? Great, this is the first step that we should be taking. Taking the available sources and using tools like Distro Constructor etc. to create something as a common base. There are several things involved to get a complete source-built distro. Existing docs are not fully adequate. I can come up with an initial set of instructions on the first steps involved and get it reviewed with Joerg. In addition I will need to update my ON auto-builder utility for recent release drops. In short basic things to be built include: ON itself Math library Mozilla NSS, NSPR (I have build scripts for these) X11 Devpro Tools SFW G11n repos JDS Man pages Binary things that need replacing: i18n libc support NFS lock manager etc. Kernel crypto stuff A few utilities A few drivers I submit to you that just as important, if not MORE important, is to wean the community off of Oracle's infrastructure and process. Whomever takes up this mantle will have to come to terms with building out infrastructure and methodology for doing this 100% independently of Oracle. The only way I can see this being successful is to treat the development repositories from Oracle as upstream (for as long as they are available), but to host all further development (including patches + closed-rewritten-as-open bits) and community under a truly open foundation and infrastructure. This is what the OGB _could_ be doing. An Ubuntu model (or Centos) or some variation on that is what I'm suggesting. Build out a source juicr. Build out a system to accept patches. Build out continuous builds and organize a build and testing team to build and test integrations. Organize the first technical projects to finally rewrite those nagging closed bit. Create a website and forums to allow the community to reorganize itself without the shadow of a hollow and unsupported charter. Nexenta and others are already doing most of this -- learn from them. Let me be clear, I'm not suggesting that collaboration with Oracle's teams cease. I have no intention, at this point, to quit ARC regardless of whether something like I'm suggesting above happens. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [distribution-discuss] Community distro
On Wed, Jul 14, 2010 at 5:12 PM, Peter Tribble peter.trib...@gmail.com wrote: On Wed, Jul 14, 2010 at 6:45 PM, Mark Martin storycraf...@gmail.com wrote: Create a website and forums to allow the community to reorganize itself without the shadow of a hollow and unsupported charter. So the OGB would have to violate its own rules and act contrary to what we were elected for. Again, the OGB would really have to quit the current system and reform in some other guise, or new people could start afresh. True, that. Maybe if someone crafted some new articles of incorporation (maybe following August 16th's regrettable, but seemingly inevitable outcome) we could take the existing bewildered community and start working again towards common goals. I don't see why such a community couldn't also adopt most or all of the existing constitution modulo any parts dealing with transfer back to Sun/Oracle. The OGB can shoot itself in the head, and from the same corpus (the community) could spring a new head. For all this, anybody could have done it over the past 5 years or so. Anybody still can. Pending the outcome of mid August, I'd be interested in lending whatever support I could to such an endeavor. Maybe sooner -- even if the bar is met, and Oracle _does_ appoint a liaison, I'm not sure that's really enough. There are many other things going on that point toward the inevitable breakup of Oracle and community. I suspect I speak for many, if not most, when I say that I think the success of a true Open OpenSolaris rests with a separate, self-sufficient, community. Distinct and separate from Oracle, but sharing many common goals (chief among them the continued success of OpenSolaris). ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [distribution-discuss] Community distro
On Wed, Jul 14, 2010 at 9:59 PM, John Plocher john.ploc...@gmail.com wrote: On Wed, Jul 14, 2010 at 7:07 PM, Paul Gress pgr...@optonline.net wrote: Great idea. Not what the current OGB, as the OGB, is chartered to do. The OGB would really have to quit the current system and reform in some other guise, or a new body would have to take this on. Maybe this is whats planned if they cut their heads off. I didn't agree with that decision, but now I'm starting to think of it as a well planned decision. The best of all worlds, IMHO, would be for us (the community) to build and maintain a website of our own that hosted a minimalist distro of our own, with IPS repos of our own, using only the master mercurial (and/or whatever) source repos mirrored from within Oracle. Explicitly NOT a fork, and explicitly NOT an Oracle product, it would provide desperately needed direction and coherence for our community. In addition to, but separate from it, there should be an Alan Cox style branch where community contributions to the core OS could be evaluated, packaged, committed and maintained. Continuing my fantasy, there would be a set of related IPS repos that contain community generated packages for each of these two distro styles (ala the source jucr and/or Blastwave and/or SunFreeWare). Imbibing fully of the Kool-Aid gets me to a point where one could use the Distro Constructor to craft a personalized distro, say with KDE and ZFS or Crosbow, ZFS and no graphics/desktop support at all. There. That's good enough for me. We can quibble later about whether IPS is really the right packaging/distribution system. That's perfect as a declaration of independence. Where do I sign? One significant hurdle is that not all of the current OGB members feel they can devote the significant quantities of their limited energy, resources and time that such an undertaking would entail - a situation that applies, I'm sure, to many others in our community... Morale couldn't probably be any lower. Maybe we'll get surprised by enough folks stepping up in the community. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Problem: Very long delay before login prompt (GDM splash)
On Tue, May 11, 2010 at 5:20 PM, Robin Axelsson gu99r...@student.chalmers.se wrote: I'm not using any particular locale (I use the default system language) and I use a Swedish keyboard layout. The keyboard is a Logitech keyboard connected via the PS/2 port and the mouse is a Logitech USB mouse. Also note that this delay has not been there all the time. Even after I upgraded to snv_b134 the login was normal. But then something happened quite recently, I don't know what it is. The only thing I've been tampering with in the system is the network configuration files such as /etc/host, /etc/nsswitch.conf and /etc/inet/inodes since I was resolving problems with slow ssh logins. I have a feeling that some configuration file was corrupted when the system was shut down. This is just a hunch and I may be terribly wrong. The system has I don't have a specific test for you to perform at the moment, but my first instinct, when I read your initial post some days ago, was that this was very indicative of a network timeout. I'm not a gnome expert by any means, so I'm glad Brian is helping, but I'd not give up the network configuration angle as another possible configuration issue. Especially since you mention you recently changed nsswitch.conf (and friends). Additionally, it occurs to me during Brian's troubleshooting with you that that sort of thing (network timeout) is often not logged with a default configuration, which is why you wouldn't see it in any of the normal logs. I suspect truss'ing would eventually find the network timeout issue if that really is the culprit. One thing you can try to do, though, in the mean time, is try using simpler (or older) versions of nsswitch.conf (try with just files or dns). If you recently added ldap for any reason, then I might even be persuaded to put money down on a bet. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Cloud services
On Mon, May 10, 2010 at 5:45 PM, Peter Jones bloosk...@netscape.net wrote: I am interested in storage/back up products such as dropbox for personal computing Crashplan has a backup solution for OpenSolaris (among other clients). I've been using the home version across 4 different platforms for quite some time and have recommended it to friends. http://b3.crashplan.com/consumer/features.html (disclosure: I do not work for Crashplan, its affiliates, or its partners; nor do I own stock) ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] XSun emancipation project proposal (Was: Re: [xwin-discuss] Sun UltraSparc: XVR-500, Expert 3D, legacy graphic cards)
(Rough) straw project proposal for your consideration. My interest is solely as an eventual beneficiary of your work. = *XSun emancipation***Project = Name *XSun emancipation* alias: *xsun*-disc...@os.o Synopsis A project to emancipate the XSun sources and write wrappers to use XSun based drivers on Xorg. Sponsor ON CG Core Contributors Martin Bochnig Ken Mays Alan Coopersmith Description Charter: To release as much XSun source as possible (considering legal encumberances this may not be the complete source base). To produce suitable wrappers and conversion utilities so that existing drivers which are closed and encumbered may still be used with newer Xorg server. Related Projects *FOX Project* Expected deliverables - Release XSun source - Modify XSun source to work with libXfont Context ON/Nevada *OpenSolaris* Development Process http://www.opensolaris.org/os/community/on/os_dev_process/ Preliminary discussions regarding project proposal http://mail.opensolaris.org/pipermail/xwin-discuss/2009-November/004041.html ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] XSun emancipation project proposal (Was: Re: [xwin-discuss] Sun UltraSparc: XVR-500, Expert 3D, legacy graphic cards)
Alan Coopersmith wrote: Mark Martin wrote: (Rough) straw project proposal for your consideration. My interest is solely as an eventual beneficiary of your work. = *XSun emancipation***Project = Name *XSun emancipation* alias: *xsun*-disc...@os.o Synopsis A project to emancipate the XSun sources and write wrappers to use XSun based drivers on Xorg. Sponsor ON CG I would think it would be the X community group, since none of this code has ever been in ON. Otherwise, the strawman seems reasonable, though I'd expect the list of contributors to change before the final proposal is submitted. For instance, while I've volunteered to work on the code release, once that's done, I won't be leading this project or probably doing much more than answering questions and giving advice. Thanks for the feedback. I've removed your name from the list of CC's and changed the sponsoring CG. I've also posted this on Genunix at http://wiki.genunix.org/wiki/index.php/LegacyVideoSupportProject Seems like the next step after wordsmithing that document would be to formally propose it in the X CG and look for (3) +1's. I'll happily sit back and let other folks drive with this now that direct contributors can edit. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] XSun emancipation project proposal (Was: Re: [xwin-discuss] Sun UltraSparc: XVR-500, Expert 3D, legacy graphic cards)
Mauro M. wrote: Emancipation sounds inappropriate as its meaning is about freeing people from oppression and slavery, Xsun is a software component, not a person and it isn't really oppressed. Firstly, the term emancipation hits the nail on its head most precisely. Although I myself also generally prefer OpenFoo, as I indicated when I proposed this new project a few hours ago: Go on some consideration for an old language ... Open is OK, or try again with another name. It's been renamed on the wiki. I chose emancipation as there is already a project (or is it a community? I forget) with similar goals. I'd invite anyone that is interested in further wordsmithing to edit the wiki directly. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] SXCE end-of-life plans
On Mon, Aug 10, 2009 at 3:49 PM, Glynn Fosterglynn.fos...@sun.com wrote: Sun is announcing the intent to discontinue production of the Solaris Express Community Edition (SXCE) by the end of October time-frame. As we intend to continue on a bi-weekly build schedule, consolidations will move towards producing native Image Packaging System (IPS) packages alongside SVR4 packages and then phase out the latter completely. Technologies such as IPS, Automated Install, Snap Upgrade and the Distribution Constructor will be integrating into a consolidation after following through the established processes including architectural (ARC) review. We recognize that this transition will require some effort for all members of the OpenSolaris development community, and are committed to working with all of you in making that transition a success. You can expect updated information from us and the communities which manage the consolidations as we further plan the transition schedules. Questions can be directed to David Comay, Glynn Foster, William Franklin, Stephen Hahn, Dave Miner, Vincent Murphy, or Dan Roberts. What would it take to document the recipe for building SXCE, such that interested /external/ community members who do not share Sun's marketing agenda might have a shot at continuing this potentially valuable distribution? Yes, I realize many bits are eternally closed. I'm interested in the *process* bits first. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Is `bacula' available in a pkg repository somewhere
Harry Putnam wrote: Robert Hartzell b...@rwhartzell.net writes: Harry Putnam wrote: Sean s...@ttys0.net writes: We just compile it ourselves. It builds without any issues. It fails here when ./configure is run like this: ./configure --prefix=/usr/local/src/test --with-mysql \ --includedir=/usr/mysql/5.1/include/mysql/ [...] checking for MySQL support... no configure: error: Unable to find mysql.h in standard locations The file `mysql.h' is where I told configure to look: ls -l /usr/mysql/5.1/include/mysql/mysql.h -r--r--r-- 1 root bin 33654 ... /usr/mysql/5.1/include/mysql/mysql.h I have never used the --includedir option but LDFLAGS has worked well for me, LDFLAGS=-L/usr/postgres/8.3/lib -R/usr/postgres/8.3/lib export LDFLAGS; ./configure ... just adjust the path for mysql. Setting that like you suggest: LDFLAGS=-L/usr/mysql/5.1/lib -R/usr/mysql/5.1/lib;export LDFLAGS ./configure --prefix=/usr/local/src/test --with-mysql [...] * Seems to make no difference at all... Still ends with the same error: checking for MySQL support... no configure: error: Unable to find mysql.h in standard locations ps- I also tried with includedir set after setting LDFLAGS as above. Same result... same error. You may want to try variations on the --includedir...sometimes there's an implicit #include mysql/mysql.h in there... Try walking up the tree to just the /usr/mysql/5.1/ dir? ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Is `bacula' available in a pkg repository somewhere
Harry Putnam wrote: Mark Martin storycraf...@gmail.com writes: ps- I also tried with includedir set after setting LDFLAGS as above. Same result... same error. You may want to try variations on the --includedir...sometimes there's an implicit #include mysql/mysql.h in there... Try walking up the tree to just the /usr/mysql/5.1/ dir? You hit it... but it was more general than includedir. It appears to have wanted the general address of mysql --with-mysql=/usr/mysql/5.1 Seems to have worked. Glad to hear it! Would you consider submitting a .spec file for this and getting it in to the /contrib repository for others to benefit from your hard work? http://jucr.opensolaris.org/home/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Spell checking for Emacs?
On Wed, Jul 8, 2009 at 9:48 PM, Alex Viskovatoffviskovat...@imap.cc wrote: Well, I've had to sort this out on my own. It turns out that it's relatively easy to get spell checking working under Emacs with aspell. That's what the two Linux distros I have, OpenSUSE and Fedora, use for Emacs. Since they both come with Hunspell, I guess the packagers of those distros couldn't get Hunspell working under Emacs any better than I could. (It does compile under OpenSolaris without any problems, and works from the command line. The problem is that it doesn't work with the Emacs ispell mode.) GNU aspell didn't compile for me with ncurses, so I used ./configure --disable-curses. You don't need ncurses to be enabled in aspell anyway, if you're only going to use it in Emacs. Mind sharing what prevented you from using Hunspell in Emac's ispell mode? If you could share your recipe for success for the aspell route, that'd be appreciated, too, I'm sure. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] GCC 4.4: Can we handle it?!?
On Sun, Jun 14, 2009 at 4:38 PM, john krolljek0...@sbcglobal.net wrote: Sorry sir my comment was not specific to GCC 4.4 OpenSolaris and Debian being, as examples, tending towards opposite ends of that spectrum. At the end of the day, this is a lot of hot air over little. I simply meant that Debian's philosophy is that absolutely nothing _not_ free (read: not opensourced) gets intot the distro. That's not the case with Sun's OpenSolaris (tm) distro, nor of probably any distro currently. One compiler is free; the other, required currently for building the base bits, is not. Debian is absolute in the extreme of 100% free stuff only. OpenSolaris in most, if not all forms, is not built with, nor contains, 100% free. Today, anyway. And if other distro's have solved for /closed then I'll apologize in advance. By the way, there are two ways to integrate into OpenSolaris today: 1) Port and go through ARC, then integrate manually but through the Sun process (sponsorship, etc), then end; 2) Port and go through /contrib, then end; The former gets you into probably most distros. The later, probably just Sun's -- I don't know if any other distros currently (or plan to) take on pkg. And then there's Nexenta :) GCC doesn't _have to_ go through ARC if it targets /contrib. I'm not endorsing or suggesting that's a good thing, but that's the reality I see. And no, OpenSolaris.Org won't migrate to OpenSolaris.net. There's so much more to the community than just Sun's distro -- it won't end when Solaris.Next ships in a more official capacity.. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] GCC 4.4: Can we handle it?!?
Glenn Lagasse wrote: * Jim Langston (jim.langs...@sun.com) wrote: Glenn Lagasse wrote: * Ian Collins (i...@ianshome.com) wrote: Glenn Lagasse wrote: * ken mays (maybird1...@yahoo.com) wrote: Hello, Since developers are getting more involved in using the GCC compiler and especially the GCC 4.4.x compilers, I started wondering why not migrate to GCC 4.4.x sooner than later?? We have more community developers building, testing, and reporting on GCC 4.4.x than before. What is the price of admission for users/developers to enter the gates of GCC 4.4.x ?? Well, it's not 4.4.x but 4.3.2 is available in 2009.06. http://pkg.opensolaris.org/release/en/search.shtml?token=gccaction=Search As Ken says, 4.4.x is where all the gcc effort is going, especially with C++. Shouldn't OpenSolaris be moving with the times? Of course it should. And at some point, I'm sure 4.4.x (or whatever the most recent version available is at the time the person doing the integrating sees) will hit the repositories. However, 4.3.2 is a nice upgrade from the 3.4.3 that was in 2008.11 wouldn't you say? This is where my confusion rests - SUNWgcc is still 3.4.3, it is through the development package that 4.3.3 gets loaded, are they both supported ? I'm confused because SUNWgcc seems distinctly directed as core part of OS, whereas, development/gcc seems to have a you're on your own feel. I can't speak definitively about this, but my best guess is that SUNWgcc is still 3.4.3 because the ON consolidation hasn't qualified later builds of GCC for building ON. And so, the supported method for compiling code using GCC in ON is to use 3.4.3 until such time as someone does the work to update ON to build using later versions. Which I'd imagine will have to happen at some point. Spot on -- http://mail.opensolaris.org/pipermail/tools-discuss/2009-June/004652.html ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] GCC 4.4: Can we handle it?!?
Shawn Walker wrote: Stephen Lau wrote: You do a disservice by dismissing anyone who may know about Sun Studio as either lacking skill or being lazy. There are plenty of developers who have written software on other platforms (OS X, Linux, etc.) who have written perfectly good software with gcc-isms, and have users (like us) appealing to them to port it over to Solaris. Having not-up-to-date matching compilers only makes Solaris look bad, and gives the developers an excuse for not porting their software. I have to agree with Stephen. While I don't believe developers should use gccisms (because I think portability and adhering to language standards is more important), sometimes there is no viable alternative or you are targeting a specific platform and it doesn't matter. For certain definitions of language standards... One might be able to argue that gcc (+autoconfig) has become the defacto standard for writing applications on *nix. At least for FOSS. But I digress. I agree with you in principle. And yes, I'm counting Apple. I also believe Sun Studio to be a better compiler, in general, and that's after using gcc since 1993 or 1994... Regardless, as long as Sun Studio remains closed, it is important that the OpenSolaris community provide a viable, up-to-date, open source option as much as possible. Depending on which end of the FOSS spectrum you hang your hat, obviously. :) OpenSolaris and Debian being, as examples, tending towards opposite ends of that spectrum. At the end of the day, this is a lot of hot air over little. Gcc 4.3 is available on The OpenSolaris(tm) today. Someone could package 4.4 tomorrow. It'd be _real easy_ to do if you used 4.3's spec as a start. This is great for app developers. Gcc 4.ish should be able to build ON very shortly based on recent work. This is great for porters and folks who believe strongly in the Open moniker. All along, suncc worked for everything. This is great for everyone. (Well, except porters, but again, I digress). ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] ARM port?
Moinak Ghosh wrote: On Tue, Mar 24, 2009 at 9:24 PM, Thomas Maier-Komor tho...@maier-komor.de wrote: Moinak Ghosh schrieb: On Tue, Mar 24, 2009 at 8:32 PM, C. codest...@osunix.org wrote: Martin Bochnig wrote: Would it be possible at all to strip down OpenSolaris enough so that it could fit into 8MB of flash or would that require spinning of an embedded version which makes a lot of compromises? You might have a look at MilaX and BeleniX. But 8MB??? Forget about it. Not true.. Milax I think can get down to 24M and still has a lot of kernel modules/drivers which could be parsed out. There's also the fact that milax still probably contains binaries for 32/64 bit.. maybe headers and worst case we could resort to binary stripping and or change compiler flags to optimize for space. Someone of course correct me if I'm wrong.. This is of course not at all to imply that it can be done tomorrow or very easy. Just that there's still room for more size reductions. Anyone daring/crazy enough that wants to work on it feel free to ping me. Stripping kernel stuff may not be practical in osol-land since all the debug info is compressed and stored as CTF data. Dtrace, mdb and other tools depend on it. Regards, Moinak. Well, I guess for embedded applications it's fine to remove DTrace, mdb, and friends. And kmdb ? How will you debug kernel panics ? Guy's poor man's debugger... Polaris didn't get kmdb. Regards, Moinak. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [powerpc-discuss] Project Proposal -- Port to MIPS architecture
On Thu, Oct 23, 2008 at 6:12 PM, William Kucharski [EMAIL PROTECTED] wrote: So if there is sufficient interest in a MIPS project, I would be happy to get the ball rolling by formally proposing the creation of such a project under the Emerging Platforms CG. I thought we had enough votes as it was: Martin B., John S., John G., and Cyril P. all registered +1 votes. Of course, I don't know if those were all from the Emerging Platforms CG, so thank you for picking up formal adoption of this. I'd just need to know the charter and who wants to be the project leads. I had trouble finding a project charter template, so I stole a rare example from John P. (thanks John!). Besides myself, nobody else has stepped forward, so I would certainly welcome volunteers. = OpenSolaris on MIPS Project = Name OpenSolaris on MIPS Architecture alias: [EMAIL PROTECTED] Synopsis A project to port the OpenSolaris operating system to the MIPS architecture and related platforms. Sponsor Emerging Platforms CG Description Charter: To develop a port of OpenSolaris suitable for running on MIPS based platforms. Primary efforts will be focused on identifying a development environment and target platforms, creating changes to the ON consolidation to support MIPS32 and possibly MIPS64 builds, and creating recommendations for follow on projects to produce a distribution as well as other necessary projects. Related Projects OpenSolaris for PowerPC port. Expected deliverables - Provide a cross linking build environment - Identify candidate hardware and software emulation platform(s) targets. One goal here is to provide a simple development environment that is easy to obtain and maintain. - Build of portions (or all) of the ON consolidation and provide kernel and userland portions to a minimal identified run state - Investigate and port tools used in the OpenSolaris PowerPC port project (Polaris). Context ON/Nevada OpenSolaris Development Process http://www.opensolaris.org/os/community/on/os_dev_process/ Preliminary discussions regarding project proposal http://mail.opensolaris.org/pipermail/emerging-platforms-discuss/2008-October/02.html http://mail.opensolaris.org/pipermail/powerpc-discuss/2008-October/002532.html = end = ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Q: DVB support ?
On Fri, Oct 24, 2008 at 1:42 PM, homerun [EMAIL PROTECTED] wrote: Hi Any plans to create support for DVB receivers ? Not at the moment. You're probably talking about Power or MIPS based systems, with limited memory and flash based file systems. While it may be possible in some time to see OpenSolaris running on those cpu's, the chance that it will run on those particular hardware platforms is low, in my opinion. You're welcome to contribute to either porting project (PowerPC or MIPS) in the meantime. Mark ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [OT] was Re: The future of the IPS system
On Fri, Oct 24, 2008 at 8:53 AM, James Carlson [EMAIL PROTECTED]wrote: A more interesting question for this group, I think, is what requirements need to put onto the projects delivering into OpenSolaris consolidations so that those systems can work. Right now, I think we have a possibly unstable situation: the source isn't just 'source,' it also (naturally) includes packaging information. That information is in SysV format, which (through scripting) has flexibility that other systems (such as IPS) don't have, so accomodating those downstream consumers (distribution constructors) is an issue. Do we restrict projects to the least common denominator? Somehow abstract packaging away? Select one mechanism as reference and convert everything over? We probably need something like an OpenSolaris-wide policy here. James, I'm glad you said something. I heard something at the LSARC meeting this week that gave me some pause and is related to IPS and porting issues. The questions you raise, along with John P's nascent project to define ARC interaction with the rest of the community combined with the ARC's scalability concerns regarding the massive porting projects that are underway makes me believe there may be floodwaters rising. Who has responsibility for addressing your concern and the related concerns? I do not see the IPS project as being aware or even concerned about these issues -- they seem to have their own internal agenda. I'm afraid the one or two voices that are raising interesting questions are only just shouting into the coming storm at this point. Do we need to define the problem statement further? Mark ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Q: DVB support ?
On Fri, Oct 24, 2008 at 7:12 PM, John Weekley [EMAIL PROTECTED]wrote: Not at the moment. You're probably talking about Power or MIPS based systems, with limited memory and flash based file systems. While it may be possible in some time to see OpenSolaris running on those cpu's, the chance that it will run on those particular hardware platforms is low, in my opinion. You're welcome to contribute to either porting project (PowerPC or MIPS) in the meantime. Mark Interesting assumption... TiVo uses MIPS, but there are some very popular, open source alternatives. I just put one together with Fedora Core 9 (x86), 4 GB RAM (overkill), Dual core Athlon, 3/4 TB disk and MythTV. I stand corrected. I took receiver to be more narrowly defined. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] The future of the IPS system
On Tue, Oct 21, 2008 at 2:04 PM, Mario Goebbels [EMAIL PROTECTED] wrote: Martin Bochnig wrote: ... Seriously, persecution complex much? For what it is worth, Martin is not alone with the concern, especially given how similar the projects are becoming. While I may not agree with the style, I absolutely agree with the substance. Unfortunately, victory was declared many months ago. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Project Proposal -- Port to MIPS architecture
On Sun, Oct 19, 2008 at 12:54 AM, Cyril Plisko [EMAIL PROTECTED]wrote: do you have enough hardware documentation to do this ? At the moment that is a gap. This was also a gap for other platforms considered for the PowerPC platform (Sony PS3, Apple PowerMacs), but I believe our advantage here is that we may have a platform where the vendor is willing to work with us. Movidis has offered to field technical questions, and I have a request in to Cavium Networks for more detailed documentation on the Octeon. I wonder if we will get similar access to documentation if the Qube is also considered as a target. Who will be the initial project members ? For the moment, myself, but I'll certainly welcome other volunteers. I do plan to reach out to the Linux, NetBSD, and OpenBSD communities for help from their MIPS porting folks. Anyhow, +1 for this project. -- Regards, Cyril ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Project Proposal -- Port to MIPS architecture
On Sat, Oct 18, 2008 at 10:04 PM, john g4lt [EMAIL PROTECTED] wrote: +1 my qube votes +1 too XD In fact, for optimal political success for this, I'd suggest making the MIPS qubes the primary target, since they were acquired by Sun with the entire Cobalt company Not a bad idea, but challenging due to the max memory sizes on the Qubes. I also wonder how much information and support we will get for those older platforms. I think if there is any chance of running on running on any platform with less than 512MB (like the Qube or most ARM boards), you'll have to figure out how to change the boot and install requirements. Personally, I think it is a shame to see Linux running on 64MB devices (for specific purposes) and know that it'd be nigh on impossible to see OpenSolaris running there right now. If you're volunteering to help, I'd welcome it and suggest we investigate how much documentation we will get from Sun regarding those systems. I'd personally consider it as a secondary effort without hesitation. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [tools-discuss] Project Proposal -- Port to MIPS architecture
On Sun, Oct 19, 2008 at 2:44 AM, C. Bergström [EMAIL PROTECTED]wrote: Mark Martin wrote: I am seeking approval for a project for porting OpenSolaris to the MIPS architecture. Proposal: Provide code changes, tools, documentation, and other necessary artifacts for a port of OpenSolaris to the MIPS architecture. Movidis, a maker of MIPS based components and systems has expressed interest in support of this port, so it is likely that their products will be the initial supported platforms -- support for other MIPS based platforms may follow suit. The current project goal is to support the MIPS64 architecture, although the MIPS32 ISA may also be a possibility. Among other deliverables, it is expected that this port will include integration of some or all of changes identified in the gccfss project: http://www.opensolaris.org/jive/thread.jspa?threadID=24934, and preserved here: http://cr.opensolaris.org/~devnull/6515400/http://cr.opensolaris.org/%7Edevnull/6515400/ http://cr.opensolaris.org/%7Edevnull/6515400/. There may be additional key core kernel changes similar to those identified in the PowerPC port project. Some of these changes were necessary for support for a gcc based cross compilation tool chain. This cross compiler tool chain is necessary for boot strap of the port, but a self-hosting, native gcc tool chain is also a goal for the project. A discussion list and source repository are also requested. It's too bad sun cc source isn't available yet.. I'm addicted to the quality of some of the code that SS12 and especially SSX is producing otherwise I'd be 100% 1+.. I've been working on size optimizations which code possibly pay off in the not too distant future for an embedded platform. Hence tools-discuss in the distribution list :) I consider it a necessary evil that GCC is in the bootstrap tool-chain and most likely the native build tool-chain as well. That was going to be the fate for PowerPC had it gotten that far. This is also a gap. I believe it is possible to build at least the OpenSolaris ON consolidation bits with GCC at the moment (although I am not certain of which version). GCC 4 compilation is not possible without at least some of those fixes I referenced, so I believe 3.x is required (at least that was the case with the PowerPC port from nv-56). Also, C++ compilation for other consolidations is going to be a sticky issue as the Sun C++ ABI is the preferred and (almost) required C++ ABI according to current ARC requirements. I believe, for the moment, that closing that gap would have to be a follow-on project. I want to see a port coming up to run levels 1 before I go working on fixing layered software issues. On that note, this brings up other issues such as distribution and testing down the road. I would like to suggest that the scope for this project be to simply bring up the port for recent versions of the ON, SFW, and X consolidations and I would look to the Emerging Platforms Community to assist in creating follow on projects to close distribution, testing, and developer p p gaps. As items come up that need to be brought for ARC attention, I can at least lead some of those tasks. Thanks ./C ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Project Proposal -- Port to MIPS architecture
On Sun, Oct 19, 2008 at 9:02 AM, Cyril Plisko [EMAIL PROTECTED]wrote: Isn't Qube too old to be considered a viable target for this project ? One of the lessons I've learned from the PPC port is to make sure the hardware is readily available and not going to die soon. Otherwise the software will follow the hardware :-( Agreed. This was, honestly, one of the main reasons I reached out to Movidis. The platform vendor willingness to cooperate is not always enough - with PPC Genesi was as cooperative as one could possibly dream, however the system logic was not their part and Marvell (their chip was there) just couldn't care less. Agreed. Since this isn't corporate sponsored, I consider it a risk to complete success that it will rely on external contributions. Regardless I still have energy and optimism. I know that won't be enough, though. The platform itself looks quite interesting. Are there any other possible _modern_ platform this project can target ? I'm open to ideas. For me, the Movidis x16 platform is interesting because it does not solely target the dedicated network switch/routing market that I so often see MIPS being used in. I think this may also be interesting http://en.wikipedia.org/wiki/Loongson ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [tools-discuss] Project Proposal -- Port to MIPS architecture
On Sun, Oct 19, 2008 at 9:48 AM, Cyril Plisko [EMAIL PROTECTED]wrote: On Sun, Oct 19, 2008 at 4:07 PM, Mark Martin [EMAIL PROTECTED] wrote: This is also a gap. I believe it is possible to build at least the OpenSolaris ON consolidation bits with GCC at the moment (although I am not certain of which version). GCC 4 compilation is not possible without at least some of those fixes I referenced, so I believe 3.x is required (at least that was the case with the PowerPC port from nv-56). Also, C++ compilation for other consolidations is going to be a sticky issue as the Sun C++ ABI is the preferred and (almost) required C++ ABI according to current ARC requirements. I believe, for the moment, that closing that gap would have to be a follow-on project. I want to see a port coming up to run levels 1 before I go working on fixing layered software issues. Indeed, I wouldn't worry about C++ and what ARC can say until the system boots up to the shell prompt. I am not sure what is the situation with MIPS/ELF target with GCC3, but I'd stick to gcc-3.4.3 (the one that comes with/builds ON) for the starter. Unless, of course, some really pressing reason will force you to go for GCC4. Other than significantly reduced build times, none at this moment. On that note, this brings up other issues such as distribution and testing down the road. I would like to suggest that the scope for this project be to simply bring up the port for recent versions of the ON, SFW, and X consolidations and I would look to the Emerging Platforms Community to assist in creating follow on projects to close distribution, testing, and developer p p gaps. As items come up that need to be brought for ARC attention, I can at least lead some of those tasks. May I suggest pushing SFW and X beyond the original scope ? I think you'll have enough problems to solve even with ON itself. OTOH, when the port become self-hosting many things come almost at no price. Sounds reasonable. Again, I'll look to the EP Community to create follow-on projects. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Project Proposal -- Port to MIPS architecture
I am seeking approval for a project for porting OpenSolaris to the MIPS architecture. Proposal: Provide code changes, tools, documentation, and other necessary artifacts for a port of OpenSolaris to the MIPS architecture. Movidis, a maker of MIPS based components and systems has expressed interest in support of this port, so it is likely that their products will be the initial supported platforms -- support for other MIPS based platforms may follow suit. The current project goal is to support the MIPS64 architecture, although the MIPS32 ISA may also be a possibility. Among other deliverables, it is expected that this port will include integration of some or all of changes identified in the gccfss project: http://www.opensolaris.org/jive/thread.jspa?threadID=24934, and preserved here: http://cr.opensolaris.org/~devnull/6515400/. There may be additional key core kernel changes similar to those identified in the PowerPC port project. Some of these changes were necessary for support for a gcc based cross compilation tool chain. This cross compiler tool chain is necessary for boot strap of the port, but a self-hosting, native gcc tool chain is also a goal for the project. A discussion list and source repository are also requested. Mark ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Project Proposal -- Port to MIPS architecture
[Resent for Reply-all] On Sat, Oct 18, 2008 at 6:03 PM, Martin Bochnig [EMAIL PROTECTED] wrote: +1 Except that it would be nice if somebody would make the Polaris port functional, before starting a new port. Also, why MIPS, not ARM? Isn't MIPS dead a bit? Thanks for the vote and the feedback. I believe the PowerPC is either lacking consensus on a platform or lacking other resources (or both). I agree that the PowerPC has some attractive features, but lack of a valid, available platform and resources I think is contributing to its dormancy. I believe that interest continues for that platform, but once Sun Labs discontinued development support, the project seems to have gone into hibernation. Someone mentioned interest in an ARM a short while ago, but in my research, I could not find a solid, available platform that provided enough physical resources -- namely 256MB to 512MB RAM, which I believe would be a minimum footprint. It is my opinion that OpenSolaris is a tough nut to crack on embedded platforms. What makes the Movidis platform interesting is support for larger memory footprints (8GB) and the intended markets, including web application hosting. Use of the Octeon processor is also interesting to me, personally. %martin ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Project planning and ARC/no-ARC integration (was was Alpine, now Exim...)
(forking to ARC-discuss) On Mon, May 5, 2008 at 11:22 AM, James Carlson [EMAIL PROTECTED] wrote: Alan DuBoff writes: On Mon, 5 May 2008, James Carlson wrote: In this case, no extra repository would have helped. It would have helped me. As it is, I had to go out, get the sources, compile them and it didn't compile the first time straight out of the tarball, I had to try a few different options. How would you be more helped by an external repository that doesn't have Alpine in it than an internal repository that doesn't have Alpine in it? I'll let Alan answer that definitively, of course, but I took it to mean had/were an external repository been available, an external contributor could have posted the built bits once they'd done the port and build. I don't think he was suggesting that the repository availability was a necessary precondition to the build, but rather for the availability. Regardless, this brings to my mind an issue. As there was already an ARC case open, there are a couple of cases that are possible. 1) An ARC case is brought for a FOSS item. It takes forever (or never?) to complete. 2) An ARC case is brought for a FOSS item and has Big Rules integration. It takes forever to complete. 3) A project is secretly started behind SWAN that intends to follow #1 or #2, but no announcement is made and no-one externally is aware of it. If future ARC policy indicates that it's not a Big Rules integration, the project team may not even intend to bring the project for ARC review. In either case, a consumer/contributor may not want to wait, or if #3, may not even know a project is already underway. They may want to do as Alan did, and port/build themselves. What do they do with the resulting package? What happens when any of the 3 previous cases complete (possibly creating duplicate packages with incompatible integration/ARC expectation levels)? How can we prevent duplicate efforts? As for the first two cases, theoretically I suppose, you contact the original submitters and check status. If the answer is Real Soon Now, do you just have to wait, or can you say, I can port that FOSS in 2 notes and go ahead and put it in the unstable repo? For the 3rd case, I suppose you can simply announce your intention to port FOSS project Y on some list and if no one responds in a timely manner, proceed as the singular trailblazer and again, put it into unstable (or if intending Big Rules integration, see #1 or #2). I have heard mention of a big list of FOSS Wants. Is this published somewhere? If there is a big pipeline of FOSS stuff being targeted, shouldn't we be aligning that with the evolving ARC vs. FOSS integration effort? I know I've done a fair share of FOSS ports some years ago for my own personal pet projects (I even attempted, once, to try getting one of them into Blastwave and never followed through). I personally feel the barrier for publishing and then maintaining the port may be more challenging than the port itself -- especially if I had an itch to scratch and even went so far as to want to do Big Rules integration. What's the expectation for a contributor (grant or no) who wants to scratch an itch and then make it available for others via a Use-This-if-You-Dare repository? Mark ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Project planning and ARC/no-ARC integration (was was Alpine, now Exim...)
On Mon, May 5, 2008 at 12:21 PM, James Carlson [EMAIL PROTECTED] wrote: Mark Martin writes: How would you be more helped by an external repository that doesn't have Alpine in it than an internal repository that doesn't have Alpine in it? I'll let Alan answer that definitively, of course, but I took it to mean had/were an external repository been available, an external contributor could have posted the built bits once they'd done the port and build. You're assuming that the port was complete, and that the bits in the port were put into some suitable format (a package) in order to upload them somewhere. Correct. It's never as simple as just doing ./configure and make. If it were, then there'd really be no point in having a repository at all, as *anybody* can do that. Sometimes it is that simple, and probably more oft not. I disagree, though, that even if package-get = ./configure make make install that *anybody* can do that. Honestly, even that bar is very high for some users. One of the first hurdle is ./configure --? (--prefix=/usr/local | /opt | /usr/sfw | ?). Linux converts might make it, but even Portage and Ports wrap a lot of that away and we don't have either. Honestly, though, it often *was* that simple for me and for my uses, and before I knew about SFE and the like, I built at least a dozen things with minimal effort and stuck them on boxes throughout my LAN (and I did this because either they were either nascent or non-existent on Blastwave). I never bothered to package anything though. FWIW, I've been slowly becoming OpenSolarisized[1] on my building efforts. I've already worked out kinks for doing ON work, but I've recently been trying to get SFE builds working, and getting my environment sane for that build environment is challenging for the time I'm investing. It was never this hard when I assumed a GNU build environment for autoconf'd projects I'd grab. That's perhaps a topic for another day, though. It doesn't match anything like my experience. And I don't believe you can make those assumptions based on the evidence provide. I really was trying to speak from personal experience. I can honestly envision going for a weekend and grabbing Angband and Moria and half a dozen other games and porting them and throwing them *somewhere*. My apologies to Dennis if those are already in Blastwave -- I'm thinking IPS, anyways. I suppose I'm really vetting the transition through Expectation level, now that I'm thinking of it. Throwing them in Experimental because I want to not set an expectation level for them. Maybe later i can come and try to move them farther along towards Aggregated by doing ARCy stuff. I think FOSS is a red herring here. The problem is with projects that duplicate effort, no matter how they do it or where they find the source or what license it may have. The ARC-specific answer to this is to ARC early and ARC often. As soon as you have the inkling that you're going to port something, file a case. And if file a case means simply registering the project on a dashboard (self approve), then I agree. I don't think I want to bother filing 6 full cases[2] for simple projects like that, though. We really don't have the capability, currently, to scale to having all people file cases in this scenario -- which spawned the Expectation Taxonomy Definition effort. I guess it's registration/ARC case dashboard of bust here. The non-ARC question being asked here is (probably) should we have an external project request/signup dashboard? I think that'd be great to have. Something like http://arc.opensolaris.org/projects/ ? What's the expectation for a contributor (grant or no) who wants to scratch an itch and then make it available for others via a Use-This-if-You-Dare repository? Given that we have no such repository, I think establishing the repository in question (and the rules that govern it) is probably the first important task. It's hard to say what the expectation might be for a process that doesn't exist. Agreed. I'm just trying to provide some requirements thought. [1] Tends to prefer SunPro C/C++ over GCC. Tends to prefer particular workspace/build environments over one-off build scripts. Etc. [2] Even the short form can be tedious at times. Maybe LSARC 2008/061? -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Informal (and unsanctioned) poll
On Thu, Feb 28, 2008 at 12:23 AM, Ché Kristo [EMAIL PROTECTED] wrote: I too would like to see the results shared publicly. When do you plan on doing this? Given that it's ~44 hours since I started it, I suspect we're at the point of diminishing returns. Let me see how I can package the report for sharing (I'm thinking genunix). I can tell you what the response was so far: 69 respondents with 55 complete responses. Mark ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Informal (and unsanctioned) poll
On Thu, Feb 28, 2008 at 10:54 AM, Shawn Walker [EMAIL PROTECTED] wrote: Considering we have several thousand registered members on opensolaris.org; I think that makes any result a passing fancy at best. No doubt. Never suggested otherwise - especially since I can't even identify the audience that the request reached. This was for my own amusement and entertainment-value only. I got what I wanted out of it, and I thank anyone who took the time to throw a nickel in the slot. Mark ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Informal (and unsanctioned) poll
On Thu, Feb 28, 2008 at 10:33 AM, Mark Martin [EMAIL PROTECTED] wrote: Given that it's ~44 hours since I started it, I suspect we're at the point of diminishing returns. Let me see how I can package the report for sharing (I'm thinking genunix). A little over 48 hours run, http://cr.opensolaris.org/~devnull/polldaddy.html 65 completed responses (out of 79). I can show country breakdown if anyone's really that curious. No warranties, expressed or implied yada yada. Mark ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] One opinion for charting forward (long)
(my apologies for length and lack of 80 column widths) Ok, here's my opinion for what a CE distribution plan might look like. This is intended as just a strawman, and I'm ignoring for a second the availability of resources and the time it would take to accomplish these goals. Requirements: Build a community distro that preserves compatibility and stability guarantees (inasmuch as we can back such guarantees). Develop that distribution using existing infrastructure and resources. Devise the processes and tools needed to create such a distribution, and create a minimal set of support goals for users of such a distribution. Such a distribution would carry the endorsement of the general OSo community. Strategy: -Expand the Distribution Community's charter (if they'll accept it) to include formulating goals for how such a distribution might be constructed and what it's requirements might be. Work with the existing distributions where necessary and prudent to help shape those goals. Have the DC CG develop a set of guidelines and (if necessary) set of technical requirements for what a community built distribution might satisfy. Make the output of such efforts be guidance only. Perhaps I'm thinking more along the lines of a project here within the CG. For example: I, for one, believe Brian and Martin's proposal for Conary should be viewed on its merits. Even if it's not the right packaging platform upon which to base a community edition distribution, at least it's illuminating gaps and raising questions. Setting the criteria for what such a proposal could be judged against could be the outcome of the Distribution CG's Define-a-Distro-requirements project. -Ask the Testing CG to devise a strategy for quality assurance, focusing on some determined levels of compatibility and stability as they might devise. Again, make the output of such work intended as guidance and as high level as necessary (but no higher). It might be prudent, too, to ask that community to define just what compatibility might mean. Or perhaps that's a question better posed to the ARC? -Ask some community to start a project to evaluate what support options we might want to provide, and whether the existing infrastructure and resources are appropriate. -Continue John's trademark policy development project so that we may know what we can get away with when the time comes. -Ratify the output of the work products of these efforts with membership votes. The intent being that once the strategic goals and guidance are in place, they can be endorsed by a consensus of the community at large. -Optionally, the OGB can review whether the projects and communities that are hosting work on Indiana are aligned with the needs of the community, and act accordingly if they feel the groups and projects aren't behaving as chartered. Work on that product seems to be a polarizing facet of the community and obviously the community's stewards may act according to which side of the fence or spectrum the majority of the membership falls on. -Optionally, add another community (or project) perhaps called Glass elevator, which would be chartered to help determine agendas and drafting future vision for the community at large. One possible outcome of this project or group would be ideas for other projects that might be useful, fun, or strategic to have and wouldn't necessarily be driven by internal Sun agendas. The team working on the Innovation Awards produced a list of project ideas in a relatively short time frame. Perhaps it might be useful to do the same for not only projects but for other strategic goals as well, and provide a forum for people to offer and incubate ideas for innovation in a way OUTSIDE a contest. Having an endorsed set of standards and goals for how we might construct a community based distribution and an idea on how to assure the quality of such a distribution should go a long way towards setting high level goals (and therefore tasks) that the community can work towards. Until now, in my opinion, the bulk of work in this community was influenced by the following factors: Work initiated internally in response to defects that will eventually end up in Solaris.Now.patch or Solaris.Next. Work initiated internally in response to projects to add features or enhance the quality of existing features of Solaris.Now.patch or Solaris.Next Work initiated by external individual contributors that add functionality or enhance the quality of Solaris.Now.patch, Solaris.Next, or a 3rd party distribution For me, personally, there was an implicit assumption that if I fell into the last bucket, then 3rd party distribution would include something akin[1] to community driven Linux distributions like Debian or Gentoo or such. I always assumed that not only would this community enhance the entire set of products that make up OpenSolaris whole, but would also produce a user consumable distribution of same. I'm on the side of the fence that feels
[osol-discuss] Looking for access to development systems temporarily
I'm in the midst of working on a few defects and RFE's, and due to personal circumstances, have been left without access to my development systems for a period of many weeks. It doesn't look like I'll have much luck adjusting that situation for at least a few more weeks, so I'm wondering if anyone has a development instance resource that I could use in the meantime -- perhaps until I am able to bring my own systems back online? Specifically, I am looking for root access on a (virtual?) system that is running a recent build of snv (73?). Most of my defect fixes affect SMF processes and libraries, so even a property assignment without root is fine -- I will need to be able to term/start/suspend/resume svc.startd and friends. Of course, I'll also need to pull down the onnv gate and build with the appropriate tools. I am aware of the OS test farm, and may follow up with that project/group although I don't believe this is the intended purpose of those resources. Thanks, Mark ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Name Change?
On 11/1/07, Jim Grisanzio [EMAIL PROTECTED] wrote: John Sonnenschein wrote: I'm relatively sure I did name him, it's Murdock that betrayed the community with that announcement the other day so I'm going to place the blame at his feet. Your comments were unprofessional. It's ashame we are using this type of rhetoric to undermine each other. I don't agree with how the Indiana team has communicated any of this, but the bottom line is that the OGB has been silent and the Members have been silent, too. Jim, I would like to add to the point about the OGB and members being silent -- I'd rather see action at this point. I know I've personally been biting my tongue because there seemed to be plenty of flame fanning and partly because most of my own views seemed to be reflected in some of the arguments. I'd like to see the rhetoric surrounding the OGB's validity contradicted by action on their part, which I have faith will come soon enough. One thing I wish people will keep in mind: a) There's unrest, it's painfully obvious b) Our conduct and arguments here are public and may be lasting c) Other communities may be keeping a keen eye, how will they perceive the ability of the current membership to work through serious issues professionally? d) The cat is out of the bag on Indiana, further flaming about how it shouldnt' have been may not be helpful any futher Mark -- -- Born to the false world, the wanderer, Storyteller, The Pied Piper On a quest for immortality Gathering a troop to find the fantasy -- Nightwish ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [trademark-policy-dev] I guess the community decided to go with my original suggestion?
On 10/26/07, Shawn Walker [EMAIL PROTECTED] wrote: On 26/10/2007, Brandorr [EMAIL PROTECTED] wrote: I want the following distros to coexist: SolarisNG, OpenSolaris Distro - Indiana Belenix, OpenSolaris Distro - SolarisNG with KDE (or whatever Moinak and team want to do) Nexenta, OpenSolaris Distro - A backwards compatible Solaris distro that supports both SYSV and Debian packages, as well as SYSV/Solaris and GNU commands. MartUX, OpenSolaris Distro Shillix, OpenSolaris Distro Which is going to be incredibly confusing to users. When I go to Ubuntu.com, I expect to download something called Ubuntu. When I go to FreeBSD.org, I expect to download something called FreeBSD. ...the list goes on. I was thinking something along the lines of: http://www.eclipse.org/downloads/distros.php and http://www.eclipse.org/downloads/ Notice that in the first link there's little distinction amongst the distributions except for what's in their description. The list is even rotated (ostensibly to promote fairness). Yes, Eclipse ain't an OS, but to my mind, it at least approaches the complexity of distribution we're talking about. And FWIW, Eclipse is not my IDE/platform of choice. :) -- Shawn Walker, Software and Systems Analyst [EMAIL PROTECTED] - http://binarycrusader.blogspot.com/ Beware of bugs in the above code; I have only proved it correct, not tried it. --Donald Knuth ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org Mark -- -- Born to the false world, the wanderer, Storyteller, The Pied Piper On a quest for immortality Gathering a troop to find the fantasy -- Nightwish ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Mail list owners: SpamAssassin implemented; Action recommended
On 10/11/07, Eric Boutilier [EMAIL PROTECTED] wrote: Basic spam filtering with SpamAssassin is now running on the Mailman server. As a result, we recommend that mail-list owners (moderators) reinstate friendly handling of non-subscriber posts, as follows: Eric, Is the recent addition of SpamAssassin related the appearance of empty messages from *-discuss-bounces to: undisclosed recipients? These wonderful gems have started to appear in the last 2 to 3 days. Mark -- -- Born to the false world, the wanderer, Storyteller, The Pied Piper On a quest for immortality Gathering a troop to find the fantasy -- Nightwish ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
