Re: [osol-discuss] Re: new community for Chinese users
Hi, This was already discussed at [EMAIL PROTECTED] And decided to have both. But there seem some troubles on Chinese languages as described the URL below. http://www.opensolaris.org/jive/thread.jspa?threadID=1206tstart=0 regards, Takaaki Higuchi(http://blogs.sun.com.thiguchi) TJ Yang wrote: Looks like this thread went digressed. Will there be forum for Chinese users ? Also if there is a need to create discussion forum for Chinese users then please create two forums. One is Simplify Chinese and one is Tranditional Chinese. T.J. Yang ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Debian with OpenSolaris: a broken dream
Shawn Walker [EMAIL PROTECTED] wrote: On 7/22/05, Alvaro Lopez Ortega [EMAIL PROTECTED] wrote: The biggest CDDL problem is that it includes a choice-of-venue: «The problem with choice of venue clauses is that anyone who accepts the license must also accept the burden of defending themselves against charges of license violation in a court which is likely to have an implicit bias in favor of the copyright holder» ... Pardon if I'm wrong, but from the way I understand it: they fail to mention that the reverse is true without a choice-of-venue clause. Meaning that the person that has to defend themselves can that might be biased against the license holder. Either way, someone's going to be unhappy. I can't imagine that clause being put in there without good reason. +1 Correct: People who demand to forbid a choice-of-venue, advocate those people who like to sue the authors of free software and those who like to violate the the Copyright or the license. Don't trust single persons on the Debian mailing lists. Debian accepts the CDDL as a free license. 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
Re: [osol-discuss] Re: Re: Re: Proposal of new community for Solaris x86 device driver
They're shipping ksh93, which is open source. Solaris includes ksh88 (g I believe), which is not. We'd love to just upgrade, but they're not 100% compatible. In the document: http://www.kornshell.com/info/ it says it's compatable. Just curious what the big compatiblity problems are? Sun technically ships ksh93 in the form of 'dtksh'. I can imagine if you have to open ksh88 up it's going to be a bumpy road. If I remember correct it's got Novell copyrights all over it. What programs are at risk if it was upgraded to ksh93? It says that it is but it is not. (It's mostly compatible and that's just not good enough; a few environment variables behave differently, for one) Casper ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Why I do think OpenSolaris ought to work with Debian
Keith M Wesolowski [EMAIL PROTECTED] wrote: On Fri, Jul 22, 2005 at 02:39:09PM -0500, Shawn Walker wrote: justifiably or not is a matter of opinion. Even if the CDDL wasn't an obstacle, I don't believe they would accept the binary redistribution guidelines that parts of ON will likely always be under. Such fatalism! You have the freedom to write compatible (or incompatible if you really want) replacements for those components. We'll always have these binaries reflects conscious choice, not immutable laws of physics. This is what I frequently read on Linux related lists but people don't do it unless they have a personal interest in doing so... If all all OSS users were enthusiasts, we had more free software. The big problem is that the OSS motion did create a lot of lazy people who just wait for things to happen and who demand for new solutions istead of creating solutions. 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
Re: [osol-discuss] Re: Re: Proposal of new community for Solaris x86 device driver
They're shipping ksh93, which is open source. Solaris includes ksh88 (g I believe), which is not. We'd love to just upgrade, but they're not 100% compatible. We can certainly ship ksh 93 as /bin/ksh93. It would be nice if we could somehow qualify the differences and have a single binary which detects how it is invoked so that the compatible extensions are available to ksh users. Casper ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] how long before we stop doing...
Shawn Walker wrote:
On 7/23/05, Sunil [EMAIL PROTECTED] wrote:
grep pkg-name /var/sadm/install/contents |awk '{print $1}' to see which
files were installed by a package? when is this simple request going to be merged in 'pkginfo
-l'?
Workaround example:
pkgchk -v SUNWGtku
Another useful option is
pkgchk -l -p fullpath filename
which is equivalent to
rpm -qf filename
-Ghee
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Debian with OpenSolaris: a broken dream
Glynn Foster wrote: So, let us not get so caught up in the numbers game. I'd just like to see a Companion DVD worth of optional open source software comparable to what you get when buying a Linux/FreeBSD at a computer store or buy it from Sun (with those Ultra 3 laptops!!!). Hey, 1K-3K packages is good enough for me if I'm going to use that many packages in my lifetime! +1 [Okay, so this mail was slightly pointless, but it really feels like Ken has hit the mark on another important point to note from this thread] A DVD full of software is interesting, but it is far from having a repository updated constantly with security fixes, new versions and new packages. IMO, people who are used to work with the repository model will not fill comfortable with just a DVD. -- Greetings, alo. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Debian with OpenSolaris: a broken dream
Ferdinand O. Tempel [EMAIL PROTECTED] wrote: Like I said earlier, both camps (opensolaris and debian) aren't too thrilled about the idea. I've already discovered that. The good news is that debian-legal finally pointed out the exact problem with the CDDL as it relates to the DFSG, instead of just saying they don't know and throw it on incompatibilities with the GPL. What I see is the opinion of a single person not the official opinion or Debian. Why dou you believe otherwise? 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
Re: [osol-discuss] Debian with OpenSolaris: a broken dream
Joerg Schilling wrote: If you look closely, there are a few paragraphs about taking kernels and building the Debian OS around those kernels (Debian GNU/OpenSolaris = Solaris kernel with Debian infrastructure (OS w/ported apps) built around it). I think the NetBSD people are doing something like this as well. So, we take out the Linux kernel and just compile the same Debian sources around the Solaris/OpenSolaris kernel. You cannot do this because the Debian people apply patches on the sources that are Linux specific and in many cases are known to break compatibility with other platforms like Solaris. Debian building system is powerful enough deal with this kind of situations. There are people working on the NetBSD port, so Debian is open to work on that way. Of course at this moment they are more concern about Linux, it is their primary kernel, but it should not be a problem for the rest of architectures. -- Greetings, alo. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: Proposal of new community for Solaris x86 device driver
On Jul 25, 2005, at 2:36 AM, [EMAIL PROTECTED] wrote: They're shipping ksh93, which is open source. Solaris includes ksh88 (g I believe), which is not. We'd love to just upgrade, but they're not 100% compatible. We can certainly ship ksh 93 as /bin/ksh93. It would be nice if we could somehow qualify the differences and have a single binary which detects how it is invoked so that the compatible extensions are available to ksh users. Why does it have to be 100% compatible? That is a serious question. What breaks so bad that not having access to the source is considered a viable solution? We must have a reasonable plan for progressing from closed binaries to open source. That means there will be compatibility risks and we must live with that fact -- staying put in a land of 100% backwards compatibility is death. We can address those risks by installing the current open source versions ASAP and addressing backwards-compatibility issues as they are discovered and determined to be worth addressing. If there is a serious compatibility issue, then Solaris can replace the new executables with ones that are 100% backwards-compatible. There is no reason for OpenSolaris to be so hobbled. Roy ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Debian with OpenSolaris: a broken dream
Joerg Schilling wrote: Like I said earlier, both camps (opensolaris and debian) aren't too thrilled about the idea. I've already discovered that. The good news is that debian-legal finally pointed out the exact problem with the CDDL as it relates to the DFSG, instead of just saying they don't know and throw it on incompatibilities with the GPL. What I see is the opinion of a single person not the official opinion or Debian. Why dou you believe otherwise? Good point Jörg! I have pinged them again. This time, I have asked for the Debian official position about the CDDL. -- Greetings, alo. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: Proposal of new community for Solaris x86 device driver
On Jul 25, 2005, at 2:36 AM, [EMAIL PROTECTED] wrote: They're shipping ksh93, which is open source. Solaris includes ksh88 (g I believe), which is not. We'd love to just upgrade, but they're not 100% compatible. We can certainly ship ksh 93 as /bin/ksh93. It would be nice if we could somehow qualify the differences and have a single binary which detects how it is invoked so that the compatible extensions are available to ksh users. Why does it have to be 100% compatible? That is a serious question. What breaks so bad that not having access to the source is considered a viable solution? Well, it certainly needs to be for a Solaris release. The problem with shells is that scripts are written so there's a body of code which may depend on this behaviour. We'd love to replace /bin/sh also, but ... We must have a reasonable plan for progressing from closed binaries to open source. That means there will be compatibility risks and we must live with that fact -- staying put in a land of 100% backwards compatibility is death. We can address those risks by installing the current open source versions ASAP and addressing backwards-compatibility issues as they are discovered and determined to be worth addressing. Absolutely; but if we can replace /bin/ksh with a dual mode binary which can do both. If there is a serious compatibility issue, then Solaris can replace the new executables with ones that are 100% backwards-compatible. There is no reason for OpenSolaris to be so hobbled. Depends on whether OpenSolaris sees 100% (backward) compatibility as a constraint or just a goal. I think some in the community see it more as a constraint; and they also see that as one of Solaris' selling points. But others may differ. Casper ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Debian with OpenSolaris: a broken dream
On Mon, 25 Jul 2005, Alvaro Lopez Ortega wrote: Glynn Foster wrote: [...] I'm just pointing out, that the average user will probably not even use close to 3000 packages - if we can focus on a good set of packages, and maintain with a repository model it seems like a better situation until we develop a big enough user/developer base. Do you want to do that inside the OpenSolaris community? In my opinion, it makes much more sense to relay that work on some packaging experts: Debian and Gentoo are my favorites. We care about the software and they care about compile and distribute it in the way the community is used to get it. It seems to me that a Debian/Solaris repository initiative should reside on debian.org; a JDS and/or SPS repository initiative should reside on opensolaris.org, a Portage/Solaris repository initiative should reside on gentoo.org; etc. Eric ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Solaris Express 7/2005 Released
Ben Rockwood wrote: Alan Coopersmith wrote: The next release of the nVidia driver should install the PCI id's for GeForce cards/chipsets as well as the Quadro ones it currently does. Has there been any reaction from nVidia thus far? I'd think of adding the id's for GeForce as a sign that they were impressed by the acceptance. Actually I think it was more a sign of our people and theirs getting tired of answering how to enable it with GeForce cards and how to recover when people tried to bind the video driver to their PCI bridge or other devices on nForce motherboards, and the higher levels in management deciding usability might be more useful than strict support enforcing. (They were originally left out so that the users would have to manually take a step to acknowledge the devices were officially unsupported.) -- -Alan Coopersmith- [EMAIL PROTECTED] Sun Microsystems, Inc. - X Window System Engineering ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: Why I do think OpenSolaris ought to work with Debian (fwd)
Hi Rod, Thanks for the detailed response. Of course I agree that it's better to avoid the problem by carefully controlling public interface changes. However more and more software in Solaris comes from external sources and while we can work with community maintainers and try and make sure they follow similar standards, ultimately it's their call. This is the point where some people would say that it's our (Sun's) call whether we update their packages in Solaris or stick to the previous version and apply our own bug fixes as needed, but that's wrong. Because of the complex network of dependencies, we are often required to update otherwise we can't build some other package. And neither can our customers. So we can't break the interfaces we'd shipped but we can't not update either. My favourite example is libxml2. Critical parts of ON depend on it, so it was declared Standard. However GNOME requires the latest and greatest. So, if there's an ABI breakage [happened before] that would break ON, we can't update. Not being able to ship GNOME on Solaris is also not an option. So what can we do? Ship a private copy of libxml2 with GNOME. Blastwave will have to do the same. And others too... What I'm getting at is, if you don't want to update and don't want to duplicate, you'll end up with even more duplicates, and in an ad-hoc manner. So I still think that well controlled and documented duplication is this the only way in these cases. I'm not taking about duplicating every single open source library, only the ones we are not allowed to break and only when the community maintainer breaks it and refuses to fix it. How to do this, or whether it's possible to do it correctly is another question. I don't know enough about this topic to make any suggestions. Thanks, Laca On Sat, 2005-07-23 at 12:56, Rod Evans wrote: Laca wrote: As far as I understand, the main problem with multiple versions (apart from the increased maintenance effort) is that different versions of the same lib may end up linked to the same executable (through dependent libs) and it'll cause unpredictable runtime linking and most likely a crash. There are a number of issues with multiple versions. The user if often left to discover that multiple versions exist, and then asks what's the difference, or more importantly, which one am I supposed to use. They you have to locate the version you need. And then comes the issue of what happens when multiple versions get loaded in the same process. There can be a larger maintenance/decision-making process for the user than there is for the maintainer of the multiple versions. It's a long shot, but would it be possible to enhance the linker/runtime linker to have some sort of namespacing that would enable it to work correctly with multiple versions? We've considered this path a couple of times, but keep returning to the same questions. If you had multiple versions how do you tell someone which one to use? Sadly many developers of shared objects don't even establish the dependencies they need. They make reference to foo() and expect it to materialize at runtime (typically because of the dependencies established by the application itself). What version of foo does the shared object get in this case? And how do we find alternative libraries? $ORIGIN helps, but we still live in a world dominated by wrapper scripts and LD_LIBRARY_PATH settings. An observation is that most users don't know of multiple versions of a library until their app breaks. Breakage which can be subtle and very hard to debug. Then we can give them the tools and information to build against differing versions. But this occurs after the upheaval of the breakage. This doesn't make happy users. Although developers exist who could manage multiple versions, I think most of our developers (the big customers - the ones that make all the noise when something breaks :-) don't want to know. They build apps from multiple, asynchronously delivered components, and don't have a clue what depends on what. They want to call foo, they want us to find it, and they expect foo to continue working as it always has. So, with these issues, we've focused our energies on maintaining single instance, compatible objects. This isn't easy, which accounts for some of our review processes. It puts the burden on the library developer, rather than back on the user - as it is a burden to the customer to decide what versions to use. We've tried hard to define our public interfaces, we don't allow them to change, we minimize exporting data, etc. etc. Lots of tricks to try and insure an object doesn't change but can still evolve in a compatible manner. We haven't always got it right either, and the desire to evolve a library in some manner has been hindered by the compatibility requirement. We do have some tricks up our sleeves. You can isolate objects into groups, use
Re: [osol-discuss] Re: Why I do think OpenSolaris ought to work with Debian
On 7/25/05, Joerg Schilling [EMAIL PROTECTED] wrote: Keith M Wesolowski [EMAIL PROTECTED] wrote: On Fri, Jul 22, 2005 at 02:39:09PM -0500, Shawn Walker wrote: justifiably or not is a matter of opinion. Even if the CDDL wasn't an obstacle, I don't believe they would accept the binary redistribution guidelines that parts of ON will likely always be under. Such fatalism! You have the freedom to write compatible (or incompatible if you really want) replacements for those components. We'll always have these binaries reflects conscious choice, not immutable laws of physics. This is what I frequently read on Linux related lists but people don't do it unless they have a personal interest in doing so... If all all OSS users were enthusiasts, we had more free software. The big problem is that the OSS motion did create a lot of lazy people who just wait for things to happen and who demand for new solutions istead of creating solutions. I of course never said that it was not possible to provide open source replacements. However, not all of us have the necessary skills like Joerg to write replacements for libm or even far more complicated components. There's also the issue of sorting out specific binary compatabilities, and so forth. I would rather spend my time getting a working distribution than worrying about re-inventing the wheel to replace specific binary-only components when they already work just fine...that's all. -- Shawn Walker, Software and Systems Analyst [EMAIL PROTECTED] - http://binarycrusader.blogspot.com/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: Re: Re: Feature request
If the space is mapped by the kernel, you can use /dev/allkmem so, if the kernel maps the APCI tables, they should be visible there. (If they're not mappable, then /dev/mem should not give access). max On Jul 23, 2005, at 11:54 AM, Martin Cerveny wrote: 2) xsvc is a hack that should be replaced by a proper /dev/mem I think /dev/mem is unusable, /dev/mem maps the most of RAM/RWM memory and not ROM/FLASH (or RAM/RWM copy of ROM/FLASH) memory where APCI tables reside. /dev/mem is driven by 'phys_install' memlist ( http:// cvs.opensolaris.org/source/xref/usr/src/uts/common/io/mem.c#633 ). You can see actual memlist with mdb ( echo 'phys_install::walk memlist | ::print struct memlist address size' | mdb -k ). M.C 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] Etymology of BFU
From: Bryan Cantrill [EMAIL PROTECTED] Subject: Re: [osol-discuss] Etymology of BFU To: [EMAIL PROTECTED] (Rich Teer) Date: Sun, 24 Jul 2005 12:59:39 -0700 (PDT) Cc: opensolaris-discuss@opensolaris.org, [EMAIL PROTECTED] (Jeff Bonwick), [EMAIL PROTECTED] (Roger A. Faulkner) Hi all, A quick question for you: what definition of BFU came first: Blindingly Fast Upgrade, or Bonwick Faulkner Upgrade? Just curious. I had always been led to believe that both were just more palatable names retrofitted on to BFU after it was in widepread use -- and that the original name was (as you'd expect if you know Bonwick) Big F'ing Upgrade. But Jeff or Roger can obviously answer for certain; they're cc:'d... - Bryan It was 1993, during the development of Solaris 2.3, when Jeff and I came up with bfu. We needed a faster way to upgrade people's workstations (otherwise, we had to wait four weeks between the time we put something back and the time it became available as a netinstall image). At that time, the nightly build produced cpio archives of everything it built that night. We used these archives to populate idle disks on test machines, but nothing else. It occurred to me that, since cpio doesn't overwrite any files (it creates new files and renames them into place), I could do this operation to a running system. I tried it and it worked (for some definition of 'worked'), but the configuration files were a problem. I told Jeff, and he said You're doing WHAT? Are you insane? Then he applied his natural talent to the problem and, with a few back-and-forth iterations between us, we came up with a shell script to do the job better than just using cpio. But we needed a name for the script (we came up with a few pretty lame names that we were unhappy with). Then, as we were walking with a bunch of irreverent kernel engineers from Building 5 in the Mountain View campus to Building 12 (the lunch room), we told them about it. At this time, there were several BF* things, including BFM (Big F'ing Make, the nightly build). [We measured the speed of a machine in units of BFM's per day.] So Jim Voll (no longer at Sun, but well and fondly remembered) declared, So it's a BFU! and the name received all-around approval. On that same trip to the lunch room, Jeff and I cleaned it up a bit to be either Blinding Fast Upgrade or Bonwick-Faulkner Upgrade, but everyone remembers Jim Voll's original. At that time, it was a bit of a pain to deal with merging the old and new (replaced by the upgrade) configuration files, so bfu was really only usable by experienced engineers. Also, Jeff wrote up the documentation for it, including the wonderful section about UFS bungee jumping (what happens if the system loses power while in the middle of copying in a cpio archive?). Since that time Jeff has improved bfu a lot and made it more reliable, and it has become one of the mainstays of Solaris development, both kernel and user-level. Everyone is expected to make appropriate changes to bfu when they integrate some big wad that requires it, so it's no longer Jeff's or my baby. Roger ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Why I do think OpenSolaris ought to work with Debian
Joerg Schilling wrote: Did you compile them yourself? . or do you just asume that it was simple to compile them because you did see the binaries made by other people? Of course, I do know how the Debian packaging system works. Otherwise I would remain in silence. Once a package is ported it wouldn't be a big issue to keep it building over its new releases. What you have to do is write down The Debian people don't port to Solaris but to Linux. They even usually apply patches that cause the the software to fail on any other platform because they don't care about other platforms. They only care about Linux because it is the only well supported architecture inside Debian; it makes sense. Anyway, that is not a rules. I mean, if we work to get OpenSolaris as another well accepted arch on Debian, that behavior will change. There are another accepted architectures in which some people are working on. I think it is a really good sign and probes that Debian is not so Linux-centric. :-) -- Greetings, alo. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: Proposal of new community for Solaris x86 device driver
On Jul 25, 2005, at 9:52 AM, Keith M Wesolowski wrote: What Alan was saying is that once a definitive list of differences exists, it should be possible to implement a clean set of extensions to ksh93 for backward compatibility; that implementation could then be used by Solaris and included with OpenSolaris for other distributions to use as well. No, we cannot work that way. OpenSolaris has to lead Solaris in all respects, including the development of revisions to existing executables. The code has to go into OpenSolaris first, developed to the point where it is compatible, and then used by Solaris in some future release. The folks building the Solaris distribution are fully capable of writing a shell script that selectively chooses what to include in Solaris based on Sun's business requirements. Solaris cannot be placed in a position where it determines the contents of OpenSolaris. That is a dead-end exercise of tossing code over the wall whenever Sun sees fit, which is the antithesis of what we are trying to do with the OpenSolaris communities. Roy ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: Proposal of new community for Solaris x86 device driver
Keith What Alan was saying is that once a definitive list of differences Keith exists, it should be possible to implement a clean set of extensions Keith to ksh93 for backward compatibility; that implementation could then be Keith used by Solaris and included with OpenSolaris for other distributions Keith to use as well. Roy No, we cannot work that way. OpenSolaris has to lead Solaris in all Roy respects, including the development of revisions to existing executables. Roy The code has to go into OpenSolaris first, developed to the point where Roy it is compatible, and then used by Solaris in some future release. The Roy folks building the Solaris distribution are fully capable of writing a Roy shell script that selectively chooses what to include in Solaris based Roy on Sun's business requirements. Roy Solaris cannot be placed in a position where it determines the contents Roy of OpenSolaris. That is a dead-end exercise of tossing code over the Roy wall whenever Sun sees fit, which is the antithesis of what we are Roy trying to do with the OpenSolaris communities. I have two problems (or potential problems) with your assertions. The first is that all the mechanisms which you rail against are in fact how things work now. Your statement of how things should work matches my understanding of how things ought to work in the *long* term, but we have a lot of short- and medium-term work to do before we get there, and much of that work may be somewhat challenging. So we need to recognize that the development processes for Solaris in the past to a large extent continue into the present and can only change so quickly in the near future. The second is that you sound[1] awfully inflexible. While it is good to have such noble goals, given where we are, being too rigid in the short term may not be a Good Thing. So I would encourage flexibility and open-mindedness as we try to move from the dark past thru the dim present to the (hopefully) bright future. -- John [1] I fully recognize that e-mail is a difficult medium for communicating certain thoughts and feelings; apologies if I am inferring a different tone that you intended. :-) ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re[2]: [osol-discuss] snv_b18 on Acer 4101WLM notebook
Hello Casper, Friday, July 22, 2005, 9:24:06 PM, you wrote: Hello opensolaris-discuss, I tried to install b18 on Acer 4101WLM notebook with Pentium M (Sonoma) 1.6GHz with 512MB DDR2 and PCI-X. Just after kernel started it panics, stack looks like: kaif_enter+7 kdi_dvec_enter+0x32 panicsys+0x36f vpanic+0xbd panic+0xf die+0xa7 trap+0xfc8 _cmntrap+0x9a 0xdabfa7e9 specfs'spec_access+0x1f fop_access+0x18 vn_openat+0x287 copen+0x24f open+0x18 sys_call+0x104 CDSC You're not the first one; and we believe that this is a memory CDSC corruption issue. (It probably happens again when autopush CDSC opens /dev/sad/admin) CDSC Now if only we could get a core dump out of this; that would likely CDSC require a netboot and a net core dump and even then I'm not sure we'd CDSC be quick enough. It's not my notebook but I think I could try again. Now, how can I make crashdump over the network during boot? but of course as you pointed it could crash before it's possible to core over the net... Anyway I'm willing to help (very limited access to the notebook). -- Best regards, Robertmailto:[EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] snv_b18 on Dell Inspiron 8200
Hello opensolaris-discuss, I tried to install snv_b18 (and 17 - the same result) on Dell Inspiron 8200 - I get system panic at the very beginning of booting. S10 03/05 works out of the box. I belive that initial SX builds worked too. kaif_enter+7 kdi_dvec_enter+0xa debug_enter+0x32 panicsys+0x36f vpanic+0xbd panic+-xf die+0xc1 trap+0xe88 +cmntrap+0x9a lookup_one+0x19 kobj_lookup_all+0x39 do_symbols+0x99 do_common+0x15 kobj+load+module+0x1e1 mod_load+0xe7 mod_hold_loaded_mod+0x23 mod_load_requisite+0x1a do_dependents+0x98 kobj_load_module+0x1d5 mod_load+0xe7 mod_hold_installed_mod+0x1f modrload+0xe3 modload+0x10 psm_modload+0x37 startup_modules+0xfb startup+0x1e main+0x1b 0xfe800342(fe80) _kobj_boot+0x441 0x1d9(fe86e1f0) 0x1007f21() 0x172() -- Best regards, Robert mailto:[EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: Proposal of new community for Solaris x86 device driver
On 7/25/05, Roy T. Fielding [EMAIL PROTECTED] wrote: On Jul 25, 2005, at 9:52 AM, Keith M Wesolowski wrote: What Alan was saying is that once a definitive list of differences exists, it should be possible to implement a clean set of extensions to ksh93 for backward compatibility; that implementation could then be used by Solaris and included with OpenSolaris for other distributions to use as well. No, we cannot work that way. OpenSolaris has to lead Solaris in Please, let's avoid the we word. I have no problem with working whatever way is required. It doesn't matter to me if Solaris leads OpenSolaris or the other way around. Your ideas are noble, but please don't assume that everyone has to work the way you say they do. -- Shawn Walker, Software and Systems Analyst [EMAIL PROTECTED] - http://binarycrusader.blogspot.com/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] snv_b18 on Dell Inspiron 8200
On 7/25/05, Robert Milkowski [EMAIL PROTECTED] wrote: Hello opensolaris-discuss, I tried to install snv_b18 (and 17 - the same result) on Dell Inspiron 8200 - I get system panic at the very beginning of booting. S10 03/05 works out of the box. I belive that initial SX builds worked too. snip Let's move this to opensolaris-help, please remove opensolaris-discuss from the to or cc lines in any further replies. To answer your question, we need more info, see this blog entry: http://blogs.sun.com/roller/comments/dmick/Weblog/diagnosing_kernel_hangs_panics_with -- Shawn Walker, Software and Systems Analyst [EMAIL PROTECTED] - http://binarycrusader.blogspot.com/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Solaris Express 7/2005 Released
Alan Coopersmith wrote: Actually I think it was more a sign of our people and theirs getting tired of answering how to enable it with GeForce cards and how to recover when people tried to bind the video driver to their PCI bridge or other devices on nForce motherboards, and the higher levels in management deciding usability might be more useful than strict support enforcing. (They were originally left out so that the users would have to manually take a step to acknowledge the devices were officially unsupported.) Regarding the PCI IDs, my personal opinion is that there should be a way for device driver writers (including those that originate at Sun) to add PCI IDs for supported devices and PCI IDs for devices that are not supported, but are known to (mostly) work. Perhaps there should be an /etc/driver_aliases_unsupported that throws INFO messages about lack of support into syslog. :) I don't know what the solution is, but there should be something. It's not necessarily any better for people to be hassled in order to have stuff work OOB. That tends to just detract from OpenSolaris more than protect the driver writer IMHO. - Matt -- Matt Ingenthron - Technical Specialist, Web Services Sun Microsystems, Inc. - Client Solutions http://blogs.sun.com/mingenthron/ email: [EMAIL PROTECTED] Phone: 310-242-6439 ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Gosling on Source Code Management
fyi ... James Gosling is looking for feedback on source code management: http://blogs.sun.com/roller/page/jag?entry=happily_subversive I just thought I'd kick the link to the list since this issue is critical for us here on OpenSolaris. If you like, let him know what you think. Jim ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] open source process
On Jul 25, 2005, at 10:43 AM, John Beck wrote: The first is that all the mechanisms which you rail against are in fact how things work now. Yes. I intend to change that. Your statement of how things should work matches my understanding of how things ought to work in the *long* term, but we have a lot of short- and medium-term work to do before we get there, and much of that work may be somewhat challenging. Like what? I believe that the first step to getting to where you want to be is to try to get there right now. Assuming that it can't be done just because it seems like a big change is a non-starter. We won't find out until we try. What exactly is blocking us from creating a directory containing ksh93 code and making it the current ksh for OpenSolaris? So we need to recognize that the development processes for Solaris in the past to a large extent continue into the present and can only change so quickly in the near future. Why? The second is that you sound[1] awfully inflexible. While it is good to have such noble goals, given where we are, being too rigid in the short term may not be a Good Thing. So I would encourage flexibility and open-mindedness as we try to move from the dark past thru the dim present to the (hopefully) bright future. My participation in OpenSolaris is conditioned on a number of statements by Sun regarding the nature of this project. If those statements are false, my participation will end quite abruptly. You may consider that to be inflexible. I consider it to be simple time management -- I have better things to do than convince a recalcitrant and conservative organization to adhere to its own press releases. OpenSolaris is intended to be a collaborative project. In order to collaborate with the rest of the world, future progress has to be made in public, using public tools, on public work products. Any code that is not open source is dead code that needs to be replaced, and the way to do that is by creating communities with live code that can be worked on in public. The only code in OpenSolaris is open source code. Determining what parts of that code are actually used by proprietary distributions like Solaris is not our community's responsibility. The CAB has been asked to create a governance process in which collaboration can thrive. While there are several ways we could approach such a process, none of them involve creating a state wherein Solaris business decisions determine what can or cannot go into OpenSolaris, since that is not collaboration. Roy ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: Proposal of new community for Solaris x86 device driver
On Mon, Jul 25, 2005 at 03:48:52AM -0700, Roy T. Fielding wrote: Why does it have to be 100% compatible? That is a serious question. What breaks so bad that not having access to the source is considered a viable solution? 100% compatibility is not always required. Sometimes, no compatibility is required at all. See the interface stability taxonomy in chapter 7 of the developer's reference. ksh, unfortunately, is Stable. Nothing I said should be interpreted to mean that not having source is acceptable. You're overlooking the point of this thread: that neither staying closed nor breaking compatibility are viable options. The right solution is to do the necessary work to reimplement sufficiently compatible functionality that can be integrated into OpenSolaris - which means open source. We must have a reasonable plan for progressing from closed binaries to open source. That means there will be compatibility risks and we must live with that fact -- staying put in a land of 100% backwards compatibility is death. We can address those risks by installing the Risks, yes. Those risks can be mitigated through the ARC process and other reviews. There is no '100% backwards compatibility' guarantee associated with either Solaris or OpenSolaris as a whole; that would stifle development. There are, however, compatibility constraints on some components. As I've explained many times in similar threads, this does not preclude the implementation of open-source alternatatives to replace existing code. All it means is that the implementation must be complete and sufficiently compatible by the time it goes back. If there is a serious compatibility issue, then Solaris can replace the new executables with ones that are 100% backwards-compatible. There is no reason for OpenSolaris to be so hobbled. Compatibility is a value that Solaris engineers, users, and third-party developers share. This community and the Solaris community overlap almost completely; therefore it is unlikely that you will find support here for destroying compatibility. That the contents of a putback can be made open is a necessary *but not sufficient* condition for their suitability for inclusion. Let's be frank: Sun will be investing a good deal of effort in replacing some of the closed code with open equivalents. This process will not be completed overnight, as much as we might like it to be. In a perfect world, it would have been done before launch; as it is, we worked our asses off to make available what's there today. But not only Sun should participate in this process; elsewhere in this thread someone has helpfully posted a list of ksh93 incompatibilities. The ksh93 sources are available to the world, and a motivated individual with access to both those sources and that list of incompatibilities could certainly create a ksh93 that, when invoked as ksh, operates in the same way as Sun's ksh88. Following review, that ksh would be added to OpenSolaris and would appear in subsequent releases of SchilliX, Solaris, and any other distributions. All this development could be done in the open, like any other project. -- Keith M Wesolowski Sir, we're surrounded! Solaris Kernel Team Excellent; we can attack in any direction! ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Debian with OpenSolaris: a broken dream
Hey, A 'DVD worth' doesn't necessarily mean it has to be the only medium. I'm just pointing out, that the average user will probably not even use close to 3000 packages - if we can focus on a good set of packages, and maintain with a repository model it seems like a better situation until we develop a big enough user/developer base. Do you want to do that inside the OpenSolaris community? Either way, I'm not fussed. We have to focus on the long term goals - how we actually get there is a completely different thread from my point of view. So a little story to compliment this, would be Jeff Waugh's GNOME Marketing talk at GUADEC. Previously, everyone had been discussing this great big GNOME 3.0 plan - how they could change the user interface, break all the libraries, turn things on their head. It was all going to be amazing. But who was going to suffer? But that's why it was immediately moved to be called Project Topaz [TPZ = Three Point Zero, with some vowels], so that people would move away from that, and look towards the long term goals of where we needed and wanted to be, rather than the free for all that everyone was thinking - and the hundreds of users that would ultimately suffer. And then Jeff turned everything on its head once more, with one simple slide - 10x10 10% of the global desktop market by 2010. That's the goal - now work on how to get there. In my opinion, it makes much more sense to relay that work on some packaging experts: Debian and Gentoo are my favorites. We care about the software and they care about compile and distribute it in the way the community is used to get it. Absolutely - but without the full committed support of a substantial number of people from Debian/Gentoo, I think that's going to be an uphill battle. I also wonder what the messages we're sending out to our customers with such a step. I don't know - maybe I'm being overly pessimistic. I'd just like us to focus on a goal, focus on the key players that we already have, and focus on what technology we already have. Seems like there is more value to creating a unified community initially, rather than creating a distributed one. Glynn ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] open source process
On Mon, Jul 25, 2005 at 12:30:19PM -0700, Roy T. Fielding wrote: OpenSolaris is intended to be a collaborative project. In order to collaborate with the rest of the world, future progress has to be made in public, using public tools, on public work products. Any code that is not open source is dead code that needs to be replaced, and the way to do that is by creating communities with live code that can be worked on in public. The only code in OpenSolaris is open source code. Determining what parts of that ... The CAB has been asked to create a governance process in which collaboration can thrive. While there are several ways we could approach such a process, none of them involve creating a state wherein Solaris business decisions determine what can or cannot go into OpenSolaris, since that is not collaboration. Compatibility constraints are technical, not business decisions. The standard GNU approach to compatibility is that everything in the world is and must be open source, and that therefore source compatibility is sufficient. We could argue forever about whether that's a good model, but there are two reasons it's not in this case the right argument: 1. *This* community has different values from GNU. Is compatibility more important to us than openness? Probably not, though it might be to some subset of people at Sun. But they might well be equally important. A person who believed that would be willing to work *with* Sun, not against us, to find solutions that simultaneously satisfy both constraints. This is the kind of collaboration to which I believe you're referring here. 2. ksh isn't something for which source compatibility is sufficient or even meaningful. Even if your scripts are all open source, you'd still have to change any of them relying on changed behaviour. Sometimes you don't even know which those will be. In short, such an incompatible change could result in a lot of work and breakage for users. Why make users do more work so we don't have to? That's not just bad for business; it's also discourteous, lazy, and wrong. -- Keith M Wesolowski Sir, we're surrounded! Solaris Kernel Team Excellent; we can attack in any direction! ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] open source process
On Mon, 2005-07-25 at 15:30, Roy T. Fielding wrote: What exactly is blocking us from creating a directory containing ksh93 code Nothing. We should probably import ksh93 as ksh93 sooner rather than later. and making it the current ksh for OpenSolaris? One of the goals for opensolaris is compatibility with solaris. We're not starting with a blank slate. I don't think switching to ksh93 is out of the question but our practice is to avoid rushing into these things without understanding the incompatibilities. But I went googling for differences and found a pretty significant one: It looks like ksh88 uses dynamic scoping while ksh93 uses lexical scoping. As I understand it, a similar disagreement caused something of a schism within the lisp community. This won't matter for many scripts. But any script which uses local variables may well trip over this, and the behavior change will be hard to diagnose if you're not aware of the incompatibility. - Bill ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: open source process
JBeck Your statement of how things should work matches my understanding JBeck of how things ought to work in the *long* term, but we have a lot JBeck of short- and medium-term work to do before we get there, and much JBeck of that work may be somewhat challenging. Roy Like what? Like migrating an organization of 600+ (Sun) engineers from working in a closed environment like it has for the past many years into working in the open. Like coming up with a development model which allows for this migration and scales with the huge additional number of (non-Sun) contributors we expect. Like bridging the gaps between those of us who have common goals but disagree on the ways to achieve them. All of this is achievable, but I expect it to be challenging. Roy I believe that the first step to getting to where you want to be is Roy to try to get there right now. For smallish (in size or in scope) changes, I agree. But that does not seem to scale to larger changes. A journey of a thousand miles must begin with a single step. Roy Assuming that it can't be done just because it seems like a big change Roy is a non-starter. We won't find out until we try. We seem to agree that we can/should/must get to an open development model, but we seem to disagree on how quickly. The reasons I think this will take a while are: * the (large) size of Sun's developer base * the (small) amount of resources committed to OpenSolaris, * the fact that in the short term we are constrained by those resources * human nature JBeck So we need to recognize that the development processes for Solaris JBeck in the past to a large extent continue into the present and can only JBeck change so quickly in the near future. Roy Why? See above. -- John ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Interface Stability and OpenSolaris (was process)
Roy: On Jul 25, 2005, at 10:43 AM, John Beck wrote: The first is that all the mechanisms which you rail against are in fact how things work now. Yes. I intend to change that. Everybody involved with Open and Free software is involved with changing how things work. I think it is great that people are getting involved with OpenSolaris. Remember that how things work now is evolving. Hopefully, we can figure out how to change things so that we create a new system that works best, taking the right directections from both within and outside of Sun. One area that should receive careful consideration has to do with interface stability. When this issue comes up, a lot of people seem think its boring and if ignored, it will hopefully go away. I suspect that the quickest roadmap to resolving many OpenSolaris issues that are worming below the surface is to tackle this process isssue. Within Sun, certain processes are defined by the ARC (Architectural Review Committeee) to help ensure interface stability. Over the past year, I have been working with the Sun ARC chairs to determine how free software, OpenSolaris, and interface stability process will all get along. One of the areas that Sun believes it adds value to the OS market is stability and support. Therefore, Sun makes more effort than many BSD or Linux vendors to map out the stability/supportability of interfaces that we ship. You will notice that any Sun manpage contains an Attributes section which should highlight to the user whether or not they should consider using (e.g. linking against) any given interface. Within Sun, teams who are responsible for including Open or Free Software in Solaris (GNOME, evolution, mozilla, others) have had difficulties working with the interface stability process. To fix these problems, the review process will have to evolve. This evolution could be easier if there is also interest from the Free/Open Software community. Therefore, within Sun there are two kinds of free software. The first kind is software that meets reasonable interface stability requirements well enough to feel comfortable assigning them a Stable classification. Typically, the need for interface stability is only needed for projects that contain interfaces that users/ISV's might depend upon. This type of software is distributed in packages that start with the SUNW prefix. The second kind of software is the software that starts with the SFW prefix (but is sometimes referred to as Companion CD or /opt/sfw. These are applications that are provided to Solaris users but do not contain any interfaces considered by Sun to be Stable. Solaris users are discourged from using interfaces that do not meet Solaris stability requirements, and I believe this rule will also apply to OpenSolaris. Therefore, if a Free/Open Source project wants to get into Solaris/OpenSolaris and receive that exposure, they should see the value in meeting such requirements. Aside from exposure, having clear and effective interface documentation is obviously a good best practice. I am currently working with the GNOME community to try and get a better handle on what Stability means, and to encourage the GNOME community to strengthen their interface documentation on the live.gnome.org Wiki. Interface documentation requirements are included in this document, and would apply to any project wanting to be included. You can read more here: http://live.gnome.org/InterfaceSpecification Your statement of how things should work matches my understanding of how things ought to work in the *long* term, but we have a lot of short- and medium-term work to do before we get there, and much of that work may be somewhat challenging. Like what? I believe that the first step to getting to where you want to be is to try to get there right now. Assuming that it can't be done just because it seems like a big change is a non-starter. We won't find out until we try. What exactly is blocking us from creating a directory containing ksh93 code and making it the current ksh for OpenSolaris? Nothing is really blocking moving ksh93 code into Solaris. However, it is necessary to go through an interface review process that highlights how well ksh supports the current interfaces. If no interfaces break (including environment variable interaction, ABI, man page is accurate with new features, etc.), then replacing an application like ksh is fairly easy. If there are differences, then these are discussed in the review process and certain resolutions might be necessary (fixing issues with ksh as bugs) or some broken interfaces may be considered acceptable. If the ksh93 program has good interface documentation already, then going through a review process should be easy enough. If not, then those people interested in bringing it into OpenSolaris may have some footwork to do to meet documentation requirements. To make things interesting, Sun realizes that it's review process will need
Re: [osol-discuss] Re: Re: Proposal of new community for Solaris x86 device driver
On Mon, 25 Jul 2005, John Beck wrote: Keith What Alan was saying is that once a definitive list of differences Keith exists, it should be possible to implement a clean set of extensions Keith to ksh93 for backward compatibility; that implementation could then be Keith used by Solaris and included with OpenSolaris for other distributions Keith to use as well. Roy No, we cannot work that way. OpenSolaris has to lead Solaris in all Roy respects, including the development of revisions to existing executables. Roy The code has to go into OpenSolaris first, developed to the point where Roy it is compatible, and then used by Solaris in some future release. The Roy folks building the Solaris distribution are fully capable of writing a Roy shell script that selectively chooses what to include in Solaris based Roy on Sun's business requirements. Roy Solaris cannot be placed in a position where it determines the contents Roy of OpenSolaris. That is a dead-end exercise of tossing code over the Roy wall whenever Sun sees fit, which is the antithesis of what we are Roy trying to do with the OpenSolaris communities. I have two problems (or potential problems) with your assertions... Funny thing is (and the crux of this misunderstanding): there isn't any such thing as OpenSolaris per se in the context in which Roy used above. There is Nevada -- which is Sun's distro -- and there is SchilliX -- which is the SchilliX team's distro. So in anticipation of an official OpenSolaris distro being created (in that oh-so-notorious not-too-distant-future), Roy's statement from above: Solaris cannot be placed in a position where it determines the contents of OpenSolaris Gets a big +1 from me in advance! ;-) Eric The first is that all the mechanisms which you rail against are in fact how things work now. Your statement of how things should work matches my understanding of how things ought to work in the *long* term, but we have a lot of short- and medium-term work to do before we get there, and much of that work may be somewhat challenging. So we need to recognize that the development processes for Solaris in the past to a large extent continue into the present and can only change so quickly in the near future. The second is that you sound[1] awfully inflexible. While it is good to have such noble goals, given where we are, being too rigid in the short term may not be a Good Thing. So I would encourage flexibility and open-mindedness as we try to move from the dark past thru the dim present to the (hopefully) bright future. -- John [1] I fully recognize that e-mail is a difficult medium for communicating certain thoughts and feelings; apologies if I am inferring a different tone that you intended. :-) ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] open source process
Bryan Cantrill [EMAIL PROTECTED] wrote: But I went googling for differences and found a pretty significant one: It looks like ksh88 uses dynamic scoping while ksh93 uses lexical scoping. As I understand it, a similar disagreement caused something of a schism within the lisp community. This won't matter for many scripts. But any script which uses local variables may well trip over this, and the behavior change will be hard to diagnose if you're not aware of the incompatibility. Bill's argument is not a theoretical one; these changes _do_ matter and they _do_ break people. As one example, Tim Bray took Solaris to task for not supporting % as an alias for %% in bash: http://www.tbray.org/ongoing/When/200x/2005/02/27/Linux-Solaris There is a big difference between the bash case and the ksh case. For bash there is a legal source available and it is possible to retain compatibility. But even with bash: if Sun does not inform us about propblems we OpenSolaris developers will use the offocial source and if this causes a problem and if Sun Solaris thus deviates from e.g. SchilliX, it is a failure at Suns side and not a failure from the SchilliX development. For ksh88 there is no legal source and from my understanding there is not even the possibility to redistribute binaries. If Sun believes that there are problems with incmpatibilities, Sun would first need to identify all possible incompatibilities. The next task could be to decide whether to live with the incompatibilties and to change to ksh93 immediately or to provide a legal backward compatible solution based on ksh93 sources. Note that we OpenSolaris developers have no choice! We need to supply a ksh with OpenSolaris and the only legal ksh for ur is ksh93. If Sun does not like to deviate from OpenSolaris based distros like SchilliX, it is up to Sun to provide a legal solutuion. Let me note about another problem: I did try to discuss important issues several times and have been ignored. When I later tried to use a more direct and explicit wording, I have been personally attacked by people (although not from Sun). There are a lot of issues we need to solve with OpenSolaris. If it is impossible to discuss these issues, I need to decide myself. Note that if there is no reaction on an attempt to discuss things and if I thus decided myself, I would call this a vote for my proposal by abstinence. 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
[osol-discuss] How would the ARC process look at this discussion of KSH 88-vs-93?
Keith and Roy's conversation about ksh... Keep in mind the traditional Sun/Solaris development model that we are trying to seed our community with: Germinate an idea into a plan, Commit to that plan from both resource and technical perspectives (do we _want_ to do it? and is this the _best_ way to architect it?) Develop/implement to that plan Integrate the result into the FCS all the time shared source base How does this differ from other FOSS projects? Primarily in the proactive nature of the commit to a plan before starting, and requiring that a project be complete before allowing integration. The former is simply good software engineering - know what you want before you start hacking; the latter helps us avoid the reactionary integration fire drills that often accompany not ready for prime time putbacks/commits. I can imagine two different proposals coming out of this discussion: A) We should develop an extension to ksh93 that allows it to be used as a Stable replacement for ksh88 in places where backwards compatibility is required (i.e, such as when invoked as /bin/ksh) while exposing all the latest features when compatibility is not required (such as when it is involved as /bin/ksh93). This new shell would expose the following interfaces: /bin/kshStable /bin/ksh93 Stable or B) We should make an incompatible change to the existing Stable ksh interfaces provided by a binary-only closed source component. This proposal would replace the existing ksh (ksh88) with an unmodified ksh93. This new shell would expose the following interfaces: /bin/ksh (ksh88) Obsolete/Removed (was Stable) /bin/ksh (ksh93) Stable If this were an ARC review, one of the proposals would be formally submitted for review and commitment. As the discussion of the merits and risks of the proposal progressed, I would hope that the core value of avoiding gratuitous incompatible changes to Stable interfaces would be in everyone's mind. After the dust settled and a formal opinion was rendered, I would expect the following results: Proposal A: Approved for a minor release of OpenSolaris/ON -or- Proposal B: There are three possible outcomes, of which B.3 is the most likely: B.1) Denied because of the incompatibilities, or B.2) Approved for release in a Major incompatible release of OpenSolaris/ON (at Sun, such a release could be expected to happen soon after hell froze over :-) It may be that the CAB/community might decide to go down this route; I hope we don't. B.3) Approved for a minor release of OpenSolaris/ON with a Technical Change Required to the spec to provide a compatibility mode, such as in Proposal A. Continuing this model the expected behavior example, now that we have a committed plan, what would we do next? One possibility: Create a teamware child workspace (or CVS branch or ...) Gather a group of interested developers together to work on this project Seed this workspace with the ksh93 sources Get it to work Start building in the dual mode behavior Develop - Test - Iterate... until complete, Request permission to Integrate the changes back into OpenSolaris Integrate/Putback/Commit... When looking at this discussion in this light, I don't think that Keith and Ray are that far apart - both want the same results in the end: Reduce the quantity of closed-source that is required to make Open Solaris usable to zero, Improve the features in Open Solaris, and Don't screw it up in the process. -John ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Interface Stability and OpenSolaris (was process)
So, this all begs the question, why isn't Sun making more of an effort to define a workable OpenSolaris process for interface review. There should be something on the http://www.opensolaris.org/ website addressing this topic, even if it just says We are working on figuring it out. Here are the difficulties. Help us. In order for OpenSolaris to be collaborative, we really need to spell this out. Yes, it definitely would be good to post some current status on the website which we'll do shortly. The effort to define a set of processes is actually underway already and there will be some discussion with the CAB next week at OSCON and I personally hope that we can post the material under discussion in the same time period for discussion. In this particular case, we have been working on defining a long-term development process for OpenSolaris although some of the low-level details (for example, the implemtentation details on how interface review will be done, what tools would be used, etc) will be defined later. dsc ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] open source process
Joerg Schilling wrote: Let me note about another problem: I did try to discuss important issues several times and have been ignored. Never attribute to malice that which can be adequately explained by stupidity. Ignored sounds so premeditated and malicious; more likely the lack of response is the result of everyone being very busy with their own urgent tasks such that nobody has the responsibility to track and monitor this kind of issue. As a meeting facilitator, I've often found it useful to maintain a parking lot of important topics that - because of the flow of discussion - would get lost or ignored if they were not written down. Maybe you could find a way to use the BugTracker and/or the OpenSolaris web site/wiki to maintain such a list of issues. Expecting others to track and remember everything mentioned in email threads such as this one will always lead to frustration. -John ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
