Re: [osol-discuss] Database Server Community
Hello Radu, Wednesday, July 27, 2005, 1:28:08 PM, you wrote: RP Hi! RP I think a community that would cover the database installation, configuration and performance tuning on Solaris would be necessary. -1 I don't think it's needed - and performance issues could be discussed on general or performance related communities. While it's good that we're starting to have lot of communities I don't think it's good to create a community for every possible thread. -- Best regards, Robertmailto:[EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: Some impressions (ksh related)
Why? That's not that important. You can not know now what other distros will be good for. It could be that there is a distro you can put in your coffee-cup and that coffee-cup communicates with the computer you are in front of - so probably there is not enough space for ksh in such a distro at the first moment. Why??? Because backward as well as forward compatbility is one of the things that makes Solaris so great to work with and work on. It's one of Solaris core strengths, one that clearly differentiates it from everybody else out there (well, not everybody, HP and SGI also go through great pains and at great lengths to maintain compatibility). That sentence should really read: it's one of the strengths that differenetiates (Open)Solaris from all the other OpenSource / Freeware alternatives. And now OpenSolaris has this great chance, this great opportunity, to not only be extended but be backwards and forwards compatible with Solaris; it would really be a shame to just throw that out of the window for the sake of Linux-like progress. Even *BSD doesn't do something like that. There are at least two meanings of stability - keep old things working and let things work without problems. My focus is at the second variant, sure you are right. But there can be no true stability without one depending on the other in some way! Some things can not be replaced. But at least I do not see the need to replace it with compatible parts to Solaris 10. I see the need to find functional equivalent things. I hope those parts that need to be replaced are not too specific to the core of OpenSolaris. Any closed source application (as ksh) that can not be released to open source will die the dead of un-importance for the (outside SUN-) open source developers. Or you have to follow the Mozilla-history and do the task of open source it at SUN. This is really not right -- this is the mindset that would just go about breaking compatibilty for no reason other than to do it. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: Re: new community for Chinese users
Tian Siyuan wrote: The original poster is back. My idea is to have a place for Chinese users, mainly for education (and then marketing). If we other communities are better suitable for specific topics posted to this one, we can redirect them. What's the next step? There's been some discussion on this and some ideas. Which is the purpose of pinging the list about forming new communities, so that's good. A Chinese education community seems more than reasonable considerign the size of the market. For my understanding the proposed community is for academic opensolaris users(consumers) in school, am I right ? If this is the case then this community will be very specific which is not a bad thing. I am trying to related my past experience in academic and couldn't figure out much difference between academic and other computer consumers. I thought about it a while and couldn't figure out the answers for following question. What will be the main agenda for this group ? For example, Will this group work on more opensource (S/T) Chinese fonts ? This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Samba with Kerberos on OpenSolaris
On Thu, 2005-07-28 at 09:34, Markus Moeller wrote: If I use cc -I/usr/share/src/uts/common -D_KERNEL I find all included header files. What is the difference/issue if I use -D_KERNEL ? The header file you found is really only for the kernel-space gssapi code. it's not likely to be useful for userland builds which is what I think you're looking to do. In general: if you're not building an object intended to be part of a kernel module, don't use -D_KERNEL. (oversimplifying wildly, kernel and userspace code have different ABI's and may use different data structure definitions, etc.,) - Bill ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Interface Stability and OpenSolaris (was process)
Mike Kupfer [EMAIL PROTECTED] wrote: Joerg But currently, I don't believe that community driven integration Joerg is possible soon as there already is an aproval for star Joerg integration but asking about a realization did not end up in a Joerg useful discussion. Yes, and I apologize for the lack of communication. I've been wanting to follow up about star and your rmt replacement since the middle of the Pilot program, and I just never found the time. :-( If you have submitted a request to the request-sponsor alias and nobody has followed up with you, please let me and/or Jim Grisanzio know. That would be a bug that we (the Sun staff) need to fix. If you haven't submitted something to request-sponsor, please do that. And I will mail the ufs folks to encourage them to respond promptly. I did hear from Dworking and Frank that the idea that started 2.5 years ago has been ap[proved in spring. I don't know what to do now 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: User Groups Community Opened
Alan DuBoff wrote: On Wednesday 27 July 2005 04:49 pm, Jim Grisanzio wrote: Hello ... we formed a user group community here: http://www.opensolaris.org/os/community/os_user_groups/ snip This is excellent. A group is forming in Broomfield and setup a spot on google groups. Let's get them over to OpenSolaris Org, it's important we keep everything together. I replied to Lisa Week and mentioned that, but we need to ensure that this doesn't slip and fragment our communities, IMO. I'm going to cc Lisa on this, because I do feel so strongly about it, and the fact that Broomfield will most likely be one of the best attended groups that will form. Lisa, we'd love to have you guys join us on OpenSolaris Org if that's possible? Thanks for the update and yes it is possible for us to join. As you may have already seen from her email, Ginnie Wray ([EMAIL PROTECTED]) is going to be setting this up for the (Colorado) Front Range OpenSolaris User Group. Thanks, Lisa ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: Laptop Power Management? GUI or Shell based?
Is Solaris 10 considered Solaris Nevada (11) build 14 and later ? Thanx This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] wifi (was open source process)
Roy == Roy T Fielding [EMAIL PROTECTED] writes: Roy Any code that is not open source is dead code that needs to be Roy replaced, and the way to do that is by creating communities with Roy live code that can be worked on in public. The only code in Roy OpenSolaris is open source code. What about things like wifi drivers? I'm not an expert in the area, but I'm told that these drivers often contain a binary-only component (even in Linux). It's apparently the result of US (FCC) regulatory requirements on the wifi hardware. mike ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Interface Stability and OpenSolaris (was process)
Joerg I did hear from Dworking and Frank that the idea that started 2.5 Joerg years ago has been ap[proved in spring. Joerg I don't know what to do now I'm working to figure out who can act as a sponsor. Dworkin was a natural fit, but alas, he is leaving Sun soon. Once we've found a sponsor, that person can contact you to discuss the next step. mike ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: wifi (was open source process)
On Jul 28, 2005, at 10:47 AM, Mike Kupfer wrote: What about things like wifi drivers? I'm not an expert in the area, but I'm told that these drivers often contain a binary-only component (even in Linux). It's apparently the result of US (FCC) regulatory requirements on the wifi hardware. Then they aren't in OpenSolaris. Not being in our products doesn't mean they can't be downloaded from somewhere else or obtained as part of a proprietary distribution. Roy ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Laptop Power Management? GUI or Shell based?
Is Solaris 10 considered Solaris Nevada (11) build 14 and later ? Thanx No. Only current Solaris Express is. Casper ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: User Groups Community Opened
On Thursday 28 July 2005 09:37 am, Lisa Week wrote: Thanks for the update and yes it is possible for us to join. As you may have already seen from her email, Ginnie Wray ([EMAIL PROTECTED]) is going to be setting this up for the (Colorado) Front Range OpenSolaris User Group. Yes, I saw. Ginnie's good people. She came to my first Installfest I did away from MPK which was in Broomfield. Geez, that's been almost a couple years ago now. -- Alan DuBoff - Sun Microsystems Solaris x86 Engineering ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: Laptop Power Management? GUI or Shell based?
1. Sound: on a notebook I don't really care anyway; but it didn't work on my Fedora Core 4, eithe r; What type of sound? Tried oss? 2. Scroll bar on the touch pad: this is very important in web/file browsing; it works with FC4; WHat type? If Synaptics, it'll soon work. 3. Wi-Fi: never expected it to work; been thinking about getting ndiswrapper--anyone having any experience with this sucker on S/OS? We're hoping to release its code ported to Solaris soon too. 4. Power management: vidoe only blanks but won't turn off; same problem with FC4 What type of graphics; which driver do you use? 5. Suspend-to-RAM: biggest issue in Linux also No support for this at all; but we have people working on it. Casper ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Database Server Community
Hi! Sorry to ask are you a maintainer or a user expressing own opinion? TY Radu --- Robert Milkowski [EMAIL PROTECTED] wrote: Hello Radu, Wednesday, July 27, 2005, 1:28:08 PM, you wrote: RP Hi! RP I think a community that would cover the database installation, configuration and performance tuning on Solaris would be necessary. -1 I don't think it's needed - and performance issues could be discussed on general or performance related communities. While it's good that we're starting to have lot of communities I don't think it's good to create a community for every possible thread. -- Best regards, Robert mailto:[EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: User Groups Community Opened
Alan DuBoff wrote: On Thursday 28 July 2005 09:37 am, Lisa Week wrote: Thanks for the update and yes it is possible for us to join. As you may have already seen from her email, Ginnie Wray ([EMAIL PROTECTED]) is going to be setting this up for the (Colorado) Front Range OpenSolaris User Group. Yes, I saw. Ginnie's good people. She came to my first Installfest I did away from MPK which was in Broomfield. Geez, that's been almost a couple years ago now. And I still have that same little cantankerous system that you helped me install but more importantly, we're up on the Open Solaris community page! http://www.opensolaris.org/os/community/os_user_groups/frosug/ g ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: How would the ARC process look at this discussion of KSH 88-vs-93?
Which is exactly how things had been working in practise inside Sun. That's what I thought originally, but a lot of the posts I have seen are emphasizing the business decisions made by an ARC rather than the technical review. The only real difference with OpenSolaris ARCs should be that there is always a branch that has no interface constraints because that is the branch where new interfaces are created. For an operating system, the constraints of existing interfaces are a _technical_ problem, _not_ just a business problem. New interfaces obviously don't have these constraints, which is precisely why they must be developed so carefully -- today's new interface is tomorrow's constraint. - Bryan -- Bryan Cantrill, Solaris Kernel Development. http://blogs.sun.com/bmc ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: How would the ARC process look at this discussion of KSH 88-vs-93?
On Thu, 2005-07-28 at 14:38, Roy T. Fielding wrote: That's what I thought originally, but a lot of the posts I have seen are emphasizing the business decisions made by an ARC rather than the technical review. ARC is all about the technical architecture and almost always doesn't get involved in business processes - we take it into account but it isn't our charter to make decisions based on business input alone our key is the technical architecture of the system as a whole. The only real difference with OpenSolaris ARCs should be that there is always a branch that has no interface constraints because that is the branch where new interfaces are created. Thats not really an ARC issue thats a project team issue, each project team creates there own gate (branch I guess in your terminology), sometimes project teams need to sync between each others gates (for example during Solaris 10 development the main on10 gate was moving forward but there was cross gate syncing between the project gates for DTrace, Zones and the Cryptographic Framework and SMF). However everything in the main gate (eg ONNV) is reviewed and release quality at all times - this is what you see in Solaris Express today. Of course with OpenSolaris this could be up for review so it is just what we do today, that we believe should be able to work for the greater Internet connected developer community in the future. BTW, could someone please describe how many ARCs currently exist over the scope of Solaris? One. There is only one ARC, there are sub committees of the ARC and when Sun people write ARCs they mean these sub committees. Currently we have: FWARC, PSARC, LSARC, WSARC: FWARC - Firmware PSARC - Platform Services LSARC - Layered Software WSARC - Web Services. For the most part WSARC doesn't review stuff you see today in OpenSolaris but is mostly about the stuff in JES - but then Application Server and parts of Access Manager are open source under the CDDL license too. PSARC is where almost all of the currently visible bits of OpenSolaris are reviewed, ie mainly core OS and networking things. LSARC is where most of GNOME/StarOffice/Mozilla level things are reviewed. SNARC is currently in hibernation, but has been used to review hardware platform stuff particularly systems as a whole and networking hardware: mostly not relevant for OpenSolaris even if it was currently active. However we often have members from the various sub committees cross over to assist in the review of other projects - some times for no other reason than personal interest. -- Darren J Moffat ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Some impressions (ksh related)
On 7/28/05, Joerg Schilling [EMAIL PROTECTED] wrote: POSIX documentations (man pages) are written in a way that allows you to implement all features of the program from only reading the apropriate man page. I'm not certain how that point is relevant. All we know in this case is that ksh88 may or may not be documented well enough to reimplement compatability. Let's hope it is, and that the fine details can be sorted out with those that have source access. If it's really that important to anyone, someone will do it of that I'm certain. -- Shawn Walker, Software and Systems Analyst [EMAIL PROTECTED] - http://binarycrusader.blogspot.com/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: How would the ARC process look at this discussion of KSH 88-vs-93?
On Jul 28, 2005, at 2:46 PM, Bryan Cantrill wrote: For an operating system, the constraints of existing interfaces are a _technical_ problem, _not_ just a business problem. That is absolute rubbish. A technical problem is something for which a technical solution can be created to resolve the problem. An interface constraint is simply a decision not to change some aspect of the interface. It is no more of a technical problem than deciding whether you want to develop a word processor or a web browser. Discovering if an interface would be changed by an integration is a technical problem. An ARC review should certainly be looking for such changes. It is fine for incompatible changes to require a major revision number to change, but the decisions on whether or not to develop such a change and when to release new major revisions are *business decisions*. Those are Sun-internal Solaris decisions, not OpenSolaris-wide decisions. Therefore, OpenSolaris can let new development happen on an unstable next major release branch and only worry about the interface constraints when those changes are proposed for back-porting to a stable branch. New interfaces obviously don't have these constraints, which is precisely why they must be developed so carefully -- today's new interface is tomorrow's constraint. They have to be released carefully. We can have 100 monkeys typing away at the interface and that is fine -- it costs nothing until someone asks can I release this as version x.y.z?, at which point the new interface is going to have to satisfy whatever constraints the community wants to place on it. Roy ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: wifi (was open source process)
On 7/28/05, Tao Chen [EMAIL PROTECTED] wrote: On 7/28/05, Shawn Walker [EMAIL PROTECTED] wrote: I don't think that's a very practical view. There is a *lot* of hardware out there that cannot be used without some binary component. Not just wifi, but many others. Quite frankly, it should be more about the user and less about ivory tower academic principles. Taking the attitude of open source only or the highway sounds very noble, but it doesn't accomplish much. Many companies *will never* provide the necessary information to develop drivers for their hardware, whether because of legal obligations to others, *government restrictions*, or otherwise. I think many people are looking at the OpenSolaris project as one that is willing to support the user instead of taking the rather unhelpful attitude of no binary drivers that other operating system projects take. When it comes down to it, the user doesn't give a flying pig about whether a driver is binary only or not. They just want their hardware to work, and if binary only components is the only choice then it's a reasonable thing to accept to many of us. Those who don't like it can just not use that hardware, the rest of us would like our hardware to work out of the box :) I fail to see where you disgree with Roy's statement, unless your definition of OpenSolaris is different Roy's in this context. On 7/28/05, Roy T. Fielding [EMAIL PROTECTED] wrote: Then they aren't in OpenSolaris. Not being in our products doesn't mean they can't be downloaded from somewhere else or obtained as part of a proprietary distribution. Since any close source binary can be put into any OpenSolaris-based _distribution_ (up to the owner to decide), such as Solaris, what exactly is not practical? We simply can't claim the binary is _ours_ (the OpenSolaris community), i.e. belongs to the OpenSolaris (in its strict meaning), even if it's Sun's. That doesn't mean we cannot discuss it, test its integration with OpenSolaris, I suppose. The point is if a driver exists that can be integrated, but has a required binary only component due to legal or other restrictions and that is the only way that hardware will work, then to me and many others it is perfectly acceptable. This binary only component could be a rom that has to be loaded into flash memory, special software to initialize a device, or perhaps a TV-Out enabler. I don't expect 3rd party binary-only-in-every-single-way drivers to be integrated into the official OpenSolaris project since they're owned by a third party. However, I do expect drivers that are open except for one component or set of components needed to initialize the hardware or otherwise provide legally restricted functionality to be given the option of being included. Wi-Fi drivers are one of many very good examples. At the very least, it must be very easy for a user to install binary drivers, and not have to worry about recompiling their kernel or any of the other dreck that certain unnamed open source projects make their users go through. -- Shawn Walker, Software and Systems Analyst [EMAIL PROTECTED] - http://binarycrusader.blogspot.com/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: wifi (was open source process)
Tao Chen wrote: ... I am not familiar with the Wi-Fi issue. How is it handled by Redhat/SuSe/Debian right now, assuming it's not part of the Linux kernel? ipw2200.sourceforge.net et al have what some people refer to as a HAL (hardware abstraction layer) for the FCC-mandated non-changeable stuff as a binary. This gets linked in when the driver is built iirc. regards, James C. McPherson -- Pacrim PTS Engineer828 Pacific Highway Gordon NSW Sun Microsystems Australia 2072 ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: How would the ARC process look at this discussion of KSH 88-vs-93?
Roy ... a lot of the posts I have seen are emphasizing the business Roy decisions made by an ARC rather than the technical review. Bryan For an operating system, the constraints of existing interfaces Bryan are a _technical_ problem, _not_ just a business problem. Roy That is absolute rubbish... It is not rubbish; Bryan's comment is spot on given the constraints under which he is operating, which you appear not to be operating under. As long as `uname -r | cut -c1` reports 5, then Bryan's comment is accurate, whereas you seem to be coming at this from the more abstract it could be anything point of view. Now, whether or not to change it to 6 (or whatever) may be a business problem, but as long as it *is* 5, then various compatibility constraints are a technical problem. -- John ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: How would the ARC process look at this discussion of KSH 88-vs-93?
Roy == Roy T Fielding [EMAIL PROTECTED] writes: Roy On Jul 28, 2005, at 2:46 PM, Bryan Cantrill wrote: For an operating system, the constraints of existing interfaces are a _technical_ problem, _not_ just a business problem. Roy A technical problem is something for which a technical solution can Roy be created to resolve the problem. Okay. But the technical solution might be to design the change so as to maintain compatibility. Roy It is fine for incompatible changes to require a major revision Roy number to change, but the decisions on whether or not to develop Roy such a change and when to release new major revisions are *business Roy decisions*. I think this is the heart of the issue. Dealing with the transition from SunOS 4 to SunOS 5 was considered so painful that the people in charge (inside Sun) said never again. So it seems like Sun's options are - plan for the possibility of having a SunOS 6 someday - convince the community that there is sufficient freedom to do cool stuff while staying within the compatibility constraints currently used by Solaris[1] - be prepared for a fork mike [1]For what it's worth, there is some wiggle room. Interfaces that are tagged as Unstable can have incompatible changes in minor (dot) releases. Interfaces that are tagged as Obsolete can go away in a minor release. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: How would the ARC process look at this discussion of KSH 88-vs-93?
On Wed, Jul 27, 2005 at 06:08:12PM -0700, Roy T. Fielding wrote: The latter constraint of requiring a commit be complete is just as true for collaborative open source projects as it is for Solaris. Most open source projects are distributed on several orders of magnitude more platforms than Solaris, and thus sometimes don't discover a problem exists until it is distributed to some platform not owned by a developer on the project, but a general rule in Apache is that a change must be complete within the branch and platform on which the developer is working before they are allowed to commit even to an unstable branch. That might be acceptable for a project gate (unstable branch; see below for some thoughts on terminology), but I've lived through Linux development, where all x86 all the time is the unofficial official policy for all branches. Please please please don't ever suggest that this is a viable way to maintain support for multiple architectures. Many people are lazy, and will do as little as the process requires before putting back. If you allow them to break some second-class architecture, you are committing that architecture's maintainers, if they even exist, to additional and unnecessary work. If you allow more people to do the same, you are condemning those architectures to perpetual brokenness and eventual removal. There can be no second-class platforms. If a contributor doesn't understand what's needed to make his change work on $WEIRD_BUT_SUPPORTED_HARDWARE, he must collaborate with the people who support that platform to make it happen. A result of this is that the community as a whole needs to decide carefully what platforms it is willing to support - the cost of maintaining them can't be borne solely by the people who use them. The community has to decide whether it's better to have a few platforms that work well and are rapidly developed or many platforms that diverge, work poorly, or slow development. [... skipping the ARC review description because it was an example of a business decision, not a technical decision.] No, I'm sorry, architectural consistency and compatibility are examples of technical decisions. Suppose for a moment that there were no business, anywhere. Money does not exist and all software is available free of charge as open source. Under those circumstances, would compatibility and architectural consistency be of any value? The answer is yes: software still has users (not customers) and those users still have finite time to spend using or working on software (24 hours a day at most). They can spend that time finding and fixing or working around newly introduced incompatibilities, or they can spend their time using the software productively. The provision of compatibility and consistency under some kind of well-known rules provides value to developers and users higher up the software stack, regardless of what they paid for their software or whether they buy hardware or get it for free. The exchange is that people working lower down the stack have to invest additional effort into maintaining that compatibility; I posit that this tradeoff is a good one, because maintaining compatibility and announcing intentional incompatibilities involves knowns: known pieces of code, known documented interfaces, and known sources of information about them. The alternative involves unknowns: unknown new problems in apparently unrelated software, unknown side effects of apparently innocuous upgrades, and unknown - and unbounded - investment of time in finding and correcting these problems. It's easy but wrong to see this as a business problem - Sun's customers have money, for which they obtain the time of technical staff to develop software or install and manage it. Therefore they see a monetary cost in the use of incompatible software, and Sun sees an opportunity to make money by reducing our customers' costs. But that set of relationships is nothing but a derivative of the original relationships described above in terms of time. The problem of developing software that provides value to users and developers - which presumably includes the very people making the software in the first place since we're talking about open source - exists in terms of time regardless of business considerations. It is therefore a fundamental issue in software development, and thus a technical problem. Would it help to know that the ARC is staffed by engineers, not executives? I wonder if that's the source of worry here. 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
Re: [osol-discuss] Re: new community for Chinese users
Takaaki Higuchi wrote: 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 Sorry for the delay in following up on this. I have been working on this problem and have been meaning to respond. We encountered two problems when we set up the Chinese language lists. 1) The database was not originally configured to handle the Chinese character sets properly. This affects the web pages and the mail forums (Jive). We have a fix for this that has been tested and is working on our staging machines. We plan to roll it out on production next week (Wednesday or Thursday) 2) Mailman does not handle Chinese character sets out of the box (at least the versions of mailman Python we are using). We need to either add some codecs to our version Python or upgrade to Python 2.4. We are in the process of figuring out which will work better. Hopefully this will be resolved next week as well. Once we get it resolved, it should (hopefully) be easy to have one list in Simplified Chinese and one in Traditional Chinese. Derek 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 -- Derek Cicero Program Manager Solaris Kernel Group, Software Division ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: wifi (was open source process)
On Thu, Jul 28, 2005 at 06:12:55PM -0500, Shawn Walker wrote: The point is if a driver exists that can be integrated, but has a required binary only component due to legal or other restrictions and that is the only way that hardware will work, then to me and many others it is perfectly acceptable. This binary only component could be Obviously this is something people will disagree on. It's pretty easy to argue that the binary-only component isn't open in any meaningful sense; it can't be modified and it isn't a source of information. At the moment, some of them are needed to do useful and important things with OpenSolaris sources; perhaps that makes them part of OpenSolaris - which seems to be your position; perhaps it makes them second-class OpenSolaris adjuncts - which seems to be Roy's position (and in fact is mine as well). The difference seems solely semantic from where I stand, and whatever you call them, they need to be replaced as quickly as possible. a rom that has to be loaded into flash memory, special software to initialize a device, or perhaps a TV-Out enabler. I don't expect 3rd party binary-only-in-every-single-way drivers to be integrated into the official OpenSolaris project since they're owned by a third party. Yep. However, I do expect drivers that are open except for one component or set of components needed to initialize the hardware or otherwise provide legally restricted functionality to be given the option of being included. Wi-Fi drivers are one of many very good examples. And that's something we're talking about right now. For example, it seems to me that firmware is fair game for delivery in binary form; I don't likely have a compiler or assembler for it anyway and although I might like to change it there's no real argument that it's part of the operating system or even of the driver; it's equivalent to delivering code in a ROM, which is part of the device. Of course, if you wanted to claim that your hardware's implementation is open source, you'd need to deliver that in source form. Anyway, I'd be thrilled - ecstatic, really - if we could move all hardware vendors to this position. Far too many pretend that the address of the register you diddle to start DMA is some kind of valuable secret. At the very least, it must be very easy for a user to install binary drivers, and not have to worry about recompiling their kernel or any of the other dreck that certain unnamed open source projects make their users go through. And on that we all (I'd hope) agree - and this is one of the benefits of offering a stable DDI. Another, even more important one (to me personally, not necessarily to Sun) is that it makes maintaining open source drivers easier too! -- 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] Re: User Groups Community Opened
On Thursday 28 July 2005 13:24, Virginia Wray wrote: And I still have that same little cantankerous system that you helped me install Sun needs to get you a new laptop! but more importantly, we're up on the Open Solaris community page! http://www.opensolaris.org/os/community/os_user_groups/frosug/ Excellent! You're ahead of us...:-/ -- Alan DuBoff - Sun Microsystems Solaris x86 Engineering - Sun on Sun is the way of the future! ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: How would the ARC process look at this discussion of KSH 88-vs-93?
On 7/28/05, John Plocher [EMAIL PROTECTED] wrote: [stop, stop, you are bringing out the verbose monster in me!] snip You are advocating starting off the OpenSolaris community on a track that immediately abandons this core value. I disagree (obviously), and instead advocate keeping the core value, and leaving the question of creating a new major branch to the point in time where we find something that - in our community's considered opinion - can not be done under our current constraints. Opening Pandora's box and intentionally throwing away one of Solaris's key features seems extremely shortsighted, not to mention counterproductive. +1 -- 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: Proposal of new community for Solaris x86 device driver
On Jul 25, 2005, at 1:12 PM, Keith M Wesolowski wrote: 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. ksh93 is pretty darn stable, if you ask me. 12 years stable. Are the people who write scripts for the sake of portability refusing to support the Solaris platform because it is stuck with an ancient, non-standards-compliant copy of ksh? Or do they just ignore Sun and move their business elsewhere? There comes a point in any business wherein compatibility with the future becomes more important than compatibility with the past, and I'd say that point was passed for ksh about 9 years ago. The fact that Solaris failed to keep up with the times should not be considered a good thing -- Sun loses customers because it is tremendously difficult to administer a system wherein 1 out of 3 system utilities have to be replaced by their more modern open source equivalents before you can start building applications. Being worried about scripts written by people running older versions of Solaris is a Sun business concern that does not apply to people who have yet to install SchilliX. It is, in fact, of far greater value for SchilliX to support all the users who want to migrate from Linux and have a bunch of ksh scripts written for ksh93. Though, quite frankly, this whole discussion is a bit obscure because I don't know anyone who writes ksh specific scripts (just sh scripts that happen to work in ksh). Of course, that too isn't a straightforward problem because some Linux distros use pdksh and other use ksh93. See, e.g, http://www.dbforums.com/t1163962.html but wouldn't it be nice if we gathered together all of the remaining OS groups and managed to all agree on ksh93 being the only standard from that point on? 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. No, the point of this thread is that viable options are dependent on your existing customer base, which is a business decision. Compatibility is a great thing, but it is not the only concern. 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. Inclusion in Solaris is not the same as inclusion in OpenSolaris. 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. Nor does it have to be entirely done by Sun. 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. That is what Jörg was asking for at the beginning of the thread. It was the statement that we couldn't possibly *start* such an activity until after it had been approved by Sun's ARC process that caused me to enter the discussion. Roy ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: How would the ARC process look at this discussion of KSH 88-vs-93?
John: I hope that: One of those core values will be backwards compatibility is a constraint, not a goal. This implies that it is seen as a feature (and not a bug) that there is no Major version development branch following the current production branch. I very much agree that interface stability and backwards compatibility is one of the things that makes Solaris (and hopefully OpenSolaris) a great operating system. Creating a framework for OpenSolaris to integrate code in ways that ensure interface stability is a great thing. However, I see a lot of problems with the approaches that seem to be evolving out of this discussion. For one thing, it seems that we are suggesting that OpenSolaris should be bound to interface stability issues for non-free interfaces found in Solaris. The ksh example is a good one. How can OpenSolaris be made into a usable operating system if the only way to fill the gaps is to create what you are calling a 2nd order fork. While it is certainly reasonable for a project to make and abide by a stability promise in order to get into OpenSolaris, it is not reasonable to expect that the Free Software community will spend time re-implementing old interfaces just to have something like ksh on the system. . It isn't clear to me how the Free Software community will even have a reasonably chance of getting things right if we expect them to be bound to non-free Solaris interfaces. Is Sun prepared to enumerate and document such expectations to the OpenSolaris community? It seems to make more sense to allow the OpenSolaris community to add the reasonable free software replacement for such components to OpenSolaris. Of course, it is reasonable to expect that they will have to make stability promises and abide by them to get them into OpenSolaris. Such bits should not need to conform to non-free Solaris interfaces. This probably means that such new bits of OpenSolaris will eventually become SunOS 6. After all, the last time there was a major release of Solaris was in the stone age, I mean the early 90's, and if Sun believes that that the evolution of OpenSolaris will not cause a major release down the pike, I think Sun has its head in the clouds. This is a dramatic change, and will likely warrant some significant interface impact. Obviously SunOS 6 will be backwards compatible with SunOS 5 for those components that Sun contributed into OpenSolaris, so SunOS 5 can continue to take new code from OpenSolaris for these pieces. In other words, the interface breakages between SunOS 5.0 and 6.0 should only be those bits to fill in the gaps to make a reasonable free operating system. At some point, migrating to 6.0 and having a more usable free software stack will likely become the right decision. It will likely be less a headache than the SunOS 4-5 transition since OpenSolaris will serve as a beta-test for the new interfaces and issues will get resolved in OpenSolaris before Sun would pull them into a SunOS 6. This seems a more workable model to me, than expecting the community to figure out how to get things into OpenSolaris without breaking Solaris interfaces that don't exist in OpenSolaris. You are advocating starting off the OpenSolaris community on a track that immediately abandons this core value. I disagree (obviously), and instead advocate keeping the core value, and leaving the question of creating a new major branch to the point in time where we find something that - in our community's considered opinion - can not be done under our current constraints. Opening Pandora's box and intentionally throwing away one of Solaris's key features seems extremely shortsighted, not to mention counterproductive. The only thing we need to agree on as a community is what the version numbers mean, and thereby allow integrations like Solaris to choose which product versions to include in which release. In addition, we obviously need to agree on a set of guiding principles and core values. I very much agree, but it seems just backwards to try and bind OpenSolaris to Solaris constraints. Instead OpenSolaris should be free to define its own constraints in areas where there is no free alternative. Especially when the Solaris rules are buried in ARC cases which are not yet visible to the OpenSolaris community. Refactoring all ARC case information so it is usable by the OpenSolaris community is probably not a reasonable task. Are we going to expect the OpenSolaris community, for example, not to break contract private interfaces between two Solaris modules? Replacing one component with a free alternative may meet all public/Stable interface requirements, but break things badly on Solaris due to private contract interfaces that the OpenSolaris community wouldn't even know about. It seems more reasonable for OpenSolaris to set the stage for interface change, and Solaris can adopt the interfaces that make the most sense for Sun customers, just like any other
