[oi-dev] What comes next?
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
Re: [oi-dev] What comes next?
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
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] Desktop Illumos Still Matters
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. 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? 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 suggest using an alternate mount point in /usr (/usr/zdu or some-such? solaris has a long history of delivering alternate userlands in filesystems off of /usr). We might even be able to integrate a window manager (like i3 or dwm) so that switching virtual desktop, actually switches to another zone. Can you do this in zones? Frankly, all my other zones have always been on the
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
[oi-dev] Please comment #2314 isc-dhcp
I've cleaned up and updated isc-dhcp to 4.2.4-R1. This already has the updates provided by Oracle so I removed the patches which are not required. I also removed duplicate items in the p5m file and fixed the Makefile so the BIND sub-module gets built correctly. This is my first foray into helping with oi userland so be critical so I can grow as a contributor. Thanks.My clone is athttps://bitbucket.org/ggendel/oi-buildGary ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Please comment #2314 isc-dhcp
Hi Gary, welcome to packaging stuff. I am resending this to userland list at illumos.org. Please, change the OpenSolaris CDDL license to the Illumos one, the text can be found at https://bitbucket.org/xenol/illumos-userland-2162/src/24656bd2ab51/components/zabbix-agent/Makefile for example. Also do not forget about copyright. Otherwise, changes look good to me. P.S: I am sorry I forgot to mention that the repository on bitbucket should contain issue number in the name. It makes tracking changes easier. So, when creating the repository for the next time, please put issue number in it's name. Cheers, Adam On Sep 5, 2012, at 12:45 AM, g...@genashor.com wrote: I've cleaned up and updated isc-dhcp to 4.2.4-R1. This already has the updates provided by Oracle so I removed the patches which are not required. I also removed duplicate items in the p5m file and fixed the Makefile so the BIND sub-module gets built correctly. This is my first foray into helping with oi userland so be critical so I can grow as a contributor. Thanks. My clone is at https://bitbucket.org/ggendel/oi-build Gary ___ 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've actually realised it would be really useful if there was a single document explaining all this stuff, a kind of In the beginning there was... style walk through of how things came to be. I'll try to write one over the next few weeks and put it on the wiki, as it would probably help new developers get their head around things. ___ 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:38 PM, Nick Zivkovic zivkovic.n...@gmail.com wrote: 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. Jenkins can automate all of that. For $JOB, I manage various products, millions of lines of code in total with it. The nice thing is that it will blame whoever breaks the build. It also provides an easy to read dashboard, and notify only on status change, not on every build that fails etc. Plus it can post to a URL, so a few lines of python code with web.py and you have an interface to a wiki or bug tracker. Francois ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
