Re: [oi-dev] OI project reboot required
On Sun, 12 May 2013, Garrett D'Amore wrote: We're going to have to support a 32-bit userland for some time to come, unfortunately, but we should no longer make that the default, and we should deliver all of our system utilities in 64-bit only form, IMO; and we could entirely kill off the 32-bit kernel. If 32-bit userland is no longer the default, then GCC should start producing 64-bit code by default. Currently GCC does not seem to support being compiled to produce 64-bit code by default (at least last I tried doing that). GNU libtool needs a small patch to compile 64-bit C++ code with working exceptions support. Probably quite a lot of Solaris-targeted user-space code has issues when compiled for 64-bit because it was not compiled that way before. The GCC that comes with 64-bit Linux systems produces 64-bit code by default, but is capable of compiling 32-bit code. The OpenIndiana/Illumos folks would need to work with the GCC folks to make sure that a GCC can be built which produces 64-bit by default. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI project reboot required
On 12/05/2013 00:17, Garrett D'Amore wrote: But nobody else has built a compelling Linux or Unix desktop with a reason to exist besides being free. And there is no commercial value in just being free ... But there are other values than commercial values; i.e., being free OI is not a commercial distribution and was started with that reason, being a noncommercial distribution. The desktop/workstation is NOT dead (I can't imagine doing science on a tablet, really!), that's just commercial wishful thinking. This all sounds like you have attended a Bilderberg conference on killing Open Source desktop software... smime.p7s Description: S/MIME Cryptographic Signature ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI project reboot required
garrett.dam...@dey-sys.com said: So, out of curiosity -- *who* is actively running illumos on 32-bit kit today? I'm not interested in hypothetical uses or kit that is sitting around in your garage waiting for you to do something with it . I'm interested in people who would be immediately impacted and severely so if illumos were not available on 32-bit CPUs right now. (To give a counter example: I have a 32-bit Atom netbook, that I have OpenIndiana on. I turn it on once every year or so if that often so I can't seriously claim that I would be negatively impacted if illumos were to move to 64-bit only.) And, garrett.dam...@dey-sys.com said: Older hardware must be *really* old. Over 5 years. For servers, probably over 10 years. I've thrown away my Pentiums and Pentium IIs. I suppose there could be some Pentium IIIs and IVs out there, or AMD Athlons (pre-Athlon64), but they'd all be really really slow by today's standards. Do people run illumos on such kit? I'm highly doubtful, unless that kit is around just to answer the question of whether 32-bit kernels still work. :-) I do. Been running OI on my Pentium IV 2.8GHz machine since oi148, which is when I converted it from Solaris-10. It has 2GB RAM and a couple 1TB drives in a mirror acting as ZFS backup server for other family members' Mac's, and also gets used daily as my personal home desktop machine (Firefox, Thunderbird, OpenOffice, xsane, gimp, exmh/MH, rcs/svn, wireshark, etc). And, it runs a Solaris-10 zone brought forward to run two binaries I haven't yet found the time to port/compile on OI, gnucash and gnome-perfmeter. But hey, don't let me hold up progress. I'm used to feeling like the last person in the world still using a Solaris-based desktop. If I had the money, I'd replace it. I ran Solaris-x86 on my previous home machine for about 10 years before replacing it with the present one, so I guess I'm nearly due. Spent my entire career working in the non-profit sector, and my Dad had a rock crusher in his business that was about 90 years old when he retired it, so I'm pretty much doomed to be a Junk-Whisperer (:-) Regards, Marion ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI project reboot required
I actually get a permissions error. $ sudo pkg set-publisher -O http://pkg.openindiana.org/hipster/ openindiana.org pkg set-publisher: Could not refresh the catalog for openindiana.org http protocol error: code: 403 reason: Forbidden URL: 'http://pkg.openindiana.org/hipster/openindiana.org/catalog/1/catalog.attrs'. I noticed Oracle upstream moves aggressively to amd64 only; installing amd64 just in bin not in bin/$(MACH64). -- David On 12 May 2013 10:30, Andrzej Szeszo asze...@gmail.com wrote: Hi All Apologies for a delay. Some things are set up now. New IPS repository is up: http://pkg.openindiana.org/hipster/. It is a clone of the /dev repo + oi_151a8 bits from Jon Tibble and JDS bits from Milan Jurik merged in. Run commands below to update your system. You can ask Jon Tibble where the name of the repo came from :) pkg set-publisher -O http://pkg.openindiana.org/hipster/ openindiana.org pk install -v pkg://package/pkg pkg update -v Latest Oracle userland hg repo was converted to git and uploaded to https://github.com/OpenIndiana/oi-userland/. Most of the components were masked and don't build by default. I have only unmasked few meta packages to test if things build/publish correctly. Quick Jenkins instance that automatically builds packages and publishes them directly to http://pkg.openindiana.org/hipster/. To start hacking, fork a repo on github, make your changes (unmask packages, add new ones) and submit pull request. If you are an existing contributor, give me a shout and I will give you direct access to the repo. Please let me know if you have any questions. Let's see if the process works out. Kind regards, Andrzej On 11 May 2013 18:28, Andrzej Szeszo asze...@gmail.com wrote: Hi Alasdair I would like to try setting up a repo on github, give trusted people direct access and support pull requests from independent developers. And then have jenkins publish packages incrementally to publicly accessible repository. In theory, it should only take few minutes from a push to a published package in a repo. It is a variation on the process which was tried earlier. I think it might work this time. I did some prep work last night. Will try to have something usable by others later tonight. Cheers, Andrzej On 10 May 2013 14:04, Alasdair Lumsden alasdai...@gmail.com wrote: Andrzej, Your vision is pretty much the same one I had. The challenge is this: Existing releng process and contribution process prevent anything from happening though. I would like to help to change that. How? On Fri, May 10, 2013 at 12:54 PM, Jim Klimov jimkli...@cos.ru wrote: On 2013-05-10 02:19, Garrett D'Amore wrote: There is little commercial future in the desktop for Linux distributions as well yet almost all of them have a graphical desktop. I would be entirely *unsurprised* if distro vendors like RedHat and Oracle simply *ditched* their desktop support at some point in the future -- its clear to me at least that folks aren't running those distros on the desktop. Well, Oracle does provide and promote SunRays, and while admittedly most of their market targeting is about VDI and access to virtual Windows desktops, there are many requests on the SRSS mailing list about adding support for server-side Ubuntu as the SRSS terminal server, because certain apps only exist for Linux and tunneling of connections makes their graphics lag, and RHEL/OEL/Solaris desktops are argued to be not so user-friendly (I have no opinion on this, to me X11 is a means to display more characters on screen than possible in a text mode). Not that Oracle seems to care to address that demand, at least publicly - just recently they began supporting versions 6 of RHEL and OEL as server-side Linuxes. But there is certain demand for non-MS/Apple desktops, and one linked to commercial interest as well. I am not sure if OI/illumos can ride that tide, though. Maybe with some other terminal client technologies (ThinLinc, Wyse, etc)?.. //Jim ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev -- Alasdair Lumsden http://www.everycity.co.uk EveryCity Managed Hosting Studio 18 Bluelion Place 237 Long Lane, London, SE1 4PU general: 020 7183 2800 support: 020 7183 2801 email: a...@everycity.co.uk Every City Limited Registered in England and Wales, No. 5689474 Registered Office: Roper Yard, Roper Road, Canterbury, CT2 7EX ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI project reboot required
pkg.depotd is misbehaving when you publish packages directly to it. I am looking at it now. Andrzej On 12 May 2013 14:19, David Höppner 0xf...@gmail.com wrote: I actually get a permissions error. $ sudo pkg set-publisher -O http://pkg.openindiana.org/hipster/ openindiana.org pkg set-publisher: Could not refresh the catalog for openindiana.org http protocol error: code: 403 reason: Forbidden URL: ' http://pkg.openindiana.org/hipster/openindiana.org/catalog/1/catalog.attrs '. I noticed Oracle upstream moves aggressively to amd64 only; installing amd64 just in bin not in bin/$(MACH64). -- David On 12 May 2013 10:30, Andrzej Szeszo asze...@gmail.com wrote: Hi All Apologies for a delay. Some things are set up now. New IPS repository is up: http://pkg.openindiana.org/hipster/. It is a clone of the /dev repo + oi_151a8 bits from Jon Tibble and JDS bits from Milan Jurik merged in. Run commands below to update your system. You can ask Jon Tibble where the name of the repo came from :) pkg set-publisher -O http://pkg.openindiana.org/hipster/ openindiana.org pk install -v pkg://package/pkg pkg update -v Latest Oracle userland hg repo was converted to git and uploaded to https://github.com/OpenIndiana/oi-userland/. Most of the components were masked and don't build by default. I have only unmasked few meta packages to test if things build/publish correctly. Quick Jenkins instance that automatically builds packages and publishes them directly to http://pkg.openindiana.org/hipster/. To start hacking, fork a repo on github, make your changes (unmask packages, add new ones) and submit pull request. If you are an existing contributor, give me a shout and I will give you direct access to the repo. Please let me know if you have any questions. Let's see if the process works out. Kind regards, Andrzej On 11 May 2013 18:28, Andrzej Szeszo asze...@gmail.com wrote: Hi Alasdair I would like to try setting up a repo on github, give trusted people direct access and support pull requests from independent developers. And then have jenkins publish packages incrementally to publicly accessible repository. In theory, it should only take few minutes from a push to a published package in a repo. It is a variation on the process which was tried earlier. I think it might work this time. I did some prep work last night. Will try to have something usable by others later tonight. Cheers, Andrzej On 10 May 2013 14:04, Alasdair Lumsden alasdai...@gmail.com wrote: Andrzej, Your vision is pretty much the same one I had. The challenge is this: Existing releng process and contribution process prevent anything from happening though. I would like to help to change that. How? On Fri, May 10, 2013 at 12:54 PM, Jim Klimov jimkli...@cos.ru wrote: On 2013-05-10 02:19, Garrett D'Amore wrote: There is little commercial future in the desktop for Linux distributions as well yet almost all of them have a graphical desktop. I would be entirely *unsurprised* if distro vendors like RedHat and Oracle simply *ditched* their desktop support at some point in the future -- its clear to me at least that folks aren't running those distros on the desktop. Well, Oracle does provide and promote SunRays, and while admittedly most of their market targeting is about VDI and access to virtual Windows desktops, there are many requests on the SRSS mailing list about adding support for server-side Ubuntu as the SRSS terminal server, because certain apps only exist for Linux and tunneling of connections makes their graphics lag, and RHEL/OEL/Solaris desktops are argued to be not so user-friendly (I have no opinion on this, to me X11 is a means to display more characters on screen than possible in a text mode). Not that Oracle seems to care to address that demand, at least publicly - just recently they began supporting versions 6 of RHEL and OEL as server-side Linuxes. But there is certain demand for non-MS/Apple desktops, and one linked to commercial interest as well. I am not sure if OI/illumos can ride that tide, though. Maybe with some other terminal client technologies (ThinLinc, Wyse, etc)?.. //Jim ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev -- Alasdair Lumsden http://www.everycity.co.uk EveryCity Managed Hosting Studio 18 Bluelion Place 237 Long Lane, London, SE1 4PU general: 020 7183 2800 support: 020 7183 2801 email: a...@everycity.co.uk Every City Limited Registered in England and Wales, No. 5689474 Registered Office: Roper Yard, Roper Road, Canterbury, CT2 7EX ___ oi-dev mailing list oi-dev@openindiana.org
Re: [oi-dev] OI project reboot required
Hello, Just so we can tack up a goal for the visionaries who like roadmaps and such... Proposed list of 'core' updates for oi_151a(8-9): * Bump illumos to 19e11862653b Implement accept4() stack overflow due to zfs lz4 compression Fast reboot support in ixgbe Chelsio 10GbE driver support Support LSI SAS2008 (Falcon) Skinny FW for mr_sas(7D) Allow ixgbe to use unsupported SFP modules detect socket type of newer AMD CPUs * New JDS package updates (2013-04-09) from: http://pkg.opensolaris.cz/osol/en/index.shtml * Wifi Stack improvement patches (enrico) Hope that helped, Ken Mays From: Andrzej Szeszo asze...@gmail.com To: OpenIndiana Developer mailing list oi-dev@openindiana.org Sent: Sunday, May 12, 2013 7:11 AM Subject: Re: [oi-dev] OI project reboot required Hi Piotr I made some choices without consulting anyone but it allowed me to get something set up in a short period of time. oi_151a8 is based on sfw-gate, that's correct. Milan built JDS against oi_151a8. Because oi_151a8 and JDS bits were already available I thought it would be a shame to not to include them in the repo I was preparing. /experimental, oi-build, illumos-userland didn't really took off. I know they exist but it would take time to figure out in what shape the binary package repos are. I thought it would be a better idea to start fresh in terms of binary packages. Build recipes however we should reuse. The github repo currently does not produce anything else other than few meta-packages. Build recipes from oi-build or illumos-userland can be added to the tree and should just work. There is an option of enabling disabled Oracle provided packages as well. This time I wanted to keep things really simple. There is single publisher now - 'openindiana.org' - but pointing at different repo. And single source repo - https://github.com/OpenIndiana/oi-userland. Any fixes or additions should be made in the github repo. In terms of fixes to the packages that came from SFW , I recommend using equivalent package from one of the userland-style repos. The idea is to not to have to compile SFW or run distro-importer ever again :) Correct me if I am wrong, but illumos-userland is dead. I don't see a point using it directly. Build recipes should be borrowed from it though :) I have heard about libffi. Not sure what the problem is. It doesn't look like it would be difficult to provide userland build recipe for it in case we need an updated version. Andrzej On 12 May 2013 12:09, Piotr Jasiukajtis est...@me.com wrote: Andrzej, oi_151a8 is still based on sfw-gate, wouldn't be better to resurrect /experimental which was based on illumos-userland? To me it was hard to manage different IPS versions along with the build environments/zones because some were based on /experimental while my main host was /dev. Another source of confusion are 3 different source repositories: sfw, oi-build and illumos-userland. Which one to use if I need a new package on my production systems? and no, I don't want to touch SFW anymore :) Maybe create another version based on illumos-userland in the /dev let say oi_152a1 or something? Btw, someone mentioned about some libffi issues on oi_151a8. I barely checked that and it seems pkg and python do work but I don't know what the issue was. Is that fixed? Thanks for doing that :) -- Piotr Jasiukajtis On May 12, 2013, at 10:30 AM, Andrzej Szeszo asze...@gmail.com wrote: Hi All Apologies for a delay. Some things are set up now. New IPS repository is up: http://pkg.openindiana.org/hipster/. It is a clone of the /dev repo + oi_151a8 bits from Jon Tibble and JDS bits from Milan Jurik merged in. Run commands below to update your system. You can ask Jon Tibble where the name of the repo came from :) pkg set-publisher -O http://pkg.openindiana.org/hipster/ openindiana.org pk install -v pkg://package/pkg pkg update -v Latest Oracle userland hg repo was converted to git and uploaded to https://github.com/OpenIndiana/oi-userland/. Most of the components were masked and don't build by default. I have only unmasked few meta packages to test if things build/publish correctly. Quick Jenkins instance that automatically builds packages and publishes them directly to http://pkg.openindiana.org/hipster/. To start hacking, fork a repo on github, make your changes (unmask packages, add new ones) and submit pull request. If you are an existing contributor, give me a shout and I will give you direct access to the repo. Please let me know if you have any questions. Let's see if the process works out. Kind regards, Andrzej On 11 May 2013 18:28, Andrzej Szeszo asze...@gmail.com wrote: Hi Alasdair I would like to try setting up a repo on github, give trusted people direct access and support pull requests from independent developers. And then have
Re: [oi-dev] OI project reboot required
On 05/12/13 05:19 AM, David Höppner wrote: I noticed Oracle upstream moves aggressively to amd64 only; installing amd64 just in bin not in bin/$(MACH64). It has been a few years since Oracle upstream dropped 32-bit i386 support, so that's just one of the decisions OI has to make - track upstream as is or fork/patch as needed to continue to support 32-bit on i386. -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - http://blogs.oracle.com/alanc ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI project reboot required
On 2013-05-12 16:54, ken mays wrote: Hello, Just so we can tack up a goal for the visionaries who like roadmaps and such... Proposed list of 'core' updates for oi_151a(8-9): * Bump illumos to 19e11862653b Implement accept4() stack overflow due to zfs lz4 compression Fast reboot support in ixgbe Chelsio 10GbE driver support Support LSI SAS2008 (Falcon) Skinny FW for mr_sas(7D) Allow ixgbe to use unsupported SFP modules detect socket type of newer AMD CPUs * New JDS package updates (2013-04-09) from: http://pkg.opensolaris.cz/osol/en/index.shtml * Wifi Stack improvement patches (enrico) I have some more suggested milestones, though not necessarily holding back some imminent release (just something that would be good to do soon, and likely requiring not much work to complete). Maybe, this might make it into oi_151a9 (if a8 would be packing up what we already have in JDS and illumos-gate today)? If possible to RTI by then, or just post to some testing repo, there has been some good work done about other networking drivers, at least those that concern me - in particular, ndis 64-bit for Broadcom WiFi by Jean-Pierre Andre, and I'm in touch with Masa Murayama (The Free NIC Drivers project) regarding my rge/gani NIC. It turned out to be a newer RTL8168 chip than was supported by gani-2.6.9, so he sent me an updated version for testing, which just works on my laptop. Now I have both wired and wireless connectivity in OI, working and stable. This was a good month! I've also set up failover with IPMP :) Earlier I've had other computers where Masa's drivers were also invaluable. Masa didn't reply yet whether he'd personally cooperate on RTI'ing his works, but he didn't say no either, and they are BSD-licensed, so... I don't know if there's any other upstream than occasionally updated source+binary code tarballs (note that bins are GLDv2 default, and should be easily recompiled for GLDv3) here on his site: http://homepage2.nifty.com/mrym3/taiyodo/eng/ I hope that the extended sets of networking drivers can sooner or later get into illumos-gate and/or directly into OI (including the installer's Live environment) as the versatile distro that is set up on very varied hardware (i.e. laptops made of whatever is available du-jour and cheap to their designers). HTH, //Jim Klimov ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI project reboot required
On 2013-05-12 17:51, Alan Coopersmith wrote: On 05/12/13 05:19 AM, David Höppner wrote: I noticed Oracle upstream moves aggressively to amd64 only; installing amd64 just in bin not in bin/$(MACH64). It has been a few years since Oracle upstream dropped 32-bit i386 support, so that's just one of the decisions OI has to make - track upstream as is or fork/patch as needed to continue to support 32-bit on i386. I believe, 32-bit should be retained. While it is of little utility for ZFS and other huge-RAM jobs, it may be required for some netbooks, older hardware repurposed for tests and SOHO servers, as well as for resource-constrained testing VMs. So I'd vouch for this fork/patch approach if this upstream is still followed. //Jim ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI project reboot required
On May 12, 2013, at 12:02 PM, Jim Klimov wrote: I believe, 32-bit should be retained. While it is of little utility for ZFS and other huge-RAM jobs, it may be required for some netbooks, older hardware repurposed for tests and SOHO servers, as well as for resource-constrained testing VMs. So I'd vouch for this fork/patch approach if this upstream is still followed. Not to mention intriguing projects like http://wiki.illumos.org/display/illumos/Raspberry+Pi+Bring-Up ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI project reboot required
On May 12, 2013, at 9:05 AM, Magnus mag...@yonderway.com wrote: On May 12, 2013, at 12:02 PM, Jim Klimov wrote: I believe, 32-bit should be retained. While it is of little utility for ZFS and other huge-RAM jobs, it may be required for some netbooks, older hardware repurposed for tests and SOHO servers, as well as for resource-constrained testing VMs. So I'd vouch for this fork/patch approach if this upstream is still followed. Not to mention intriguing projects like http://wiki.illumos.org/display/illumos/Raspberry+Pi+Bring-Up ARM11 is only 32-bit, and has nothing to do with the discussion of whether we would retain *x86* 32-bit mode support. - Garrett ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI project reboot required
On 2013-05-12 19:06, Garrett D'Amore wrote: So, out of curiosity -- *who* is actively running illumos on 32-bit kit today? I'm not interested in hypothetical uses or kit that is sitting around in your garage waiting for you to do something with it…. I'm interested in people who would be immediately impacted and severely so if illumos were not available on 32-bit CPUs right now. (To give a counter example: I have a 32-bit Atom netbook, that I have OpenIndiana on. I turn it on once every year or so… if that often … so I can't seriously claim that I would be negatively impacted if illumos were to move to 64-bit only.) Indeed, I can't vouch for such systems, even my old home-NAS which was my first victim of illumos/OI endearment had a Pentium-D with x86_64 support (though likely not virtualization acceleration features - which would IIRC require VMs to be 32-bit). This box would be in my production today, had it not broken while I am on a prolonged trip away from that home; but it won't be impacted by a 64-bit only OS, indeed (it did have some VMs for a test farm though, and they might be impacted). Also I know of many small (SOHO) storage boxes which can be made to work with OpenSolaris and illumos-based OSes, and of those only the HP N36 and N40L have (known to me) 64-bit AMD CPUs and ECC support; most other such boxes are built around Atom, and often 32-bit with some 2GB RAM. While this is not interesting for intensive production use, some users of these boxes as reliable (ZFS) home storage might be hurt by move to 64-bit only OS. Arguably though, lack of ECC did probably burn my home-NAS causing some corruptions poorly-explicable otherwise. While I wouldn't recommend non-ECC ZFS NASes for any use, at least as a newly built rig, people that have a black box which just works, and aren't keen on spending time and money to buy and setup regular upgrades, are kind of stuck with it until the HW dies. My 2c of theoreticizing :) //Jim Klimov ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI project reboot required
On May 12, 2013, at 11:31 AM, Jim Klimov jimkli...@cos.ru wrote: On 2013-05-12 19:06, Garrett D'Amore wrote: So, out of curiosity -- *who* is actively running illumos on 32-bit kit today? I'm not interested in hypothetical uses or kit that is sitting around in your garage waiting for you to do something with it…. I'm interested in people who would be immediately impacted and severely so if illumos were not available on 32-bit CPUs right now. (To give a counter example: I have a 32-bit Atom netbook, that I have OpenIndiana on. I turn it on once every year or so… if that often … so I can't seriously claim that I would be negatively impacted if illumos were to move to 64-bit only.) Indeed, I can't vouch for such systems, even my old home-NAS which was my first victim of illumos/OI endearment had a Pentium-D with x86_64 support (though likely not virtualization acceleration features - which would IIRC require VMs to be 32-bit). This box would be in my production today, had it not broken while I am on a prolonged trip away from that home; but it won't be impacted by a 64-bit only OS, indeed (it did have some VMs for a test farm though, and they might be impacted). Your VMs should be migratable to a more modern hypervisor, if the one you have can't run x64. Also I know of many small (SOHO) storage boxes which can be made to work with OpenSolaris and illumos-based OSes, and of those only the HP N36 and N40L have (known to me) 64-bit AMD CPUs and ECC support; most other such boxes are built around Atom, and often 32-bit with some 2GB RAM. While this is not interesting for intensive production use, some users of these boxes as reliable (ZFS) home storage might be hurt by move to 64-bit only OS. Arguably though, lack of ECC did probably burn my home-NAS causing some corruptions poorly-explicable otherwise. While I wouldn't recommend non-ECC ZFS NASes for any use, at least as a newly built rig, people that have a black box which just works, and aren't keen on spending time and money to buy and setup regular upgrades, are kind of stuck with it until the HW dies. The thing is… most of these in place systems aren't likely to want or need the continuous stream of updates. We can argue about bug fixes, and security considerations, but your average home NAS isn't sitting out there exposed on the internet. Anyone building a new box like this would use a newer Atom that supports x64. (And Atom is entirely unsuited to this due to lack of ECC, as you mentioned, but hey, most SOHO users don't care about that, although they should. The ones who use ZFS because they worry about silent data corruption are probably *also* smart enough to understand the risks of running without ECC.) I think *most* users of these SOHO boxes are *not* using illumos, even those who use illumos in other capacities, but are instead relying on FreeNAS, or the commercially supplied solution. - Garrett ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI project reboot required
On Sun, May 12, 2013 at 6:06 PM, Garrett D'Amore garrett.dam...@dey-sys.com wrote: On May 12, 2013, at 8:51 AM, Alan Coopersmith alan.coopersm...@oracle.com wrote: It has been a few years since Oracle upstream dropped 32-bit i386 support, so that's just one of the decisions OI has to make - track upstream as is or fork/patch as needed to continue to support 32-bit on i386. Yep. And that has sweeping consequences; lots of things depend upon it this decision. I'm of the opinion that enough time has passed that we should seriously consider doing the same. Its been about a decade since 64-bit x86 systems came on the scene (Opteron was released in June 2003). I seriously considered killing all support for 32-bit CPUs in Tribblix from the start. The main reason I didn't is that it's (currently) extra work to strip out 32-bit from the packages. I haven't seen a serious use of a 32-bit only CPU in production in over 5 years. My OI laptop is 32-bit only. It's on its deathbed, only waiting for me to find a newer one that Illumos will actually boot and install on. And I think most hobbyists upgrade their kit more frequently as well -- I have to believe almost everyone is on 64-bit kit these days. Furthermore, most interesting systems (based on illumos) require more memory than is practical with a 32-bit only CPU. I think that argument is specious, though. Tribblix gives you a fully functional graphical desktop in 512M (OK, so you're not going to run firefox for very long!). The other area is that test or play systems tend to be older ones that aren't in use for front-line service. That's also an interesting area for Illmuos distros, as we might be in better shape for driver support on something that isn't brand new. (As a case in point, none of my available sparc test systems will run S11, as support for all of them was dropped as well.) The same is true of people taking home retired office kit, it's not new. I have to believe we could eliminate a *lot* of baggage by nixing 32-bit support. I *know* we can, because I've nixed a bunch of system utilities in our DEY environment that were delivered in both 32 and 64 bit variants. Not to mention simplification by eliminating the isaexec dance. We're going to have to support a 32-bit userland for some time to come, unfortunately, but we should no longer make that the default, and we should deliver all of our system utilities in 64-bit only form, IMO; and we could entirely kill off the 32-bit kernel. Alternatively, if there is sufficient demand, one could imagine a separate architecture for ia32, that is the 32-bit variant port. I think the key there is to manage the transition. Provided those who want to continue with a 32-bit platform are able to do so, I don't see a problem. But I can imagine distros producing a final 32-bit release, and then moving on. I know I would. It just has to be announced and planned for - it's really a rather major flag day. -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI project reboot required
I am running a small web and ftp server at university on a 32-bit AMD Athlon. So I would be affected. However I cannot argue for retaining 32-bit support in OI, because any baggage certainly should be dropped in order for OI project to proceed. I can upgrade the hardware (unlikely); I can switch to Linux (reluctantly). - Dmitry. So, out of curiosity -- *who* is actively running illumos on 32-bit kit today? I'm not interested in hypothetical uses or kit that is sitting around in your garage waiting for you to do something with it…. I'm interested in people who would be immediately impacted and severely so if illumos were not available on 32-bit CPUs right now. ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI project reboot required
On 05/12/13 07:10 PM, Garrett D'Amore wrote: On May 12, 2013, at 9:02 AM, Jim Klimov jimkli...@cos.ru wrote: I believe, 32-bit should be retained. While it is of little utility for ZFS and other huge-RAM jobs, it may be required for some netbooks, older hardware repurposed for tests and SOHO servers, as well as for resource-constrained testing VMs. So I'd vouch for this fork/patch approach if this upstream is still followed. We've been doing this for years now. I'm now starting to think -- 3 years later on -- that this argument feels specious today. Who runs illumos on a netbook? I did, once. Not any more. (And modern netbooks have 64 bit support!) Older hardware must be *really* old. Over 5 years. For servers, probably over 10 years. I've thrown away my Pentiums and Pentium IIs. I suppose there could be some Pentium IIIs and IVs out there, or AMD Athlons (pre-Athlon64), but they'd all be really really slow by today's standards. Do people run illumos on such kit? I'm highly doubtful, unless that kit is around just to answer the question of whether 32-bit kernels still work. :-) Maybe it's called backward compatibility. I think Firefox and Thunderbird are 32-bit. Isn't the Multiarch what defined Solaris, like always? I don't want we should loose Solris10 zone if someone needs that in some moments untill some moment in the future. (There are still people not migrated from S10) There is still many older computers that could be useful with Illumos distro. Some Oracle decisions are a bit also insane, like removing support for Floppy disk (why removing when not already used much) and support for Smart card identification for a Workstation/server. Openindiana, Illumos have also an advantage of supporting older hardware, that Oracle removed support for. We should not forget that market of people using Just FINE servers that large corporations throw out but could be used for years. Removing support for still widest-supported architecture on the planet could be a bit short-sighted in our current market position (not counting those high-end cloud Illumos consumers, but ordinary people). If there is some netbook that needs to be used, or older but fine notebook as a control console, Illumos distro could work on it for years, since one of the `advantages` of slow development moving of Illumos could be lower need of changing hardware over years. Or bigger stability and backward compatibility. Of course, nothing is set in the stone, it will be how developers want. If 32-bit needs to be moved to separate place or cut of from newest advanced be it. But not if it is not necessary. GDA: Will there ever be Release or Version of Illumos? Unlike current rolling-releases? Will Illumos ABI,API remain stable, like on Solaris? ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI project reboot required
On 05/12/13 07:06 PM, Garrett D'Amore wrote: We're going to have to support a 32-bit userland for some time to come, unfortunately, but we should no longer make that the default, and we should deliver all of our system utilities in 64-bit only form, IMO; and we could entirely kill off the 32-bit kernel. Alternatively, if there is sufficient demand, one could imagine a separate architecture for ia32, that is the 32-bit variant port. That would not need to carry the 64-bit support. Admittedly going this route reduces the likelihood of keeping certain bits capable of running 32-bit mode (e.g. device drivers), but one would argue that 32 bit systems are unlikely to adapt new devices, etc. precisely because they are *so* friggin' old. Not only x86. There is also SPARC with it's 32-bit apps to count for. (I don't use 32-bit but on Eeepc) As I understand 32-bit SPARC apps run faster then 64 , unlike on x86 where amd64 apps are faster. And what about if Illumos starts running/being ported on ARM (64Bit) and have need of supporting KVMs with tons of 32-bit ARM applications? Will it also work if 32-bit is ditched right now? I don't expect 32-bit applications/userland to stop being important so soon. If multiarch bitness priciple is ditched from building Illumos , that would ditch one thing that is present only on Illumos until now and not elsewhere. I guess there is still no 128-bit CPUs? Will multiarch need to be reinvented when they arrive? ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI project reboot required
I have a hard time believing you would choose to switch to Linux instead of taking the time to upgrade the hardware. A two or three year or even five year old system will probably be a big upgrade and cost less than the labor to switch to Linux. Sent from my iPhone On May 12, 2013, at 12:13 PM, Dmitry Kozhinov d...@desktopfay.com wrote: I am running a small web and ftp server at university on a 32-bit AMD Athlon. So I would be affected. However I cannot argue for retaining 32-bit support in OI, because any baggage certainly should be dropped in order for OI project to proceed. I can upgrade the hardware (unlikely); I can switch to Linux (reluctantly). - Dmitry. So, out of curiosity -- *who* is actively running illumos on 32-bit kit today? I'm not interested in hypothetical uses or kit that is sitting around in your garage waiting for you to do something with it…. I'm interested in people who would be immediately impacted and severely so if illumos were not available on 32-bit CPUs right now. ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI project reboot required
Don't misunderstand me. I want to eliminate 32 bit kernels and delivery of certain 32 bit versions of system utilities. This should in no way affect any 3rd party apps. We need to keep the 32 bit app runtime for the foreseeable future. Sent from my iPhone On May 12, 2013, at 12:51 PM, Nikola M. minik...@gmail.com wrote: On 05/12/13 07:10 PM, Garrett D'Amore wrote: On May 12, 2013, at 9:02 AM, Jim Klimov jimkli...@cos.ru wrote: I believe, 32-bit should be retained. While it is of little utility for ZFS and other huge-RAM jobs, it may be required for some netbooks, older hardware repurposed for tests and SOHO servers, as well as for resource-constrained testing VMs. So I'd vouch for this fork/patch approach if this upstream is still followed. We've been doing this for years now. I'm now starting to think -- 3 years later on -- that this argument feels specious today. Who runs illumos on a netbook? I did, once. Not any more. (And modern netbooks have 64 bit support!) Older hardware must be *really* old. Over 5 years. For servers, probably over 10 years. I've thrown away my Pentiums and Pentium IIs. I suppose there could be some Pentium IIIs and IVs out there, or AMD Athlons (pre-Athlon64), but they'd all be really really slow by today's standards. Do people run illumos on such kit? I'm highly doubtful, unless that kit is around just to answer the question of whether 32-bit kernels still work. :-) Maybe it's called backward compatibility. I think Firefox and Thunderbird are 32-bit. Isn't the Multiarch what defined Solaris, like always? I don't want we should loose Solris10 zone if someone needs that in some moments untill some moment in the future. (There are still people not migrated from S10) There is still many older computers that could be useful with Illumos distro. Some Oracle decisions are a bit also insane, like removing support for Floppy disk (why removing when not already used much) and support for Smart card identification for a Workstation/server. Openindiana, Illumos have also an advantage of supporting older hardware, that Oracle removed support for. We should not forget that market of people using Just FINE servers that large corporations throw out but could be used for years. Removing support for still widest-supported architecture on the planet could be a bit short-sighted in our current market position (not counting those high-end cloud Illumos consumers, but ordinary people). If there is some netbook that needs to be used, or older but fine notebook as a control console, Illumos distro could work on it for years, since one of the `advantages` of slow development moving of Illumos could be lower need of changing hardware over years. Or bigger stability and backward compatibility. Of course, nothing is set in the stone, it will be how developers want. If 32-bit needs to be moved to separate place or cut of from newest advanced be it. But not if it is not necessary. GDA: Will there ever be Release or Version of Illumos? Unlike current rolling-releases? Will Illumos ABI,API remain stable, like on Solaris? ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI project reboot required
To move OI forward I think 32-bit kernels should be dropped. I had been looking for alternatives for my web/mail servers but have always liked Solaris and would like to continue to leverage my knowledge and have mostly decided to go with OI. From: Garrett D'Amore garrett.dam...@dey-sys.com To: OpenIndiana Developer mailing list oi-dev@openindiana.org Cc: oi-dev@openindiana.org oi-dev@openindiana.org Sent: Sunday, May 12, 2013 5:14 PM Subject: Re: [oi-dev] OI project reboot required Don't misunderstand me. I want to eliminate 32 bit kernels and delivery of certain 32 bit versions of system utilities. This should in no way affect any 3rd party apps. We need to keep the 32 bit app runtime for the foreseeable future. Sent from my iPhone On May 12, 2013, at 12:51 PM, Nikola M. minik...@gmail.com wrote: On 05/12/13 07:10 PM, Garrett D'Amore wrote: On May 12, 2013, at 9:02 AM, Jim Klimov jimkli...@cos.ru wrote: I believe, 32-bit should be retained. While it is of little utility for ZFS and other huge-RAM jobs, it may be required for some netbooks, older hardware repurposed for tests and SOHO servers, as well as for resource-constrained testing VMs. So I'd vouch for this fork/patch approach if this upstream is still followed. We've been doing this for years now. I'm now starting to think -- 3 years later on -- that this argument feels specious today. Who runs illumos on a netbook? I did, once. Not any more. (And modern netbooks have 64 bit support!) Older hardware must be *really* old. Over 5 years. For servers, probably over 10 years. I've thrown away my Pentiums and Pentium IIs. I suppose there could be some Pentium IIIs and IVs out there, or AMD Athlons (pre-Athlon64), but they'd all be really really slow by today's standards. Do people run illumos on such kit? I'm highly doubtful, unless that kit is around just to answer the question of whether 32-bit kernels still work. :-) Maybe it's called backward compatibility. I think Firefox and Thunderbird are 32-bit. Isn't the Multiarch what defined Solaris, like always? I don't want we should loose Solris10 zone if someone needs that in some moments untill some moment in the future. (There are still people not migrated from S10) There is still many older computers that could be useful with Illumos distro. Some Oracle decisions are a bit also insane, like removing support for Floppy disk (why removing when not already used much) and support for Smart card identification for a Workstation/server. Openindiana, Illumos have also an advantage of supporting older hardware, that Oracle removed support for. We should not forget that market of people using Just FINE servers that large corporations throw out but could be used for years. Removing support for still widest-supported architecture on the planet could be a bit short-sighted in our current market position (not counting those high-end cloud Illumos consumers, but ordinary people). If there is some netbook that needs to be used, or older but fine notebook as a control console, Illumos distro could work on it for years, since one of the `advantages` of slow development moving of Illumos could be lower need of changing hardware over years. Or bigger stability and backward compatibility. Of course, nothing is set in the stone, it will be how developers want. If 32-bit needs to be moved to separate place or cut of from newest advanced be it. But not if it is not necessary. GDA: Will there ever be Release or Version of Illumos? Unlike current rolling-releases? Will Illumos ABI,API remain stable, like on Solaris? ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI project reboot required
To move OI forward I think 32-bit kernels should be dropped. I had been looking for alternatives for my web/mail servers but have always liked Solaris and would like to continue to leverage my knowledge and have mostly decided to go with OI. From: Garrett D'Amore garrett.dam...@dey-sys.com To: OpenIndiana Developer mailing list oi-dev@openindiana.org Cc: oi-dev@openindiana.org oi-dev@openindiana.org Sent: Sunday, May 12, 2013 5:14 PM Subject: Re: [oi-dev] OI project reboot required Don't misunderstand me. I want to eliminate 32 bit kernels and delivery of certain 32 bit versions of system utilities. This should in no way affect any 3rd party apps. We need to keep the 32 bit app runtime for the foreseeable future. Sent from my iPhone On May 12, 2013, at 12:51 PM, Nikola M. minik...@gmail.com wrote: On 05/12/13 07:10 PM, Garrett D'Amore wrote: On May 12, 2013, at 9:02 AM, Jim Klimov jimkli...@cos.ru wrote: I believe, 32-bit should be retained. While it is of little utility for ZFS and other huge-RAM jobs, it may be required for some netbooks, older hardware repurposed for tests and SOHO servers, as well as for resource-constrained testing VMs. So I'd vouch for this fork/patch approach if this upstream is still followed. We've been doing this for years now. I'm now starting to think -- 3 years later on -- that this argument feels specious today. Who runs illumos on a netbook? I did, once. Not any more. (And modern netbooks have 64 bit support!) Older hardware must be *really* old. Over 5 years. For servers, probably over 10 years. I've thrown away my Pentiums and Pentium IIs. I suppose there could be some Pentium IIIs and IVs out there, or AMD Athlons (pre-Athlon64), but they'd all be really really slow by today's standards. Do people run illumos on such kit? I'm highly doubtful, unless that kit is around just to answer the question of whether 32-bit kernels still work. :-) Maybe it's called backward compatibility. I think Firefox and Thunderbird are 32-bit. Isn't the Multiarch what defined Solaris, like always? I don't want we should loose Solris10 zone if someone needs that in some moments untill some moment in the future. (There are still people not migrated from S10) There is still many older computers that could be useful with Illumos distro. Some Oracle decisions are a bit also insane, like removing support for Floppy disk (why removing when not already used much) and support for Smart card identification for a Workstation/server. Openindiana, Illumos have also an advantage of supporting older hardware, that Oracle removed support for. We should not forget that market of people using Just FINE servers that large corporations throw out but could be used for years. Removing support for still widest-supported architecture on the planet could be a bit short-sighted in our current market position (not counting those high-end cloud Illumos consumers, but ordinary people). If there is some netbook that needs to be used, or older but fine notebook as a control console, Illumos distro could work on it for years, since one of the `advantages` of slow development moving of Illumos could be lower need of changing hardware over years. Or bigger stability and backward compatibility. Of course, nothing is set in the stone, it will be how developers want. If 32-bit needs to be moved to separate place or cut of from newest advanced be it. But not if it is not necessary. GDA: Will there ever be Release or Version of Illumos? Unlike current rolling-releases? Will Illumos ABI,API remain stable, like on Solaris? ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI project reboot required
On Sunday, May 12, 2013 06:17 AM, Garrett D'Amore wrote: The exception here is the Chromebook experience and OLPC…. they were able to do something cool and make a compelling argument. But nobody else has built a compelling Linux or Unix desktop with a reason to exist besides being free. And there is no commercial value in just being free -- you can't make up in volume unless you have some revenue. :-) It's ironic that Chromebook appears to have fulfilled the meme the network is the computer Innovation is a weird creature. ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI project reboot required
Hi Alasdair I would like to try setting up a repo on github, give trusted people direct access and support pull requests from independent developers. And then have jenkins publish packages incrementally to publicly accessible repository. In theory, it should only take few minutes from a push to a published package in a repo. It is a variation on the process which was tried earlier. I think it might work this time. I did some prep work last night. Will try to have something usable by others later tonight. Cheers, Andrzej On 10 May 2013 14:04, Alasdair Lumsden alasdai...@gmail.com wrote: Andrzej, Your vision is pretty much the same one I had. The challenge is this: Existing releng process and contribution process prevent anything from happening though. I would like to help to change that. How? On Fri, May 10, 2013 at 12:54 PM, Jim Klimov jimkli...@cos.ru wrote: On 2013-05-10 02:19, Garrett D'Amore wrote: There is little commercial future in the desktop for Linux distributions as well yet almost all of them have a graphical desktop. I would be entirely *unsurprised* if distro vendors like RedHat and Oracle simply *ditched* their desktop support at some point in the future -- its clear to me at least that folks aren't running those distros on the desktop. Well, Oracle does provide and promote SunRays, and while admittedly most of their market targeting is about VDI and access to virtual Windows desktops, there are many requests on the SRSS mailing list about adding support for server-side Ubuntu as the SRSS terminal server, because certain apps only exist for Linux and tunneling of connections makes their graphics lag, and RHEL/OEL/Solaris desktops are argued to be not so user-friendly (I have no opinion on this, to me X11 is a means to display more characters on screen than possible in a text mode). Not that Oracle seems to care to address that demand, at least publicly - just recently they began supporting versions 6 of RHEL and OEL as server-side Linuxes. But there is certain demand for non-MS/Apple desktops, and one linked to commercial interest as well. I am not sure if OI/illumos can ride that tide, though. Maybe with some other terminal client technologies (ThinLinc, Wyse, etc)?.. //Jim __**_ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/**mailman/listinfo/oi-devhttp://openindiana.org/mailman/listinfo/oi-dev -- Alasdair Lumsden http://www.everycity.co.uk EveryCity Managed Hosting Studio 18 Bluelion Place 237 Long Lane, London, SE1 4PU general: 020 7183 2800 support: 020 7183 2801 email: a...@everycity.co.uk Every City Limited Registered in England and Wales, No. 5689474 Registered Office: Roper Yard, Roper Road, Canterbury, CT2 7EX ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI project reboot required
On 05/10/13 02:19 AM, Garrett D'Amore wrote: more constructive than whinging about it will be to find ways to either a) make a commercially viable case for it so people can get paid to work on it, or b) lead a volunteer effort to make this work. I think that without Desktop that is running on the server, I can not sell Illumos based distribution as a server product. That is because small companies and offices expect to have GUI working, so they can log in and possible do something with the machine. I suppose that machine without GUI would look to them as a blackbox if there is just command line. There is no desktop per se and server as a product per se. It is the server distribution that has desktop environment and programs for convenience. If I am selling it, I am selling a server. And having Desktop environments on server is nice. Not having desktop environment on server in 2013 is NOT NICE. I want to be able to run both legacy apps and have compatibility with Solaris 10 in it's zone and that's about compatibility. Apps made for Opensolaris also mostly got integrated in OI. I want innovation in Illumos and to have separated issues of updating desktop and GUI parts and applications from the core OS. Having Desktop environment that aether is started or not, does not stop innovation in Illumos from happening and be used in practice. If Solaris 10 (and 11) is a server operating system (GUI does not hurt server use), then Illumos distribution could not be hurt to have GUI available and not to be stuck in CLI. To me it is strange, why some people that do not care about having at least some desktop on top of Illumos, continuously talking about it? New people coming to the platform FIRST discover how much cool GUI is and they dig deeper IF you lure them, to at least try using it for some time. And if they got right info they can get on the ship as users, bug reporters and then contributors. I came from Linux, I were a fanboy. I found better technology, I migrated. On Linux I had everything I actually need, BUT the sense of sanity that Solaris/Illumos have with integrated technologies in one place. Since I too think that putting on server anything BUT Illumos-based distribution , is having not much sense, I want to have server distro on my *laptop* I can use, develop solution and then apply it on remote server. I do not want to use Windows/OSX, VMWare, Microsoft Office etc. (nor have money to throw on Apple etc) I want to be able to have things I use independent from hostile proprietary vendors. Illumos devs could use Openindiana for their development environment and run KVM instead of VMWare. And for running Virtualbox I also need Openindiana. One thing many people do not realize is that because of advanced Illumos technologies, Illumos-based distributions have a potential to be super-desktops in some future. Maybe that IS insane, but I tend to see the future where I use GUI to manage servers and do things I can not do with CLI-only. If Fedora would ditch desktop upon install, and Ubuntu started releasing only server edition without Desktop environment, what would be left of them selling to customers? (Even if server do not run Desktop) What would you show to them on the presentation? Black screen of 1985? I always planned to eventually sell Illumos distro as a server, but I want a customer to SEE it and say: OK, NICE, whatever. And not: Oh, no.., whatever. And that is how money could flow. If I have something to contribute back , but without GUI, I don't think it can sell. Anyway, I expect Illumos itself in the OI to include KVM and ZFS disk bandwidth usage scheduling. And for GUI- those wanting GUI should care about that. Including me. ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI project reboot required
On May 11, 2013, at 10:05 AM, Nikola M. minik...@gmail.com wrote: On 05/10/13 02:19 AM, Garrett D'Amore wrote: more constructive than whinging about it will be to find ways to either a) make a commercially viable case for it so people can get paid to work on it, or b) lead a volunteer effort to make this work. I think that without Desktop that is running on the server, I can not sell Illumos based distribution as a server product. That is because small companies and offices expect to have GUI working, so they can log in and possible do something with the machine. I suppose that machine without GUI would look to them as a blackbox if there is just command line. And yet, many people are building products on top of illumos that *are* selling well, and don't provide a graphical login (at least not in the traditional sense -- some of them offer a browser based login.) SmartOS, Nexenta, GreenBytes, etc…. even Sun traditionally sold more headless systems than systems with a graphical desktop. (All those rack mount systems don't need a graphical desktop -- but they *should* offer a compelling experience using other management tools -- like Browser or native mobile apps to help with systems management.) There is no desktop per se and server as a product per se. It is the server distribution that has desktop environment and programs for convenience. If I am selling it, I am selling a server. And having Desktop environments on server is nice. Not having desktop environment on server in 2013 is NOT NICE. Actually, I think this attitude is dated for the reverse reason. In 2013 *desktop* doesn't matter, and that trend has only been accelerating. Because people access their systems using their personal Macs, or more often using thin clients (tablets, mobile devices, etc.)… 10 years ago your arguments were much more valid, IMO. The question is no longer about whether I need a desktop UI on my server, but is now moving to whether I need a desktop at all. (I think a bunch of us *do*, but we're a shrinking population.) [ cut! ] One thing many people do not realize is that because of advanced Illumos technologies, Illumos-based distributions have a potential to be super-desktops in some future. Maybe that IS insane, but I tend to see the future where I use GUI to manage servers and do things I can not do with CLI-only. Hey, now you're talking! If were (or anyone) is going to invest in an illumos desktop, why not do it in a way that makes sure that what we're doing is *better* than just another Linux distro. Trying to keep playing catchup with Ubuntu is IMO a wasted effort. If on the other hand you can *surpass* them in some meaningful ways, *then* you've got my attention. The problem is that nobody has been able to do that yet. If Fedora would ditch desktop upon install, and Ubuntu started releasing only server edition without Desktop environment, what would be left of them selling to customers? (Even if server do not run Desktop) What would you show to them on the presentation? Black screen of 1985? They show GDM today. But who really cares about that? Of the people who are decision makers in any company, how many of them choose a Linux graphical desktop? The exception here is the Chromebook experience and OLPC…. they were able to do something cool and make a compelling argument. But nobody else has built a compelling Linux or Unix desktop with a reason to exist besides being free. And there is no commercial value in just being free -- you can't make up in volume unless you have some revenue. :-) I always planned to eventually sell Illumos distro as a server, but I want a customer to SEE it and say: OK, NICE, whatever. And not: Oh, no.., whatever. And that is how money could flow. If I have something to contribute back , but without GUI, I don't think it can sell. I think if you believe your buyers care about the desktop, then I think you probably don't understand your buyers. Or possibly I don't understand your market -- but in the *server* space almost *nobody* cares about the desktop UI. - Garrett ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI project reboot required
I agree with what Peter and Garrett wrote earlier. OI is lacking a clear vision. It should be different than other illumos distros' as well to avoid duplicating work unnecessarily. I think, OI could be illumos hacker distro, and: - carry on providing GUI support, good enough for illumos hackers to use it on their desktops/laptops - it could potentially be based on vanilla illumos-gate; few OI specific changes could be upstreamed or dropped - existing OI users should be able to do pkg update to get the latest bits Not radical or innovative at all. Different enough to what other distros are doing though (no GUI, own illumos-gate forks). I did a quick survey on IRC and looks like there is enough talented and capable people who would be willing to help with the model described above. Existing releng process and contribution process prevent anything from happening though. I would like to help to change that. Radical and innovative ideas are welcome as well. They could be worked on in parallel as sub-projects. What do you think about OI being illumos hacker distro? Andrzej On 10 May 2013 03:12, Nick Zivkovic zivkovic.n...@gmail.com wrote: For what it's worth, I only need Xorg, xpdf and xterm to take care of my graphics needs. Everything that doesn't involve coding happens on linux, mac and winxp. As long as a distro can support Xorg, it is viable for me. So whatever you guys do, please don't remove the basic graphics capability! On May 9, 2013 7:20 PM, Garrett D'Amore garrett.dam...@dey-sys.com wrote: On May 9, 2013, at 4:00 PM, Bob Friesenhahn bfrie...@simple.dallas.tx.us wrote: On Thu, 9 May 2013, Garrett D'Amore wrote: Upshot, *today* anyone who thinks there is a commercial future in illumos on the desktop is probably smoking something. There are a few people who would be willing to pay for it, but it needs more than a few dozen people willing to pay a couple hundred dollars (more often substantially less) to make this a viable and interesting (economically) venture. There is little commercial future in the desktop for Linux distributions as well yet almost all of them have a graphical desktop. Admittedly true. And yet, most of them *started* on the desktop. Linux's roots are in the desktop. Most of those distros took off because they had a groundswell of support from developer users who wanted it on the desktop -- they didn't have servers, and options like VMware simply didn't exist at the time. I'd argue that this is largely an artifact of history. I would be entirely *unsurprised* if distro vendors like RedHat and Oracle simply *ditched* their desktop support at some point in the future -- its clear to me at least that folks aren't running those distros on the desktop. In fact, I can't think of *anyone* who's paying for a desktop OS that doesn't come from either Apple or Microsoft. Availability of a graphical desktop is seen as a requirement for common acceptance. Historically true, but I seriously doubt it now. SmartOS is the counter example from this community. I think there are others. For example, OpenBSD was highly popular for a long time for its security emphasis, but I don't know *anyone* who ran it on a desktop. The widespread availability of virtualization like VMware, VirtualBox, and Parallels means that there is little need to take over the user's desktop to provide a reasonable environment. Most people these days develop using SSH, etc. The folks I know who use Linux would, apart from a few extremists, not care whether the desktop ran Linux, FreeBSD, or Solaris, as long as it Just Worked and provided a familiar UNIX-like backend. (I contend that these principles have lead strongly to the uptake of MacOS in the developer community…. I use an Apple laptop for my own environment, even though I wouldn't *dream* of using MacOS in a server capacity.) For me, Terminal.app and ssh is along with VMware gives me everything I need for doing cool things with illumos on my desktop. I explicitly *disable* the graphical login on illumos. :-) Much/most of the graphical desktop development taking place for Linux does not seem to be done by the companies which popularly peddle it (e.g. Canonical has been more of a desktop packager except for its useless Unity). Only partly true (Qt is the counter example). But yes, a lot of the desktop development in Gnome and company is done by community members who are passionate about this. And guess what -- almost all those guys are Linux bigots. There's a huge trend in those spaces to adopt technologies that are Linux-specific, to the point of near active hostility towards other FOSS. That creates a huge barrier for leveraging their efforts. Do we have the kind of volunteerism here to take up a duplicate effort? And why just duplicate? If we have *that* kind of interest and volunteerism, I'd recommend actually doing something *cooler* and better. Of course,
Re: [oi-dev] OI project reboot required
On 2013-05-10 02:19, Garrett D'Amore wrote: There is little commercial future in the desktop for Linux distributions as well yet almost all of them have a graphical desktop. I would be entirely *unsurprised* if distro vendors like RedHat and Oracle simply *ditched* their desktop support at some point in the future -- its clear to me at least that folks aren't running those distros on the desktop. Well, Oracle does provide and promote SunRays, and while admittedly most of their market targeting is about VDI and access to virtual Windows desktops, there are many requests on the SRSS mailing list about adding support for server-side Ubuntu as the SRSS terminal server, because certain apps only exist for Linux and tunneling of connections makes their graphics lag, and RHEL/OEL/Solaris desktops are argued to be not so user-friendly (I have no opinion on this, to me X11 is a means to display more characters on screen than possible in a text mode). Not that Oracle seems to care to address that demand, at least publicly - just recently they began supporting versions 6 of RHEL and OEL as server-side Linuxes. But there is certain demand for non-MS/Apple desktops, and one linked to commercial interest as well. I am not sure if OI/illumos can ride that tide, though. Maybe with some other terminal client technologies (ThinLinc, Wyse, etc)?.. //Jim ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI project reboot required
Andrzej, Your vision is pretty much the same one I had. The challenge is this: Existing releng process and contribution process prevent anything from happening though. I would like to help to change that. How? On Fri, May 10, 2013 at 12:54 PM, Jim Klimov jimkli...@cos.ru wrote: On 2013-05-10 02:19, Garrett D'Amore wrote: There is little commercial future in the desktop for Linux distributions as well yet almost all of them have a graphical desktop. I would be entirely *unsurprised* if distro vendors like RedHat and Oracle simply *ditched* their desktop support at some point in the future -- its clear to me at least that folks aren't running those distros on the desktop. Well, Oracle does provide and promote SunRays, and while admittedly most of their market targeting is about VDI and access to virtual Windows desktops, there are many requests on the SRSS mailing list about adding support for server-side Ubuntu as the SRSS terminal server, because certain apps only exist for Linux and tunneling of connections makes their graphics lag, and RHEL/OEL/Solaris desktops are argued to be not so user-friendly (I have no opinion on this, to me X11 is a means to display more characters on screen than possible in a text mode). Not that Oracle seems to care to address that demand, at least publicly - just recently they began supporting versions 6 of RHEL and OEL as server-side Linuxes. But there is certain demand for non-MS/Apple desktops, and one linked to commercial interest as well. I am not sure if OI/illumos can ride that tide, though. Maybe with some other terminal client technologies (ThinLinc, Wyse, etc)?.. //Jim __**_ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/**mailman/listinfo/oi-devhttp://openindiana.org/mailman/listinfo/oi-dev -- Alasdair Lumsden http://www.everycity.co.uk EveryCity Managed Hosting Studio 18 Bluelion Place 237 Long Lane, London, SE1 4PU general: 020 7183 2800 support: 020 7183 2801 email: a...@everycity.co.uk Every City Limited Registered in England and Wales, No. 5689474 Registered Office: Roper Yard, Roper Road, Canterbury, CT2 7EX ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI project reboot required
On 10 May 2013 12:54, Jim Klimov jimkli...@cos.ru wrote: Well, Oracle does provide and promote SunRays ... Actually, if you check the SunRay forums people are getting the impression that Oracle does _not_ promote SunRays, and some of their sales guys are actively trying to dissuade people from buying them ... it's got to the point that a large number of the original users are getting scared and are moving away from them to something like a WYSE client instead. Apart from that and the changes in licenses that Oracle decided to levy retroactively on our old models when we bought new ones, I love them, they're great, they do exactly what we need ... but then we only need access to email, internet and openoffice. ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI project reboot required
On 2013-05-10 14:11, Jonathan Adams wrote: On 10 May 2013 12:54, Jim Klimov jimkli...@cos.ru mailto:jimkli...@cos.ru wrote: Well, Oracle does provide and promote SunRays ... Actually, if you check the SunRay forums people are getting the impression that Oracle does _not_ promote SunRays, and some of their sales guys are actively trying to dissuade people from buying them ... it's got to the point that a large number of the original users are getting scared and are moving away from them to something like a WYSE client instead. Yes, that too. At least, they say that they invest more than Sun, release more often, and such blah-blah. As for licensing... maybe that's why I mentioned other terminal technologies ;) I heard about problems with sales of some other ex-Sun products - Oracle has little interest in meddling with small customers; often this means purchases of thousands of licenses. Smaller volume may be discussed, but needs approval procedures and is not guaranteed to happen. Many of largest national companies (in market share terms, excluding giants like banking and oil industry) have 2-3 thousand employees and don't really want to overpay twofold just to qualify for a minimum-sized purchase. It gets much harder with deployments which start as some departmental PoC with potential to scale onto thousands of accounts, but for the starter year would have just several tens or hundreds of users. I can understand how it can be cost-ineffective for a bureaucratic monster to have small customers... but why forbid partners to make it their problem? Then again, it opens the same niches for smaller players, including those which provide same ex-Sun technologies at a smaller price, or just make it possible to buy in small volumes. This monopoly actually promotes competition and innovation among scavengers who can feel happy about leftovers from a tiger's meal ;) my 2c //jim ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI project reboot required
On 2013-05-10 13:43, Andrzej Szeszo wrote: I agree with what Peter and Garrett wrote earlier. OI is lacking a clear vision. It should be different than other illumos distros' as well to avoid duplicating work unnecessarily. I think, OI could be illumos hacker distro, and: - carry on providing GUI support, good enough for illumos hackers to use it on their desktops/laptops - it could potentially be based on vanilla illumos-gate; few OI specific changes could be upstreamed or dropped - existing OI users should be able to do pkg update to get the latest bits Not radical or innovative at all. Different enough to what other distros are doing though (no GUI, own illumos-gate forks). Are there many (any?) OI-private deviations from illumos-gate? I thought it was built with the vanilla kernel already. Also, being a hacker desktop distro with access to all other software packages that are available to other distros does not change the fact that OI can be used on servers as well - efficiently, with same kernel capabilities, scaling ability, etc? The difference may be minute, such as compile-time flags for optimizations, default tuning, administrative models and the proper way to do things (i.e. zones in OI and SmartOS are AFAIK quite different logical models). Meaning, that while other distros might be more suitable and optimal for production servers with a clearly pre-defined purpose, such as a VM server or an app server or a storage server - built for that purpose, OI might run a desktop or a undefined-purpose server with possibly smaller efficiency but higher versatility, or admin-friendliness by means of having same administrative interface as on his desk/lap-top or just having the interface at the console of the only server in the small office, etc... maybe :) //Jim ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI project reboot required
On 10 May 2013 14:13, Jim Klimov jimkli...@cos.ru wrote: Are there many (any?) OI-private deviations from illumos-gate? I thought it was built with the vanilla kernel already. I don't believe that KVM is in the default Illumos kernel, but is in OI. I don't know whether the planned new Wireless stack is going in Illumos, or in userland, or would have been designated as an Implementer option ... Jon ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] OI project reboot required
Hi All (Instead of replying to a message in one of the other threads I thought I will create a new one.) Just wanted to say that I don't see a future for the project in its current form. There is simply too many packages and too much baggage for a handful of people to look after. I think the project needs a new vision and a reboot. If you have any ideas for the project and can write scripts/makefiles to generate a distro/live CDs/etc. - speak up! You don't have to be a leader if you don't want to :) Regards, Andrzej ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI project reboot required
On 05/09/2013 10:01 AM, Andrzej Szeszo wrote: Hi All (Instead of replying to a message in one of the other threads I thought I will create a new one.) Just wanted to say that I don't see a future for the project in its current form. There is simply too many packages and too much baggage for a handful of people to look after. I think the project needs a new vision and a reboot. If you have any ideas for the project and can write scripts/makefiles to generate a distro/live CDs/etc. - speak up! You don't have to be a leader if you don't want to :) I volunteer to maintain packages around the GNUstep project (http://gnustep.org/), mainly the GNUstep frameworks and associated libraries. Cheers, -- Saso ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI project reboot required
On 2013-05-09 10:01, Andrzej Szeszo wrote: Hi All (Instead of replying to a message in one of the other threads I thought I will create a new one.) Just wanted to say that I don't see a future for the project in its current form. There is simply too many packages and too much baggage for a handful of people to look after. I think the project needs a new vision and a reboot. If you have any ideas for the project and can write scripts/makefiles to generate a distro/live CDs/etc. - speak up! You don't have to be a leader if you don't want to :) You're probably right. I would like to help, though have limited time lately, and without docs similar to Building illumos won't really know where to start beside the illumos-gate. I guess many potential and active contributors are in the same boat. I think it would be proper to maintain a page (hosted on OI wiki) with copies of notes, caveats and other informational snippets about building the OI distro components. We have many talented people who can turn that knowledge into more polished narrative text, scripts and makefiles, paragraph at a time - but too few people who know what should actually be done (the content to polish). After all, you know how many man-months were invested into untangling this know-how from sources, comments, ARCs and whatnot. Please share the result :) I might guess that Martin Bochnig, who made the SPARC port last year single-handedly (and SVR4 backport at the same time), might also be quite in the know of the intricacies for the build. Possibly, he is now the only single person that knows it all. His contribution of the distro building know-how would be just as invaluable as the resulting distribution itself ;) Recently, it was noted that there is no equivalent for a make world in OI. I do believe that after years of development, each consolidation in the distro has some equivalent command to build it, as well as a specified build environment (such as CBE, or just particular GCC/SS12u1, perl, Python and other tool-chain tool versions). The consolidations would likely be built each with its own make sub-world, thus a global make world for OI would run a dozen make's for the sub-worlds... Right? :) The build environments could be made in zones, and provisioning of those can be easily scripted (I think I might help in that direction). The build could be executed by i.e. logging in from GZ into the zones (or somehow harnessing the dmake's distributed properties natively, or by automating with CI/Hudson and its ssh-login capabilities onto many hosts with pieces of the code puzzle), culminating with a call to the distro constructor. This is all a job for a master makefile to be called in the GZ, and waiting a few days for it to complete. Quite possibly, the master-builder automations (scripts to provision standardized build zones, compilation environments on top of them, and local package servers for resulting packages accumulated from those zones, etc.) - these scripts and makefiles would deserve a repository of their own, even if just a small one for starters. This way people would be able to install OI (or real iron or in a VM), fetch a script to provision build zones, download/update source codes, clone the per-bug workspace, etc. all in the same standardized and well-tested manner, and easily start helping the project move on in whatever way they can. //Jim Klimov ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI project reboot required
Hi Sašo Thanks for your support! Andrzej On 9 May 2013 10:36, Sašo Kiselkov skiselkov...@gmail.com wrote: On 05/09/2013 10:01 AM, Andrzej Szeszo wrote: Hi All (Instead of replying to a message in one of the other threads I thought I will create a new one.) Just wanted to say that I don't see a future for the project in its current form. There is simply too many packages and too much baggage for a handful of people to look after. I think the project needs a new vision and a reboot. If you have any ideas for the project and can write scripts/makefiles to generate a distro/live CDs/etc. - speak up! You don't have to be a leader if you don't want to :) I volunteer to maintain packages around the GNUstep project (http://gnustep.org/), mainly the GNUstep frameworks and associated libraries. Cheers, -- Saso ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI project reboot required
On 2013-05-09 13:06, Andrzej Szeszo wrote: The process you have described sounds a lot like OI's original plan. It didn't work out. There was too much baggage. No one was willing to spend time learning it. It was just too ... ugly. It's possible to try it differently this time :) One way or another, in these consolidations we have tons of source code, which, one way or another, need a process to build them. Even if the system of build scripts, spec recipes, makefiles and so on would be changed to something else, just to develop this new build logic and to check validity and comparability of the resulting packages we (individual developers) need to be able to build it the old way and the new way (whatever that would be). AFAIK, very few people know what to do to create the binaries and packages in the old techniques, which makes it problematic for others (not in the know) to start improvements or from-scratch rewrites. Of course, some architectural overview or general framework for all consolidations of what we want to achieve as the new build system (i.e. conforms to this list of technical requirements: A, B, C... Z) would be needed. I may be wrong to think that ability to build the whole beast in the old ways is useful to make the new building technology, but lack of it also hinders an ability to make new spins of the whole OI distro or just updated package repos, as one other commonly-requested useful result of the overall OI project. So far most users can rebuild the kernel part (illumos-gate) of their installations and third-party code like updated sendmail, apache or whatever they need to update, rebuilt and installed in traditional unpackaged ways into alternate paths or even overriding the system binaries, but that's about it. And this is wrong, especially for SOHO farms of several OI machines or zones which could otherwise reuse the in-house updated packages automatically and properly :) Individual gates provide some semi-automated ways of building things. I don't know anyone who managed to automate them all though. No one was able to provide equivalent of make world to build complete OI to date. There are occasional requests on the list from people who are willing to give it a try, and look at the same bits of knowledge from their perspective. If those are shared, including the info on what works and what doesn't and hypotheses on why it doesn't, it is possible that just by sheer increase of the number of eyes, hands and brains aimed at parts of the problem, it would budge and give in :) After all, most manual administrative tasks can be scripted with mega-scripts of logic based on practical observations (do this, check that, don't do this if...). If someone formulates the problems in English, others can translate them to bash or perl or make scripts... There is no doubt Martin Bochnig has a lot of expertise in putting operating systems together. I got impression that he was heavily invested in SVR4 based systems though. OI may not be an interesting project for him as it will probably remain IPS based for the time being. I did lose track of what he implemented in the end, but I think his builds did rely on existing IPS manifests, and he had fixed quite a few, and the SVR4 packages were built using automated backports of the IPS metadata. IF this assessment is correct, then it is more a matter of taste - which packaging system the resulting OI distro would use, either format would come from same sources. //Jim Klimov ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI project reboot required
Hi David Igor is doing great job with his CIBS stuff. Certainly worth consideration for a project reboot. I agree on the contribution front. I had similar experience with Vagrant. It took probably less than 1h for my change to end up in the official repo. Andrzej On 9 May 2013 11:08, David Höppner 0xf...@gmail.com wrote: I think Igor Pashev has done some valueable work with https://github.com/Nexenta/cibs https://github.com/ip1981/last-hope When I was core member of the Homebrew project we just used github pull requests. Contributing should be simple and easy. If I found problems with a patch, I just fixed it in place. -- David On 9 May 2013 10:01, Andrzej Szeszo asze...@gmail.com wrote: Hi All (Instead of replying to a message in one of the other threads I thought I will create a new one.) Just wanted to say that I don't see a future for the project in its current form. There is simply too many packages and too much baggage for a handful of people to look after. I think the project needs a new vision and a reboot. If you have any ideas for the project and can write scripts/makefiles to generate a distro/live CDs/etc. - speak up! You don't have to be a leader if you don't want to :) Regards, Andrzej ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI project reboot required
Hi, (Instead of replying to a message in one of the other threads I thought I will create a new one.) Just wanted to say that I don't see a future for the project in its current form. There is simply too many packages and too much baggage for a handful of people to look after. I think you need to go back a level further. What's the project for? Try to put together a quick mission statement (or even a mission word). And work on an elevator pitch that can grab any member of your potential audience. Part of that is thinking about your audience - both the providers (contributors/developers) and consumers (users/customers). And also what differentiates you from other offerings. Specifically, thinking about other similar projects, what would OI offer that you wouldn't get from OmniOS (which I regard as the closest distro)? I think the project needs a new vision and a reboot. If you have any ideas for the project and can write scripts/makefiles to generate a distro/live CDs/etc. - speak up! You don't have to be a leader if you don't want to :) Concentrate on the vision, and get people engaged. That'll give you a start on having manpower to do the work. I had a completely different vision - both directionally and technically - and ended up completely throwing away all the build system(s), and the entire packaging and install infrastructure. Having to largely reinvent a whole mass of functionality for Tribblix from scratch was orders of magnitude easier than using what was inherited from OpenSolaris. -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI project reboot required
Hello, 1. Provide an updated kernel userland (i.e. Illumos-gate, rev: 19e11862653b or higher). This allows people that use OI for server-based projects to stay in sync with Illumos development on a much wider scale. 2. Optionally, implement JDS updates already maintained by Milan from http://pkg.opensolaris.cz/osol/en/index.shtml. That is it. This also keeps most things consistent to other project work dealing with GNU/userland/spec-files-extra testing with = oi_151a7. You can do this with very minimal manpower and not need to rebuild components / entire consolidations as much (aka 'project overkill'). You can also just dump the updated packages in a IPS repo for testing and review. You don't necessarily have to 'make world' right off the cuff. Start small, then think big. Fact: Entire distribution projects like Tribblix, Milax/OpenSXCE, EON, and DilOS are maintained by 1-2 people. Hope that helped, Ken Mays From: Andrzej Szeszo asze...@gmail.com To: OpenIndiana Developer mailing list oi-dev@openindiana.org Sent: Thursday, May 9, 2013 4:01 AM Subject: [oi-dev] OI project reboot required Hi All (Instead of replying to a message in one of the other threads I thought I will create a new one.) Just wanted to say that I don't see a future for the project in its current form. There is simply too many packages and too much baggage for a handful of people to look after. I think the project needs a new vision and a reboot. If you have any ideas for the project and can write scripts/makefiles to generate a distro/live CDs/etc. - speak up! You don't have to be a leader if you don't want to :) Regards, Andrzej ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI project reboot required
Hi, One thing to keep in mind that OI has (or at least, had) the largest install base of any OpenSolaris derived distro, thanks to the fact it is upgrade compatible with OpenSolaris. If you don't maintain that, then there is no point in continuing with OI - you may as well start with OmniOS. My personal view was that I wanted OI to be to illumos what Debian was to Linux - a community maintained general purpose operating system. If we had managed to kick OI into shape with regular releases and up to date software, it might have had a bright future. It certainly had plenty of users. Alasdair On Thu, May 9, 2013 at 2:05 PM, ken mays maybird1...@yahoo.com wrote: Hello, 1. Provide an updated kernel userland (i.e. Illumos-gate, rev: 19e11862653b or higher). This allows people that use OI for server-based projects to stay in sync with Illumos development on a much wider scale. 2. Optionally, implement JDS updates already maintained by Milan from http://pkg.opensolaris.cz/osol/en/index.shtml. That is it. This also keeps most things consistent to other project work dealing with GNU/userland/spec-files-extra testing with = oi_151a7. You can do this with very minimal manpower and not need to rebuild components / entire consolidations as much (aka 'project overkill'). You can also just dump the updated packages in a IPS repo for testing and review. You don't necessarily have to 'make world' right off the cuff. Start small, then think big. Fact: Entire distribution projects like Tribblix, Milax/OpenSXCE, EON, and DilOS are maintained by 1-2 people. Hope that helped, Ken Mays -- *From:* Andrzej Szeszo asze...@gmail.com *To:* OpenIndiana Developer mailing list oi-dev@openindiana.org *Sent:* Thursday, May 9, 2013 4:01 AM *Subject:* [oi-dev] OI project reboot required Hi All (Instead of replying to a message in one of the other threads I thought I will create a new one.) Just wanted to say that I don't see a future for the project in its current form. There is simply too many packages and too much baggage for a handful of people to look after. I think the project needs a new vision and a reboot. If you have any ideas for the project and can write scripts/makefiles to generate a distro/live CDs/etc. - speak up! You don't have to be a leader if you don't want to :) Regards, Andrzej ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev -- Alasdair Lumsden http://www.everycity.co.uk EveryCity Managed Hosting Studio 18 Bluelion Place 237 Long Lane, London, SE1 4PU general: 020 7183 2800 support: 020 7183 2801 email: a...@everycity.co.uk Every City Limited Registered in England and Wales, No. 5689474 Registered Office: Roper Yard, Roper Road, Canterbury, CT2 7EX ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI project reboot required
On 05/09/2013 03:29 PM, Alasdair Lumsden wrote: It certainly had plenty of users. Still has. What needs to be done is stop bickering about stuff on the mailing list and starting pushing out releases. By that I don't mean that you or anybody else in the community is doing something bad - you did wonderful work. It's just that there's a lot of armchair experts who like to disagree on minutia and lose overview of the big picture. All users care about is: *) how stable is this release *) when's the next release *) for commercial guys: who do I blame when shit doesn't work (having paid for shit to work in advance is of course a given) The finer details of release engineering and project architecture is of course something to be debated, but probably not on a public forum. Cheers, -- Saso ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI project reboot required
On 05/09/2013 03:55 PM, mag...@yonderway.com wrote: On Thu, 09 May 2013 15:39:39 +0200, Sašo Kiselkov skiselkov...@gmail.com wrote: The finer details of release engineering and project architecture is of course something to be debated, but probably not on a public forum. Why not? Cause not everybody's opinion is equally well informed. I for my part don't give a fuck if the control information packages I'd maintain for OI were kept in Makefiles or spec files, the bug tracker was Bugzilla or Trac or whatever minor technical knit. I need to know how I start working on packages, who to talk to and where to get the details of how the process works. I don't need to improve the process, I only need to know it. Cheers, -- Saso ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI project reboot required
On Thu, 9 May 2013, Peter Tribble wrote: And also what differentiates you from other offerings. Specifically, thinking about other similar projects, what would OI offer that you wouldn't get from OmniOS (which I regard as the closest distro)? The main differentiators appear to be the ability to log into a graphical multimedia desktop (similar to Linux) and the ability to install and execute most existing Solaris binaries. I had a completely different vision - both directionally and technically - and ended up completely throwing away all the build system(s), and the entire packaging and install infrastructure. Having to largely reinvent a whole mass of functionality for Tribblix from scratch was orders of magnitude easier than using what was inherited from OpenSolaris. The Tribblix approach is likely a good one. Start off with a good smaller core and then add more sophisticated features via packages. This requires a new distribution though. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI project reboot required
On 2013-05-09 16:02, Bob Friesenhahn wrote: The Tribblix approach is likely a good one. Start off with a good smaller core and then add more sophisticated features via packages. This requires a new distribution though. Two words: backwards compatibility ;) Reinventing the wheel from scratch doesn't mean that it magically becomes incompatible and should be renamed and called a new project. If it is round, and weight can be put on an axle, it is still a wheel. As long as the administrative (end-user) interfaces remain in place, the ways we get there can change. In case of OI, as a multipurpose distribution which is an upgrade path for IPS-based OpenSolaris (and older OI) systems with SVR4 support, there is just a certain set of properties that should remain in place. Whatever the process is under the hood - we don't really care, all it should do is create the IPS packages and spit them out via pkg.oi.o repository server. I am not convinced that a new system rewritten from scratch won't be able to make an output indistinguishable (to a reasonable compatible extent) from whatever the current ugly difficult process produces. In short, change of the process does not require that this becomes a new distro. Especially since the impact on deployments would be minimal: there's just a few people that know the current process and practice its black magic, and are allegedly fed up with doing so and have little personal attachment to have that remain in place. If a functionally equivalent compilation technique appears, which a wider audience can use, there are nearly zero systems that must be converted to it and won't know that they should do so (i.e. flag-day changes). Likely, those systems that fulfill this role now would be the ones that will implement the new method first - if not develop it directly ;) //Jim ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI project reboot required
Fundamentally, the question you all should be asking is, what is the purpose of the project? The problem with OI has always been lack of a clear vision. The original purpose, to be a free community-run clone of Solaris 11, had no future. It was doomed to fail because it was an attempt to follow a leader who who did not want to be followed and was making changes that specifically made such an attempt extraordinarily difficult (like changing closed source dependencies) -- and the leader had also itself lost its vision, or at least altered it, such that it was never going to the same places that the folks behind OI wanted to go. I'm a big fan of trying to build cool and interesting technologies. Of innovation. Can OI innovate? Its not clear to me. Thankfully, *illumos* is certainly innovating. Other distros are innovating. Some in cases that lead very very far from the vision or model of OI. (SmartOS has led the way the most -- challenging many of us to rethink how we manage systems, in ways that ultimately have been extremely beneficial for those who were able to cross the cognitive hurdles presented by its new administrative model.) Can OI find a niche that sets itself apart from excellent options like SmartOS and OmniOS? Is there even a purpose to such differentiation? I don't know the answers to these questions. I do think that there is always going to be substantial tension between those who want to keep compatibility with their old stuff (whether the old stuff be legacy closed source applications, scripts that they wrote 15 years ago, decades old SPARC kit, ancient laptops, or 10 Mbps ethernet with AUI transceivers), and the people who want to innovate and explore modernization (Gary Mills' work to support login names 8 characters is a prime example of this tension). Its a tricky balance to find, and many of the hardest working people (Martin Bochnig comes to mind, for example) are firmly in the don't break my old stuff camp. The problem is that this camp is inherently change resistant -- and yet fundamentally OI was already too different from previous Solaris releases to satisfy those folks. Where this is leading me is this…. 1. Is there enough market demand/interest/skills/resources to justify a legacy style distro (something more like Solaris 10 than Solaris 11/OI, including SPARC distro support, etc.) It seems there is almost enough talent here -- perhaps if those forces worked together more collaboratively we'd see something good come about? 2. Is there a need for a more forward looking distro apart from the work being done in OmniOS? (To be clear, I'm not affiliated with OmniTI in any way -- I just hate to see pointless duplication of effort) Again, I don't know the answers to these questions, but I *strongly* believe that anyone thinking of stepping up to reboot the OI project (or create any new one) needs to have a much clearer vision -- and needs to be a strong enough leader to more or less enforce this vision. A democracy here won't work -- precisely because of the pressures I've already indicated. In my opinion it would be better to spawn two separate projects, each of which creates value to serve their adherents, than to have single project that cannot make any progress because of the inherent inability to resolve the differences between the two main camps. What I *will* say is this… regardless of what happens, I'm very pleased that illumos will carry on -- and continues to be a home for innovation, thanks in no small part to the efforts of folks like Joyent, OmniTI, Nexenta, DEY, and perhaps many others who've been working more quietly. I'm incredibly grateful to the team that put OI together -- it filled an important gap in the ecosystem, and contributed significantly to the uptake of illumos -- so regardless of what ultimately becomes of the project, a big thank you to the various parties who put it together. - Garrett On May 9, 2013, at 1:01 AM, Andrzej Szeszo asze...@gmail.com wrote: Hi All (Instead of replying to a message in one of the other threads I thought I will create a new one.) Just wanted to say that I don't see a future for the project in its current form. There is simply too many packages and too much baggage for a handful of people to look after. I think the project needs a new vision and a reboot. If you have any ideas for the project and can write scripts/makefiles to generate a distro/live CDs/etc. - speak up! You don't have to be a leader if you don't want to :) Regards, Andrzej ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI project reboot required
Privet ! On Thu, May 9, 2013 at 1:45 PM, Jim Klimov jimkli...@cos.ru wrote: On 2013-05-09 13:06, Andrzej Szeszo wrote: The process you have described sounds a lot like OI's original plan. It didn't work out. There was too much baggage. No one was willing to spend time learning it. It was just too ... ugly. It's possible to try it differently this time :) One of the main reasons why it is complicated to build OpenSolaris, is definitely IPS itself. Rather than just the fact, that almost every of the consolidations has different ways in which they implemented their build, with different locations for Makefile.master, a different directory hierarchy versus even with pkgbuild and .spec files. To resolve deps, that's cpu intensive like little else and also error prone. One way or another, in these consolidations we have tons of source code, which, one way or another, need a process to build them. Even if the system of build scripts, spec recipes, makefiles and so on would be changed to something else, just to develop this new build logic and to check validity and comparability of the resulting packages we (individual developers) need to be able to build it the old way and the new way (whatever that would be). AFAIK, very few people know what to do to create the binaries and packages in the old techniques, which makes it problematic for others (not in the know) to start improvements or from-scratch rewrites. Starting in 2007 I had the same dream. And I even started and made some progress (still have it somewhere in my backup archives). My idea was, to merge all consolidations (for MartUX) into one single Makefiles system, namely into that of Sun's X11 group, as developed by Alan Coopersmith and team on the basis of OS/Net's Makefiles. I think Moinak Ghosh has worked on something similar even before me (as I learned later), and has come further. So I stopped the effort. I recall that he released this on belenix.org a long time ago. If I'm corerct he once called it DistroGenerator (don't confuse this with DistroConstructor, which, btw, HE also invented long before Sun took err stole it).The first so called Indiana was in fact BeleniX in 2007!!! And is was completely unfair and injust that Sun had hired that Ian Murdock destructor purely for marketing reasons alone, and that he was permitted to give the stolen BeleniX his name. This is the primary reason why those that remember all this (including myself) could never be happy with the name ind_IAN_a. Of course, some architectural overview or general framework for all consolidations of what we want to achieve as the new build system (i.e. conforms to this list of technical requirements: A, B, C... Z) would be needed. I may be wrong to think that ability to build the whole beast in the old ways is useful to make the new building technology, but lack of it also hinders an ability to make new spins of the whole OI distro or just updated package repos, as one other commonly-requested useful result of the overall OI project. So far most users can rebuild the kernel part (illumos-gate) of their installations and third-party code like updated sendmail, apache or whatever they need to update, rebuilt and installed in traditional unpackaged ways into alternate paths or even overriding the system binaries, but that's about it. And this is wrong, especially for SOHO farms of several OI machines or zones which could otherwise reuse the in-house updated packages automatically and properly :) I made bad experiences with IPS. With SVR4 all this is a ton (1000kg!) easier, more transparent, and more fine grained. You can touch every package, even inside the repo, by hand. It is not a database like monster, black box or even rather black hole, that IPS appears to be, in my personal view (sorry about that). Example: If you want to change a single package, maybe even a single file, or an arbitrary number of packages, it is always easy, transparent and doable: http://svr4.opensxce.org/sparc/5.11/ For example, if a new Firefox comes out, many users care about the newest version, yeah. Here is the SVR4 way: 0.) Delete http://svr4.opensxce.org/sparc/5.11/sunw_firefox-18.0%2cREV%3d110.0.4.2013.01.10.17.25-SunOS5.11-sparc-SUNW.pkg.gz 1.) Build FF or take the Oracle supplied redistributable bins from China and create the package by just hitting make install in my prepared SUNWfirefox subdir, this creates the SUNWfirefox package 2.) With a plain flat miniscript from another dir convert it into the pkgtool.net format 3.) Copy over or sftp upload the new file to http://svr4.opensxce.org/sparc/5.11/ 4.) ssh into http://svr4.opensxce.org/sparc/5.11/ and run bldcat (if the server hosting http://svr4.opensxce.org/sparc/5.11/ is not a Solaris machine, just do the previous steps but take your local mirror of http://svr4.opensxce.org/sparc/5.11/ and run bldcat there, then simply upload the two catalog files to the real repo site. To
Re: [oi-dev] OI project reboot required
Having the server is key to the linux / unix world. Portability is the newer direction that several distros are moving toward so a multi-platform architecture is key. Would we be able to include a few compilers (C / C++ etc. ) stock for when the driver is not available after initial install? I have previously worked on network architecture and system monitoring. Lemme know where / when I can help :-) James R. M. Winter ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI project reboot required
On May 9, 2013, at 1:05 PM, Milan Jurik milan.ju...@xylab.cz wrote: Hi, OK, so start yet another distro :-) OI needs one thing it does not have - release engineering team. Jon is too busy and I cannot do that. I am happy to work on some things from time to time for fun but my job is more and more time consuming and I enjoy it (and my private life also). And to be fair, with total lost of interest in desktop systems in Illumos by core team, I have less and less motivation to work on it. I'm not sure who the core team for illumos is -- I'd guess I'm part of it, since I started the darn project, but we don't have any definition of core team, apart from the Developer Council. As the developer council is made of up some of the most widely recognized illumos/Solaris leadership, and almost *never* actually makes any official decisions, its hard to say there is any group of people that you'd say has no interest in desktop systems. What *is* true is that there is zero commercial investment in illumos on the desktop, while there is substantial commercial investment on server side innovation. This is not a bad thing -- we (the commercial investors in illumos -- the folks who use and develop it as part of our day jobs) simply recognize that like any tool, illumos has some tasks that it is well suited for, and others where other tools make more sense. Some may attribute this type of thinking to nefarious purposes, but it really comes down to something much much simpler. Economics. Maintaining a desktop capable system is *hard*. Making one that can compete against capable offerings from Apple, Microsoft, Google, and Canonical is *really* hard. And *those* guys are fighting a battle to keep the very desktop itself, relevant, in the face of tablet devices. And so how do you make a commercial case for investing in illumos on the desktop? There are some specious arguments for supporting legacy uses, facilitating developer adoption, etc., but none of them have actually borne fruit, and there are known non-trivial hurdles for such cases. Indeed, the very failure of OpenSolaris itself can be cited as an example of this failure -- Sun with not inconsiderable investment and resources, was unable to make a commercially viable desktop based on Solaris technology, even though they were clearly willing to do so even at the *expense* of their otherwise lucrative server business. So most of us have learned from those failures (even though they may not have been our own), and moved on. (Admittedly there are still people in Oracle working on the Solaris desktop, but AFAICS that mostly amounts to acting as a gateway to Microsoft systems via Rdesktop, or acting as a glorified webtop / kiosk front end. And I think you'd be hard pressed to show those efforts as being profit centers within Oracle. They're mostly seen as supportive of Oracle's other more core business needs.) Upshot, *today* anyone who thinks there is a commercial future in illumos on the desktop is probably smoking something. There are a few people who would be willing to pay for it, but it needs more than a few dozen people willing to pay a couple hundred dollars (more often substantially less) to make this a viable and interesting (economically) venture. What that means is that illumos desktop technologies have been relegated, at least for the time being, to the realm of hobbyists. In some cases, very talented hobbyists -- even in some cases people who work professionally on illumos server technologies --, but hobbyists nonetheless. All this said, I'd love for someone to come up with a believable, realistic story for making a commercial desktop product on illumos. I think it would be good for illumos. But in the absence of more compelling evidence to the contrary, I'd question the sanity, or sobriety, of anyone who seriously thought that commercial investment in illumos on the desktop made sense today. - Garrett ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI project reboot required
On Thu, May 9, 2013 at 10:05 PM, Milan Jurik milan.ju...@xylab.cz wrote: enjoy it (and my private life also). And to be fair, with total lost of interest in desktop systems in Illumos by core team, I have less and less motivation to work on it. Hi Milan, good observation. Sadly I must agree with you: While Oracle sees Solaris only as wrapper for their database, the Illumos sponsors only seem to be interested in selling their x64 JBOD solutions and servers. Everything else is just in the way and doesn't deserve any backing, especially not financial support. I experience this all the way along with SPARC, OpenSXCE or whatever is of little commercial use to these corporations. Forget individuals like myself or the other hardcore enthusiasts. But especially I'm not sure if this serves the broader Solaris user base all too well, either. Fortunately Garrett is more interested in keeping Solaris a multipurpose OS. But only money pays developers. And so only it is able to make a substantial change. Regards, Martin ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI project reboot required
On Thu, 9 May 2013, Garrett D'Amore wrote: Upshot, *today* anyone who thinks there is a commercial future in illumos on the desktop is probably smoking something. There are a few people who would be willing to pay for it, but it needs more than a few dozen people willing to pay a couple hundred dollars (more often substantially less) to make this a viable and interesting (economically) venture. There is little commercial future in the desktop for Linux distributions as well yet almost all of them have a graphical desktop. Availability of a graphical desktop is seen as a requirement for common acceptance. Much/most of the graphical desktop development taking place for Linux does not seem to be done by the companies which popularly peddle it (e.g. Canonical has been more of a desktop packager except for its useless Unity). The argument about no commerical future is becoming worn out and tired since that (commercial purpose) is not why OpenIndiana/Illmos users want to log into a graphical desktop. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI project reboot required
Precisely. Cheers Dave Bob Friesenhahn bfrie...@simple.dallas.tx.us wrote: Availability of a graphical desktop is seen as a requirement for common acceptance. Much/most of the graphical desktop development taking place for Linux does not seem to be done by the companies which popularly peddle it (e.g. Canonical has been more of a desktop packager except for its useless Unity). The argument about no commerical future is becoming worn out and tired since that (commercial purpose) is not why OpenIndiana/Illmos users want to log into a graphical desktop. -- Sent from Kaiten Mail. Please excuse my brevity. ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI project reboot required
On 2013/05/09, at 17:09, Martin Bochnig mar...@martux.org wrote: On Thu, May 9, 2013 at 10:05 PM, Milan Jurik milan.ju...@xylab.cz wrote: enjoy it (and my private life also). And to be fair, with total lost of interest in desktop systems in Illumos by core team, I have less and less motivation to work on it. Hi Milan, good observation. Sadly I must agree with you: While Oracle sees Solaris only as wrapper for their database, the Illumos sponsors only seem to be interested in selling their x64 JBOD solutions and servers. Everything else is just in the way and doesn't deserve any backing, especially not financial support. I experience this all the way along with SPARC, OpenSXCE or whatever is of little commercial use to these corporations. Forget individuals like myself or the other hardcore enthusiasts. But especially I'm not sure if this serves the broader Solaris user base all too well, either. Fortunately Garrett is more interested in keeping Solaris a multipurpose OS. But only money pays developers. And so only it is able to make a substantial change. Oracle seems to be taking good enough care of the Solaris desktop on its end. I'm sure it's a peripheral part of their overall effort, but somebody at Oracle is keeping hardware support up to par and fixing desktop bugs. It's not the aforementioned commercial case and it's clearly not being targeted at desktop users, but for someone like me who cares more about ZFS and a good terminal emulator than about Netflix, it's perfectly adequate, and I don't think it's fair to peg Oracle for neglecting the desktop. Clearly, the OI desktop usage case is not going to be a commercial one, so the only question is whether there are enough interested volunteer developers to sustain it. Various Linux distributions have shown that a commercial usage case is not the only way to sustain a general-purpose graphical OS, but they have also had a critical mass of users and developers to support the project instead. I don't know what the long-term answer to that question is for OI, but for what it's worth, the one thing that keeps me off of it as a desktop platform is a CJK text bug in Illumos and not an issue with OI itself. Ian Johnson ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI project reboot required
On Fri, May 10, 2013 at 1:09 AM, Ian Johnson ian...@yahoo.co.jp wrote: snip Oracle seems to be taking good enough care of the Solaris desktop on its end. I'm sure it's a peripheral part of their overall effort, but somebody at Oracle is keeping hardware support up to par and fixing desktop bugs. It's not the aforementioned commercial case and it's clearly not being targeted at desktop users, but for someone like me who cares more about ZFS and a good terminal emulator than about Netflix, it's perfectly adequate, and I don't think it's fair to peg Oracle for neglecting the desktop. Ok, for x64. But what about SPARC graphics driver support versus text-only? All their JDS work that they still seem to keep in sync for both x64 and SPARC is of little value, if you have no gfx drivers to start up X11. This unbelievable direction was admittedly already taken before Oracle took over, with the removal of Xsun in 2009. What about the drop of sun4u in 2010 starting with Oracle Solaris Express? sun4u servers and even the U25/U45 workstations were still sold until 2008 and (the last sun4u big iron servers until 2009). Not to mention Fujitsu, which is still selling its sun4us line. I know, there is a secret I cannot post in public. But to the general users ... Anyways, the 'W' in the original Sun stock ticker symbol SUNW stood for guess what: Workstations. And then just 1 or 2 years later such complete drops??? Is that fair? If I was a manager who spent a few hundred thousends or millions in a top 500 enterprise's infrastructure, identify a single reason why I would not migrate to Linux x64 after such a blow. BTW: Oracle also removed IA32 support. So if you want to run Solaris 11 on your PentiumIV Laptop, you cannot do this. Also consider the removal of all so called legacy x86 gfx driver from Xorg, in 2010. Only as an example. With Linux you can still use much of the slightly older hardware out of the box (without building your own distro). Just my 5 Kopekes ... %martin ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI project reboot required
On May 9, 2013, at 4:00 PM, Bob Friesenhahn bfrie...@simple.dallas.tx.us wrote: On Thu, 9 May 2013, Garrett D'Amore wrote: Upshot, *today* anyone who thinks there is a commercial future in illumos on the desktop is probably smoking something. There are a few people who would be willing to pay for it, but it needs more than a few dozen people willing to pay a couple hundred dollars (more often substantially less) to make this a viable and interesting (economically) venture. There is little commercial future in the desktop for Linux distributions as well yet almost all of them have a graphical desktop. Admittedly true. And yet, most of them *started* on the desktop. Linux's roots are in the desktop. Most of those distros took off because they had a groundswell of support from developer users who wanted it on the desktop -- they didn't have servers, and options like VMware simply didn't exist at the time. I'd argue that this is largely an artifact of history. I would be entirely *unsurprised* if distro vendors like RedHat and Oracle simply *ditched* their desktop support at some point in the future -- its clear to me at least that folks aren't running those distros on the desktop. In fact, I can't think of *anyone* who's paying for a desktop OS that doesn't come from either Apple or Microsoft. Availability of a graphical desktop is seen as a requirement for common acceptance. Historically true, but I seriously doubt it now. SmartOS is the counter example from this community. I think there are others. For example, OpenBSD was highly popular for a long time for its security emphasis, but I don't know *anyone* who ran it on a desktop. The widespread availability of virtualization like VMware, VirtualBox, and Parallels means that there is little need to take over the user's desktop to provide a reasonable environment. Most people these days develop using SSH, etc. The folks I know who use Linux would, apart from a few extremists, not care whether the desktop ran Linux, FreeBSD, or Solaris, as long as it Just Worked and provided a familiar UNIX-like backend. (I contend that these principles have lead strongly to the uptake of MacOS in the developer community…. I use an Apple laptop for my own environment, even though I wouldn't *dream* of using MacOS in a server capacity.) For me, Terminal.app and ssh is along with VMware gives me everything I need for doing cool things with illumos on my desktop. I explicitly *disable* the graphical login on illumos. :-) Much/most of the graphical desktop development taking place for Linux does not seem to be done by the companies which popularly peddle it (e.g. Canonical has been more of a desktop packager except for its useless Unity). Only partly true (Qt is the counter example). But yes, a lot of the desktop development in Gnome and company is done by community members who are passionate about this. And guess what -- almost all those guys are Linux bigots. There's a huge trend in those spaces to adopt technologies that are Linux-specific, to the point of near active hostility towards other FOSS. That creates a huge barrier for leveraging their efforts. Do we have the kind of volunteerism here to take up a duplicate effort? And why just duplicate? If we have *that* kind of interest and volunteerism, I'd recommend actually doing something *cooler* and better. Of course, that flies in the face of legacy compatibility…. The argument about no commerical future is becoming worn out and tired since that (commercial purpose) is not why OpenIndiana/Illmos users want to log into a graphical desktop. Worn out and tired it may be, and *yet* people complain about the lack of leadership and progress. I don't know about you, but I have to pay for housing, groceries, and gasoline (among other things). So I have to work at things that pay the bills. I am lucky enough that this maps well to things that are also interesting to me. Maybe its unfortunate that folks aren't finding ways to make a living at this, so that a developer community will spring up around it. But more constructive than whinging about it will be to find ways to either a) make a commercially viable case for it so people can get paid to work on it, or b) lead a volunteer effort to make this work. The problem with b is that its a very large, and often thankless, job. People spend more time complaining about broken things on the desktop, than they do actually helping fix things. Individual leaders get exhausted, and move on. This is a recurring theme in this community -- Nexenta desktop, StormOS, AuroraUX, OI, etc. So, it comes, for me at least, back to a. Figure out a way to make a commercially viable story so that you keep a small group of developers paid. Right now, I don't know of any such story, and when I bring this up, the responses like yours Bob, amount to nothing more than putting your head in
Re: [oi-dev] OI project reboot required
For what it's worth, I only need Xorg, xpdf and xterm to take care of my graphics needs. Everything that doesn't involve coding happens on linux, mac and winxp. As long as a distro can support Xorg, it is viable for me. So whatever you guys do, please don't remove the basic graphics capability! On May 9, 2013 7:20 PM, Garrett D'Amore garrett.dam...@dey-sys.com wrote: On May 9, 2013, at 4:00 PM, Bob Friesenhahn bfrie...@simple.dallas.tx.us wrote: On Thu, 9 May 2013, Garrett D'Amore wrote: Upshot, *today* anyone who thinks there is a commercial future in illumos on the desktop is probably smoking something. There are a few people who would be willing to pay for it, but it needs more than a few dozen people willing to pay a couple hundred dollars (more often substantially less) to make this a viable and interesting (economically) venture. There is little commercial future in the desktop for Linux distributions as well yet almost all of them have a graphical desktop. Admittedly true. And yet, most of them *started* on the desktop. Linux's roots are in the desktop. Most of those distros took off because they had a groundswell of support from developer users who wanted it on the desktop -- they didn't have servers, and options like VMware simply didn't exist at the time. I'd argue that this is largely an artifact of history. I would be entirely *unsurprised* if distro vendors like RedHat and Oracle simply *ditched* their desktop support at some point in the future -- its clear to me at least that folks aren't running those distros on the desktop. In fact, I can't think of *anyone* who's paying for a desktop OS that doesn't come from either Apple or Microsoft. Availability of a graphical desktop is seen as a requirement for common acceptance. Historically true, but I seriously doubt it now. SmartOS is the counter example from this community. I think there are others. For example, OpenBSD was highly popular for a long time for its security emphasis, but I don't know *anyone* who ran it on a desktop. The widespread availability of virtualization like VMware, VirtualBox, and Parallels means that there is little need to take over the user's desktop to provide a reasonable environment. Most people these days develop using SSH, etc. The folks I know who use Linux would, apart from a few extremists, not care whether the desktop ran Linux, FreeBSD, or Solaris, as long as it Just Worked and provided a familiar UNIX-like backend. (I contend that these principles have lead strongly to the uptake of MacOS in the developer community…. I use an Apple laptop for my own environment, even though I wouldn't *dream* of using MacOS in a server capacity.) For me, Terminal.app and ssh is along with VMware gives me everything I need for doing cool things with illumos on my desktop. I explicitly *disable* the graphical login on illumos. :-) Much/most of the graphical desktop development taking place for Linux does not seem to be done by the companies which popularly peddle it (e.g. Canonical has been more of a desktop packager except for its useless Unity). Only partly true (Qt is the counter example). But yes, a lot of the desktop development in Gnome and company is done by community members who are passionate about this. And guess what -- almost all those guys are Linux bigots. There's a huge trend in those spaces to adopt technologies that are Linux-specific, to the point of near active hostility towards other FOSS. That creates a huge barrier for leveraging their efforts. Do we have the kind of volunteerism here to take up a duplicate effort? And why just duplicate? If we have *that* kind of interest and volunteerism, I'd recommend actually doing something *cooler* and better. Of course, that flies in the face of legacy compatibility…. The argument about no commerical future is becoming worn out and tired since that (commercial purpose) is not why OpenIndiana/Illmos users want to log into a graphical desktop. Worn out and tired it may be, and *yet* people complain about the lack of leadership and progress. I don't know about you, but I have to pay for housing, groceries, and gasoline (among other things). So I have to work at things that pay the bills. I am lucky enough that this maps well to things that are also interesting to me. Maybe its unfortunate that folks aren't finding ways to make a living at this, so that a developer community will spring up around it. But more constructive than whinging about it will be to find ways to either a) make a commercially viable case for it so people can get paid to work on it, or b) lead a volunteer effort to make this work. The problem with b is that its a very large, and often thankless, job. People spend more time complaining about broken things on the desktop, than they do actually helping fix things. Individual leaders get exhausted, and move on. This is a
