[OpenIndiana-discuss] SeaMonkey
Where I can get the latest (2.1 or 2.2-beta) version package for the OpenIndiana? I use 2.0b1 at the moment. It eats 3-4 times less memory than the Firefox+Thunderbird. ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Question about drive LEDs
Blinking led's is a nice to have, but if your server supports ipmi and ses, the fault management report has already located the disk. So I need to replace the disk in ses-enclosure=1/bay=6/disk=0 Apr 15 2010 22:25:27 abbbe612-1131-6add-f5c9-8537ecb46dc7 DISK-8000-0X 100% fault.io.disk.predictive-failure Problem in: hc://:product-id=LSILOGIC-SASX36-A.1:server-id=:chassis-id=50030480005a337f:serial=6 XW15V2S:part=ST32000542AS-ST32000542AS:revision=CC34/ses-enclosure=1/bay=6/disk=0 Affects: dev:///:devid=id1,sd@n5000c50021f4916f//pci@0,0/pci8086,4023@3/pci15d9,a680@0/sd@24, 0 FRU: hc://:product-id=LSILOGIC-SASX36-A.1:server-id=:chassis-id=50030480005a337f:serial=6 XW15V2S:part=ST32000542AS-ST32000542AS:revision=CC34/ses-enclosure=1/bay=6/disk=0 Location: 006 Mark. ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Question about drive LEDs
Mark, Can you post the content of your blog in this list? Many thanks. look here. http://stored-on-zfs.blogspot.com Fred -Original Message- From: Mark [mailto:mark0...@gmail.com] Sent: 星期五, 六月 24, 2011 16:24 To: openindiana-discuss@openindiana.org Subject: Re: [OpenIndiana-discuss] Question about drive LEDs Blinking led's is a nice to have, but if your server supports ipmi and ses, the fault management report has already located the disk. So I need to replace the disk in ses-enclosure=1/bay=6/disk=0 Apr 15 2010 22:25:27 abbbe612-1131-6add-f5c9-8537ecb46dc7 DISK-8000-0X 100% fault.io.disk.predictive-failure Problem in: hc://:product-id=LSILOGIC-SASX36-A.1:server-id=:chassis- id=50030480005a337f:serial=6 XW15V2S:part=ST32000542AS-ST32000542AS:revision=CC34/ses- enclosure=1/bay=6/disk=0 Affects: dev:///:devid=id1,sd@n5000c50021f4916f//pci@0,0/pci8086,4023@3/pci15d9, a680@0/sd@24, 0 FRU: hc://:product-id=LSILOGIC-SASX36-A.1:server-id=:chassis- id=50030480005a337f:serial=6 XW15V2S:part=ST32000542AS-ST32000542AS:revision=CC34/ses- enclosure=1/bay=6/disk=0 Location: 006 Mark. ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] oracle removes 32bit x86 cpu support for solaris 11 will OI do same?
While we are talking about 32 | 64 bit processes; Which one is better? Faster? More efficient? Mike On Thu, 2011-06-23 at 13:59 +0100, Deano wrote: Windows made the shift last server release (2008r2 is x64 only). So it's only the OSS server families which support 32bit, likely because both BSD and Linux support lots of platforms outside of x86. Deano -Original Message- From: Gary Driggs [mailto:gdri...@gmail.com] Sent: 23 June 2011 02:10 To: Discussion list for OpenIndiana Subject: Re: [OpenIndiana-discuss] oracle removes 32bit x86 cpu support for solaris 11 will OI do same? FWIW, Mac OS X Lion will only support x64 as well. IMHO, this is a good move for modern operating systems since there are always going to be alternatives for those still using i386 architecture. How long has Solaris/SPARC been 64-bit? At least ten years if not more... -Gary ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] oracle removes 32bit x86 cpu support for solaris 11 will OI do same?
On Jun 23, 2011, Ben Taylor wrote: Personally, I wouldn't have signed up for a Kw based pricing scheme which you apparently did) I didn't as it's one of many data centers that our company built and maintains. I just prefer not to be an ass about resources. -Gary ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] oracle removes 32bit x86 cpu support for solaris 11 will OI do same?
The answer really is it depends. On x86-64, the big advantage to 64-bit performance-wise is the additional CPU registers that it enables. The downside is the additional memory usage due to bigger pointer sizes. From what I understand, this increased size can have negative effects on CPU cache hit rates. -Dustin On Fri, Jun 24, 2011 at 7:02 AM, Michael Stapleton michael.staple...@techsologic.com wrote: While we are talking about 32 | 64 bit processes; Which one is better? Faster? More efficient? Mike On Thu, 2011-06-23 at 13:59 +0100, Deano wrote: Windows made the shift last server release (2008r2 is x64 only). So it's only the OSS server families which support 32bit, likely because both BSD and Linux support lots of platforms outside of x86. Deano -Original Message- From: Gary Driggs [mailto:gdri...@gmail.com] Sent: 23 June 2011 02:10 To: Discussion list for OpenIndiana Subject: Re: [OpenIndiana-discuss] oracle removes 32bit x86 cpu support for solaris 11 will OI do same? FWIW, Mac OS X Lion will only support x64 as well. IMHO, this is a good move for modern operating systems since there are always going to be alternatives for those still using i386 architecture. How long has Solaris/SPARC been 64-bit? At least ten years if not more... -Gary ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] branding for illumos/openindiana
As long as the reaction people get when installing and using it is not OY! Yes :))) ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] oracle removes 32bit x86 cpu support for solaris 11 will OI do same?
For Intel CPUs, 32 bit code is certainly more compact , and in some cases arguably faster than 64 bit code. (say, comparing the same code on the same machine compiled 32 and 64 bit) But, newer cpu silicon tends to make performance improvements in many ways (e.g locating more supporting circuity on the cpu's silicon, increasing L1 /L2 cache sizes, etc) Newer CPUs also tend to be more energy efficient. Intel made great strides towards energy efficiency. E.g.: idling the cpu when not in use ( deep C states etc. of gating off any circuitry that is not in use, modulating the cpu clock rate ( SpeedStep). So performance and energy efficiency is more dependent on which generation of cpu core design we have, rather than on just the the bitness . The primary advantage of 64 bit per se ( ie running a given cpu in 64 bit mode) is the increased addressable memory space. The current hardware limit set by the manufacturers is at 48 address bits (256 terabytes theoretical limit) Actual OS support cuts this in half, or less. Motherboard limitations further curtail this, but 48G motherboards are now commonplace. On 32 bit Intel (Amd) you are typically limited to 4G, which is split between kernel and userland depending on the OS and configuration. (E.g.: 1G kernel and 3G userland) Steve - Michael Stapleton michael.staple...@techsologic.com wrote: While we are talking about 32 | 64 bit processes; Which one is better? Faster? More efficient? Mike ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] oracle removes 32bit x86 cpu support for solaris 11 will OI do same?
The main difference is (in)ability to use large amount of RAM. 32-bit systems use 32-bit pointers, and maximum value of unsigned 32-bit integer is 2^32, or 4Gb. In practice many 32-bit OSes are able to address only 2Gb of RAM. 64-bit pointers can address much more RAM (no hardware has reached 2^64 RAM limit yet). Nowadays even laptops may have 4 or 8 Gb of RAM, not to mention servers, which should have much more. So, 32-bit OS is a past day OS, for legacy hardware only. Unfortunately not everyone can afford a new hardware. My web server has 1 GB RAM and 32-bit processor :( Happily running OSol b134 :) Regards, Dmitry. While we are talking about 32 | 64 bit processes; Which one is better? Faster? More efficient? ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] oracle removes 32bit x86 cpu support for solaris 11 will OI do same?
So I guess it would be fair to say that the best OS is the one that support both at the same time, and leaves the option to the developer for each individual application. My understanding is that Solaris is more like 4G per process/kernel, rather than 4GB total. Multiple 32 bit processes could use more than 4GB total; just not individually. Mike On Fri, 2011-06-24 at 15:58 +, Steve Gonczi wrote: For Intel CPUs, 32 bit code is certainly more compact , and in some cases arguably faster than 64 bit code. (say, comparing the same code on the same machine compiled 32 and 64 bit) But, newer cpu silicon tends to make performance improvements in many ways (e.g locating more supporting circuity on the cpu's silicon, increasing L1 /L2 cache sizes, etc) Newer CPUs also tend to be more energy efficient. Intel made great strides towards energy efficiency. E.g.: idling the cpu when not in use ( deep C states etc. of gating off any circuitry that is not in use, modulating the cpu clock rate ( SpeedStep). So performance and energy efficiency is more dependent on which generation of cpu core design we have, rather than on just the the bitness . The primary advantage of 64 bit per se ( ie running a given cpu in 64 bit mode) is the increased addressable memory space. The current hardware limit set by the manufacturers is at 48 address bits (256 terabytes theoretical limit) Actual OS support cuts this in half, or less. Motherboard limitations further curtail this, but 48G motherboards are now commonplace. On 32 bit Intel (Amd) you are typically limited to 4G, which is split between kernel and userland depending on the OS and configuration. (E.g.: 1G kernel and 3G userland) Steve - Michael Stapleton michael.staple...@techsologic.com wrote: While we are talking about 32 | 64 bit processes; Which one is better? Faster? More efficient? Mike ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] oracle removes 32bit x86 cpu support for solaris 11 will OI do same?
Steve Gonczi wrote: I really can not make a case for 32 bit except for a legacy binary where you do Not have a choice Do we need a 32 bit kernel ? Probably not. Do we need the ability To run a 32 bit binary?I think so Well, can't speak to opensolaris, but for 64-bit linux and windows, you can run 32-bit executables just fine, so that argument is not compelling, IMO... ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] branding for illumos/openindiana
On Fri, Jun 24, 2011 at 9:44 AM, Kent Watsen k...@watsen.net wrote: Open Indiana is a goofy name, even considering its history, but the acronym is OK. How about just shortening it to OpenIndy? :) -- .\\ark ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] oracle removes 32bit x86 cpu support for solaris 11 will OI do same?
On 06/24/11 08:58 AM, Steve Gonczi wrote: For Intel CPUs, 32 bit code is certainly more compact , and in some cases arguably faster than 64 bit code. (say, comparing the same code on the same machine compiled 32 and 64 bit) But 64-bit code has access to more registers, which can make a measurable difference for some code. SPARC is much more like you say, since the registers and ISA's are basically the same between the two modes, leaving it down to things like accessing a greater range of memory vs. doubling the memory used by every pointer address long int. -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] branding for illumos/openindiana
On 6/24/2011 10:45 AM, Dan Swartzendruber wrote: Kent Watsen wrote: Open Indiana is a goofy name, even considering its history, but the acronym is OK. Similar to how Kentucky Fried Chicken is now KFC, can we consider emphasizing oi? As long as the reaction people get when installing and using it is not OY! How about Oui! (Yes! in French) I do agree though that the OI acronym works fairly well. ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] oracle removes 32bit x86 cpu support for solaris 11 will OI do same?
So I guess it would be fair to say that the best OS is the one that support both at the same time Yes, and that's OSol and OI do. On 24.06.2011 22:17, Michael Stapleton wrote: So I guess it would be fair to say that the best OS is the one that support both at the same time, and leaves the option to the developer for each individual application. My understanding is that Solaris is more like 4G per process/kernel, rather than 4GB total. Multiple 32 bit processes could use more than 4GB total; just not individually. Mike On Fri, 2011-06-24 at 15:58 +, Steve Gonczi wrote: For Intel CPUs, 32 bit code is certainly more compact , and in some cases arguably faster than 64 bit code. (say, comparing the same code on the same machine compiled 32 and 64 bit) But, newer cpu silicon tends to make performance improvements in many ways (e.g locating more supporting circuity on the cpu's silicon, increasing L1 /L2 cache sizes, etc) Newer CPUs also tend to be more energy efficient. Intel made great strides towards energy efficiency. E.g.: idling the cpu when not in use ( deep C states etc. of gating off any circuitry that is not in use, modulating the cpu clock rate ( SpeedStep). So performance and energy efficiency is more dependent on which generation of cpu core design we have, rather than on just the the bitness . The primary advantage of 64 bit per se ( ie running a given cpu in 64 bit mode) is the increased addressable memory space. The current hardware limit set by the manufacturers is at 48 address bits (256 terabytes theoretical limit) Actual OS support cuts this in half, or less. Motherboard limitations further curtail this, but 48G motherboards are now commonplace. On 32 bit Intel (Amd) you are typically limited to 4G, which is split between kernel and userland depending on the OS and configuration. (E.g.: 1G kernel and 3G userland) Steve - Michael Stapletonmichael.staple...@techsologic.com wrote: While we are talking about 32 | 64 bit processes; Which one is better? Faster? More efficient? Mike ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
[OpenIndiana-discuss] tuntap 64bit driver
Hi, A few years ago I built a 64bit tuntap driver for Solaris 10 x86 to use with VirtualBox and made it available in October 2007. I switched isp but the website remains, if you want to try the binary it is still available here http://www.facts4u.dsl.pipex.com/ ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] oracle removes 32bit x86 cpu support for solaris 11 will OI do same?
On Jun 24, 2011, at 4:17 PM, Dmitry Kozhinov wrote: So I guess it would be fair to say that the best OS is the one that support both at the same time Yes, and that's OSol and OI do. Processes running under 32-bit Solaris can only be 32-bit. Processes running under 64-bit Solaris can be either. However, drivers, etc must match the kernel. And for all practical purposes, debugging a process (or the kernel) is a whole lot easier when done by a process with the same bitness as what it's debugging. For instance, it may not be feasible for a 32-bit process to control a 64-bit process (although the reverse may be possible, if more difficult than if they were the same). So the loss of a 32-bit kernel option limits mainly the hardware you can run on (CPU, but maybe also old drivers that were never ported to 64-bit). Other OS's may have somewhat different rules. OS X for instance can run 64-bit processes on a 32-bit kernel given 64-bit capable hardware. I expect that very few OS's would go to the trouble of supporting 32-bit drivers on a 64-bit OS, for example; not perhaps 100% impossible depending on the driver-to-OS interface, but certainly extra complexity where it's most dangerous. ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
