Re: [oi-dev] Resignation
The issue of governance has been talked about before, so I'll just summarize the decisions the Illumos community reached. Governance causes way more problems than it solves. For example, it adds a political aspect to the community, creating clear winners and losers. This leads to rivalry, factions, and the like. This can cause schisms in the community. I used to be a Gentoo user years ago, and I watched the community tear itself apart over petty politics. For example, technological decisions were on the basis of personal egos, feuds, and certain devs' personalismo. As opposed to technical merits and objective measurements. All of this happened because the founder of Gentoo, left the project and left a governing-board in his place. The Illumos community believes --- and please correct me if I'm wrong --- that those who write the code have the power to decide, to disagree, and so on. Those who are merely consumers of the code don't get much say in development decisions. Hence, there is no need for governance. Code rules. On Sun, Sep 7, 2014 at 2:24 AM, Peter Firmstone j...@zeus.net.au wrote: Hi, It appears your developer has reached the point where he must quit to get his point accross. Illumos doesn't have any stable releases and it sounds like developers are having issues with that. Also it sounds like experimental features are being introduced into the Illumos kernel and these components also sound like they belong in a distribution rather than the kernel. If Illumos isn't prepared to listen, maintain a stable kernel version here on OpenIndiana, give it a version, track the changes and make it available to other distributions, treat Illumos like experimental code, contribute fixes back to Illumos. Again: Create kernel stable releases, leave out the experimental stuff (if it's not part of the kernel and can be provided as an optional package, leave it out). Eventually Illumos will come around, if not, only integrate what makes sense and ignore what doesn't and continue to contribute fixes upstream. It's not worth loosing developers over external project issues. Also some other ideas, based on observations: 1. Document your governance model, I'm a member of an Apache project, we have clear rules that assist in resolving differences 1. We have PMC committers and members, we have lazy concensus and voting, if there's disagreement, we vote after debating (yes people are passionate), PMC votes are binding, members votes are non binding (see the apache rules). 2. Also, doers decide. 2. If there are a lot of users, but not many developers, allow users to make donations against issues, then developers can earn these donations by completing work. 3. Actively encourage users to donate (Debian has a donation system, adopt something similar), eg every time someone downloads an ISO, provide the option to donate. Regards, Peter. On 08/11/14 08:22 PM, Milan Jurik wrote: / Hi, // // based on the current situation with OI - lack of old OI non-hipster // branch - and because of bad situation (according my view) of Illumos - // like stupid ideas to include large chunks of 3rd party code to ON gate // which makes it unmaintainable (why did Sun and Oracle invest so much to // remove OpenSSL, SunSSH and ksh from ON gate? See how bad is ksh in // Illumos and how old is Illumos SSH) I have to finalize my decision about // my participation. Illumos and its distros are not for me anymore. /I think idea behind that is to have current SSH for illumos, and later to remove it from illumos. But It is yet to be determined are there SPARC hardware crypto support inside new solution (that is present in SunSSH), because that would be very short-sighted if it is not. GDA even tried to remove UltraSPARC T1/T2 support (?). illumos is tailored by few large companies wishes , that actually pay developers, but it is always possible to contribute. / opensolaris.cz will be up for some time but no more updates to JDS and // SFE. Do not hestitate to contact me in private if you think I still know // something but I will not spend more time on the lists. // If anybody is interested in some older bits then: // // http://www.opensolaris.cz/builds/illumos-wpa-enterprise/webrev/ // http://www.opensolaris.cz/builds/tnf/webrev/ // http://www.opensolaris.cz/builds/ext2-merge/webrev/ /That sounds a bit interesting, since Hipster is much more BSD-style development by few commiters and yet I understand you left for BSD. Hipster broke code consolidations some time ago and without actual numbered versions that are pushed, it is hard to test and debug many new bugs. (And without resurrected 'updatemanager' to update regularly) There is large disproportion between number of people wanting just to install and use OI and illumos distributions and those that want to maintain and work
Re: [oi-dev] [developer] GSoC? Decision time....
I'm replying to _everyone_ not just Kieth. It seems this discussion spans several lists... Just to throw in some of my personal experience. While a freshman, I had only one computer at my disposal. Running OpenSolaris (later OpenIndiana) was very painful. I couldn't NOT run it because it was the only OS with ZFS, DTrace, and Zones. From the perspective of having only one machine, Illumos is a mixed blessing. It cripples you by not allowing you to easily do desktop-ish things, but gives you an __amazing__ platform for (especially C) programming and data storage. I think that the Illumos-desktop folks see the _potential_ of what Illumos _could_ be on the desktop and want to make it happen. Long story short, I changed my strategy from zealously trying to turn OI into _the one true OS_, into a combined-systems approach: I have a SmartOS server that holds all of my data, zones, and KVMs, and that I use for 90% of my programming (over SSH). I have three client systems: a Mac laptop for normal consumer-things, a Thinkpad running FreeBSD for client-side DTracing of desktop apps and hooking up to my server, and an outdated Ubuntu tower for anything the other systems don't cover. I often code on SmartOS and then deploy on FreeBSD and my Mac (with minor changes). Even if the Illumos-Desktop effort reaches application-parity with Linux, there is still the major problem of device drivers. Linux (even FreeBSD) has a huge advantage here, that is difficult to match without a large supply of enthusiastic device-driver writers that all have diverse hardware. OI hasn't been able to recognize my WiFi card for years, and SmartOS can't even boot --- it's not exactly level playing field. Having multiple, specialized systems while not _physically_ economical, is very economical in terms of _time_ --- you don't have to waste it reinventing so many wheels. Of course this approach is broken over bad networks --- which sadly are too common in parts of the world. That said, a desktop variant of Illumos could leverage the clearly innovative and high-quality kernel tech in some cool ways, but I can't see this making a dent in the market share of Linux --- let alone that of Mac, iOS, Windows, or Android. Desktop-Illumos (OpenSolaris) was useful around 2006ish as a way to get young people (I was still in highschool) to use and understand the benefits of DTrace, ZFS, Zones, etc. It was a great gateway. I think that the Illumos project doesn't need a desktop-variant per-se. It needs a _gateway_ through which it can recruit the next generation of systems programmers for the project. Seeing how the trend is that tablets are devouring desktops and laptops for most of the population, I think Illumos needs a new gateway strategy through which it can easily recruit young blood. Just as OpenSolaris (the distro) was able to frame the benefits of its unique technologies in the desktop context, I think that Illumos needs to find a way to frame the benefits of its unique technologies in the context of whatever 16-year-old computer-enthusiasts use these days to get things done / have fun / etc. Anyway, I'm _not_ convinced that GSoC is such a gateway... Cheers, -Nick On 2/14/14, Keith Wesolowski keith.wesolow...@joyent.com wrote: On Thu, Feb 13, 2014 at 11:52:53PM -0500, Gordon Ross wrote: I'm not sure if you were aware of this, but the GSoC program organizers have in the past expressed a prefer that related projects band together with shared applications. That makes less work for them. I recommend we tell GSoC in our application that we will entertain projects using any and all illumos distributions. OpenIndiana is one of several good choices. I see no harm in mentioning their inclusion. Would you be more comfortable if we mentioned other open-source distros as well? I'll turn that on its head: would everyone else be comfortable with the addition of SmartOS-specific work to the projects list? I certainly would not be, if I were a partisan of a different distribution. And I don't even consider most of the projects the OI folks have listed as being in any way related to the development of an operating system (nor would many SmartOS-specific projects I might come up with). But I guess that's just me. Bluntly, leading with OI or treating it as special is thoroughly and uncompromisingly insane. Pretending that, in 2014 no less, achieving desktop application parity with 1997 GNU/Linux is an important goal in operating systems development probably covers half the syndromes described by the DSM-5. In the community I *thought* we were a part of, that's a nonissue, because the insanity is kept off to the side, separate from the core effort and merely one consumer among equals. To each his own. Live and let live. What I'm learning here is that many people don't see things that way, and want to explicitly define illumos and OI as having a single, shared vision. If that's what's happening here, I'll be aboard
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
Re: [oi-dev] Compiler migration #2
All good points. Just want to chime in and say that for userland C code development, gcc3 is adequate. I don't think anyone will see some huge, practical benefit from a bleeding edge C compiler. For C++11 development, it seems that there is no choice but use the latest and greatest. It's a shame that major apps are written in C++ and not C (like firefox). Although I do have a question. If gcc3 is deemed more desirable than gcc4 because it generates code that can run on i386, and isn't specialized, then why did the Illumos engineers switch the kernel compiler to gcc4 from sunstudio, and not to gcc3 from sunstudio. Thanks. On Sun, Jan 27, 2013 at 9:10 AM, Jim Klimov jimkli...@cos.ru wrote: On 2013-01-26 20:57, Bob Friesenhahn wrote: GCC 4.4 does not produce code for modern CPUs whereas GCC is continually enhanced to be able to produce code which targets modern CPUs. And in terms of prepackaged generic distribution that works on i386 and above, how can targeting of modern CPUs be a useful bonus and not a drawback? This was stressed by Luca's question: The only possible workarounds are build a recent gcc version yourself or use SFEgcc package, but the last option is not a viable alternative if your CPU is not SSE2-capable. So, not every users are able to use that compiler/runtime. I do know that there are solutions to my questions, and a couple of months ago we've discussed them (i.e. prebuilt HW-specific libraries lofs-mounted over a common filename, as is libc.so; or usage of UBE unified binary executables). I just wanted to raise this concern - that newest is not always the best when you deal with such heterogenous environments. I am for the optimized code running on machines and using their CPUs in the best possible manner, but this should be specially catered for by the distro - so that these newest CPUs aren't the only ones capable of running this distro ;) My 2c, //Jim Klimov ___ 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] Post 151 development
For what it's worth: I use a Mac on a laptop, OpenIndiana 147 on my ThinkPad and OpenIndiana 151 on a desktop. I've kept my thinkpad laptop on for weeks at a time. I've kept my desktop (when it was running OI 147) on for _over a year_. Both of those machines have 4GB of RAM. The desktop has an Core 2 Duo and the laptop has an intel i3. My macbook has an intel i7 and 4GB of RAM. I've had to reboot my macbook at _least_ once every 2 days. If it is running for 3 days it begins to swap like crazy and the spinning disk of doom appears. If Mac OS X, the _premiere_ desktop OS, can have this kind of instability (which is what it is), then I think OI is ahead of the curve as far as stability goes. Definitely trailing in user experience and aesthetics, but really, who cares? Do you want a show-horse or a work-horse? Just my 2 cents. On Fri, Sep 14, 2012 at 4:21 PM, Francois Dion francois.d...@gmail.com wrote: On Fri, Sep 14, 2012 at 3:40 PM, Jose-Marcio Martins da Cruz jose.marcio...@gmail.com wrote: Hello, ken mays wrote: 1. Is the latest JDS build something wanted by OI users and developers? This was one of the issues brought up, yet are we looking for a build of the most latest bits? This was done a few months ago for a build kit ISO so the work can transfer over. This way oi developers and users can test and review the latest JDS build and msy help redolve some issues in modernization of the distro as mentioned elsewhere. Although me too I'm one of those dinosaurs ... My needs are just a OS stable enough to run on a infrastructure server. Although I understand people wanting a full operational desktop environment, I don't care too much. For me (but it's just a personnal opinion), I want a openindiana environment just to be able to have a multi-windowing system (in fact many terminals on the console). For the moment, I work on two workstations, one running an old version of Solaris and the other running Linux (a laptop), but I surely can switch one of them to OpenIndiana. All this to say that, IMHO, it's important to release, as soon as possible, a stable server version. A stable desktop version may be released later. It's not a problem for me to add another desktop based workstation to work on and test. Regards, José-Marcio Not sure if anybody noticed, but OI 151 was released 1 year ago. Been running OI 151 as my primary desktop for 365 days. The definition of stable is relative, I'd say... Francois ___ 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] is there a vector for donating to OI?
On Fri, Sep 7, 2012 at 12:07 AM, garrett.dam...@dey-sys.com wrote: However I think OI and illumos have been fairly symbiotic -- indeed OI still builds upon the illumos base, and at the moment OI is the de-facto reference distribution of illumos. However, if OI is considering a different base -- say SchilliX -- then that would probably represent a significant rift. (I have some concerns about the topics of conversation on oi-dev of late; decisions to for example change the shell or filesystem layout can have broad ramifications. While a distro can choose to do as it wants, if there is that much difference between the base and the distro, then it will be much harder for the base developers to continue to use the distro as a reference.) The filesystem layout change discussion was initiated by me, because of a perceived inconsistency in the way Illumos stores binaries on disk. But Alan C has since cleared that up, and I no longer intend to pursue the idea. Instead I am now focusing my attention on pre-built (detached) zones, which would offer a true functional separation between groups of applications. As for the shell changes, I can't speak to the technical merit of that option as I haven't looked closely at that code or the problem(s) it claims to solve. I don't think anyone is going to rebase the OI distro on Schillix-ON just yet. If they did, that would create a significant rift not just between Illumos and OI but a rift within the OI community itself. - Garrett But that's just my opinion. Others are certainly free to disagree. ___ 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] Desktop Illumos Still Matters
On Tue, Sep 4, 2012 at 5:39 PM, Alasdair Lumsden alasdai...@gmail.com wrote: Hi All, On 04/09/2012 22:42, mag...@yonderway.com wrote: On Tue, 4 Sep 2012 13:25:39 -0500, Andrew M. Hettinger ahettin...@prominic.net wrote: One of the biggest issues here isn't that packages are particularly HARD to make with IPS (they aren't). It's that there are about three different approaches to it, and we need to get that standardized. Many of the packages are tied up in the consolidations, which DO seem to have a high barrier to entry. So what are the cliff's notes to the three different approaches, and is one of those approaches going to have a lower barrier to entry with still high-quality results? I'm thinking along the lines of a third party repo. I think there's a bit of confusion surrounding the terms involved. A consolidation is just a logical grouping of packages, such as JDS (Java Desktop System, renamed to just desktop on Solaris 11), SFW (Sun Freeware, replaced with userland in Solaris 11), etc. The big issue is that all the consolidations use different build systems. JDS uses RPM style spec-files similar to SFE (Spec files extra, a collection of 3rd party package recipes). SFW used a horrible Makefile based system. Userland is an excellent replacement for SFW, and uses Makefiles but in a way very similar to the FreeBSD ports tree or pkgsrc. I was attempting (with some others) to get OI updated in a giant leap forward replacing SFW with userland-gate (renamed to oi-build, and later illumos-userland after Nexenta started meddling). The idea was that we would try to focus on one single build system, the userland-gate style, which is the best of the lot. New software would go in there, and if we needed to update something in another consolidation, we would instead re-implement the recipe for it in userland-gate format. Unfortunately my approach with /experimental was quite ambitious and didn't quite work how we wanted. Jon Tibble is continuing to release new OpenIndiana builds (such as prestable 6, released *today* - http://wiki.openindiana.org/oi/oi_151a_prestable6+Release+Notes) and is advocating we do move to a single build system based on userland-gate, but more slowly and in a more controlled fashion. oi_151a actually already has a mini userland-gate/oi-build, which you can see here: https://hg.openindiana.org/sustaining/oi_151a/oi-build/ It's used to deliver some additional software and some bits from other consolidations have been moved there. It is probably where people should focus their efforts moving forward. Incorporations are probably what people are bitching about, which are there to provide lockstep upgrades between known working version sets of software. entire is the best known incorporation, which with each release locks all system software at a particular version. Incorporations are needed to prevent your system getting shafted. Lets say you are on oi_148, and in oi_151a we introduced some new software called foo. Foo depends on version 2.0 of bar. oi_148 delivers bar version 1.0. Without incorporations, if you pkg install foo it will upgrade bar no questions asked. Any software linked against bar probably just stopped working with libbar.so.1 changed to libbar.so.2. Incorporations present a challenge when you're developing software, because they stop you installing new versions of things. The way to get around this is to have empty incorporations on your development system, that way you are free to shaft your own install if you want to. It's like taking your seatbelt off. Well, incorporations sound like a great feature, imho. I guess the only problem is when two packages have mutually exclusive dependencies (foo depends on libbar.so.1, and baz depends on libbar.so.2). But even then, one can probably avoid this by using NGZ's, if the foo package isn't updated to use libbar.so.2, or if that software is no longer maintained by the original author. Incorporations map to consolidations, so SFW, JDS, etc each have their own incorporation. This means the incorporations have to be updated when you move software from one consolidation to another, eg from JDS to oi-build. Hope this makes sense. Alasdair ___ 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] Distro Constructor in NG Zone?
Has anyone tried getting the DC to work in an NGZ? Does anyone know if this feasible? Thanks. ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Desktop Illumos Still Matters
On Wed, Sep 5, 2012 at 4:18 AM, Jim Klimov jimkli...@cos.ru wrote: 2012-09-04 22:25, Andrew M. Hettinger пишет: was kept in /bin and /sbin that did not depend on anything. This was done to allow you to NFS mount everything else. IIRC the decision was made to go ahead and make them dynamicly linked because noone NFS mounts them anymore anyway, and it meant we had to keep both a simplified and full version of the programs. I think this will encounter many similar issues as that. If we are going back down this road, we could consider just delivering a /bin and /sbin we can use as you propose. It would have the advantage of bringing back this lost (albit rarely used) functionality. Well, as a little offtopic from desktopness, I have long ago posted an illumos RFE 829 to (again) support separatable /usr datasets, allowing one to compress much of the rootfs among other benefits of hierarchical environment (quotas, different storage and stuff). I've recently redone this on my laptop with no problems, following my own logs on wiki and bugtracker; the only substantial blocker was and is the /sbin/sh being a symlink to ../usr/bin/ksh or somesuch. System fails to boot itself when /usr is separate. Replacing this symlink with a hard copy of /usr/bin/bash (as /sbin/sh) does not break the system as much as I can see (several machines doing this for several months now) and allows to split /usr off into its own compressed dataset. There were some other nuances discussed in the RFE, like additions to the SMF service which mounts minimal root environment, and problems with beadm/zfsclone not setting compression attributes on clones, but I won't bother you here with those ;) I just wanted to stress that this is not a feature only useful for diskless NFS boots, but also on a PC or a laptop or a VM, especially with limited HDD or SSD space and/or IOPS/bandwidth (less reads = faster boots). Agreed. Also, I see that /opt and /usr/$consolidation overlap in terms of their purpose. For example we have /usr/X11. According to `man filesystem` /opt is meant to hold add-on/third-party software. If that's the case shouldn't X11 be in /opt/X11? Or should the convention be updated, so that we store the bundles or consolidation in /usr as is already being done? If sub-directories of /usr are separate datasets (like /usr/X11 is rpool/X11), that should make migration easier. Basically, I'm asking if it is better to have one convention (everything in /usr/$consolidation) instead of two (some things in /usr/$consolidation and others in /opt/$consolidation)? Also, for the SMF nits you ran into, _I think_ we can probably update the manifests so that SMF doesn't try to start, for example, gdm/X11 until it mounts rpool/X11 onto /usr/X11. Thanks. //Jim Klimov ___ 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] Desktop Illumos Still Matters
I think that Andrew want to use a unified build system, instead of the loose confederation of radically different systems that's currently in use. I agree. A unified build system is necessary. The only question is: what should it be? Makefile-based, like ports/pkgsrc/oi-build? specfile-based? tcl-base like macports? shell-based like Gentoo's and Exherbo's? python-based like conary? I'm fine with any of the above (as well as any that I've not mentioned). As long as we end up with a standardized build system so that contributors can cross-fertilize consolidations instead of confining themselves to just one. What do existing OI-contributors think? Anyone know what the most technically-superior or technically-advanced build system is? On Wed, Sep 5, 2012 at 11:05 AM, Andrew M. Hettinger ahettin...@prominic.net wrote: Andrew Hettinger http://Prominic.NET || ahettin...@prominic.net Tel: 866.339.3169 (toll free) -or- +1.217.356.2888 x.110 (int'l) Fax: 866.372.3356 (toll free) -or- +1.217.356.3356 (int'l) Alasdair Lumsden alasdai...@gmail.com wrote on 09/04/2012 05:39:58 PM: On 04/09/2012 22:42, mag...@yonderway.com wrote: On Tue, 4 Sep 2012 13:25:39 -0500, Andrew M. Hettinger ahettin...@prominic.net wrote: One of the biggest issues here isn't that packages are particularly HARD to make with IPS (they aren't). It's that there are about three different approaches to it, and we need to get that standardized. Many of the packages are tied up in the consolidations, which DO seem to have a high barrier to entry. So what are the cliff's notes to the three different approaches, and is one of those approaches going to have a lower barrier to entry with still high-quality results? I'm thinking along the lines of a third party repo. I think there's a bit of confusion surrounding the terms involved. A consolidation is just a logical grouping of packages, such as JDS (Java Desktop System, renamed to just desktop on Solaris 11), SFW (Sun Freeware, replaced with userland in Solaris 11), etc. The big issue is that all the consolidations use different build systems. JDS uses RPM style spec-files similar to SFE (Spec files extra, a collection of 3rd party package recipes). SFW used a horrible Makefile based system. Userland is an excellent replacement for SFW, and uses Makefiles but in a way very similar to the FreeBSD ports tree or pkgsrc. I was attempting (with some others) to get OI updated in a giant leap forward replacing SFW with userland-gate (renamed to oi-build, and later illumos-userland after Nexenta started meddling). The idea was that we would try to focus on one single build system, the userland-gate style, which is the best of the lot. New software would go in there, and if we needed to update something in another consolidation, we would instead re-implement the recipe for it in userland-gate format. Unfortunately my approach with /experimental was quite ambitious and didn't quite work how we wanted. Jon Tibble is continuing to release new OpenIndiana builds (such as prestable 6, released *today* - http://wiki.openindiana.org/oi/oi_151a_prestable6+Release+Notes) and is advocating we do move to a single build system based on userland-gate, but more slowly and in a more controlled fashion. oi_151a actually already has a mini userland-gate/oi-build, which you can see here: https://hg.openindiana.org/sustaining/oi_151a/oi-build/ It's used to deliver some additional software and some bits from other consolidations have been moved there. It is probably where people should focus their efforts moving forward. Incorporations are probably what people are bitching about, which are there to provide lockstep upgrades between known working version sets of software. entire is the best known incorporation, which with each release locks all system software at a particular version. Incorporations are needed to prevent your system getting shafted. Lets say you are on oi_148, and in oi_151a we introduced some new software called foo. Foo depends on version 2.0 of bar. oi_148 delivers bar version 1.0. Without incorporations, if you pkg install foo it will upgrade bar no questions asked. Any software linked against bar probably just stopped working with libbar.so.1 changed to libbar.so.2. Incorporations present a challenge when you're developing software, because they stop you installing new versions of things. The way to get around this is to have empty incorporations on your development system, that way you are free to shaft your own install if you want to. It's like taking your seatbelt off. Incorporations map to consolidations, so SFW, JDS, etc each have their own incorporation. This means the incorporations have to be updated when you move software from one consolidation to another, eg from JDS to oi-build. Hope this makes sense. Alasdair I used terminology sloppily, thank you for clarifying for everyone. Source
Re: [oi-dev] Desktop Illumos Still Matters
Someone thought it would be a good idea to have a unified build system across consolidations. I think it's a pretty good idea to standardize on one build system. I'm merely asking which one would be preferred by the community (assuming the community would be willing to standardize). On Wed, Sep 5, 2012 at 12:31 PM, Andrew Stormont andyjstorm...@gmail.com wrote: On 5 Sep 2012, at 18:04, Nick Zivkovic zivkovic.n...@gmail.com wrote: I think that Andrew want to use a unified build system, instead of the loose confederation of radically different systems that's currently in use. I agree. A unified build system is necessary. The only question is: what should it be? Makefile-based, like ports/pkgsrc/oi-build? specfile-based? tcl-base like macports? shell-based like Gentoo's and Exherbo's? python-based like conary? Userland already has a perfectly good build system. I don't understand what you're trying to accomplish here. Andrew S. I'm fine with any of the above (as well as any that I've not mentioned). As long as we end up with a standardized build system so that contributors can cross-fertilize consolidations instead of confining themselves to just one. What do existing OI-contributors think? Anyone know what the most technically-superior or technically-advanced build system is? On Wed, Sep 5, 2012 at 11:05 AM, Andrew M. Hettinger ahettin...@prominic.net wrote: Andrew Hettinger http://Prominic.NET || ahettin...@prominic.net Tel: 866.339.3169 (toll free) -or- +1.217.356.2888 x.110 (int'l) Fax: 866.372.3356 (toll free) -or- +1.217.356.3356 (int'l) Alasdair Lumsden alasdai...@gmail.com wrote on 09/04/2012 05:39:58 PM: On 04/09/2012 22:42, mag...@yonderway.com wrote: On Tue, 4 Sep 2012 13:25:39 -0500, Andrew M. Hettinger ahettin...@prominic.net wrote: One of the biggest issues here isn't that packages are particularly HARD to make with IPS (they aren't). It's that there are about three different approaches to it, and we need to get that standardized. Many of the packages are tied up in the consolidations, which DO seem to have a high barrier to entry. So what are the cliff's notes to the three different approaches, and is one of those approaches going to have a lower barrier to entry with still high-quality results? I'm thinking along the lines of a third party repo. I think there's a bit of confusion surrounding the terms involved. A consolidation is just a logical grouping of packages, such as JDS (Java Desktop System, renamed to just desktop on Solaris 11), SFW (Sun Freeware, replaced with userland in Solaris 11), etc. The big issue is that all the consolidations use different build systems. JDS uses RPM style spec-files similar to SFE (Spec files extra, a collection of 3rd party package recipes). SFW used a horrible Makefile based system. Userland is an excellent replacement for SFW, and uses Makefiles but in a way very similar to the FreeBSD ports tree or pkgsrc. I was attempting (with some others) to get OI updated in a giant leap forward replacing SFW with userland-gate (renamed to oi-build, and later illumos-userland after Nexenta started meddling). The idea was that we would try to focus on one single build system, the userland-gate style, which is the best of the lot. New software would go in there, and if we needed to update something in another consolidation, we would instead re-implement the recipe for it in userland-gate format. Unfortunately my approach with /experimental was quite ambitious and didn't quite work how we wanted. Jon Tibble is continuing to release new OpenIndiana builds (such as prestable 6, released *today* - http://wiki.openindiana.org/oi/oi_151a_prestable6+Release+Notes) and is advocating we do move to a single build system based on userland-gate, but more slowly and in a more controlled fashion. oi_151a actually already has a mini userland-gate/oi-build, which you can see here: https://hg.openindiana.org/sustaining/oi_151a/oi-build/ It's used to deliver some additional software and some bits from other consolidations have been moved there. It is probably where people should focus their efforts moving forward. Incorporations are probably what people are bitching about, which are there to provide lockstep upgrades between known working version sets of software. entire is the best known incorporation, which with each release locks all system software at a particular version. Incorporations are needed to prevent your system getting shafted. Lets say you are on oi_148, and in oi_151a we introduced some new software called foo. Foo depends on version 2.0 of bar. oi_148 delivers bar version 1.0. Without incorporations, if you pkg install foo it will upgrade bar no questions asked. Any software linked against bar probably just stopped working with libbar.so.1 changed to libbar.so.2. Incorporations present a challenge when you're developing software, because they stop
Re: [oi-dev] Desktop Illumos Still Matters
On Wed, Sep 5, 2012 at 12:56 PM, Alasdair Lumsden alasdai...@gmail.com wrote: Hi Nick, On 05/09/2012 18:49, Nick Zivkovic wrote: Someone thought it would be a good idea to have a unified build system across consolidations. I think it's a pretty good idea to standardize on one build system. I'm merely asking which one would be preferred by the community (assuming the community would be willing to standardize). The decision was already made by the core OI devs to use the userland-gate format. That's the future unified build system. So the choice doesn't really have to be made again - it's why oi-build is in userland-gate format. Cheers, Alasdair Oh, ok. I'm still catching up on what's been going on here, while I was away in my cave. ___ 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] Desktop Illumos Still Matters
On Wed, Sep 5, 2012 at 2:43 PM, Alan Coopersmith alan.coopersm...@oracle.com wrote: On 09/ 5/12 10:55 AM, Andrew Gabriel wrote: Nick Zivkovic wrote: Basically, I'm asking if it is better to have one convention (everything in /usr/$consolidation) instead of two (some things in /usr/$consolidation and others in /opt/$consolidation)? There's never been any rule about consolidations being funneled into specific directories. It may be that it makes sense in a few specific cases because of functional groupings, but not universally. In fact, we've been going the other way for years, moving away from /usr/$subsystem directories that impose meaningless boundaries in the way of users. In the last OpenSolaris builds released (snv_130 later), OpenIndiana, and Solaris 11 you should find that /usr/X11 is simply a bunch of backwards compatibility symlinks. Most of the X11 libraries were simply reached via /usr/lib since Solaris 2.6, and the rest of the X11 files moved to /usr/bin, /usr/share, /usr/lib, etc. in those Nevada builds. Thanks for clearing this up, Alan. Besides, these boundaries are better enforced through NG zones than through the filesystem heirarchy. -- -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 ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] What comes next?
On Tue, Sep 4, 2012 at 8:19 AM, ken mays maybird1...@yahoo.com wrote: The desktop for OpenSolaris is not an issue nor major desktop apps. Most of the major apps were ported and some specs live in SFE. You can look at distros like Shillix or even Solaris 11. Do you need Xorg 7.7 or Xfce 4.10? What specific hardware do you have and what does not work? Having out dated software will only make people continue to see Illumos as a thing of the past, no matter how amazing our kernel is. OpenSolaris distro was always a CORE OS distro in which most bloatware apps was moved to IPS. So X11 is the main thing to support besides parts of JDS. -- On Tue, Sep 4, 2012 4:38 AM EDT Damian Wojslaw wrote: Hello So, all you OpenIndiana developers, whom I admire, what comes next? :) I've seen few people declaring they would like to help, I think packaging was mostly mentioned. Please, let me ask few questions. 1. Is this link still valid? http://wiki.openindiana.org/oi/IPS+Knowledge 2. What would those people need to do, so start maintaining a package? Is there a process, like in Debian, a person has to go through before they are given package maintaining duty? 3. Is the development sof OI till going at all? 4. What you, OI developers, would want from this distribution? What your priorities are? Below are things that I intend to work and code on. These were all problems in OI-147. I just upgraded to OI-151a, and some these may have been fixed. As soon as a scrub completes, I will reboot the machine, get networking running and do 2, 1, 7, 5, 6, 3, 4, in that order. 1: Making drivers for wifi; drivers for usb3 (as soon as I get HW); improve usb-stack (major source of anguish and bugs). 2: Making NGZ appliances that users can use to get started on things like building illumos. Or other projects. NGZ appliances can be transported via USB device (because some machines may not be networked [no wifi drivers, etc]). 3: Delivering app-bundles to the GZ using zfs datasets. Same rationale as above, but some software (i.e. drivers) will only work on GZ. 4: Enhance IPS to utilize the above two methods (the more choices we have, the better). 5: Making improvements to IPS. IPS already has a large catalog of software. It would be difficult to justify making a new pkg-system from scratch, because repackaging everything would outweigh any superiority of a new pkg system. Improvements include performance improvements, bug fixes to IPS, better error messages, and bug fixes to existing packages, that fail to install. 6: Modernize compiler support. Illumos still sucks at compiling modern C++ code, even though some major commands/apps are in C++ (nmap, Chrome, firefox). I am thinking of bringing Clang and GCC up to date. This is mostly for userland, as the Illumos kernel already compiles with an older version of GCC. 7: Port i3 and dwm, and add them to IPS-repos. Same for cmake (surprising how many projects use it). I'd like to reiterate what I've said many times in the past, when OpenSolaris was still a live distribution. If illumos wants to become widespread, it needs desktop distribution, a usable one, so that people can use it, play with it and learn it. This is how Linux crept into datacenters, because people like me installed it as their hobby desktop, to look at X, to look at FVWM, to use pine and share modem connection at home. And then, it was natural to start exim and apache on it. And then people like me became admins, CIOs and CTOs and started to use what they knew and liked. And I'd love illumos to become the system people can install as their hobby desktop. Agreed. Hence why need to support the latest or near-latest popular unix-apps. For example firefox is still at 3.X, and we don't have chrome. Drivers are not getting made. My thinkpad has no wifi. NGZs are not being utilized to their full potential. I am going to try to fix as much of this as possible. Thank you. Damian Wojsław ___ 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] What comes next?
Other distros will better serve those who need a very, very lean system. OI is meant to facilitate usable desktop variant of Illumos for power users who need a better hobby than linux administration ;) On Tue, Sep 4, 2012 at 8:19 AM, ken mays maybird1...@yahoo.com wrote: The desktop for OpenSolaris is not an issue nor major desktop apps. Most of the major apps were ported and some specs live in SFE. You can look at distros like Shillix or even Solaris 11. Do you need Xorg 7.7 or Xfce 4.10? What specific hardware do you have and what does not work? OpenSolaris distro was always a CORE OS distro in which most bloatware apps was moved to IPS. So X11 is the main thing to support besides parts of JDS. -- On Tue, Sep 4, 2012 4:38 AM EDT Damian Wojslaw wrote: Hello So, all you OpenIndiana developers, whom I admire, what comes next? :) I've seen few people declaring they would like to help, I think packaging was mostly mentioned. Please, let me ask few questions. 1. Is this link still valid? http://wiki.openindiana.org/oi/IPS+Knowledge 2. What would those people need to do, so start maintaining a package? Is there a process, like in Debian, a person has to go through before they are given package maintaining duty? 3. Is the development sof OI till going at all? 4. What you, OI developers, would want from this distribution? What your priorities are? I'd like to reiterate what I've said many times in the past, when OpenSolaris was still a live distribution. If illumos wants to become widespread, it needs desktop distribution, a usable one, so that people can use it, play with it and learn it. This is how Linux crept into datacenters, because people like me installed it as their hobby desktop, to look at X, to look at FVWM, to use pine and share modem connection at home. And then, it was natural to start exim and apache on it. And then people like me became admins, CIOs and CTOs and started to use what they knew and liked. And I'd love illumos to become the system people can install as their hobby desktop. Thank you. Damian Wojsław ___ 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] New Project Lead?
On Tue, Sep 4, 2012 at 1:41 PM, Andrew M. Hettinger ahettin...@prominic.net wrote: +1 I'd like to see this lead by a committee with a written governance structure. That way we don't have to worry about this in the future, and it's not on one persons shoulders. My complaint right now is I don't know who to take things to. I disagree. I've been a long-time Gentoo user (before OpenSolaris and Illumos), and the governance was what destroyed the community after Daniel Robins left. It was so dysfunctional, that people weren't accepting improvements to their portage package manager from other developers due personal disputes and grudges, instead of technical grounds. We really don't need politics in a software project. Besides, what is governance going to do exactly? Anyone can write code and, if not commit it, can run their own branch on github or bitbucket. Any governance that we implement will be fundamentally impotent, unless they concern themselves with matters other than code. As someone earlier mentioned, what we really need is one person who can act as a coordinator or go-between between various projects in OI. We need a network, not a hierarchy (governance implies the latter). If no one else feels up to the task, I'll do it. But, to be honest I was hoping an OI veteran contributor would step up to the task. Andrew Hettinger http://Prominic.NET || ahettin...@prominic.net Tel: 866.339.3169 (toll free) -or- +1.217.356.2888 x.110 (int'l) Fax: 866.372.3356 (toll free) -or- +1.217.356.3356 (int'l) Garrett D'Amore garrett.dam...@dey-sys.com wrote on 09/02/2012 11:46:39 PM: Just a quick note to since I'm the PL for illumos - or I was until recently. We've made some adjustments which basically make that role obsolete by creation of a very simple governance structure that reflects a meritocracy. It is also split between two bodies, one that addresses technology and another that handles non tech issues. About the only real thing my role does now is that as founder I will have a permanent seat on the foundation. Otherwise I am now just another contributor. The point is, I don't think you need to worry frantically about replacing Alasdair with another PL. I would instead work hard to find parties who can help fill other gaps in release engineering, formal QA, and product packaging. I think also a project planner would be helpful to the project, but not one who makes decisions for the project but rather one who helps coordinate the product plans and communicates this eg by producing gantt charts and acting as secretary at team meetings etc. I am not offering to help with any of these as my plate is already overfull. I am just offering my perspective is all. - Garrett Sent from my iPhone On Sep 3, 2012, at 7:22 AM, Nick Zivkovic zivkovic.n...@gmail.com wrote: On Sun, Sep 2, 2012 at 9:50 PM, chrisjo...@unixmen.com wrote: Although I am relatively new to the project and it is true I have not contributed any code, I would be prepared to take on the role if there was IMHO, a project lead should be one who contributes code and packages to OI. Otherwise, the project lead is just an expendable figure head with no real purpose. In order to set a release schedule, and so on, you have to be intimately familiar with the code that is being released. Before this discussion devolves into a governance orgy, I think that all we really need is people who write code, and make it publicly available, in a roughly synchronized way. We should have a network of developers. Not a hierarchy. no one else suitable. Just some food for thought I guess. I think the real question is who is going to select the new Project Leader? Even if a new project leader is selected by the community and sworn in, what difference will it make, other than making OI's situation _seem_ less dire? I think a de facto project leader will emerge from the ranks of programmers pretty much automatically. Most likely it will be the programmer that has had or is having the most profound impact on the OI project. But that's just my theory. Regards Chris Jones ___ 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 ___ 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] Desktop Illumos Still Matters
On Tue, Sep 4, 2012 at 1:25 PM, Andrew M. Hettinger ahettin...@prominic.net wrote: My thoughts. Remember, they are probably only worth what you paid for them! ;p Nick Zivkovic zivkovic.n...@gmail.com wrote on 09/01/2012 10:42:14 AM: Yes. I am more interested in contributing drivers and the like. As far as packages go, to be honest, I've experienced torture at the hands of IPS (though that could very easily be my fault), and am reluctant go near it. For example I tried an image-update and it failed. So I am stuck on OI-147 until I backup-reinstall-import to OI-151a. I think packages are a high priority, but not as high as making sure the latest illumos-gate can build and run on a modern desktop. For example, I can't get SmartOS running on a thinkpad or my desktop computer. Somewhere in June 2012, a bug was introduced that prevents the illumos kernel from booting. If I had been building and testing the latest source, that bug could probably have been caught before it got buried in a mountain of commits. Now, I image, it is like finding a needle in a haystack. I am willing to assist with packages, but my time is limited, and I think it is more important to direct my effort to building illumos-gate and writing drivers. Also, making packages is still a black art to me, and wouldn't know where to start. One of the biggest issues here isn't that packages are particularly HARD to make with IPS (they aren't). It's that there are about three different approaches to it, and we need to get that standardized. Many of the packages are tied up in the consolidations, which DO seem to have a high barrier to entry. I considered putting together a source-juicer-like self-service system for building packages. If I can get the time, I'll revisit that. It would make my (and everyone else's, I think) life easier. Ok this sounds very useful. I will investigate consolidations, and see what can be done to lower that barrier. But since we are already on the topic of packages, Adam, do you think there is a way to make it less painful, more consistent? I'm _not_ talking about extreme measures like changing from IPS to [DEB/RPM/SVR/etc]. I'm wondering if we could 1) make IPS easier to use by documenting stuff in an easily accessible way [the man pages aren't very helpful] The wiki would be an ideal place for this to happen. Frankly, I haven't see much trouble with the man pages from a user perspective, but from the developer's side, it could definitely use some work. Much of this was documented in the OS.o site, but we need to not depend on that. 2) document every single IPS failure and either fix the packages or the IPS code (depend on what caused the failure), and First thought here is that it needs to be in the bug tracker, but that may not be easily accessible either. Maybe a sub-page on the wiki? Either should be fine. FreeBSD records their ports build failures on their wiki. I think Gentoo recorded this on a bug tracker. Wiki is probably easiest. 3) have IPS install all userland libs to a zfs dataset named rpool/ips or rpool/pkgs; this way, we can zfs-send these datasets, and snap-shot them, and clone them, without pulling in the rest of the file-system heirarchy. This would make my bitterness toward IPS reduce significantly. This way, you can migrate different user-land configs between systems. Also, an easy way to do updates across a multitude of systems. One can share their binaries and packages via zfs-send, because they won't destroy an existing system's /usr /bin and so forth. Also, OI would benefit tremendously from offering pre-made NG zones on the web-site, available for downloading and running. In fact, we could use Zones as a delivery mechanism for things like an Illumos build-environment. An NG zone can contain a working and sandboxed version of firefox. Zones are a great technology that can make the system more attractive amateur power users who may become programmers some day (like I did). Multiple ways of sharing pre-compiled binaries can only help OI and Illumos. In fact I can see people sharing datasets with packages via bit-torrent. Plus, incremental send/recv is a huge benefit. Back in the bad-old-days, (if memory serves) a basic copy of userland was kept in /bin and /sbin that did not depend on anything. This was done to allow you to NFS mount everything else. IIRC the decision was made to go ahead and make them dynamicly linked because noone NFS mounts them anymore anyway, and it meant we had to keep both a simplified and full version of the programs. I think this will encounter many similar issues as that. If we are going back down this road, we could consider just delivering a /bin and /sbin we can use as you propose. It would have the advantage of bringing back this lost (albit rarely used) functionality. That said, there is nothing stopping anyone from delivering a basic userland in /rpool/pkgs, although I would
Re: [oi-dev] New Project Lead?
On Mon, Sep 3, 2012 at 5:44 AM, Joerg Schilling joerg.schill...@fokus.fraunhofer.de wrote: Maxim Kondratovich maxim@gmail.com wrote: +1 I think that leader is not a main problem now, but coordinator must be. If we like OpenSolaris to survive, we need an OpenSolaris coordinator. The current changes in Illumos are not in the right direction for a universally usable OpenSolaris and there are more challenges like e.g. needed enhancements Just so that I can get a better idea, what changes were made to Illumos that make OpenSolaris less usable? for more recent POSIX standards and a plan to achieve binary compatibility across at least different OpenSolaris forks. So, binaries that run on OI, Delphix, OmniOS, SmartOS, Nexenta, Schiilix, Belenix, etc, are not compatible with each other? How/when did this happen? Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily ___ 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] New Project Lead?
Or do you mean that the packages are not compatible? On Mon, Sep 3, 2012 at 8:33 AM, Nick Zivkovic zivkovic.n...@gmail.com wrote: On Mon, Sep 3, 2012 at 5:44 AM, Joerg Schilling joerg.schill...@fokus.fraunhofer.de wrote: Maxim Kondratovich maxim@gmail.com wrote: +1 I think that leader is not a main problem now, but coordinator must be. If we like OpenSolaris to survive, we need an OpenSolaris coordinator. The current changes in Illumos are not in the right direction for a universally usable OpenSolaris and there are more challenges like e.g. needed enhancements Just so that I can get a better idea, what changes were made to Illumos that make OpenSolaris less usable? for more recent POSIX standards and a plan to achieve binary compatibility across at least different OpenSolaris forks. So, binaries that run on OI, Delphix, OmniOS, SmartOS, Nexenta, Schiilix, Belenix, etc, are not compatible with each other? How/when did this happen? Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev -- :. Blog: nickziv.wordpress.com Twitter: www.twitter.com/nickziv ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] New Project Lead?
Depending on viewpoint, OpenSolaris is either alive or dead. However, it is indisputable that OpenSolaris is also ambiguous, and confusing. The distro is dead, but has been resurrected as OpenIndiana. The OS is alive, but it is called Illumos (to avoid ambiguity). Illumos is the only OpenSolaris out there, in the sense that it is an open source descendant of Solaris 10, with extras. I strongly recommend that we use unambiguous terminology from here on. We may all understand what we mean when we use ambiguous terms, but outsiders won't. And we don't have a lot outside contributors. Even if we count the ex-sun talent that contributes to Illumos and its distros, we have a dangerously low bus factor. If we look at Illumos as many projects, instead of one (i.e. DTrace, SMF, Zones, ZFS), we have an _even lower_ bus factor. On Mon, Sep 3, 2012 at 9:46 AM, Joerg Schilling joerg.schill...@fokus.fraunhofer.de wrote: Magnus mag...@yonderway.com wrote: On Sep 3, 2012, at 10:24 AM, Joerg Schilling wrote: Looks like you missunderstand the problem and that your understanding is one of the reasons for the existing problems. I'm not so sure that I misunderstand. I understand that OpenSolaris != OpenIndiana. They have a common ancestry, but they are two different things made by two different organizations. OpenSolaris is dead, the organization responsible for it has mostly buried it, and we should only be referring to it in the past-tense. It may be that your mistake is to believe that OpenSolaris is a distro? The real name of that distro was Indiana and Indiana is of course dead. I am however talking about OpenSolaris.and this is a generic OS classification. SchilliX is the oldest distro based in OpenSolaris, Indiana started much later but is also nothing than a distro based on OpenSolaris. OpenSolaris is still alive Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily ___ 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] New Project Lead?
On Mon, Sep 3, 2012 at 10:11 AM, Joerg Schilling joerg.schill...@fokus.fraunhofer.de wrote: Nick Zivkovic zivkovic.n...@gmail.com wrote: Depending on viewpoint, OpenSolaris is either alive or dead. However, it is indisputable that OpenSolaris is also ambiguous, and confusing. The distro is dead, but has been resurrected as OpenIndiana. The OS is alive, but it is called Illumos (to avoid ambiguity). The latter is a false assumption. Illumos is the only OpenSolaris out there, in the sense that it is an open source descendant of Solaris 10, with extras. Also a false assumption. Why is it a false assumption? Are there other projects that forked OpenSolaris? Can you please elaborate on what your contention with illumos is? I am new here, so please forgive my ignorance :) Thanks. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily ___ 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] New Project Lead?
I wish I had known about Schillix-ON earlier. I had just finished upgrading to OI151a. Are Schillix-ON and the OI userland mutually exclusive? Or can we swap the Illumos and Schillix-ON kernels as we please? I hope both kernels can mutually read each others' zfs pools, to avoid unintentional lock-in. It would be beneficial to OI and its users to offer a choice between kernels, if this is at all feasible. It would also be great if Schillix-ON can offer a list of different goals they have from Illumos. How is a potential user/contributor supposed to know which kernel to use, aside from picking the most popular one off hand? I see that Shillix-ON deviates from Illumos since version 147, I wonder if KVM support is planned? But this probably belongs in another list. On Mon, Sep 3, 2012 at 11:57 AM, Ken Gunderson kgund...@teamcool.net wrote: At Mon, 3 Sep 2012 11:13:07 -0500, Nick Zivkovic wrote: On Mon, Sep 3, 2012 at 10:57 AM, Joerg Schilling joerg.schill...@fokus.fraunhofer.de wrote: Jonathan Adams t12nsloo...@gmail.com wrote: On 3 September 2012 16:34, Joerg Schilling joerg.schill...@fokus.fraunhofer.de wrote: snip Correct, OpenSolaris is an umbrella and we need to find a way to coordinate it's development to keep enough community behind OpenSolaris. except of course that we cannot and do not own any right to the name Solaris in any way shape or form, hence the reason that we need to refer to the OS/Network as Illumos. for us, OpenSolaris is dead, because we cannot use the name. Some people created the fork Illumos but failed to get the whole community behind them, so using the name Illumos does not work. Ok. I see. Can you please direct me to these other forks? Hello Nick: I suspect Schillix may be one such reference: http://schillix.berlios.de/ Also, explicit reasons for the lack of acceptance of Illumos by other community members, would be helpful. We can learn from them, and possibly make changes accordingly (open source, etc, etc). I think Joerg touched on this on his email to Alasdair that was inadvertently directed to the list. Check his initial reply in this thread. Peace-- Ken ___ 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] New Project Lead?
On Sun, Sep 2, 2012 at 6:17 PM, Magnus mag...@yonderway.com wrote: On Sep 2, 2012, at 7:14 PM, Nick Zivkovic wrote: Do we have any idea who the new project lead is? Or is it too soon to tell? Are you volunteering for the position? Not unless it involves writing code :) But, seriously, I am willing to help the project by contributing a lot of good code. That's where I will be most effective. ___ 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] Desktop Illumos Still Matters
I was just reading through the oi-dev archives (about the resignation of the OI lead) where a former Sun engineer, claimed that the efforts made by sun to port OpenSolaris to the desktop/laptop platforms (by adding wifi support, by making a new audio system, etc), only hurt Sun in the long run, and that it was all for nothing. I agree that it probably hurt Sun in the long run. But I promise that it was not for nothing. I started using OpenSolaris some time in 2006 or 2007. I was 16 then, and didn't know anything about programming. The availability of the OpenSolaris distribution, is what gave me, a mere mortal, the ability to store files in a 3-way ZFS mirror (a teen would not be able to afford an enterprise RAID card). To play with DTrace and illuminate the inner workings of the system. OpenSolaris is the platform that I started writing my first serious code on. It is the platform that I write code on to this day. It was and still is a joy to use DTrace daily, and to transport data between machines as ZFS datasets, and not as tar-balls. It is bliss to have inline compression and deduplication. Fast and free snapshots. Most Illumos devs take these things for granted. They are all professional engineers, whom I respect deeply. But in 2006 I was a mere teenager, who was merely enthusiastic about administering unix-like systems. I guess switching between Linux distros, and being different made me feel elite. But the truth is, I was a pretender. I was a mere hobbyist, looking for a distraction. Something that would make life less boring and humdrum. I meandered about the web, not knowing what kind of distraction I was looking for. Funny youtube videos? Yeah those were okay. But they got stale and weren't as stimulating. Video games? Stimulating, but tiring. Not fulfilling. Almost masturbatory in nature. Porn? Same as video games, though slightly more effective. Going out / hanging out? Only in short bursts. Doing it constantly made me tired and fatigued. Setting up a Linux distro had its own kind of high. It lasted longer. But once you've set up a distro, you can't really leave it alone. You either have to try another distro, or upgrade the existing distro. I can't explain how I longed for upgrades. Especially on Gentoo. That was the high of _assembling_ something that worked. Of making an otherwise blank machine come to life, and operate in a customized manner. (As customized a manner as possible for a non-coder). But it wasn't until I tried OpenSolaris that I made a decision to learn to code proficiently. For several reasons. The burst of innovation that came with OpenSolaris (ZFS, DTrace, etc), made me aware that software/computing had unsolved problems (or problems in need of better solutions). The availability of DTrace, and the prospect of being able to see what the machine is doing (and hence what my own code is doing), was too tempting a technology to ignore. I understood that the technologies in OpenSolaris would best facilitate my new-found need to create, to build, to engineer solutions to problems. Namely my problems, but problems nonetheless. But if OpenSolaris were not usable on the desktop -- If it didn't have support for things like audio and wifi -- I would never have considered it. I would never have decided that writing code might be a good idea. I would have never discovered one of the most exhilarating, blissful, and strangest activities that we humans have come up with. Coding has been the most profound and intense experience of my life. I don't know exactly when it started changing me, I just know that it did. And I am glad it did. If I hadn't chanced down the OpenSolaris road, I probably would have ended up an uninspired burnout, a wasted bag of cells. If Illumos were to disappear from the desktop. Or even from the world. I would be disappointed. But I would move on, because I already know the bliss of writing code, and I'll do it elsewhere, even if the environment and tools are not as agreeable. One wouldn't be able to stop a writer from writing his heart out, by taking away his typewriter and giving him a quill and parchment. But when I think that there is some kid out there who is bored out of his skull and wandering aimlessly, because, quite frankly, he is too smart for average activities, who may never learn the joys of the art of programming because some developers decided that they're content letting Illumos's basic desktop capabilities atrophy over time as new devices replace old devices... well, my heart breaks. Because these kids might be those that never get inspired, and waste their lives on stupidity. I'm not saying that the Illumos engineers are doing the wrong thing. In fact I think they are all doing the right things. I hope Illumos retains the desktop essentials (usb1/2/3/N, wifi, audio, modern browser); that's all that's needed to get someone started down the path of writing code. Desktop Illumos isn't supposed to replace Ubuntu and Mac. It is supposed
