Re: [osol-discuss] Re: [gnu-sol-discuss] Incorporating open-source cmds/libs into OpenSolaris
Paul Durrant [EMAIL PROTECTED] wrote: Initial Proposal * GNU commands that don't collide with current /usr/bin namespace - place these in /usr/bin. * GNU commands that do collide with commands already in /usr/bin - place these in /usr/gnu/bin, following the convention we started with /usr/xpg*/bin. I'd definitely go with this option. If there should be only one hierarchy for free software, it should not be named 'gnu' as GNU (FSF) programs are a minority in the FOSS universe. * Existing aliases (gtar, gmake, etc) will appear in /usr/sfw (and perhaps also in /usr/bin). You could add aliases to /usr/bin but I think it might be cleaner to keep GNU on non-GNU separated to avoid confusion. (Keeping symlinks from the current names in /usr/sfw to /usr/gnu is a good idea for backwards compatibility's sake though). If GNU tar is made available under the name 'tar' at all, it needs to be a recent version and compiled in a way that makes sure that the default archive format in create mode is POSIX compliant. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED](work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] opensolaris and Virtual PC
Bill Rushmore wrote: I got it working with VMware and it work quite nicely. I haven't tried Solaris in a while but I think the issue is that only Xorg will work with VPC. Try a text based install and configure for Xorg. From the feedback that I have received about BeleniX this is indeed an Xorg issue. One needs to manually configure Xorg to use a generic S3 video card driver. More details here: http://vpc.visualwin.com/ Text based install should work just fine. Regards, Moinak. Bill On Mon, 28 Nov 2005, Matty wrote: Has anyone gotten Nevada to boot with MSFT VPC running on OS X? I assume the answer is no, but I thought I would ask. From my limited testing, it looks like my opensolaris VM becomes unresponsive almost immediately after I select interactive installation. - Ryan -- UNIX Administrator http://daemons.net/~matty ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] lchmod
[EMAIL PROTECTED] wrote: What do you like to achieve with this call? There's one potential use: a chmod() call which doesn't follow symlinks. No race conditions, etc... OK, this makes sense. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED](work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] SOSUG#4 videos available
James McPherson on ZFS and Bryan Cantrill on new stuff in DTrace. Currently only have WMV version 9 video, I'm working on DivX. See the blog for details, I need to get to bed. http://blogs.sun.com/roller/page/tpenta?entry=sosug_4_videos_available alan. -- Alan Hargreaves - http://blogs.sun.com/tpenta Kernel/VOSJEC/Performance Staff Engineer Product Technical Support (APAC) Sun Microsystems ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: OpenSolaris - Why should I care?
Darren J Moffat [EMAIL PROTECTED] wrote: On Mon, 2005-11-28 at 13:34, Joerg Schilling wrote: Robert Lunnon [EMAIL PROTECTED] wrote: The simplicity of administering ZFS is far over everything else. All other systems seem to have usability problems, even the windows practice of rooting all drives in the same place isn't particularly convenient especially when it breaks all you shortcuts. I think ZFS gives all the benefits of unix filesystem semantics without the drawbacks. The simplicity of administration has it's drawbacks at the points where ZFS in incompatible with the UNIX philosohy (mount handling) and causes extra effort in order to make it usable for e.g. the SchillIX life CD. Thats what legacy mount points are for. Maybe I did not yet grok them, could you help me please? I tried 'zfs set mountpoint=legacy', but while mount -F zfs pool /mnt works, mount -F zfs /dev/lofi/1 /mnt does not work and gives this message: cannot open '/dev/lofi/1': invalid filesystem name If I like to mount a zfs partition, I will need to do this when / is mounted read only and /dev/ is empty. So after some checks, I willl e.g. know that the device that holds the zfs I like to mount is e.g. on: /devices/[EMAIL PROTECTED],0/[EMAIL PROTECTED],1/[EMAIL PROTECTED]/[EMAIL PROTECTED],0:d How do I tell this zfs to be able to mount it? Some times progress needs to be made and not everything in the original UNIX philosohy's makes sense anymore. Guess why I integrated find into star although UNIX people would say that you could run find | star list=- ? There are features, you cannot have with the 1970s UNIX philosohy. I understand that in case you integrate a volume management system into a filesystem, there is no way to write this down in vfstab. But for single background data volume based FS, it looks nice to handle. To me the old UNIX mount handling is even more broken than rc.local or sysvinit was and ZFS is to the old UNIX mount handling what SMF is to rc.local ans sysvinit. Mmm, why? Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED](work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: New forum proposal/wish
Hi There. What about a new forum regardig the Redhat linux binary execution in solaris zone feature, which are realeased very soon according to Sun ? The community will be coming very soon. The timeout on the naming proposal expired over the weekend, so hopefully we'll have a 'brandz' community running shortly. You can find the naming discussion archived on opensolaris.org: http://www.opensolaris.org/jive/click.jspa?searchID=8555messageID=15298 Nils This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: Solaris Containers for Linux Applications
is there a solaris containers for linux apps (SCLA?) thread/forum/whatever here somewhere? Not yet, but the timeout on the naming proposal expired over the weekend, so hopefully there will be a community within a few days. You can find the naming discussion archived on opensolaris.org: http://www.opensolaris.org/jive/click.jspa?searchID=8555messageID=15298 Nils This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Nexenta Systems Inc.
Joerg Schilling wrote: yesterday, I ran across something I could like to know but have not been able to elaborate: On www.gnusolaris.org, I read This work is initiated and sponsored by Nexenta Systems, Inc. Technical support is available from a variety of sources, including Community and Web Forums. The web site www.nexenta.com is a dummy and trying to find out who is behind Nexenta Systems, Inc. leads to a dead end: http://whois.sc/nexenta.com Could someone from the gnusolaris people enlighten me please? Please, this isn't the right mailing list for that. Instead you could have sent the question over to [EMAIL PROTECTED] as stated on the web site. Last I checked the folks at Nexenta prefer to stay anonymous for various reasons at the moment, so let's respect their decision. -- Mac ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: Re: Re: Re: OpenSolaris - Why should I care?
On Sun, 27 Nov 2005 10:02 pm, Joerg Schilling wrote: Jake Maciejewski [EMAIL PROTECTED] wrote: But you already claimed OpenBSD has unacceptable limitations for the desktop that Solaris doesn''t have. BTW Solaris has roots in a 30 year old technology not 10. Having said this Solaris is far more modern than that in just about everything, and with OpenSolaris now, is Solaris locked into technology any more than OpenBSD ? I'm not advocating OpenBSD for the desktop. And if you want to talk about roots, OpenBSD has its roots in NetBSD which has its roots in BSD. Solaris from what I know has its roots in the merging of BSD derived SunOS with SVR4 because SVR4 was more advanced at the time. Whereas Solaris got refreshed with the more advanced codebase, OpenBSD enjoys the benefits of a complete security audit to eliminate vulnerabilities from the old BSD days when security wasn't much of a concern. I admit that Solaris is more scalable (OpenBSD often performs worse with SMP enabled, for example) and possibly more stable, but that's because the developers care more about security. Looks like you forgot that Svr4 was derived from SunOS and SVr3... Which of course then traces all the way back to ATT which predates BSD. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: [gnu-sol-discuss] Incorporating open-source cmds/libs into OpenSolaris
Nikhil wrote:
I believe all of them putting under /usr/gnu/{lib,bin,include} whatever
specific to gnu under /usr/gnu as prefix directory would be better.
Do you have a reason?
My reason for preferring /usr/bin unless there's a name conflict is
simply this : if users cannot readily find a command, they implicitly
assume it isn't available. There is basically no benefit obtained from
hiding commands in strange places around the system; once a user
discovers he needs /usr/wombat/bin once in his path, he adds it - and
any benefit obtained from sequestering commands there is immediately
obviated.
Since there's no useful benefit, why put users through this at all?
In Solaris for years, we placed commands that were subject to change
outside of Sun's control in /usr/sfw/bin. This led to such absurdities
as having a menu item on the Solaris desktop to launch Mozilla,
but having mozilla not be found when invoked from a shell with
the default path - and all of this ostensibly to protect the user!
We could add more and more directories to the default path, ala SUSE.
This seems somewhat broken, and is now problematic with so many users
already explicitly setting their paths rather than appending to the
one they inherit from their login shell.
Note that executables not normally used from the command line (Xorg,
for example) should _not_ appear in the default path.
- Bart
--
Bart Smaalders Solaris Kernel Performance
[EMAIL PROTECTED] http://blogs.sun.com/barts
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: [gnu-sol-discuss] Incorporating open-source cmds/libs into OpenSolaris
On Tue, Nov 29, 2005 at 11:22:52AM -0800, Bart Smaalders wrote:
Nikhil wrote:
I believe all of them putting under /usr/gnu/{lib,bin,include} whatever
specific to gnu under /usr/gnu as prefix directory would be better.
Do you have a reason?
My reason for preferring /usr/bin unless there's a name conflict is
simply this : if users cannot readily find a command, they implicitly
assume it isn't available. There is basically no benefit obtained from
hiding commands in strange places around the system; once a user
discovers he needs /usr/wombat/bin once in his path, he adds it - and
any benefit obtained from sequestering commands there is immediately
obviated.
Since there's no useful benefit, why put users through this at all?
In Solaris for years, we placed commands that were subject to change
outside of Sun's control in /usr/sfw/bin. This led to such absurdities
as having a menu item on the Solaris desktop to launch Mozilla,
but having mozilla not be found when invoked from a shell with
the default path - and all of this ostensibly to protect the user!
I'm just impressed that Bart was able to get through this rant without
quoting our favorite example of this: /usr/proc/bin. Indeed, this
directory was _so_ egregious that we put the p-tools in /usr/bin in
Solaris 8, leaving /usr/proc/bin as a directory of symlinks into /usr/bin.
Suffice it to say that we have learned the hard way: put it in /usr/bin
unless there's a conflict that prevents it. Yes, this sullies /usr/bin,
and yes, there is a non-zero risk in terms of system compatibility --
but we know from painful experience that acts of cowardice like
/usr/proc/bin create more problems than they solve.
- Bryan
--
Bryan Cantrill, Solaris Kernel Development. http://blogs.sun.com/bmc
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
[osol-discuss] questions about moving to ZFS
Hi all. I do have some questions concerning the move away from UFS/SVM to ZFS. Using SVM mirror quite intensivly in the past we many times broke up mirrors and mounted each submirrors UFS on seperate mountpoint or just kept one as a kind of snapshot. Has always been a nice quick and cheap backup while upgrading the OS. So here question 1: - assuming a zpool in 2 disk mirror configuration on which one or more ZFS reside would it be possible to do the same trick? I understand that we could export the pool and import on two different machines and fix the 'missing mirror part' afterwards. But is there a way to get a similar thing done on ONE machine? Many years ago we developed a home grown cluster solution for Solaris whick makes use of a nive SVM feature: disksets. The kernel issues a SCSI reservation command protecting the external RAIDs from being accessed by the standby cluster node. If it tries anyway the active one will panic. So the complete setup holds two external hardware RAID5 boxes mirrored by SVM. The mirrors can easily mounted by both of the clusternodes as they are attached by FC-AL links, of course only one is allowed at any given time. Q2: ZFS surely allows for the mirrored setup but is there something similar to the reservation mechanism in SVM. Q3: if disks holding zpools are attached to different machines, each of the machines could (ignoring the conflicts) in theory access the pools only by scanning the information residing on the disks, right? Would there be need for an 'export' or will it just work? Hope it's not to early to raise the questions but we are facing the limitations of UFS so I'm looking forward to yours answers Thanks a lot Thomas - GPG fingerprint: B1 EE D2 39 2C 82 26 DA A5 4D E0 50 35 75 9E ED ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] what kind of updates ?
hi.. I read at solaris site that free updates are in place for security and hardware drivers..if cost of ownership for system ( non security or hardware related) udpates means at least $120/yr then thats not a road I feel comfortable going down ( when clear linux alteratives exist ) but I of course wanted to make sure I was understanding the website info correclty. thank you ;-) nl Message was edited by: neighbor This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
RE: [osol-discuss] what kind of updates ?
nl, Those updates are for Solaris, not OpenSolaris. Since OpenSolaris source code is free, updates could be obtained and compiled any time you wanted them. There will be multiple distributions based on OpenSolaris (Solaris, SchilliX, Nexenta, etc. You can choose to run any of them, and they will each have their own support policies. Brett Albertson [EMAIL PROTECTED] Strategic Technologies voice: 919-379-8449 FAX: 919-379-8100 Solaris Core, Enterprise, E10K, F15K certified. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] lchmod
Chris Ricker [EMAIL PROTECTED] wrote: On Tue, 29 Nov 2005, Joerg Schilling wrote: [EMAIL PROTECTED] wrote: What do you like to achieve with this call? There's one potential use: a chmod() call which doesn't follow symlinks. No race conditions, etc... OK, this makes sense. BTW, it's not just a Linux thing -- the BSDs have lchmod as well, and HP-UX used it for their transition links stuff HP-UX checks the permissions of symlinks, but I am not sure whether lchmod exists for a longer time. star sets the modes of a symlink using umask(2) on HP-UX. As this is not deactivated on other OS, it would work on Solaris too if Solaris would allow to have different symlink modes. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED](work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: OpenSolaris - Why should I care? More
On 11/28/05, UNIX admin [EMAIL PROTECTED] wrote: A classic one I just *adore* is allowing the use of // for comments inside of C source code... actually, that's C99. SunStudio allows it as well. no flamewar points for you!! You think? Sun Studio compilers used to complain violently until C99 got implemented a few releases back. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] SVOSUG ZFS video online at genunix (from 11/22/05)
The video from our last Silicon Valley Open Solaris User Group is online, in case anyone didn't know, and can be got from genunix.org at this link: http://www.genunix.org/osug/video/OSUG-Nov.avi Much thanks to the folks that make genunix.org possible for all of us! -- Alan DuBoff - Sun Microsystems Solaris x86 Engineering ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [desktop-discuss] Re: [osol-discuss] Re: [gnu-sol-discuss] Incorporating open-source cmds/libs into OpenSolaris
Bryan Cantrill wrote: Suffice it to say that we have learned the hard way: put it in /usr/bin unless there's a conflict that prevents it. Though I still get complaints about GNOME being in /usr/bin, since it makes it harder to install another version and without breaking all the existing bits of the OS that depend on Sun's version. -- -Alan Coopersmith- [EMAIL PROTECTED] Sun Microsystems, Inc. - X Window System Engineering ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [desktop-discuss] Re: [osol-discuss] Re: [gnu-sol-discuss] Incorporating open-source cmds/libs into OpenSolaris
On Tue, 2005-11-29 at 18:08 -0800, Alan Coopersmith wrote: Bryan Cantrill wrote: Suffice it to say that we have learned the hard way: put it in /usr/bin unless there's a conflict that prevents it. Though I still get complaints about GNOME being in /usr/bin, since it makes it harder to install another version and without breaking all the existing bits of the OS that depend on Sun's version. I see it like this: GNOME's /usr/bin stuff should correspond to the latest installed one and /usr/lib should has older libraries so, closed sourced user apps will not break. Erast ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] opensolaris on 915gm
does opensolaris latest build supports intel 915gm? thanks This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [desktop-discuss] Re: [osol-discuss] Re: [gnu-sol-discuss] Incorporating open-source cmds/libs into OpenSolaris
Alan Coopersmith wrote: Bryan Cantrill wrote: Suffice it to say that we have learned the hard way: put it in /usr/bin unless there's a conflict that prevents it. Though I still get complaints about GNOME being in /usr/bin, since it makes it harder to install another version and without breaking all the existing bits of the OS that depend on Sun's version. Which I guess this opens the can of worms that is should the OS depend on its desktop? Ian ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] opensolaris on 915gm
On Tue, 2005-11-29 at 20:26, len wrote: does opensolaris latest build supports intel 915gm? thanks Sort of, err not very well. Maybe. Got one in this Dell D610, I use the XSun Intel VESA driver. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: [gnu-sol-discuss] Incorporating open-source
Nikhil wrote:
I believe all of them putting under
/usr/gnu/{lib,bin,include} whatever
specific to gnu under /usr/gnu as prefix directory
would be better.
Do you have a reason?
My reason for preferring /usr/bin unless there's a
name conflict is
simply this : if users cannot readily find a
command, they implicitly
assume it isn't available. There is basically no
benefit obtained from
hiding commands in strange places around the
system; once a user
discovers he needs /usr/wombat/bin once in his path,
he adds it - and
any benefit obtained from sequestering commands there
is immediately
obviated.
Since there's no useful benefit, why put users
through this at all?
I have to disagree. I truely believe that the gnu tree should be installed in
it's own cubbyhole i.e. /usr/gnu/{bin, lib, libexec, man, ...}. This way the
user can set the path select their preference (gnu commands over solaris or
visa-versa). As for the libraries... I think that the rule should be to build
applications with the -R linkage option so no matter what the library search
order is the application binds to the specific library known to be compatible.
Under Solaris 9, I had one heck of a time resolving the iconv discrepancies for
the gnu programs that required the gnu version of iconv, (as well as other
libraries).
It's nice to be able to know what you're selecting. For example, I really
abhor that Linux /bin/sh is really bash. When I ask for sh, I'd like to get
the sh I know with all it's own quirks. If I wanted bash I would have asked
for it.
My 2 cents.
Gary
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Re: [osol-discuss] questions about moving to ZFS
Hello Thomas, Tuesday, November 29, 2005, 9:15:19 PM, you wrote: TN Hi all. TN I do have some questions concerning the move away from UFS/SVM to ZFS. TN Using SVM mirror quite intensivly in the past we many times broke up TN mirrors and mounted each submirrors UFS on seperate mountpoint or just TN kept one as a kind of snapshot. Has always been a nice quick and cheap TN backup while upgrading the OS. So here question 1: TN - assuming a zpool in 2 disk mirror configuration on which one or more ZFS TN reside would it be possible to do the same trick? I understand that we TN could export the pool and import on two different machines and fix the TN 'missing mirror part' afterwards. But is there a way to get a similar TN thing done on ONE machine? Why not to use snapshots? They are persistent regarding to reboots (which is not a case in UFS). TN Q2: ZFS surely allows for the mirrored setup but is there something TN similar to the reservation mechanism in SVM. Not (yet). TN Q3: if disks holding zpools are attached to different machines, each of TN the machines could (ignoring the conflicts) in theory access the pools TN only by scanning the information residing on the disks, right? Would there TN be need for an 'export' or will it just work? Should just work if it hasn't changed lately. TN Hope it's not to early to raise the questions but we are facing the TN limitations of UFS so I'm looking forward to yours answers Keep in mind that ZFS on-disk format could possible still change from version to version (or maybe it's frozen right now after it went public - ???). -- Best regards, Robertmailto:[EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] questions about moving to ZFS
Thanks for the quick reply Robert. TN - assuming a zpool in 2 disk mirror configuration on which one or more ZFS TN reside would it be possible to do the same trick? I understand that we TN could export the pool and import on two different machines and fix the TN 'missing mirror part' afterwards. But is there a way to get a similar TN thing done on ONE machine? Why not to use snapshots? They are persistent regarding to reboots (which is not a case in UFS). Snapshots only solve half of the problem as they don't allow a mirror to be broken up and each part being treated independently. For anything else you are of course right Keep in mind that ZFS on-disk format could possible still change from version to version (or maybe it's frozen right now after it went public - ???). That's my hope too. Of course we won't move all our mail spool and home directories to ZFS as long as no official statement from Sun ensuring that the format is frozen Thomas - GPG fingerprint: B1 EE D2 39 2C 82 26 DA A5 4D E0 50 35 75 9E ED ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] how to do read/write files in the kernel?
In kernel modules, how to do read/write files ? This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
