Re: [osol-discuss] HCL is pretty anemic...
We never had any luck with the micro ATX boards. Will never touch them again. Sun's hardware comes with 3-yr warranty, sometimes this is more important than price. Plus, the list price may not be the final price. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] HCL is pretty anemic...
Sun's hardware comes with 3-yr warranty, sometimes this is more important than price. Plus, the list price may not be the final price. Most hardware you get from shops come with at least 3 year warranty nowadays. Seagate disks under 5 and others are even under lifetime warranty. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Is a /tmp slice a wise move on Solaris?
Hello, I have my roots in the Linux and *BSD worlds. When I install a system, I am used to create separated partitions (slices) for /usr, /opt, /, /var, /tmp. It's an old habit. I just like it this way... ;) Now I wonder, regarding Solaris, I read that to create a /tmp slice was not such a good idea. Why? Is it included in the swap? Daniel -- ** Daniel TOURDEE-mail : [EMAIL PROTECTED] FOI, Swedish Defence Research AgencyTel : +46 (0)8-55 50 32 12 Defence Security, Systems and Technology Fax : +46 (0)8-55 50 36 51 Department of Autonomous Systems Cellular : +46 (0)70-849 93 40 SE-164 90 Stockholm, Sweden ** ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Is a /tmp slice a wise move on Solaris?
Daniel, I have my roots in the Linux and *BSD worlds. When I install a system, I am used to create separated partitions (slices) for /usr, /opt, /, /var, /tmp. It's an old habit. I just like it this way... ;) Fair enough...you may want to look into ZFS at some stage which makes partition/slice management (as such) a cinch. Now I wonder, regarding Solaris, I read that to create a /tmp slice was not such a good idea. Why? Is it included in the swap? /tmp lives on a special filesystem called swapfs (which contains, amoung other things, the swap file system itself and potentially some/all of the free memory). It's best to leave it like. (Also, unlike many linuxes expect things in /tmp to disappear on every reboot). I'm not sure if this question belongs on [osol-help] (the help mailing list) or not -) I'm happy to answer but I *think* that's possibly a better list to ask such questions on. DSL ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Is a /tmp slice a wise move on Solaris?
I have my roots in the Linux and *BSD worlds. When I install a system, I am used to create separated partitions (slices) for /usr, /opt, /, /var, /tmp. It's an old habit. I just like it this way... ;) There's a downward trend in the number of partitions; I remember needing to have two partitions for / and /usr because they would not fit on single disks. The reasons for not having multiple partitions are: - ease of management - you won't run out of space as quickly (typically one partition will run out much sooner than the others) But it also depends on what type of system. For small systems (desktop, servers with a few disks) I'd recommend just two slices: / and swap for the OS. On larger servers you may want to separate out /var. Then, of course, whatever you need for (but also preferably one storage pool) Now I wonder, regarding Solaris, I read that to create a /tmp slice was not such a good idea. Why? Is it included in the swap? By default /tmp is 'tmpfs' or virtual memory based filesystem; files there are relegated to swap when not needed. Casper ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Downloading the latest build...
How do I get the latest build. I have been looking for a build to correct bug:6589662 but can't find a build other than snv_70. I must be looking in the wrong spot... Thanks Bryan This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Memory requirements to install Solaris
Oh C'mon. 512Mb is not enough to run Windoze XP reasonably - even if you can actually install it. With 1Gb memory DIMMs around $50 (or less), expecting to run a state-of-the-art OS in 512Mb is absolutely unacceptable. If you're serious about (Open)Solaris, then you're serious about your hardware. We should never, under any circumstances, defend regression. Regression is an error. A severe and serious error. Dealing with regression has been one of the main selling points of Solaris. If Solaris starts regressing now, it will have lost one of the most crucial competetive edges. We should also stop defending every bad decision and hiding behind engineering for everything that just plain isn't right: making that installer Java-based and Java-dependent was just plain bad decision and it caused regression. Rather than hiding behind claims that Java is great and that it's engineering, the responsible person(s) should admit the error and fix it. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Memory requirements to install Solaris
Oh C'mon. 512Mb is not enough to run Windoze XP reasonably - even if you can actually install it. With 1Gb memory DIMMs around $50 (or less), expecting to run a state-of-the-art OS in 512Mb is absolutely unacceptable. If you're serious about (Open)Solaris, then you're serious about your hardware. We should never, under any circumstances, defend regression. Regression is an error. A severe and serious error. Dealing with regression has been one of the main selling points of Solaris. If Solaris starts regressing now, it will have lost one of the most crucial competetive edges. We should also stop defending every bad decision and hiding behind engineering for everything that just plain isn't right: making that installer Java-based and Java-dependent was just plain bad decision and it caused regression. Rather than hiding behind claims that Java is great and that it's engineering, the responsible person(s) should admit the error and fix it. No disagreement with most of that, except that I'm not sure I see increases in memory requirements (even for the duration of installation) as regression as such, even if they may a real obstacle. Unless of course working on a specified minimum configuration is a distro objective that was violated. I see a lot of tradeoffs here (ease of use, flexibility, speed, minimum hardware requirements, development resources needed to optimize the balance of the previous, etc). The present situation may suck, but a balance that would satisfy all interests may not be feasible. Or to put it another way, for whatever you want, what would you be willing to give up? :-) Part of the problem may be RAM-resident miniroot bloat. Seems to me that only volatile data _needs_ to live there; everything else could be on the installation media. However, optical media is slow in the face of a lot of seeks. Dividing miniroot space requirements into volatile data vs cache for performance might help; the latter could be built in increments based on available resources, so that a system with ample RAM could install very quickly, but a slimmer system would still install, if slowly. That is, divide the possible miniroot contents into multiple cpio (or tar, as you prefer) archives on the installation medium, grouped so the most benefit comes with the initial increments. Depending on how much RAM is available, load zero or more of those into the miniroot (over and above the skeleton needed to hold e.g. device files, symlinks, directories, config files needed during installation, etc); set $PATH so that those tools would be found first on the miniroot, and if not there, on fully-populated versions of the miniroot directories stored on the installation media. RPATH would be set in the executables to look for libraries similarly. A modular installer could also lend itself to both flexibility (character vs GUI vs answering as much as possible from site config/policy store) and to having no more of itself resident at any given time than reasonably necessary. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] flowindent in dvm
hi, i am new in dtrace. can we use flowindent directive with dvm provider? if no then is there any solution for this? thanks, ajit bansode. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Memory requirements to install Solaris
Hi Richard and All, Just a few comments inline... specific to the steps we took in the Caiman installer related to this discussion. Oh C'mon. 512Mb is not enough to run Windoze XP reasonably - even if you can actually install it. With 1Gb memory DIMMs around $50 (or less), expecting to run a state-of-the-art OS in 512Mb is absolutely unacceptable. If you're serious about (Open)Solaris, then you're serious about your hardware. We should never, under any circumstances, defend regression. Regression is an error. A severe and serious error. Dealing with regression has been one of the main selling points of Solaris. If Solaris starts regressing now, it will have lost one of the most crucial competetive edges. We didn't regress with Dwarf Caiman. We are within the existing memory checks that the Solaris installer has had in them for some time. This is our current requirements: 1. SXDE3 (Dwarf)- 786MB - we do exit out if the user doesn't have enough memory. We tell them to go to the text based installer. Now, 768 is a high limit for Dwarf. We know we can run under less memory, but not on any reasonable boundary where we can lower this requirement at this time. But, we are working on this. 2. SXCE - Interactive GUI - 768MB(same as it has been for a long time) 3. Text installer - windows based - 512MB 4. Console based text installer - 256MB - its not quite 256MB any longer. Not sure exactly the numbers though. We should also stop defending every bad decision and hiding behind engineering for everything that just plain isn't right: making that installer Java-based and Java-dependent was just plain bad decision and it caused regression. Rather than hiding behind claims that Java is great and that it's engineering, the responsible person(s) should admit the error and fix it. With Dwarf and subsequent Caiman projects we have moved from the Java based GUI to Gnome and C. This should help some, but it doesn't mitigate all the size issues in the miniroot. No disagreement with most of that, except that I'm not sure I see increases in memory requirements (even for the duration of installation) as regression as such, even if they may a real obstacle. Unless of course working on a specified minimum configuration is a distro objective that was violated. I see a lot of tradeoffs here (ease of use, flexibility, speed, minimum hardware requirements, development resources needed to optimize the balance of the previous, etc). The present situation may suck, but a balance that would satisfy all interests may not be feasible. Or to put it another way, for whatever you want, what would you be willing to give up? :-) Part of the problem may be RAM-resident miniroot bloat. Seems to me that only volatile data _needs_ to live there; everything else could be on the installation media. However, optical media is slow in the face of a lot of seeks. Dividing miniroot space requirements into volatile data vs cache for performance might help; the latter could be built in increments based on available resources, so that a system with ample RAM could install very quickly, but a slimmer system would still install, if slowly. That is, divide the possible miniroot contents into multiple cpio (or tar, as you prefer) archives on the installation medium, grouped so the most benefit comes with the initial increments. Depending on how much RAM is available, load zero or more of those into the miniroot (over and above the skeleton needed to hold e.g. device files, symlinks, directories, config files needed during installation, etc); set $PATH so that those tools would be found first on the miniroot, and if not there, on fully-populated versions of the miniroot directories stored on the installation media. RPATH would be set in the executables to look for libraries similarly. Actually, what you describe is what we do, partially. As part of the work on Dwarf I separated out what needed to be in the part we call the 'miniroot', x86.miniroot archive, and created several new archives that hold the data that may or may not be used depending on the path the user chooses for installation. We unpack only the archives necessary. This helps with the RAM situation. We no longer load Java when it isn't needed. We don't load Gnome when the user has chosen the Java GUI. But, we don't, at this time, run anything from the media until much later for the Tools install. This is something we are looking in to doing. As you note, there may be performance issues with this approach. A modular installer could also lend itself to both flexibility (character vs GUI vs answering as much as possible from site config/policy store) and to having no more of itself resident at any given time than reasonably necessary. Regards, sarah *** This message posted from opensolaris.org ___
Re: [osol-discuss] Memory requirements to install Solaris
4. Console based text installer - 256MB - its not quite 256MB any longer. Not sure exactly the numbers though. i thought grub required at least 512mb, that is a limiting factor in the x86 world nacho ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Downloading the latest build...
Bryan Cantu wrote: How do I get the latest build. I have been looking for a build to correct bug:6589662 but can't find a build other than snv_70. I must be looking in the wrong spot... It's fixed in 72, which is not out yet. Dave ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Memory requirements to install Solaris
We didn't regress with Dwarf Caiman. We are within the existing memory checks that the Solaris installer has had in them for some time. This is our current requirements: I wasn't saying that Caiman regressed. I'm saying that installer and therefore Solaris as a whole regressed in terms of memory requirements. One used to be able to install Solaris 2.5.1 on 16MB of RAM. Is anyone laughing at those 16 measly megabytes? I sure am not. This is serious. 1. SXDE3 (Dwarf)- 786MB - we do exit out if the user doesn't have enough memory. We tell them to go to the text based installer. Now, 768 is a high limit for Dwarf. We know we can run under less memory, but not on any reasonable boundary where we can lower this requirement at this time. But, we are working on this. 2. SXCE - Interactive GUI - 768MB(same as it has been for a long time) 3. Text installer - windows based - 512MB 4. Console based text installer - 256MB - its not quite 256MB any longer. Not sure exactly the numbers though. Again: did somebody, anybody at all, study how sgi solved this particular issue? sgi did not need 256MB of RAM to install IRIX, an OS which was on the order of several gigabytes in his default incarnation and used miniroot more than 15 years ago. It follows logically from this, that 15 years ago most sgi systems only had 24-32MB of RAM, so sgi must have done something right. If the answer is simply no, why not? This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Memory requirements to install Solaris
I think it's time we took this discussion to install-discuss. Please remove opensolaris-discuss from replies. Instead of requiring that we unpack to a RAM based miniroot, have we explored the option of mounting compressed filesystems on the CDROM, and using symlinks in the miniroot, when the system is under a certain amount of RAM. (Generally, compressed filesystems increase IO throughput, in exchange for CPU cycles. This is particularly true on slow storage media). I think it is possible that this option has not been explored, because there may not have been a supported compressed filesystem before the recent changes to ZFS. Thanks, Brian On 8/28/07, Sarah Jelinek [EMAIL PROTECTED] wrote: Hi Richard and All, Just a few comments inline... specific to the steps we took in the Caiman installer related to this discussion. Oh C'mon. 512Mb is not enough to run Windoze XP reasonably - even if you can actually install it. With 1Gb memory DIMMs around $50 (or less), expecting to run a state-of-the-art OS in 512Mb is absolutely unacceptable. If you're serious about (Open)Solaris, then you're serious about your hardware. We should never, under any circumstances, defend regression. Regression is an error. A severe and serious error. Dealing with regression has been one of the main selling points of Solaris. If Solaris starts regressing now, it will have lost one of the most crucial competetive edges. We didn't regress with Dwarf Caiman. We are within the existing memory checks that the Solaris installer has had in them for some time. This is our current requirements: 1. SXDE3 (Dwarf)- 786MB - we do exit out if the user doesn't have enough memory. We tell them to go to the text based installer. Now, 768 is a high limit for Dwarf. We know we can run under less memory, but not on any reasonable boundary where we can lower this requirement at this time. But, we are working on this. 2. SXCE - Interactive GUI - 768MB(same as it has been for a long time) 3. Text installer - windows based - 512MB 4. Console based text installer - 256MB - its not quite 256MB any longer. Not sure exactly the numbers though. We should also stop defending every bad decision and hiding behind engineering for everything that just plain isn't right: making that installer Java-based and Java-dependent was just plain bad decision and it caused regression. Rather than hiding behind claims that Java is great and that it's engineering, the responsible person(s) should admit the error and fix it. With Dwarf and subsequent Caiman projects we have moved from the Java based GUI to Gnome and C. This should help some, but it doesn't mitigate all the size issues in the miniroot. No disagreement with most of that, except that I'm not sure I see increases in memory requirements (even for the duration of installation) as regression as such, even if they may a real obstacle. Unless of course working on a specified minimum configuration is a distro objective that was violated. I see a lot of tradeoffs here (ease of use, flexibility, speed, minimum hardware requirements, development resources needed to optimize the balance of the previous, etc). The present situation may suck, but a balance that would satisfy all interests may not be feasible. Or to put it another way, for whatever you want, what would you be willing to give up? :-) Part of the problem may be RAM-resident miniroot bloat. Seems to me that only volatile data _needs_ to live there; everything else could be on the installation media. However, optical media is slow in the face of a lot of seeks. Dividing miniroot space requirements into volatile data vs cache for performance might help; the latter could be built in increments based on available resources, so that a system with ample RAM could install very quickly, but a slimmer system would still install, if slowly. That is, divide the possible miniroot contents into multiple cpio (or tar, as you prefer) archives on the installation medium, grouped so the most benefit comes with the initial increments. Depending on how much RAM is available, load zero or more of those into the miniroot (over and above the skeleton needed to hold e.g. device files, symlinks, directories, config files needed during installation, etc); set $PATH so that those tools would be found first on the miniroot, and if not there, on fully-populated versions of the miniroot directories stored on the installation media. RPATH would be set in the executables to look for libraries similarly. Actually, what you describe is what we do, partially. As part of the work on Dwarf I separated out what needed to be in the part we call the 'miniroot', x86.miniroot archive, and created several new archives that hold the data that may or may not be used depending on the path the user chooses for installation. We
Re: [osol-discuss] Memory requirements to install Solaris
4. Console based text installer - 256MB - its not quite 256MB any longer. Not sure exactly the numbers though. i thought grub required at least 512mb, that is a limiting factor in the x86 world No, I regularly boto a 256 MB system undergrub. Grub based installs require more memory because of the sheer size of the miniroot. It needs to fit main memory with room to spare to run Solaris in. Casper ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Memory requirements to install Solaris
I wasn't saying that Caiman regressed. I'm saying that installer and therefore Solaris as a whole regressed in terms of memory requirements. One used to be able to install Solaris 2.5.1 on 16MB o f RAM. Is anyone laughing at those 16 measly megabytes? I sure am not. This is serious. Solaris 2.5.1, in 16MB? I *am* surprised; I know it kinda worked in 48MB (laptop I had at the time). Again: did somebody, anybody at all, study how sgi solved this particular issue? sgi did not need 256MB of RAM to install IRIX, an OS which was on the order of several gigabytes i n his default incarnation and used miniroot more than 15 years ago. It follows logically from this, that 15 years ago most sgi systems only had 24-32MB of RAM, so sgi must have done something right. SunOS 3.x had a graphical installer which worked in 4MB, so perhaps that is not an argument :-) I think there's a fundamental flaw in he current installers; the installer needs to copy the 100s of megabytes of data it by and large does not use into memory before it starts working. (In fairness, the SunOS 3.x copied to disk) Casper ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Memory requirements to install Solaris
Hi there, I used to install/upgrade snvs using 384MB in Console/Text mode. and Up/Downgrade the RAM size as according to the system requirements. The very minimum to run the installed svn is 96MB (tested by a mal-function RAM stick of 256MB), the 96MB box will walk, not run, well for simple named, isc-dhcpd. To install the developer version, it's best to install from s10u3 and upgrade to Express, then use /cdrom/Developer_Tools/install.sh to install the developer kits, regardless of your RAM size (better 256MB for to be in failsafe mode), you may run Sun Studio 1[12]. Ah! do prepare larger swap area on different disk if you can and perform ufsdump/ufsrestore after installation and registration to minimize defragmentation. arrange frequently accessed area to the beginning of the disk will help a bit. That's two cents, if you find it helpful, Clarence CHU [EMAIL PROTECTED] This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Memory requirements to install Solaris
Richard L. Hamilton wrote: [...] We should also stop defending every bad decision and hiding behind engineering for everything that just plain isn't right: making that installer Java-based and Java-dependent was just plain bad decision and it caused regression. Rather than hiding behind claims that Java is great and that it's engineering, the responsible person(s) should admit the error and fix it. [...] Part of the problem may be RAM-resident miniroot bloat. Seems to me that only volatile data _needs_ to live there; everything else could be on the installation media. However, optical media is slow in the face of a lot of seeks. Dividing miniroot space requirements into volatile data vs cache for performance might help; the latter could be built in increments based on available resources, so that a system with ample RAM could install very quickly, but a slimmer system would still install, if slowly. That is, divide the possible miniroot contents into multiple cpio (or tar, as you prefer) archives on the installation medium, grouped so the most benefit comes with the initial increments. Depending on how much RAM is available, load zero or more of those into the miniroot (over and above the skeleton needed to hold e.g. device files, symlinks, directories, config files needed during installation, etc); set $PATH so that those tools would be found first on the miniroot, and if not there, on fully-populated versions of the miniroot directories stored on the installation media. RPATH would be set in the executables to look for libraries similarly. Slim Install: http://www.opensolaris.org/os/project/caiman/Slim_Install Live Media Kit: http://www.opensolaris.org/os/project/livemedia/ Performance: http://blogs.sun.com/moinakg/entry/the_belenix_livecd_performance_story http://blogs.sun.com/moinakg/entry/the_belenix_livecd_performance_story1 http://blogs.sun.com/moinakg/entry/the_belenix_livecd_performance_story2 http://blogs.sun.com/moinakg/entry/hsfs_changes_in_recent_belenix Regards, Moinak. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Memory requirements to install Solaris
[EMAIL PROTECTED] wrote: Performance: http://blogs.sun.com/moinakg/entry/the_belenix_livecd_performance_story http://blogs.sun.com/moinakg/entry/the_belenix_livecd_performance_story1 http://blogs.sun.com/moinakg/entry/the_belenix_livecd_performance_story2 http://blogs.sun.com/moinakg/entry/hsfs_changes_in_recent_belenix So why aren't your hsfs enhancement in ordinary OpenSolaris yet? Working on it. Should be going in soon. It is needed for Slim Install. I sent out the webrevs for community review to caiman-discuss a few days back. Regards, Moinak. Casper ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Memory requirements to install Solaris
I think the code review of Moinak's changes is going on. I did see a request on livemedia and caiman discuss. ~Joe On 28-Aug-07, at 9:09 PM, [EMAIL PROTECTED] wrote: Performance: http://blogs.sun.com/moinakg/entry/ the_belenix_livecd_performance_story http://blogs.sun.com/moinakg/entry/ the_belenix_livecd_performance_story1 http://blogs.sun.com/moinakg/entry/ the_belenix_livecd_performance_story2 http://blogs.sun.com/moinakg/entry/hsfs_changes_in_recent_belenix So why aren't your hsfs enhancement in ordinary OpenSolaris yet? Casper ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Memory requirements to install Solaris
Performance: http://blogs.sun.com/moinakg/entry/the_belenix_livecd_performance_story http://blogs.sun.com/moinakg/entry/the_belenix_livecd_performance_story1 http://blogs.sun.com/moinakg/entry/the_belenix_livecd_performance_story2 http://blogs.sun.com/moinakg/entry/hsfs_changes_in_recent_belenix So why aren't your hsfs enhancement in ordinary OpenSolaris yet? Casper ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Memory requirements to install Solaris
Solaris 2.5.1, in 16MB? I *am* surprised; I know it kinda worked in 48MB (laptop I had at the time). I have installed Solaris 7 on a 24MB SparcStation 1+, my own personal first ever UNIX piece of hardware. SunOS 3.x had a graphical installer which worked in 4MB, so perhaps that is not an argument :-) Why not? It's proof that it can be done in even less than 16MB! But I persist with my question: has anyone involved with working on the Solaris installer studied how sgi solved it? I think there's a fundamental flaw in he current installers; the installer needs to copy the 100s of megabytes of data it by and large does not use into memory before it starts working. It could load the miniroot into the swap slice instead; if the disk has no Solaris swap slices, it could use the newly ported qparted to offer to resize/reslice and create the necessary swap slice to load the miniroot into, and run it from there. RAM requirements for such code are minimal, on the order of few hundred kilobytes, plus whatever qparted needs. Even at 24-bit depth, installer graphics could be made to fit in under 2MB at decent resolution. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Memory requirements to install Solaris
UNIX admin writes: I think there's a fundamental flaw in he current installers; the installer needs to copy the 100s of megabytes of data it by and large does not use into memory before it starts working. It could load the miniroot into the swap slice instead; if the disk has no Solaris swap slices, it could use the newly ported qparted to offer to resize/reslice and create the necessary swap slice to load the miniroot into, and run it from there. Except, of course, that swap slices aren't a required part of the system. RAM requirements for such code are minimal, on the order of few hundred kilobytes, plus whatever qparted needs. Even at 24-bit depth, installer graphics could be made to fit in under 2MB at decent resolution. The big trade-off is with development time and support: re-using common components (such as Xorg and GNOME) means that development is much easier and we end up with rapid development of new install features and good, lasting support. It's entirely possible to create a tiny installer using custom parts. We could probably fit the whole darned thing in 100KB if we wanted. The trade off would be: - It'd be custom stuff, so nobody would know how to write to it. Bugs would be inevitable. - It'd be unshared with the rest of the system, so when there are problems, nobody would care about it. (Unless we posit a lifetime spent dedicated to supporting this obscure corner; an unlikely act by someone who works in engineering.) - When new hardware is developed, it wouldn't be supported, and might never be supported if the installer team has long since gone off to greener pastures. I agree that some of these parts are bloated and could be put on a diet. If you're interested in engineering this part of the system (in detail) then please do bring it up in install-discuss and the Caiman project in particular. There's likely a lot of interesting work yet to be done here. -- James Carlson, Solaris Networking [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: [osol-discuss] HCL is pretty anemic...
You can pretty much divide the Sun list price by 2, as is common with some other tech vendors. HP seems is the only one of the big computer firms I know that actually uses meaningful (i.e. accurate) list prices. Cheers Andrew. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] 915 gav boards installation?
will any thing work on intel 915 gav boards, starting from 11/06 release to latest b70 release I have tried every thing, nothing is working for me, either after installation, it fails to show up login splash screen or it fails at the installation stage for example b70 release failed to install after detecting key board layout and next screen weird display of failed graphic type.what could be the reasons, could some one throw some light on it please. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Is Sun's LDAP Directory server open source?
If so what consolidation is it part of? (I want to see how it compares to other open source directory servers.) Thanks, Brian -- - Brian Gupta http://opensolaris.org/os/project/nycosug/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] HP dv9000z
Has any one been able to download the F.38 bios from HP? I get a zero length file when I try. Near as I can tell, F.27 only supports a single hard disk. -John Sorry I missed your post. I never bothered to do the BIOS upgrade (don't know how to do the BIOS update from the Vista DVD). I downloaded sp36393.exe from HP.com which happened to be a zero byte file. So far, the built-in mouse pad doesn't work (I always disable it anyway). But I would like to have sound, though it is not a concern at least right now. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Is Sun's LDAP Directory server open source?
On 8/28/07, Brandorr [EMAIL PROTECTED] wrote: If so what consolidation is it part of? (I want to see how it compares to other open source directory servers.) no, it is not, however there is another opensource DS from sun called opends which is opensource. btw, not being opensouce is a requirement for the comparison or just another item to take into consideration? i'm just wondering nacho ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] An Open Letter to the Solaris Community.
two follow-up posts:
First:
Yes, this is from my blog. Thanks for reading :).
And yes, we can run Windows HVM on Solaris dom0 now.
BTW, I did a little bit correction on the translation below...
In our next step, we'll support nic/disk PV drivers for Windows HVM. At
that time, the performance should be very satisfactory.
Thanks,
Max
Second:
Hi Wayne,
I'm running Windows XP Home on Xen/Nevada. The CPU is Core2Duo 1.8GHz,
performance is ok. Attached is the config file.
Rgds,
Andre W.
#
# Python configuration setup for 'xm create'.
# This script sets the parameters used when a domain is created using 'xm
create'.
# You use a separate script for each domain you want to create, or
# you can set the parameters for the domain on the xm command line.
#
import os, re
arch = os.uname()[4]
if re.search('64', arch):
arch_libdir = 'lib64'
else:
arch_libdir = 'lib'
#
# Kernel image file.
kernel = /usr/lib/xen/boot/hvmloader
# The domain build function. HVM domain uses 'hvm'.
builder='hvm'
# Initial memory allocation (in megabytes) for the new domain.
#
# WARNING: Creating a domain with insufficient memory may cause out of
# memory errors. The domain needs enough memory to boot kernel
# and modules. Allocating less than 32MBs is not recommended.
memory = 512
# Shadow pagetable memory for the domain, in MB.
# Should be at least 2KB per MB of domain memory, plus a few MB per vcpu.
shadow_memory = 8
# A name for your domain. All domains must have different names.
name = Windows-on-Solaris
# 128-bit UUID for the domain. The default behavior is to generate a new UUID
# on each call to 'xm create'.
#uuid = 06ed00fe-1162-4fc4-b5d8-11993ee4a8b9
#-
# the number of cpus guest platform has, default=1
vcpus=1
# enable/disable HVM guest PAE, default=0 (disabled)
#pae=0
# enable/disable HVM guest ACPI, default=0 (disabled)
acpi=1
# enable/disable HVM guest APIC, default=0 (disabled)
apic=1
# List of which CPUS this domain is allowed to use, default Xen picks
#cpus = # leave to Xen to pick
#cpus = 0# all vcpus run on CPU0
#cpus = 0-3,5,^1 # run on cpus 0,2,3,5
# Optionally define mac and/or bridge for the network interfaces.
# Random MACs are assigned if not given.
#vif = [ 'type=ioemu' ]
#
# Define the disk devices you want the domain to have access to, and
# what you want them accessible as.
# Each disk entry is of the form phy:UNAME,DEV,MODE
# where UNAME is the device, DEV is the device name the domain will see,
# and MODE is r for read-only, w for read-write.
#disk = [ 'file:/export/home/mydisk.raw,hdc,w',
'file:/export/home/install.iso,hda:cdrom,r' ]
#disk = [ 'phy:/dev/dsk/c1d0p0,hdc,w',
'file:/export/home/install.iso,hda:cdrom,r' ]
#disk = [ 'phy:/dev/zvol/dsk/mypool/mydisk,hdc,w',
'file:/export/home/install.iso,hda:cdrom,r' ]
disk = [ 'file:/linuxpool/isos/winxp.iso,hdc:cdrom,r',
'phy:/dev/zvol/dsk/linuxpool/winxp,hda,w' ]
#
# Configure the behaviour when a domain exits. There are three 'reasons'
# for a domain to stop: poweroff, reboot, and crash. For each of these you
# may specify:
#
# destroy,meaning that the domain is cleaned up as normal;
# restart,meaning that a new domain is started in place of the old
# one;
# preserve, meaning that no clean-up is done until the domain is
# manually destroyed (using xm destroy, for example); or
# rename-restart, meaning that the old domain is not cleaned up, but is
# renamed and a new domain started in its place.
#
# The default is
#
# on_poweroff = 'destroy'
# on_reboot = 'restart'
# on_crash= 'restart'
#
# For backwards compatibility we also support the deprecated option restart
#
# restart = 'onreboot' means on_poweroff = 'destroy'
#on_reboot = 'restart'
#on_crash= 'destroy'
#
# restart = 'always' means on_poweroff = 'restart'
#on_reboot = 'restart'
#on_crash= 'restart'
#
# restart = 'never'means on_poweroff = 'destroy'
#on_reboot = 'destroy'
#on_crash= 'destroy'
on_poweroff = 'destroy'
on_reboot = 'restart'
on_crash= 'preserve'
#
# New stuff
device_model = '/usr/' + arch_libdir + '/xen/bin/qemu-dm'
#-
#
[osol-discuss] The open Microsoft XPS document format ?
friends : I am not a lawyer and perhaps some other kind community people can help me to understand what Microsoft is saying about their XML Paper Specification. I figure it is only a matter of time before we need some sort of software on Solaris that can deal with this format but as near as I can tell the license is horribly restrictive. This page : http://www.microsoft.com/whdc/xps/xpscommunitypromise.mspx I do not know *what* that page is trying to say. However I do see some plain language on this page : http://www.microsoft.com/whdc/xps/xpsspec.mspx Microsoft Corporation Technical Documentation License Agreement for the XML Paper Specification READ THIS! THIS IS A LEGAL AGREEMENT BETWEEN MICROSOFT CORPORATION (MICROSOFT) AND THE RECIPIENT OF THE ABOVE REFERENCED MATERIALS, WHETHER AN INDIVIDUAL OR AN ENTITY (YOU). IF YOU HAVE ACCESSED THIS AGREEMENT IN THE PROCESS OF DOWNLOADING THESE MATERIALS (MATERIALS) FROM A MICROSOFT WEB SITE, BY CLICKING I ACCEPT, DOWNLOADING, USING OR PROVIDING FEEDBACK ON THE MATERIALS, YOU AGREE TO THESE TERMS. IF THIS AGREEMENT IS ATTACHED TO MATERIALS, BY ACCESSING, USING OR PROVIDING FEEDBACK ON THE ATTACHED MATERIALS, YOU AGREE TO THESE TERMS. IF YOU DO NOT AGREE TO THESE TERMS, YOU ARE NOT AUTHORIZED TO ACCESS, DOWNLOAD, USE OR REVIEW THE MATERIALS. For good and valuable consideration, the receipt and sufficiency of which are acknowledged, You and Microsoft agree as follows: 1. You may review these Materials only (a) as a reference to assist You in planning and designing Your product, service or technology (Product) to interface with a Microsoft product, specification, service or technology (Microsoft Product) as described in these Materials; and (b) to provide feedback on these Materials to Microsoft. All other rights are retained by Microsoft; this Agreement does not give You rights under any Microsoft patents. You may not (i) duplicate any part of these Materials, (ii) remove this Agreement or any notices from these Materials, or (iii) give any part of these Materials, or assign or otherwise provide Your rights under this Agreement, to anyone else. etc etc etc The part that scares me are the words You may review these Materials ... as a reference to assist You in planning and designing Your product ... to interface with a Microsoft product, specification, service or technology Like I said .. I am not a lawyer and I am not about to drop $300/hour ( per shark ) to a team of IP lawyers to tell me that the XPS document format forces you into Microsoft lockin. Am I reading that correct? Does that tell me that one may never implement any software on Solaris or an OpenSolaris based distro such that one may open, use, manage an XPS document? It seems to say that I must work with some Microsoft technology. - Dennis ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
