Re: [OpenIndiana-discuss] [developer] Re: Memory usage concern
On Sat, Oct 20, 2012 at 1:57 PM, Cedric Blancher cedric.blanc...@googlemail.com wrote: On 16 October 2012 01:22, Jason Matthews ja...@broken.net wrote: -Original Message- From: Cedric Blancher [mailto:cedric.blanc...@googlemail.com] IMO you blame the wrong people. You can have the same kind of problems with any Illumos-based distribution if you activate a zone and let the machine just sit there for a week or so or have a lot filesystem activity using mmap(). Either way the machines will choke themselves to memory starvation. The only workaround we found are regular reboots (every 24h), or limit the ZFS ARC to an absolute minimum. I don't think you understand. My proxy tier does almost no reads from the file system. There is no content on the server. OK, sorry then. Same symptoms, different cause, albeit it's so bad that it makes the OS virtually unusable for any serious work. Ced This whole discussion sounds bizarre to me. I have a Solaris 10 Update 1 system with over a dozen zones with UFS with 8 Gig RAM and don't experience these types of issues. We reboot once a year, whether we need to or not. This is my limited understanding... - UFS basically consumes all unused memory for paging, without ever telling the OS, but releases it to OS processes when memory is needed. UFS does not tell the OS that it is using the unused memory as buffer cache, so you never know it when you check for your memory usage. - ZFS basically consumes all unused memory for ARC, but tells the OS when it is taking RAM. The ZFS ARC is supposed to give back memory when there is pressure to do so. You always know how much memory is really being used when you check your memory usage. I had issues in the past where disk I/O started to go through the roof, on UFS filesystems, when the free memory was getting below 4 Gig of RAM... a sure sign the apps were starving the invisible UFS buffer cache. I don't really understand how applications can be starved by ZFS unless ZFS can not give back the buffers (lots of constant full-table scans?) Has Illumos developers really confirmed such a ZFS bug, where it is not returning memory to the OS? This just does not sound right, to me. Thanks - Dave H http://netmgt.blogspot.com/ ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Namespace management and symlinks in /usr
--- On Wed, 10/17/12, James Carlson carls...@workingcode.com wrote:
From: James Carlson carls...@workingcode.com
Subject: Re: [OpenIndiana-discuss] Namespace management and symlinks in
/usr
To: Discussion list for OpenIndiana
openindiana-discuss@openindiana.org
Date: Wednesday, October 17, 2012, 2:45 PM
Reginald Beardsley wrote:
I'm a geoscientist and have spent most of my career
working for big oil as in majors and super majors.?
Those certainly qualify as large sites and are a lot
bigger than any academic institute I know of. So I'm acutely
aware of the issues and what things work and what things
don't.
A site administrator's job is to protect the user
community from disruptive changes.? However, that does
not entitle any site administrator to push bandaids onto the
larger user community.? It is the profligate use of
bandaids to which I'm objecting.
I think both of you are right (and wrong) in a way.
Intentionally introduced set of links that aid in
compatibility and that
are put in place by the designer of the system (and that
hopefully
disappear at some point in the future when no longer useful)
== good.
Ad-hoc forest of links created by some administrator who
isn't directly
involved with the fundamental system design and that likely
persist way
past their sell or use by date == bad.
So, I suggest that someone who is interested in this sort of
clean-up
effort should catalog the links that exist, exclude the ones
that are
intentional and good, and provide a summary of links that
are presumed
to be either obsolescent or just hazardous.
At least some of the things I see look good to me.?
Having the p* tools
symlinked in /usr/proc/bin matches where they were
originally, and any
script that invokes /usr/proc/bin/pkill (or similar) would
be harmed by
removing these, with little obvious benefit in the
clean-up.? And having
/usr/bin/g* symlinked to /usr/gnu/bin/* makes a lot of sense
for
commonly used things, as the g-prefix is a pretty
well-known
cross-platform allowance for GNU stuff, and having a
separate unprefixed
/usr/gnu/bin directory means that those who want to live in
an
unprefixed world can just prepend that to their PATHs.?
Best of both
with little pain.
I suspect that final set of bad actors is really quite
small, but
perhaps you or one of the other contributors has something
else in mind.
So *when* do they disappear? That's the question I'm raising. What are
criteria for acceptable links? Why are user site level customizations
cluttering a general distribution image?
I'm concerned about the proliferation. 15715 symlinks is a lot of links. I
don't see any sign of discipline. Do we really need a symlink in /usr/sbin
to everything in /sbin? Setting PATH properly is much cleaner.
We have similar silliness w/ /usr/X11 being a tree of links pointing to
/usr. Again, setting the default PATH properly in the system files is much
cleaner.
I raised this because
find -L /usr -type l -print
produces a list w/ 10 cycles and 132 dangling links. That is broken by
any standard. When I find loops and broken links in the directory tree I
start getting worried. I worked in two environments that were brought to
their knees by that. And in both cases it all started out as a good idea.
I'm all in favor of disciplined use of symlinks. I use a large table of
links to select the active version of software I compile from source.
find /app/{bin,lib,include,man,share} -type l -print | wc
reports 15464 links. But they're not links to links unless the package
itself contains links for things like library aliases and all the links
point into /app/pkgs. It's carefully designed so that I can safely install
things w/o undetected name space collisions among third party packages. It
also lets me toggle between versions quickly. But the primary motivation
was making sure that make install didn't cause any damage.
Reg
(I can't believe I am about to say this...) I would suggest... symlinks for
compatibility could be at the distro level.
When I say that this should be distro level, this should not absolve
Illumos from responsibility in moving things around. If Illumos pulls
things out of their core, they should document it, indicate where it is at,
so a distro can easily pick it up. If Illumos moves things around, then a
distro can easily add symlinks to make it happen.
Honestly, this should be an automatic process... it should not be manual.
Every binary, .so, etc. with compiler vendor/version should be referenced
in a federated on-line read-only database of some kind. A distro could
help to figure out what is needed, update their tree in the database,
Illumos should keep track of where their binaries are, in comparison to a
(nonchanging) base distribution like the final OpenSolaris release.
From there, people could build maps to all OpenSolaris
Re: [OpenIndiana-discuss] [developer] Preliminary Download link: Illumos based MartUX_OpenIndiana_Edition for SPARC LiveDVD (without installer)
Hi Rob, I did not see a posting from you on the list, could it be that you are not a subscriber? I will forward your question on to the list. Hello List, Can anyone provide a suggestion for how vnc server and gdm can be enabled on a SPARC headless server? David Halko http://svr4.blogspot.com/ http://netmgt.blogspot.com/ P.S. Rob is starting an X Gui wrapper for SVR4 package installers On Thu, Oct 4, 2012 at 8:39 PM, Rob Petty rob.a.pe...@gmail.com wrote: -- Forwarded message -- From: Rob Petty rob.a.pe...@gmail.com Date: Thu, Oct 4, 2012 at 2:22 AM Subject: Re: [developer] [OpenIndiana-discuss] Preliminary Download link: Illumos based MartUX_OpenIndiana_Edition for SPARC LiveDVD (without installer) To: Discussion list for OpenIndiana openindiana-discuss@openindiana.org Cc: develo...@lists.illumos.org Hello Martin and all, I'm working with David on his SPARC systems (do not have video cards), When trying to enable GDM, we're receiving an error: /lib/svc/method/svc-gdm: not found Any help with this is appreciated. - Rob (more extensive log follows) # svcs gdm STATE STIMEFMRI maintenance23:05:06 svc:/application/graphical-login/gdm:default # svcs -L gdm /var/svc/log/application-graphical-login-gdm:default.log # cat /var/svc/log/application-graphical-login-gdm:default.log [ start + 135.51s Disabled. ] [ Oct 3 23:03:53 Enabled. ] [ Oct 3 23:03:55 Executing start method (/lib/svc/method/svc-gdm start). ] /sbin/sh[1]: exec: /lib/svc/method/svc-gdm: not found [ Oct 3 23:03:55 Method start exited with status 127. ] [ Oct 3 23:03:56 Executing start method (/lib/svc/method/svc-gdm start). ] /sbin/sh[1]: exec: /lib/svc/method/svc-gdm: not found [ Oct 3 23:03:56 Method start exited with status 127. ] [ Oct 3 23:03:56 Executing start method (/lib/svc/method/svc-gdm start). ] /sbin/sh[1]: exec: /lib/svc/method/svc-gdm: not found [ Oct 3 23:03:56 Method start exited with status 127. ] [ Oct 3 23:04:30 Leaving maintenance because clear requested. ] [ Oct 3 23:04:30 Enabled. ] [ Oct 3 23:04:30 Executing start method (/lib/svc/method/svc-gdm start). ] /sbin/sh[1]: exec: /lib/svc/method/svc-gdm: not found [ Oct 3 23:04:30 Method start exited with status 127. ] [ Oct 3 23:04:43 Leaving maintenance because disable requested. ] [ Oct 3 23:04:43 Disabled. ] [ Oct 3 23:05:06 Enabled. ] [ Oct 3 23:05:06 Executing start method (/lib/svc/method/svc-gdm start). ] /sbin/sh[1]: exec: /lib/svc/method/svc-gdm: not found [ Oct 3 23:05:06 Method start exited with status 127. ] On Wed, Oct 3, 2012 at 4:57 AM, David Halko davidha...@gmail.com wrote: Good Day Martin! Some of us spent this evening working with your LiveDVD on a V120 with 4 Gig RAM. - it takes about 48 minutes to boot - we have no video display, so we use the serial console - we figured out how to bring up ethernet interface with DHCP and an external VNC console - we like the nice selection of apps that were included on the desktop - we accessed your OI-SPARC via VNC from a SunRay client hosted on a Solaris 10 V240 - very reliable - we will need to update scripts on the iso, to make it more useful as a live-dvd server environment This being said, this looks good enough to move forward with! Very professional! As far as an installer, Caiman is not required. With your direction, a basic installer could be made using existing infrastructure (I see dtksh is bundled, meaning X, CLI, and HTTP are all reasonable... I did not look for fmli yet... a solid bug-free scripting frameworks with small footprint is desirable.) Maybe even gdm/xdm on boot for console-less serial-less installs. We may be able to assist here, with your guidance. I am wondering whether zfsdiff with snapshots may be helpful for release management and automatic package creation. SVR4 class-action scripts could provide for compression support. Sparse SVR4 packages could be made for upgrades. Packages could automatically be made available over HTTP to pkgadd -x option for a wanboot mini-root. Later, pkgadd could install against a ZFS alternate boot environment. Perhaps zfssend from a build environment, named by release. There is no reason this could/should not be 100% automated. Once again, we could help here. Have you thought about a network boot from OpenBoot, maybe mounting some NFS network drives from a Solaris 10 platform (until OI-SPARC is stable enough to self-host)? We have some other V100's and V120's... This could make a very nice release management environment (zfs snapshot, boot first box, validate, package; zfs snapshot, boot second box, validate, package; keep a few boxes always live) We would be willing to work on that, if we could get a little guidance. I realize everything I said above is very brief, may not be 100% technically accurate, but I think you can see that I am excited
Re: [OpenIndiana-discuss] [developer] Preliminary Download link: Illumos based MartUX_OpenIndiana_Edition for SPARC LiveDVD (without installer)
Hi Kumar, On Wed, Oct 3, 2012 at 3:23 PM, Shivakumar Gopalakrishnan ku...@xstorsystems.com wrote: Hi Martin --- On Tue, 10/2/12, Martin Bochnig mar...@martux.org wrote: From: Martin Bochnig mar...@martux.org Subject: Re: [developer] [OpenIndiana-discuss] Preliminary Download link: Illumos based MartUX_OpenIndiana_Edition for SPARC LiveDVD (without installer) To: develo...@lists.illumos.org, Discussion list for OpenIndiana openindiana-discuss@openindiana.org Date: Tuesday, October 2, 2012, 8:19 AM On Mon, Oct 1, 2012 at 8:38 AM, DavidHalko davidha...@gmail.com wrote: [snip] Thanks, David Halko http://svr4.blogspot.com/ http://netmgt.blogspot.com/ Hi David! many thanks for your nice comments and +1 :) I'm glad to get such feedback. However, it is still only a LiveDVD and only pre-Alpha stuff. No installer yet (and Caiman gui-install and textinstall crash early during, it would be a very long story to tell) ... [snip] it is from a user's point of things. Then you do not want to imagine, how one feels as a distribution-constructor!! A year is nothing while fighting with IPS ... Maybe you have already evaluated this option, but we have come with a way to perform an automated install without requiring a network connection while still using IPS. Let me know if you need more details on what we did if you think it would be helpful for you. If it works under SPARC, I would be interested in some alternatives. Right now, Martin is the first SPARC distribution out of the gate - would love HTTP, TFTP, NFS, or WebNFS options. I now have 3 V120's in the test lab: - 4 Gig RAM (DVD) - 2 Gig RAM (CD-ROM) - 1 Gig RAM (CD-ROM) Depending on how this goes, will start adding V100's. Suggestions appreciated! Thanks, David Halko http://svr4.blogspot.com/ http://netmgt.blogspot.com/ Kumar --- illumos-developer Archives: https://www.listbox.com/member/archive/182179/=now RSS Feed: https://www.listbox.com/member/archive/rss/182179/21175352-313cabda Modify Your Subscription: https://www.listbox.com/member/?member_id=21175352id_secret=21175352-bac0445a Powered by Listbox: http://www.listbox.com ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] [developer] Preliminary Download link: Illumos based MartUX_OpenIndiana_Edition for SPARC LiveDVD (without installer)
Good Day Martin! Some of us spent this evening working with your LiveDVD on a V120 with 4 Gig RAM. - it takes about 48 minutes to boot - we have no video display, so we use the serial console - we figured out how to bring up ethernet interface with DHCP and an external VNC console - we like the nice selection of apps that were included on the desktop - we accessed your OI-SPARC via VNC from a SunRay client hosted on a Solaris 10 V240 - very reliable - we will need to update scripts on the iso, to make it more useful as a live-dvd server environment This being said, this looks good enough to move forward with! Very professional! As far as an installer, Caiman is not required. With your direction, a basic installer could be made using existing infrastructure (I see dtksh is bundled, meaning X, CLI, and HTTP are all reasonable... I did not look for fmli yet... a solid bug-free scripting frameworks with small footprint is desirable.) Maybe even gdm/xdm on boot for console-less serial-less installs. We may be able to assist here, with your guidance. I am wondering whether zfsdiff with snapshots may be helpful for release management and automatic package creation. SVR4 class-action scripts could provide for compression support. Sparse SVR4 packages could be made for upgrades. Packages could automatically be made available over HTTP to pkgadd -x option for a wanboot mini-root. Later, pkgadd could install against a ZFS alternate boot environment. Perhaps zfssend from a build environment, named by release. There is no reason this could/should not be 100% automated. Once again, we could help here. Have you thought about a network boot from OpenBoot, maybe mounting some NFS network drives from a Solaris 10 platform (until OI-SPARC is stable enough to self-host)? We have some other V100's and V120's... This could make a very nice release management environment (zfs snapshot, boot first box, validate, package; zfs snapshot, boot second box, validate, package; keep a few boxes always live) We would be willing to work on that, if we could get a little guidance. I realize everything I said above is very brief, may not be 100% technically accurate, but I think you can see that I am excited, and there are others ready to dig-in and bring this forward. For storage, test systems, scripting, and automation - we can find some resources. We don't do C, nor do we do pretty, but we do functional. Thanks - David Halko http://svr4.blogspot.com/ http://netmgt.blogspot.com/ On Tue, Oct 2, 2012 at 11:19 AM, Martin Bochnig mar...@martux.org wrote: On Mon, Oct 1, 2012 at 8:38 AM, DavidHalko davidha...@gmail.com wrote: U da man! I will be looking into testing it tomorrow on some machines. Thank you for your efforts! Honestly, I see no value of IPS under OI SPARC since I do not expect any software will ever be commercial software made available for IPS under SPARC OI since it is so buggy a moving target. There is plenty of SVR4 Solaris 10 SPARC commercial software currently available. SVR4 packaging is also extensible without code changes. We also don't need to do pre/post install/remove scripts, if we choose not to in SVR4 packaging. Thanks, David Halko http://svr4.blogspot.com/ http://netmgt.blogspot.com/ Hi David! many thanks for your nice comments and +1 :) I'm glad to get such feedback. However, it is still only a LiveDVD and only pre-Alpha stuff. No installer yet (and Caiman gui-install and textinstall crash early during, it would be a very long story to tell) ... As for IPS I could not agree more with you. The question is and remains, if we necessarily ___need__ IPS for anything. From a user-only's point of view it is already bad enough. From a distribution-builder's view I would not even wish my worst enemy to experience it (ghhrr!!!). Here only one current example: A user's T2000 runs pkg for 8 hours, then crashes. To do a thing that would not even be necessary in the first place in such a scenario, with SVR4-pkgadd! And this is how ugly it is from a user's point of things. Then you do not want to imagine, how one feels as a distribution-constructor!! A year is nothing while fighting with IPS ... See the thread pkg-discuss] gcc install? under: http://mail.opensolaris.org/pipermail/pkg-discuss/2012-October/thread.html p.s. I added your SVR4 link to my footer ... tnx rgds, %martin http://wiki.openindiana.org/oi/MartUX_OpenIndiana+oi_151a+SPARC+LiveDVD http://www.youtube.com/user/MartUXopensolaris http://www.facebook.com/pages/MartUX_SPARC-OpenIndiana/357912020962940 https://twitter.com/MartinBochnig http://www.martux.org (new page not yet online, but pretty soon) Forwarding David Halko's: http://svr4.blogspot.com/ ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] from the lost to the river
Hi, Hi, I still don't know what IPS really is Image Packaging System It's a software packaging scheme that was designed during the OpenSolaris days as a replacement for the old SysV packaging system. The big change is that it's based on a client/server model, where (at least in the first implementation) the server was a required part of the software upgrade mechanism. The old SysV packaging system had a disk format that delivered files, including scripts that ran at installation. SVR4 had a stream option, to bundle packages. Packages were often delivered on floppies, tapes, disks, and eventually by HTTP. IPS does not, and instead has a set of pre-determined actions that can be taken during upgrade or install of a file. The lack of scripting is an important improvement -- the old scripting mechanisms allowed software developers to deliver arbitrary horrors inside scripts, but the new system doesn't allow that. OpenSolaris (and OpenIndiana) still supports SysV packaging, but the main software, at least in the main line of code, is delivered via IPS. One big difference between IPS and the old SysV system: A SysV package is one huge file whereas packages delivered via IPS are split into lots of single files; simplified said: one file on your disk from a certain package ^= one file in IPS, cryptographically signed in the IPS manifest and stored in compressed form on the IPS server. SVR4 packages could be delivered in streams encapsulating 1 or more packages or as a bursted filesystem spooled packages. Encryption and compression was an option in SVR4 using class action scripts by multiple vendors. If you download a newer version of a SysV package, MySQL for example, you normally have to suck the whole package, even when only a small part inside the package was changed. IPS on the other hand will download only the delta, i.e. those files that were changed. SVR4 packages supports sparse packages so full packages are not required to be downloaded. The quality of the package provider will determine whether you get full or sparse packages. Additionally the IPS server doesn't really care about the architecture of your system; it can store files for different CPU architectures and operating systems in one single repository. GlassFish for example is using this technique (*). (*) https://blogs.oracle.com/alexismp/entry/java_ee_6_tutorial_and I used to build singular SVR4 hybrid packages which supported Solaris SPARC as well as NCR UNIX MP-RAS under Intel. It was not difficult to build SVR4 packages to work identically under different OS's and CPU architecture - it just meant more binaries were required in the package. I think the big difference is pre-requisite bundling. Some SVR4 package providers offer this capability, as well, as an add-on feature via a front-end script... but this is strictly not SVR4 packaging today. SVR4 packages include the ability to perform integrity checks of the installed package against an accepted manifest. This offers security checking options to ensure that scripts binaries have proper permissions and have not been tampered with (i.e. viruses, worms, malware protection) while supporting volatile files (so security checks are not tripped up by config file changes, log file rotations, etc.) I am uncertain whether the newer IPS offers this level of post-install and lifecycle integrity checking, since I never needed to audit a Solaris 11 / Illumos production platform. Hope that helps, David Halko http://svr4.blogspot.com/ Just my 0.02$ ;-) HTH Thorsten ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] [developer] Re: SPARC-OpenIndiana Screenshots
*This is really phenominal work, Martin!* There are some applications, being served for free, from UNIXPackages.COM (i.e. firefox, thunderbird, sunbird) - perhaps you could de-bundle them from the distro, and make an icon on the default desktop to download/install the packages (to safe space)? Thanks - Dave H P.S. Can it be WAN Booted over the internet from OpenBoot? ;-) Perhaps, we need to get some regional vollunteers to host a WAN Boot archive? (How about me?) On Mon, Sep 10, 2012 at 9:14 AM, Sašo Kiselkov skiselkov...@gmail.comwrote: On 09/10/2012 03:10 PM, Martin Bochnig wrote: However, in case of the current stuff a 4.4GB DVD is 99% full. So even 1MB too much is ... still too much. Of course we could simply delete something that nobody wants to use on such a LiveDVD. Let's see what i/o compression of stuff inside the ramdisk brings. And also I think that I put too much into the boot_archive. I recommend losing some large unused app blobs that nobody needs on a Live CD. I don't know what you've got in there, but I recommend you throw out stuff like image editing software and the like. A Live CD is primarily for installation and rescue, not for regular work. First I give you this current instable stuff, let's say tomorry, really. Then we can go ahead. MUST first verify, if JDS really works again now. My wish is, that you cleanly boot directly into JDS, rather than just an xterm (from where you could start gnome-session yourself). Will log off and be online again by tomrrow. Sure, I think the OI people should weigh in on the hosting issue here, I'm sure they can give you some space where you can upload your work for others to access and test. Hardware resources are cheap compared to the hard time-consuming work by volunteers like you. Cheers, -- Saso --- illumos-developer Archives: https://www.listbox.com/member/archive/182179/=now RSS Feed: https://www.listbox.com/member/archive/rss/182179/21175352-313cabda Modify Your Subscription: https://www.listbox.com/member/?member_id=21175352id_secret=21175352-bac0445a Powered by Listbox: http://www.listbox.com ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] google drive on openindiana?
Sorry for the late repsonse, Jerry. Message: 4 Date: Wed, 15 Aug 2012 21:42:13 -0500 From: Jerry Kemp sun.mail.lis...@oryx.cc To: Discussion list for OpenIndiana openindiana-discuss@openindiana.org Subject: Re: [OpenIndiana-discuss] google drive on openindiana? Message-ID: 502c5e05.6060...@oryx.cc Content-Type: text/plain; charset=ISO-8859-1 I think that it would be difficult for me to pose a legitimate argument to your statement, but, for those of you running OpenIndiana on your desktop, or Solaris, or one of the many open Solaris based distro's, how many of you are running a current, or close to current copy of Firefox and/or Thunderbird? Whenever I do a Solaris install, the FIRST thing I do is go to sunfreeware.com or unixpackages.com, download the latest version of Firefox and install it. I just did this under Solaris 10 Update 10 on SPARC under a week ago. After that, I wait until a user in the community complains, then I upgrade all 300 virtual desktop instances with the latest version of Firefox that I can. (I still have 2 VDI hosts running Solaris 9, unfortunately. They get what they get.) None of those are compiled by Mozilla personnel, although they are distributed on the Mozilla site. All of the current *Solaris stuff is in the contrib section, and has been for some time. Jerry We need to keep our development resources out of this area of compiling individual packages and keep professional packagers doing this for us. It should be their day job. Their time is worth every penny. This is the instanity of a packaging system for every distro. SVR4 can download packages from a network stream directly, SVR4 can natively handle custom methods (like compression) without source-code change, it has stood the test of time, and packages have been available for our consumption for decades. If we need an update, then we should pay for an update, if we don't want to spend our own time, or we should compile it and contribute it, and maybe ask for a credit! ;-) Thanks - Dave http://svr4.blogspot.com/ ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] OpenIndiana lead Alasdair Lumsden resigns - next steps
See comments below, in-line. Date: Sun, 2 Sep 2012 11:29:48 +0200 From: Open Indiana openindi...@out-side.nl To: 'Discussion list for OpenIndiana' openindiana-discuss@openindiana.org Subject: Re: [OpenIndiana-discuss] OpenIndiana lead Alasdair Lumsden resigns Message-ID: 001a01cd88ed$7f8ebce0$7eac36a0$@nl Content-Type: text/plain; charset=us-ascii I guess i sparked this discussion about the GUI. Not that I want a GUI, but if you read the comments on Alasdair Lumsden resign then most people that call OI a stupid OS are the people that only use a GUI to do things. ;-) But based on the number of reactions on this subject I fear that there a just a very few OI users. Or the rest must have been sleeping the last days. So I would suggest that we start some kind of voting/.. somewhere on the internet. Maybe in this mailgroup or on the OI website. I suggest the following questions: 1. Who wants to help develop OI? I would be interested. 2. What skills do you (the voter) have that can help OI? Documentation, Web Upkeep, How-To's, Scripting, Packaging 3. What kind of software do you want to have running on OI? Nothing, Can't get OI to run on any hardware available to me. 4. What kind of hardware/drivers do you want to have running on OI? V100, V120, V240, UltraSPARC 60, an Intel laptop. 5. Have you ever created a HOWTO for OI? If YES where is it? As soon as I can find a load which works, I can start. 6. Have you ever found a useful HOWTO for OI? If YES where is it? No. 7. Have you ever created a useful software package for OI? If YES where is it? No. Only created large software systems under Solaris 10 for internal facing user communities 8. Do you use OI in a commercial environment? I would if OI would run under UltraSPARC systems. There is a market for OI, if it keeps Solaris 10 software compatibility. Especially if OI will run under an LDOM, since Oracle will not be moving Solaris 10 forward and various ISV's are showing disinterest in supporting Solaris 11 due to the high-barrier to entry (all new hardware of every kind in the Oracle product suite.) OI just has to look like Solaris 10 and get new features to remain relevant. 9. There must be more useful questions that I forget. But if we start to gather the above information we already have more (centralized) than we have right now. How about: 9. Does OI need to concentrate on being a hypervisor? Run which operating systems? Yes, run Solaris 9, Solaris 10, Windows, Various Linux, maybe other SVR4 operating systems on other architectures. 10. What features would make OI compelling? - Shared-nothing clustered ZFS fileyststem with Lustre or some other clustering technology. - Solaris 10 Compatibility, to woo ISV's who refuse to develop for Solaris 11. - Development track which is disjoint from Solaris, concentrate on moving SVR4 packaging forward, so previous development resources are not wasted on fixing IPS bugs/incompatibilities, making possible future source code releases (how ever unlikely that is) able to easily integrate, and making it easier to integrate OI developments upstream. - Leverage a simple, already existing, well defined management environment like FMLI, so one group can create CUI management interfaces, and another group of individuals can create port FMLI (XFMLI [again], WebFMLI, AJAX like interfaces, etc.) so all short term work can be later leveraged. Conclusions: An OS is useless unless there is a market for it and it fulfills a market need. Someone needs to decide what the market is, who the customers are (i.e. user community), what other market elements it facilitates (i.e. software vendors), who will pay for it (i.e. funding source), and what the roadmap is to make it more relevant in the future to ever expanding groups of consumers (i.e. any market that is not expanding is contracting - new markets must always be courted and not denied.) Thanks, David http://svr4.blogspot.com/ ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
