Re: [ksh93-integration-discuss] Re: [osol-discuss] Formal Proposal : Port OpenSolaris to PowerPC
But why is SUNW so uninterested??? Where is your vision of ^^We strongly believe in One Solaris^^ now? There is a lot of history there and it is hard to change. I'm sure they don't want to ship on Xorg on SPARC which only supports older framebuffers poorly so a lot more work is involved. Are you afraid of publically being expected to opensource all your (mostly eol'ed) gfx drivers? Or is it that you yourself don't believe in sparc anymore. I will better stop here. I wished, you truly meant it 100.00% serious with above vision. _No_ exceptions: Just as you said it(!). We're serious but it's a matter of resources. It's also not possible to opensource everything (OpenSourcing costs time and effort and sometimes you spend those resources only to find out that you cannot open source the drivers. Martin Bochnig marTux p.s.: Is SUNW interested in GRUB2 on sparc? We finally could boot from USB mass storage then. We're working on something akin newboot for SPARC; how would grub2 on SPARC allow for booting from USB? Grub2 would need to be loaded from somewhere else first. Casper ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] link aggregation failed on T2000 boxes (T1 8cores CPU), Sol 10
Hi,all: I tried to install solaris 10 on a T2000 boxes (T1 8 cores,32 multi-threading CPU) in recent days, after installation, I tried dladm to test the 802.3 link aggregation,but failed, error msg is : bash-3.00# dladm create-aggr -d ipge0 -d ipge1 1 dladm: create operation failed: No such file or directory (invalid interface name) bash-3.00# dladm show-link ipge0 type: legacymtu: 1500 device: ipge0 ipge1 type: legacymtu: 1500 device: ipge1 ipge2 type: legacymtu: 1500 device: ipge2 ipge3 type: legacymtu: 1500 device: ipge3 Anyone can give me a hint? p.s. if I configurate the link aggregation successfully, can I configurate the several zones on this new aggregated link? just like ipge1:1ipge1:n? b/r oxy ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: [networking-discuss] link aggregation failed on T2000 boxes (T1 8cores CPU), Sol 10
Oxy Hazard wrote: Hi,all: I tried to install solaris 10 on a T2000 boxes (T1 8 cores,32 multi-threading CPU) in recent days, after installation, I tried dladm to test the 802.3 link aggregation,but failed, error msg is : bash-3.00# dladm create-aggr -d ipge0 -d ipge1 1 dladm: create operation failed: No such file or directory (invalid interface name) bash-3.00# dladm show-link ipge0 type: legacymtu: 1500 device: ipge0 ipge1 type: legacymtu: 1500 device: ipge1 ipge2 type: legacymtu: 1500 device: ipge2 ipge3 type: legacymtu: 1500 device: ipge3 The interfaces you have are legacy devices, not GLDv3 (Nemo) devices. Currently only drivers written in GLDv3 can do link aggregation using dladm create-aggr. But I agree that the error message should be more informative. - Cathy ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: Re: [ksh93-integration-discuss] Re: [osol-discuss] Formal Proposal : Port OpenSolaris to PowerPC
Original-Message Date: Fri, 28 Jul 2006 10:45:31 +0200 From: [EMAIL PROTECTED] To: Martin Bochnig [EMAIL PROTECTED] Subject: Re: [ksh93-integration-discuss] Re: [osol-discuss] Formal Proposal : Port OpenSolaris to PowerPC But why is SUNW so uninterested??? Where is your vision of ^^We strongly believe in One Solaris^^ now? There is a lot of history there and it is hard to change. Migrating from Xsun to Xorg did work on x86. What lot of history do you mean exactly? (okay, /dev/fb is different on x86, and vga text mode etc.) I'm sure they don't want to ship on Xorg on SPARC which only supports older framebuffers poorly so a lot more work is involved. What are you referring to? You hopefully do not mean the old unsupported opensourced Xsun shipping together with Xorg. That one truly only supports older framebuffers. Very old ones. However, I'm talking about Xorg here, not Xorg's co-shipping Xsun. Do you consider Elite3D, Creator3D, PGX, PGX24, PGX32, PGX64, XVR-100, (maybe also XVR-500 / not yet here to test that again) older frame buffers ?? They all work quite well with Xorg on sparc (only afb and ffb perform poorly as you say, because accelleration does not yet work). Well I know, most of them are EOL now (except the XVR-100). But - on the other hand - certainly 90% (my personal guess) of the existing sparc user base does have one of them. Didn't you see my various Xorg announcements? We're serious but it's a matter of resources. It's also not possible to opensource everything (OpenSourcing costs time and effort and sometimes you spend those resources only to find out that you cannot open source the drivers. Is it also a matter of resources that you don't allow (even non-commercial) distributors to redistribute a closed binary for /dev/fb for the older framebuffers developed by SUNW themselves (probably no 3rd party NDA's affected)? And what is with the shared Studio C++ runtime required by almost everything : bash-3.1$ ls -al /usr/lib/libC* -rwxr-xr-x 1 root bin 100764 Jan 23 2005 /usr/lib/libC.so.3 -rwxr-xr-x 1 root bin 401144 Jan 23 2005 /usr/lib/libC.so.5 -rwxr-xr-x 1 root bin63820 Jan 23 2005 /usr/lib/libCrun.so.1 -rwxr-xr-x 1 root bin 1907540 Jan 23 2005 /usr/lib/libCstd.so.1 A matter of resources ? What will the press think, when they see Belenix marTux OpenSolaris require users to download those libs after each LiveDVD boot (they already see it) ... Why can nobody give me a concrete answer on that issue. I don't understand it. p.s.: Is SUNW interested in GRUB2 on sparc? We finally could boot from USB mass storage then. We're working on something akin newboot for SPARC; how would grub2 on SPARC allow for booting from USB? Grub2 would need to be loaded from somewhere else first. I was quite wrong on that. I already admitted it. Thanks again to Jan Setje-Eilers for having corrected me in good detail. Martin ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [ksh93-integration-discuss] Re: [osol-discuss] Formal Proposal : Port OpenSolaris to PowerPC
(ks93 discuss removed) But why is SUNW so uninterested??? Where is your vision of ^^We strongly believe in One Solaris^^ now? There is a lot of history there and it is hard to change. Migrating from Xsun to Xorg did work on x86. What lot of history do you mean exactly? (okay, /dev/fb is different on x86, and vga text mode etc.) The lot of history is in a large part the organizational split between SPARC desktop doing Xsun for SPARC and the X group doing the rest. The move from Xsun to Xorg on x86 was easy because there was nothing in the way of device support Xorg didn't do better and the choice was often between crippled Xsun or Xorg so the move was easy. The SPARC device support is a completely different picture. What are you referring to? Mostly the optimized 3D and OpenGL support for SPARC framebuffers. Is it also a matter of resources that you don't allow (even non-commercial) distributors to redistribute a closed binary for /dev/fb for the older framebuffers developed by SUNW themselves (probably no 3rd party NDA's affected)? And what is with the shared Studio C++ runtime required by almost everything : bash-3.1$ ls -al /usr/lib/libC* -rwxr-xr-x 1 root bin 100764 Jan 23 2005 /usr/lib/libC.so.3 -rwxr-xr-x 1 root bin 401144 Jan 23 2005 /usr/lib/libC.so.5 -rwxr-xr-x 1 root bin63820 Jan 23 2005 /usr/lib/libCrun.so.1 -rwxr-xr-x 1 root bin 1907540 Jan 23 2005 /usr/lib/libCstd.so.1 A matter of resources ? What will the press think, when they see Belenix marTux OpenSolaris require users to download those libs after each LiveDVD boot (they already see it) ... Why can nobody give me a concrete answer on that issue. I don't understand it. because we are a large organization and nobody has all the answer I cannot help you with these questions other than to give you the global indication that in many cases it *is* a resource issue or a contractual issue. OpenSolaris is a high priority item for some managers and less so for others; without higher ups pushing this message all the way done to all corners of Sun, this will change but slowly. People don't seem to appreciate how difficult it is to open source software which has been developed in closed form for decades. Casper ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: Re: [ksh93-integration-discuss] Re: [osol-discuss] Formal Proposal : Port OpenSolaris to PowerPC
Martin Bochnig writes: Are you afraid of publically being expected to opensource all your (mostly eol'ed) gfx drivers? If by afraid you mean know that we'll be doing something illegal, then perhaps that's a partly reasonable interpretation. I think you're at least underestimating the amount of effort required to scour our ~20 year history to get the legal pedigree right. In order to release things as open source, we cannot just slap a sticker on the front and say good to go. That's why there's a roadmap: http://www.opensolaris.org/os/about/roadmap/ and that's also why some things (regrettably) will just never be open source. In general, it's because the actual owner of those things prohibits that sort of release (and in some cases also prevents us from even talking about it). In other cases, it's just time and effort. Again, a large amount of work has to go into that legal drudgery. It's not just blind fear, though, nor is it malice. Looking at the staggering amount of code we've been able to release so far, I'm a bit baffled how anyone could even begin to think that we're holding back out of spite. -- James Carlson, KISS Network[EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: Re: Re: [ksh93-integration-discuss] Re: [osol-discuss] Formal Proposal : Port OpenSolaris to PowerPC
It's not just blind fear, though, nor is it malice. Looking at the
staggering amount of code we've been able to release so far, I'm a bit
baffled how anyone could even begin to think that we're holding back
out of spite.
--
James Carlson, KISS Network[EMAIL PROTECTED]
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
Please don't understand me wrong: OpenSolaris is imho the best and GREATest
project on earth:)
(That is exactly the reason, why I myself invest so much effort and time.)
I also do understand, that opensourcing huge masses of complex code - with a
20++year history - may be very time-, labour- and cost-intensive.
And of course, that certain pieces cannot be open-sourced at all.
And I am well aware of OpenSolaris's roadmap, too.
I am very happy, that you did - and continue to - open Solaris up.
I would just love being explicitly allowed to integrate and redistribute a few
closed things
{
***
two of the closed /dev/fb drivers:
bash-3.1$ find /platform|grep afb
/platform/sun4u/kernel/drv/sparcv9/afb
/platform/sun4u/kernel/drv/afb
/platform/sun4u/kernel/drv/afb.conf
bash-3.1$ find /platform|grep ffb
/platform/sun4u/kernel/drv/sparcv9/ffb
***
the Studio C++ runtime library:
bash-3.1$ ls -al /usr/lib/libC*
-rwxr-xr-x 1 root bin 100764 Jan 23 2005 /usr/lib/libC.so.3
-rwxr-xr-x 1 root bin 401144 Jan 23 2005 /usr/lib/libC.so.5
-rwxr-xr-x 1 root bin63820 Jan 23 2005 /usr/lib/libCrun.so.1
-rwxr-xr-x 1 root bin 1907540 Jan 23 2005 /usr/lib/libCstd.so.1
And may be one or two more driver modules.
Plus the FC-AL drivers for QLogic, but that seems already to be under way
}.
Everyone in the word - including the worst countries - can download SXCR w/o an
(btw unverifiable) registration. What is so hard in allowing a few well-known
distributors to redistribute those files in binary form (for community /
non-profit purposes) ?
Okay, it may not be bad intention.
I see this now.
Maybe just a vacuum of responsibility in a few separate niche areas, in a
complex global enterprise organisation otherwise working very well.
I will temprarily continue to work around those things, by letting users
download the missing pieces on the fly.
Okay.
Martin
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Re: Re: Re: [ksh93-integration-discuss] Re: [osol-discuss] Formal Proposal : Port OpenSolaris to PowerPC
Martin Bochnig writes: I would just love being explicitly allowed to integrate and redistribute a few closed things Since you have a fairly specific hit-list of items you need, how about filing bugs against each requesting an open version? That might be a more productive approach than complaining here. -- James Carlson, KISS Network[EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: Re: [ksh93-integration-discuss] Re: [osol-discuss] Formal Proposal : Port OpenSolaris to PowerPC
Original-Message Date: Thu, 27 Jul 2006 16:54:17 -0700 From: Jan Setje-Eilers [EMAIL PROTECTED] To: Martin Bochnig [EMAIL PROTECTED] Subject: Re: [ksh93-integration-discuss] Re: [osol-discuss] Formal Proposal : Port OpenSolaris to PowerPC p.s.: Is SUNW interested in GRUB2 on sparc? We finally could boot from USB mass storage then. The idea that GRUB or GRUB2 has anything to do with what devices a system can or can not boot from is mostly a miss-conception. Except NICs you mean? Doesn't Grub (at least Grub1) use the etherboot/rom-o-matic NIC drivers? Okay - that was x86 only and therefore bios based systems. But the principle of scanning the pci bus for a known NIC chipset would probably the same on ieee1275 systems. With the exception, that Grub1 was x86 only. I don't know, if the multi-ISA Grub2 still implements the etherboot NIC drivers, or not. I really need to carefully go through the grub1 and grub2 sources first. Plus through the ieee1275 datasheets. Before I can really talk about that. But _when_ A number of amd64/legacy-x86 systems have BIOSs that can talk to and boot from USB devices. On such systems GRUB as well as a number of other boot loaders can be loaded from a USB device by the BIOS and then using the BIOS's support talk to and continue booting from this USB device. GRUB2 on sparc sits on top of OBP (ieee1275) and uses it to talk to IO devices. The current Sun OBPs do not have support for USB devices. As such GRUB doesn't change the picture. As I said, I wasn't aware, that the ongoing Grub2 sparc port just sits on top of OBP. I thought it includes native code to talk to USB. WRT getting OBP support for USB: At least one other vendor, who seems to be abandoning their OBP strategy, Apple?! Don't know how they would respond. We could try it. But SUNW might have better chances, than if I asked them something. did have USB support in their OBPs, so perhaps someone could ask nicely and talk then into freeing/opening their code for this. Now I used the term mostly. One could implement native support for USB in GRUB (or any other boot-strap) and then as long as this USB enabled boot-strap is loaded from something other than USB that OBP (or whatever firmware) _can_ talk to, then the OS load could be completed (but not initiated) from a USB device. That is, what I initially thought all the time. The native NIC drivers work that way in that they are loaded by the generic PXE code and then interface with the NIC directly. Ah, that is what I asked you a few lines above. Yeah. Or loaded via Grub1 floppy, where no PXE is present. And then interfacing with the NIC directly. Damn, I had been hoping from outside (never worked through the grub sources) this would be handled similarily with a certain set of USB controllers. Not so:-( So, GRUB2 does _not_ get us any closer to booting our sparc systems from USB devices. How much working hours (and therefore money) would it cost SUNW to integrate that into current box's OBP (ok /packes/SUNW,builtin-drivers) ? I mean, aren't the U45, U25 and all the servers including T1/2000 worth it? Now to put the soap box aside and answer you question: We are continuing to look at GRUB2 as a way to get a cross-platform consistent menuing interface that may be useful for managing multiple boot-environments. This is particularly interesting as the possibility of zfs snapshots of (coming soon) zfs root filesystems will increase the number of boot-environments on a typical system. -jan I'm looking forward to see zfs root fs's and Boot-menues on SPARC. Martin ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: Re: Re: Re: [ksh93-integration-discuss] Re: [osol-discuss] Formal Proposal : Port OpenSolaris to PowerPC
Since you have a fairly specific hit-list of items you need, how about filing bugs against each requesting an open version? That might be a more productive approach than complaining here. -- James Carlson Strange, but okay. Be sure that I will do that asap (not now). -- Martin Bochnig ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [ksh93-integration-discuss] Re: [osol-discuss] Formal Proposal : Port OpenSolaris to PowerPC
Except NICs you mean? Including NICs. Doesn't Grub (at least Grub1) use the etherboot/rom-o-matic NIC drivers? Not for Solaris as Sun ships it. The grub that comes with Solaris is loaded in memory using PXE (over the wire) and then the Grub PXE driver continues to use PXE to bootstrap the kernel. (So you can even download a Solaris kernel over the net without there being Solaris support for your network driver). The rom-o-matic drivers can be used too but they require grub to be booted from other media (floppy, USB, CD, DVD, harddisk) first. I use a special grub version to netboot an old laptop without PXE support. I boot grub from the harddisk and then select network boot/install from the grub menu The picture Jan drew is accurate: a system can only boot from devices the firmware supports. BIOS or Openboot makes no difference. Of course, the OS you then load may be more limited and not allow booting from the device you've just downloaded the bootloader from. (E.g., old Solaris boot was more limited than some BIOSes). The best you can hope for is a boot loader loaded from any of the supported devices (on SPARC, that would be net, disk, CD/DVD) and then boot a bootloader which understands the device you actually want to boot from (USB, firewire?) As I said, I wasn't aware, that the ongoing Grub2 sparc port just sits on top of OBP. I thought it includes native code to talk to USB. That is possible but it will need to be loaded in memory first; and it can't be loaded from USB because the OBP won't let it. Ah, that is what I asked you a few lines above. Yeah. Or loaded via Grub1 floppy, where no PXE is present. And then interfacing with the NIC directly. Damn, I had been hoping from outside (never worked through the grub sources) this would be handled similarily with a certain set of USB controllers. Not so:-( Well, loading grub from floppy and then using USB boot could be possible. Casper ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: [networking-discuss] link aggregation failed on T2000 boxes (T1 8cores CPU), Sol 10
You are going to need to use the old trunking software to do this since you have legacy devices.On 7/28/06, Cathy Zhou [EMAIL PROTECTED] wrote:Oxy Hazard wrote: Hi,all: I tried to install solaris 10 on a T2000 boxes (T1 8 cores,32 multi-threading CPU) in recent days, after installation, I tried dladm to test the 802.3 link aggregation,but failed, error msg is : bash-3.00# dladm create-aggr -d ipge0 -d ipge1 1 dladm: create operation failed: No such file or directory (invalid interface name) bash-3.00# dladm show-link ipge0 type: legacymtu: 1500 device: ipge0 ipge1 type: legacymtu: 1500 device: ipge1 ipge2 type: legacymtu: 1500 device: ipge2 ipge3 type: legacymtu: 1500 device: ipge3The interfaces you have are legacy devices, not GLDv3 (Nemo) devices.Currently only drivers written in GLDv3 can do link aggregation using dladm create-aggr.But I agree that the error message should be more informative.- Cathy___opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: bug database improvement
preHey All, Below are some mock-ups that we are currently working on for bugs.opensolaris.org. Yes, there is work being done, but we do not have a schedule right now. This is mini preview of features to come. Please take a look and feel free to comment. Once we have a schedule, I will post. I fail to see any substainial improves that address the bug database problems. Try scheduling changes that resolve the issues. ---Bob This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Grub on sparc _/_ Re: [osol-discuss] Formal Proposal : Port OpenSolaris to PowerPC
Ah, that is what I asked you a few lines above. Yeah. Or loaded via Grub1 floppy, where no PXE is present. And then interfacing with the NIC directly. Damn, I had been hoping from outside (never worked through the grub sources) this would be handled similarily with a certain set of USB controllers. Not so:-( Well, loading grub from floppy and then using USB boot could be possible. Casper Maybe one doesn't believe me that late: I always had a picture of a Floppy-/CD-/DVD-/HDD- booted Grub1 (2?) in mind, and __then__ booting from USB (or maybe even ieee1394a) - whether it is on top of the firmware, or implemented nativiely into Grub itself. (I also mean the plain Grub command line, with no cosmetic menu set up at all.) Remember, that I didn't have a PC until recently (and the U20 is hardly powered on). My memories go back to May2005, when I netbooted the first newboot based Solaris10-Express via a self build Grub 0.95 on SunPCi_2_pro (with no PXE activated[completely cut down, no way]). I also have a Genesi ppc ODW (and Grub2), put didn't come to it very much, recently. I did - however - never assume, I could load Grub itself via USB. Would be kind of chicken and egg problem, that's clear. Martin ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: problem with Installing web browser opera 9
Hi all, I have the same problem with installing web browser opera 9 on Solaris 10: bash-3.00# pwd /usr/local/bin bash-3.00# ./opera opera: $HOME set to /root. Use -personaldir if you do not want to use /root/.opera/ Xlib: connection to :0.0 refused by server Xlib: No protocol specified opera: cannot connect to X server :0.0 This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Formal Proposal : Port OpenSolaris to PowerPC
Martin Bochnig wrote: Having a redistributable DLJ-distros-jdk available, which necessarily depends on (apparently) non-redistributable SUNWspro-shared C++ libs, is another such problem. It's really annoying that I have to force LiveDVD-users to download them on the fly first (automatically/script-driven), before they are able to run anything from the distros-jdk (or anything else, that had been built with SUNW's cc). Is a non-commercial distributor (like myself) allowed to ship them, or rather not? I really do not want to violate any license. I might initiate a new thread for that topic, depending on the replies here. I had been asking many people (and even two CAB members, one other distributor), but never got a concrete answer. The SUNWspro license seems to prohibit this, in full contradiction to the DLJ's paragraph of being required to stay compatible [...] with it ... I also sent a message to the java-distro team a month ago (no response so far). Does anybody know this for sure? Am I allowed to redistribute those /usr/libC* libs YES [ ] NO [ ]? The Belenix creators published their view: http://www.genunix.org/distributions/belenix_site/ Martin, As of right now - you are not allowed to redistribute those libC* libs. We're working on getting permission to allow for redistribution though - so please know that *it is being worked on*. It's not always trivial/easy to work through these licensing issues; but we do realise that this is a problem, and we are trying to fix it. cheers, steve -- stephen lau // [EMAIL PROTECTED] | 650.786.0845 | http://whacked.net opensolaris // solaris kernel development ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: problem with Installing web browser opera 9
James wrote: Hi all, I have the same problem with installing web browser opera 9 on Solaris 10: bash-3.00# pwd /usr/local/bin bash-3.00# ./opera opera: $HOME set to /root. Use -personaldir if you do not want to use /root/.opera/ 1) Why are you running as root instead of a normal user? 2) Resetting $HOME makes it not find $HOME/.xauthority with the magic cookies needed to access your display. Sounds like a bug in Opera for overriding $HOME. You may be able to workaround by setting XAUTHORITY to /.xauthority first, but the best solution is STOP RUNNING IT AS ROOT and create yourself a non-root account for tasks like web browsing which have no business running as root. -- -Alan Coopersmith- [EMAIL PROTECTED] Sun Microsystems, Inc. - X Window System Engineering ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: Re: [ksh93-integration-discuss] Re: [osol-discuss] Formal Proposal : Port OpenSolaris to PowerPC
On Fri, 28 Jul 2006, Martin Bochnig wrote: Is it also a matter of resources that you don't allow (even non-commercial) distributors to redistribute a closed binary for /dev/fb for the older framebuffers developed by SUNW themselves (probably no 3rd party NDA's affected)? And what is with the shared Studio C++ runtime required by almost everything : Dunno about the frame buffers, but perhaps libC contains 3rd party IP, and Sun's license to use it prohibits redistribution by other parties? I believe that's one of the reasons why you and I are not allowed to redistribute the Solaris ISOs we can download for free from Sun's web site: Sun is allowed to distribute it, but others are not. Sensible? NOt really, but as Casper (and others) has said, that's one of the prices paid for developing stuff as closed source. I'm sure Sun is doing their best to open up libC (or at least allow redistribution), but if the owner of the IP won't play ball, it's out of Sun's hands (apart from Sun re-writing the bits that are closed)... -- Rich Teer, SCNA, SCSA, OpenSolaris CAB member President, Rite Online Inc. Voice: +1 (250) 979-1638 URL: http://www.rite-group.com/rich ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: Re: [osol-discuss] Formal Proposal : Port OpenSolaris to PowerPC
Martin Bochnig wrote:
Having a redistributable DLJ-distros-jdk available, which necessarily
depends on (apparently) non-redistributable SUNWspro-shared C++ libs, is
another such problem.
It's really annoying that I have to force LiveDVD-users to download them
on the fly first (automatically/script-driven), before they are able to
run anything from the distros-jdk (or anything else, that had been built with
SUNW's cc).
Is a non-commercial distributor (like myself) allowed to ship them, or
rather not?
I really do not want to violate any license.
I might initiate a new thread for that topic, depending on the replies
here.
I had been asking many people (and even two CAB members, one other
distributor), but never got a concrete answer.
The SUNWspro license seems to prohibit this, in full contradiction to
the DLJ's paragraph of being required to stay compatible [...] with it ...
I also sent a message to the java-distro team a month ago (no response
so far).
Does anybody know this for sure?
Am I allowed to redistribute those /usr/libC* libs
YES [ ]
NO [ ]?
The Belenix creators published their view:
http://www.genunix.org/distributions/belenix_site/
Martin,
As of right now - you are not allowed to redistribute those libC* libs.
We're working on getting permission to allow for redistribution though
- so please know that *it is being worked on*. It's not always
trivial/easy to work through these licensing issues; but we do realise
that this is a problem, and we are trying to fix it.
cheers,
steve
--
stephen lau // [EMAIL PROTECTED] | 650.786.0845 | http://whacked.net
opensolaris // solaris kernel development
Steve,
first of all thanks for that precise top2bottom answer.
The first concrete fact I ever got back on this topic.
In a long while.
I might have tried to contact Jonathan Schwartz next.
I also assume, that _you_(and your team) are not responsible for that
[ABCDEFGH] {*1}
But what do you believe, will a thinking human being (including myself,
hopefully) make of that policy???
Wow, SUNW does offer a Distros-JDK now. The slightly restrictive DLJ license
requires distributors to only ship it with compatible kernel distributions.
(Well, yet another License needed to be invented for the lovely JDK.) But you
- SUNW - yourself hinder distributors from shipping the damn two or so libs it
is dynamically linked against?! Libs that anyone can download and extract from
certain patches, widespread worldwide on many ftp servers for free?
This actually makes your DLJ thing void, because no single OpenSolaris
distributor can actually fulfill DLJ's terms.
Are your lawyers mad? Is it the heat?
Why didn't the JDK folks use gcc then (which does NOT depend on those files)?
Sorry, but this sounds like a really poor April 1st fool.
Believe me the following two statements:
#0.) I will never again (recommend the) use any of your free Studio compilers
anymore.
Even if I was a commercial licensee (Blastwave for example is), you would
hinder me from shipping the runtime with
Open- Solaris?
How ridiculous!
#1.) If things like that (there are more, this is only the most obvious one)
fail to be fixed in the near future, this will not be my problem any longer,
because I might discard my projects in such a nasty case.
Footnotes: {*1} == [Page 1484 of License Agreement %3452, paragraph %$#899
line 67a, except in cases, where ^755 is equal to 733664 paragraph one,
argument s.]
And finally take into account the following aspect please: Your dear share
holders may have invested more or less $$$ into SUNW.
_But_ your (rather small) true core community has invested complete human life
into it. See guys like Dennis Clarke, Joerg Schilling, Cyril Plisko, Phil
Brown, the Belenix-creators and a few more of that sort.
This needed to be said.
And I will shut my mouth now.
I do not believe all that!
Friendly,
Martin Bochnig
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Project proposal: integrate GCCfss into SFW
Alexey, The exact version of GCC to be bundled is an exhausting topic. We can decide on the final GCCfss/gcc version latter. indeed :-) That's why the proposal is named support GCCfss and gcc 4 in ON I believe that the set of changes we have for ON will be equally useful for any gcc 4.x version. Both sparc and x86. That's the main point. That's why this topic was started. Whatever version is chosen this work would need to be done anyway. So, can I get +1 since that's what policy to start the project requires ? Sure, both for the GCCfss (and eventually gcc 4.x) integration into sfw or companion, and the ON support. After that the plan is: [...] Sounds good. Thanks. Rainer - Rainer Orth, Faculty of Technology, Bielefeld University ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: Re: Re: [ksh93-integration-discuss] Re: [osol-discuss] Formal Proposal : Port OpenSolaris to PowerPC
Dunno about the frame buffers, but perhaps libC contains 3rd party IP, and Sun's license to use it prohibits redistribution by other parties? I believe that's one of the reasons why you and I are not allowed to redistribute the Solaris ISOs we can download for free from Sun's web site: Sun is allowed to distribute it, but others are not. Sensible? NOt really, but as Casper (and others) has said, that's one of the prices paid for developing stuff as closed source. I'm sure Sun is doing their best to open up libC (or at least allow redistribution), but if the owner of the IP won't play ball, it's out of Sun's hands (apart from Sun re-writing the bits that are closed)... -- Rich Teer, SCNA, SCSA, OpenSolaris CAB member President, Rite Online Inc. Hi Rich, okay. If (and only if) 3rd parties are involved into the libC* thing, I _would_ understand it. What I still would not understand - however - is, why the Distros-JDK (on which SUNW has made so much noise about, back in May'06) has not been built with the open gcc. A gcc-built JDK would not depend on those closed libs. Martin (leaving office now) ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: Re: Re: [ksh93-integration-discuss] Re: [osol-discuss] Formal Proposal : Port OpenSolaris to PowerPC
On Fri, 28 Jul 2006, Martin Bochnig wrote: okay. If (and only if) 3rd parties are involved into the libC* thing, I _would_ understand it. Would a statement by a Sun employee (provided, of course, thet such a license doesn't prohibit Sun from doing so) clarifying the situation help? What I still would not understand - however - is, why the Distros-JDK (on which SUNW has made so much noise about, back in May'06) has not been built with the open gcc. Perhaps they did it for performance reasons? I know *I* avoid building anything with gcc unless I absolutely have to. -- Rich Teer, SCNA, SCSA, OpenSolaris CAB member President, Rite Online Inc. Voice: +1 (250) 979-1638 URL: http://www.rite-group.com/rich ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Teamware release?
Ian Collins wrote: I tried this on tools-discuss but didn't get an answer, so I'll try again here: Are we going to see Teamware released to open source? I was told it was almost ready a year or so back. Ian, I actually I saw this both times but I don't know the answer, so I was hoping someone else would jump in. I will go find out. Derek Ian. ___ 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
[osol-discuss] [Please read this!] What is the purpose of the ksh93-integration list ?
Hi! Just a small note on the recent postings around Formal Proposal : Port OpenSolaris to PowerPC send to ksh93-integration-discuss@: The [EMAIL PROTECTED] list was originally created to aid the developers to integrate ksh93 into OS/Net and then discuss the technical details of the migration of /usr/bin/ksh to ksh93. The list primarily is for TECHNICIAL DETAILS, please keep (unrelated) philosophical comments/flamewars and things like the crusade against the unbelievers in opensolaris-discuss@opensolaris.org if possible. Please send postings to [EMAIL PROTECTED] when you find techinicial details and remove it from the CC: list when the subject of the email becomes totally unrelated to ksh93 again). Thanks! :-) Bye, Roland P.S.: Reply-to: set to opensolaris-discuss@opensolaris.org -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ MPEG specialist, CJAVASunUnix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: Re: [ksh93-integration-discuss] Re: [osol-discuss] Formal Proposal : Port OpenSolaris to PowerPC
cc: opensolaris-discuss@opensolaris.org Subject: Re: Re: [ksh93-integration-discuss] Re: [osol-discuss] Formal Proposal : Port OpenSolaris to PowerPC I don't want to get involved in political arguments so I will state my view one once. It looks as if Casper Dik and Martin Schaffstall have views that are at opposite ends of the spectrum. Neither is right and neither is wrong. There are tradeoffs in either view which I will outline below and present the pros and cons of each. Casper's view: Avoid making changes that could be incompatible and effect customers. Add ksh but putting it under a new name. Install ksh93 as /bin/ksh. Here are the pros: 1. Sun provides continuity for customers. 2. Easier to get approved. 3. Each version can be modified independently. 4. Can be implemented quickly. 5. It is simpler in the short term. Here are the cons: 1. Complexity grows over time. 2. Multiple versions need to be supported. 3. Versions might diverge making future merges more difficult. 4. Features that users want might be partially in one version and not in the other. 5. More closed source code. 6. Less compatbility with Linux systems. 7. Gets worse as time goes on. Martins view: Select the best shell and make that the standard. Install ksh93 as /bin/sh. Here are the pros: 1. Once adopted, improves productivity for users. 2. Reduces code and the need to support closed version. 3. Improves Solaris performance. Here are the cons: 1. Sun would have to make sure that all their scripts run which is likely to require some changes. 2. It might break some existing user scripts. 3. When installed as /bin/sh, it must be able to handle all calls to system(). 4. This would take longer to implement. 5. Harder to get approved. An alternative would be to do things in three phases. Phase 1. 1. Move the current ksh to /bin/ksh88 2. Install the new ksh as /bin/ksh 3. Fix any Solaris scripts that currently use ksh so that they run with ksh93. 4. Inform user to either change the #! in their scripts to use /bin/ksh88 or fix the script if it doesn't run under the new /bin/ksh. 5. Mark /bin/ksh88 as obsolete and stop any maintenence. Phase 2. 1. Make sure all Solaris scripts run with /bin/sh as ksh93. 2. Let /bin/sh be a symlink that can be set to /bin/ksh or to the old /bin/sh. 3. Mark /bin/osh as obsolete and stop any maintenence. Phase 3. 1. Make /bin/sh and /bin/ksh links. David Korn [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] ksh93 integration status
Just a very brief status for those who are interested... The ksh93 project team is currently working out the final details on the PSARC case for the ksh93 integration project. The expectation is that it will be submitted for an open PSARC review by the week of Aug 7th. April ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Project Proposal: Packet Event Framework (PEF)
Yu Xiangning wrote: Hello OpenSolaris folks, I would like to open an OpenSolaris project - Packet Event Framework (PEF), on behalf of the PEF project team. The Packet Event Framework project is a follow-on to FireEngine, which will provide a framework for fine-grain modularity of the network stack based on the execution of a series of event functions as specified by the IP classifier. PEF will provide the following benefits: - Better observability as the framework will support dynamic changes to an event vector. - Improved performance due to: - Smaller code footprint by executing the code needed based on packet classification only. - Iterative execution of events which leads to smaller stack depth. - Fewer parses of the packet. Packet parsing is done once at classification time. - Support for multiple vertical perimeters(squeue_t), so a packet can traverse from one squeue_t to the next. Currently FireEngine supports a single IP squeue_t requiring packet processing to use both STREAMS based queuing and FireEngine IP squeue_t queuing. As a result, a packet can be processed totally within PEF and does not require any STREAMS processing. - CMT(Chip Multi-Threading) based processors will additionally benefit from the multiple squeue_t support through pipe-lined processing of a connection. Multiple cores and/or threads of a core can process different layers of the stack. Also, packet fanout of packets such that multiple packets can be simultaneously processed. Thanks in advance for your support! - yxn ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org +1 Sounds like this will improve performance significantly, esp. as networks increase in performance faster than single cpu cores - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: Re: Re: Re: [ksh93-integration-discuss] Re: [osol-discuss] Formal Proposal : Port OpenSolaris to PowerPC
Would a statement by a Sun employee (provided, of course, thet such a license doesn't prohibit Sun from doing so) clarifying the situation help? Yes. What I still would not understand - however - is, why the Distros-JDK (on which SUNW has made so much noise about, back in May'06) has not been built with the open gcc. Perhaps they did it for performance reasons? I know *I* avoid building anything with gcc unless I absolutely have to. -- Rich Teer, SCNA, SCSA, OpenSolaris CAB member President, Rite Online Inc. Aehmm, what kind of performance is better in practical use? [ ] gcc: It may run only at 60% of the speed it could, when built with SUNWspro. (depending on what and how etc.) [ ] SUNWspro: it does not run at all, because it is linked against missing and unredistributable libs -- Martin Bochnig SCSA, SCNA, SCSecA, TOEFL, Student of Maths. at TU-Berlin, marTux ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [Please read this!] What is the purpose of the ksh93-integration list ?
Hi Roland, sorry, I have deleted the ksh subject line and the ksh-list as receipient a few times. Others integrated it back. So I then thought people want it that way and didn't delete it any longer. Further, I agree it didn't have to do anything with ksh88 vs. ksh93 anymore. Though I do not agree, that it was technically irrelevant. I apologize in the name of anyone (partially including myself), who has posted OT to the ksh list: Sorry! -- Martin Bochnig Hi! Just a small note on the recent postings around Formal Proposal : Port OpenSolaris to PowerPC send to ksh93-integration-discuss@: The [EMAIL PROTECTED] list was originally created to aid the developers to integrate ksh93 into OS/Net and then discuss the technical details of the migration of /usr/bin/ksh to ksh93. The list primarily is for TECHNICIAL DETAILS, please keep (unrelated) philosophical comments/flamewars and things like the crusade against the unbelievers in opensolaris-discuss@opensolaris.org if possible. Please send postings to [EMAIL PROTECTED] when you find techinicial details and remove it from the CC: list when the subject of the email becomes totally unrelated to ksh93 again). Thanks! :-) Bye, Roland P.S.: Reply-to: set to opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Formal Proposal : Port OpenSolaris to PowerPC
okay. If (and only if) 3rd parties are involved into the libC* thing, I _would_ understand it. What I still would not understand - however - is, why the Distros-JDK (on which SUNW has made so m uch noise about, back in May'06) has not been built with the open gcc. A gcc-built JDK would not depend on those closed libs. Most compiler libraries can be redistributed, but strangely enough not libC (because of bundling in the OS?) If that small bit was rectified, we could easily fix it.. Casper ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
(un)redistributable SUNWspro libs _/_ WAS: Re: Re: [osol-discuss] Formal Proposal :
okay. If (and only if) 3rd parties are involved into the libC* thing, I _would_ understand it. What I still would not understand - however - is, why the Distros-JDK (on which SUNW has made so m uch noise about, back in May'06) has not been built with the open gcc. A gcc-built JDK would not depend on those closed libs. Most compiler libraries can be redistributed, but strangely enough not libC (because of bundling in the OS?) If that small bit was rectified, we could easily fix it.. Casper That woul be very cool:)) Martin ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: AMD buys ATI....
Yes it's true.However I hope to see taken some other good opportunities I am omitting the obvious. In light of the fact that: (1) Sun is now AMD's most valuable customer, (2) CDDL, which, unlike GPL, allows proprietary drivers to be included in the kernel, (3) (to a much less extent) the increasing romance between NB and OOo, we may begin to dream about the world dominance of Solaris desktops/laptops. Sun's lawyers can and should play an active role (re point No. 2). This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Really ksh88 vs. ksh93 _/_ Re: Re: Re: [ksh93-integration-discuss] Re: [osol-discuss] Formal Proposal : Port OpenSolaris to PowerPC
Hello David Korn, I'm Martin Bochnig, not the other Martin S. However, your suggestions below get a strong +1 from me. Martin Bochnig Original-Message Datum: Thu, 27 Jul 2006 13:15:40 -0400 (EDT) From: David Korn [EMAIL PROTECTED] To: [EMAIL PROTECTED], opensolaris-discuss@opensolaris.org Subject: Re: Re: [ksh93-integration-discuss] Re: [osol-discuss] Formal Proposal : Port OpenSolaris to PowerPC cc: opensolaris-discuss@opensolaris.org Subject: Re: Re: [ksh93-integration-discuss] Re: [osol-discuss] Formal Proposal : Port OpenSolaris to PowerPC I don't want to get involved in political arguments so I will state my view one once. It looks as if Casper Dik and Martin Schaffstall have views that are at opposite ends of the spectrum. Neither is right and neither is wrong. There are tradeoffs in either view which I will outline below and present the pros and cons of each. Casper's view: Avoid making changes that could be incompatible and effect customers. Add ksh but putting it under a new name. Install ksh93 as /bin/ksh. Here are the pros: 1. Sun provides continuity for customers. 2. Easier to get approved. 3. Each version can be modified independently. 4. Can be implemented quickly. 5. It is simpler in the short term. Here are the cons: 1. Complexity grows over time. 2. Multiple versions need to be supported. 3. Versions might diverge making future merges more difficult. 4. Features that users want might be partially in one version and not in the other. 5. More closed source code. 6. Less compatbility with Linux systems. 7. Gets worse as time goes on. Martins view: Select the best shell and make that the standard. Install ksh93 as /bin/sh. Here are the pros: 1. Once adopted, improves productivity for users. 2. Reduces code and the need to support closed version. 3. Improves Solaris performance. Here are the cons: 1. Sun would have to make sure that all their scripts run which is likely to require some changes. 2. It might break some existing user scripts. 3. When installed as /bin/sh, it must be able to handle all calls to system(). 4. This would take longer to implement. 5. Harder to get approved. An alternative would be to do things in three phases. Phase 1. 1. Move the current ksh to /bin/ksh88 2. Install the new ksh as /bin/ksh 3. Fix any Solaris scripts that currently use ksh so that they run with ksh93. 4. Inform user to either change the #! in their scripts to use /bin/ksh88 or fix the script if it doesn't run under the new /bin/ksh. 5. Mark /bin/ksh88 as obsolete and stop any maintenence. Phase 2. 1. Make sure all Solaris scripts run with /bin/sh as ksh93. 2. Let /bin/sh be a symlink that can be set to /bin/ksh or to the old /bin/sh. 3. Mark /bin/osh as obsolete and stop any maintenence. Phase 3. 1. Make /bin/sh and /bin/ksh links. David Korn [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re[2]: [osol-discuss] Formal Proposal : Port OpenSolaris to PowerPC
Hello Stefan, Thursday, July 27, 2006, 9:42:45 PM, you wrote: ST [ offlist ] ST On 7/27/06, Rich Teer [EMAIL PROTECTED] wrote: Mmmm. Perhaps I was overly assertive, although I stick to the principle. 'Course, the ensuing discussion about ksh88 not being able to be open sourced doesn't help the debate. ST you weren't being overly assertive. ST this backwards compatibility for backwards compatibility's sake is no ST longer a selling point. Linux has proven that backwards compatibility ST for its own sake is largely irrelevant (my personal unhappiness about ST this incompatibility, grounded in purely philosophical rather than ST practical considerations notwithstanding). We do lot of app development on Linux and Solaris. And due to lack of backward compatibility in case of Linux it takes us much more time to upgrade Linux distros and get our applications running while on Solaris upgrading or running every possible nevada with the same binaries just work. With Solaris generally we produce only one binary package for a given application and then use with older Solaris releases. With Linux we have to provide different binary package for every distro release version we use. And it takes more and more time spent on upgrading Linux distros. In that area Solaris saves a lot of time comparing to Linux. -- Best regards, Robertmailto:[EMAIL PROTECTED] http://milek.blogspot.com ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re[2]: [osol-discuss] Formal Proposal : Port OpenSolaris to PowerPC
On Sat, 29 Jul 2006, Robert Milkowski wrote: In that area Solaris saves a lot of time comparing to Linux. And therefore, presumably, saves money too. -- Rich Teer, SCNA, SCSA, OpenSolaris CAB member President, Rite Online Inc. Voice: +1 (250) 979-1638 URL: http://www.rite-group.com/rich ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [Please read this!] What is the purpose of the ksh93-integration list ?
Roland Mainz, I'm to blame for that, because my very first message had been a reply to a thread _also_ posted to your ksh93 list (together with opensol-discuss). My very first msg. contained your ml's address in its header's CC field therefore. It then obviously spreaded by ReplyAll's - multiplied by each other / snowball. Accept it or not: I apologize again and take full responsibility for all of it. I should have paid more attention before I sent out my earliest message. Yours faithfully, Martin Original-Message Date: Fri, 28 Jul 2006 18:31:28 +0200 From: Roland Mainz [EMAIL PROTECTED] To: ksh93-integration-discuss [EMAIL PROTECTED], opensolaris-discuss opensolaris-discuss@opensolaris.org Subject: [osol-discuss] [Please read this!] What is the purpose of the ksh93-integration list ? Hi! Just a small note on the recent postings around Formal Proposal : Port OpenSolaris to PowerPC send to ksh93-integration-discuss@: The [EMAIL PROTECTED] list was originally created to aid the developers to integrate ksh93 into OS/Net and then discuss the technical details of the migration of /usr/bin/ksh to ksh93. The list primarily is for TECHNICIAL DETAILS, please keep (unrelated) philosophical comments/flamewars and things like the crusade against the unbelievers in opensolaris-discuss@opensolaris.org if possible. Please send postings to [EMAIL PROTECTED] when you find techinicial details and remove it from the CC: list when the subject of the email becomes totally unrelated to ksh93 again). Thanks! :-) Bye, Roland P.S.: Reply-to: set to opensolaris-discuss@opensolaris.org -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ MPEG specialist, CJAVASunUnix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Solaris vs. its clones
On Sat, 29 Jul 2006, Robert Milkowski wrote: In that area Solaris saves a lot of time comparing to Linux. And therefore, presumably, saves money too. -- Rich Teer, SCNA, SCSA, OpenSolaris CAB member President, Rite Online Inc. Definitely. Unfortunately will most UNIX-clone users never realize that. And even if: Would they ever admit it? I didn't use Linux very often in my life (as you know). But when I tried it, I instantly had to understand what you mean: LoadableKernelModules's versus incompatible kernel revisions. (i.e. VMware) Binaries versus incompatible glibc revisions. (i.e. AcrobatReader) Even sources requiring a glibc higher than x.xx in some cases. (i.e. Qemu) I only talked about a single distro with a release progress of 0.8 (two years) so far. All the (often incompatible) distributions give it the rest. That's enough. I don't need to provide examples for how different backward compatibility looks on Solaris 2.11 down to things originally compiled on/linked against at least 2.6 (if not 2.3 [or in certain cases still older]). Source backward compatibility is also amazing (I had to deal with a tetris version from 1989 last week). Okay - a few kernel interfaces did disappear (and compiles like 1993's aperture driver will break). But SUNW has certainly the best documentation. Covering those changes carefully. -- Martin ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Open BootProm ?
What about having the OpenBoot source code for an EOL'ed sun4u USB based box (the sb2k would be nice). The best one apparently can get until this day is PROLL (http://people.redhat.com/zaitcev/linux/). PROLL is a limited sun4m OpenBoot. The drawback of PROLL is that only a subset of old sun4m hardware is supported, and a forth emulator is not included. If the code was opensource, one might get a better understanding of what is required to implement USB-booting (which is cetainly not trivial). Just an idea. Is there an existing user demand for this? But it is probably an illusion to think, such a thing could legally ever be open sourced (many 3rd party devices in such a system). Plus it would help BlueSwirl from Qemu's sparc emulation target. Chances are low? -- martin ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
