Re: [osol-discuss] xenix?
On Mon, Apr 30, 2007 at 08:31:23PM +0200, Joerg Schilling wrote: Jim Bolin [EMAIL PROTECTED] wrote: does opensolaris allow a xenix drive to be mounted? I have an old xenix drive that people want data off of and it won't boot anymore. I can't find a xenix install set anywhere so am looking for another os that will allow me to mount it. Linux won't do it as far as I can tell. What filesystem type is it? Sun did remove support for the old V7 filesystem many years ago. Xenix is mostly a v7-style filesystems, but with a bunch of subtile changes. The Linux sysv filesystem driver supports, I don't know about any other opensource implementation that can deal with this filesystem type. Unfortunately Linux doesn't deal with the Xenix/SCO divvy style partition tables, so the only use the driver is are floppies. I've managed to recover data from Xenix drivers by searching the disk for the superblock magic and the hacking an offset directly into the driver. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Community participation
On Wed, Jan 31, 2007 at 09:09:20PM +0100, [EMAIL PROTECTED] wrote: Oh, and when did kprobes and ReiserFS integrate? In Opensolaris? Not at all. In Linux which is probably offtopic here it's 2004 (kprobes) and 2001 (reiserfs). ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: Shipping lsof with Solaris ? / was: Re: [osol-discuss] problem with /tmp FS still up
On Fri, Jan 05, 2007 at 11:59:27AM +, Frank Hofmann wrote: On the other hand, the request for lsof in Solaris is anything but new, and the reference to pfiles, the mentioning that lsof does nasty digging in the kernel's intestines as a reply is neither, and the arguments that the output format is different, the system load of pfiles is higher, lsof is common operator knowledge, ... - all that isn't new either ... Note that lsof doesn't have to do kmem craling. For example on Linux it only uses proper procfs interfaces. As such proper interfaces seem to exist on Solaris as well for use with pfiles it shouldn't be a problem for people knowledgeable in this area to adjust lsof to do the right thin on Solaris aswell. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Project proposal: support GCCfss and gcc 4 in ON
On Mon, Jul 24, 2006 at 09:11:23PM +0200, Rainer Orth wrote: New releases can be provided in distro, but kernel is alwasy based on some branch of some release branch. Currently they are 4.0s and 4.1s This may be for the same reasons as with Solaris: they may require specific changes that didn't make it into the GCC release, or bug fixes that weren't acceptable for GCC mainline. The Linux kernel definitly does not require changes to release gcc versions. It works with any gcc starting from gcc 3.2 up to the most recent released version. That the linux distributions ship gcc versions with local patches has nothing to do with the linux kernel. In fact if you look at the patches you'll see that very few even touch the C frontend but most are in the support for other languages or to the lesser extent the architecture backends. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Project proposal: support GCCfss and gcc 4 in ON
On Mon, Jul 24, 2006 at 12:52:43PM -0700, Alexey Starovoytov wrote: On Mon, 24 Jul 2006, Christoph Hellwig wrote: That is of course utter bullshit. The Linux kernel doesn't require a specific gcc version. I didn't say it requires. I said shipped Linux kernel is always built with patched gcc. Please prove otherwise. I'm just now building it with an unpatched gcc at this moment (and so do probably various other people). Does that count or do I need a sun certified officially unpatched (TM) gcc for it? ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Red Hat vs. Sun processor number war: 64:21 - RHwins!
On Sat, Mar 18, 2006 at 12:38:27PM +0100, Frank van der Linden wrote: But, touting the limit is kinda pointless if the current limit is well below it.. I've never run NetBSD/amd64 on more than 4CPU/16G, and it might blow up spectacularly when run on 32CPU hardware, should it become available. The RH 64 limit is just marketing.. I don't know of an actual x86_64 system with 64 cpus, but the Unisys E7000 series is supported with up to 32 (single core) Cpus with both RedHat and SuSE and works well (although not officially supported) with normal mainline kernels. As they probably plan using dual core Xeons that 64 Cpu will probably be readched with real hardware soon. On the ia64 side there's hundreds of machines in the range from 64 to 128 in the field from sgi that run normal SuSE or seldomly RedHat, and there are some 256 and 512 cpu machines with plain SLES9 in the field aswell. So this isn't just marketing, machines of that size do become more or less common these days. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] mounted CDROMs and door locking
On Sun, Nov 20, 2005 at 03:42:52PM +0100, Joerg Schilling wrote: This practice is used since 1988 and before Microsoft and Linux did something else, nobody complained. Linux doesn't allow to eject a CD in use. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] mounted CDROMs and door locking
On Mon, Nov 21, 2005 at 07:36:25PM +0530, Moinak Ghosh wrote: This practice is used since 1988 and before Microsoft and Linux did something else, nobody complained. It does. Just try a latest 2.6 kernel which has subfs. I works on SuSE 9.3. Then the suse folks patched your kernel. Standard linux behaviour for Linux is to lock the door on a cdrom once it's opened (from kernel or userspace). ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] mounted CDROMs and door locking
On Mon, Nov 21, 2005 at 07:36:25PM +0530, Moinak Ghosh wrote: It does. Just try a latest 2.6 kernel which has subfs. There's no subfs in a latest 2.6 kernel. I looked up what subfs is, and it's a stackable filesystem that is mounted to a mount pointed at boot time, and then mounts an underlying filesystem on access + a daemon that umounts it once it's unused again. I don't see that it uses any special care to unlock the door of a mounted cdrom, it just keeps it's usage time down. If you are really keen on this behaviour you could write a similar filesystem for solaris or try to trick autofs into this scenario. In general I'd advice against it because it's a really stupid idea. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Porting ReiserFS to Solaris?
You don't seem to have any expertise about linux filesystems, and what you're writing is both totally offtopic here and completely wrong. Please let this sub-thread die. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
