Re: [oi-dev] [developer] suspend/resume in Illumos
That’s only true if you’re running on a hypervisor that uses suspend / resume for live migration. I’m not sure how widespread running illumos on VMware is – the absence of suspend/resume support means that nobody is benefiting from this particular capability today (at least with illumos). Sent from Mail for Windows 10 From: DavidHalko Sent: Monday, June 24, 2019 5:18 AM To: illumos-developer Cc: ran...@sibernet.com; oi-dev@openindiana.org Subject: Re: [developer] suspend/resume in Illumos Suspend and Resume is critical for live migration in a data center with external storage to reduce schedules downtime incurred with firmware updates to maintain a secure platform. Thanks, David Halko http://netmgt.blogspot.com/ Sent from my iPhone > On Jun 12, 2019, at 4:01 AM, Jim Klimov wrote: > >> On June 11, 2019 9:29:23 PM UTC, ran...@sibernet.com wrote: >> >> >>> On Tue, 11 Jun 2019, Toomas Soome via illumos-developer wrote: >>> >>> I’d say, anything to encourage people to try, use and join to develop >> [illumos] is very welcome. Better laptop support will definitely be >>> bonus. >> >> Betting better graphics support would be higher on the list (yea, the >> other 'dropped' project). >> >> Cheers! >> >> Randy >> >>> >>> Sent from my iPhone >>> >>> On 11 Jun 2019, at 22:58, Garrett D'Amore wrote: >>> >>> My gut instinct is that this isn’t that interesting – most everyone >> is running illumos in either VMs, or in datacenter >>> applications where suspend/resume has little if any applicability. >>> >>> While the work itself is probably interesting, and it may enable new >> applications for illumos, the concern I’d have would be >>> detraction from other more pressing work, without any clear use cases >> for it. >>> >>> That said, if someone (you?) wanted to spend cycles on this for >> personal satisfaction, I hardly see any reason to discourage it, >>> and I’m fairly certain if the risks of the new code being introduced >> are small (or well managed by sufficient testing for >>> example), I can’t see any other reason we would reject a suitably >> formed RTI. >>> >>> Sent from Mail for Windows 10 >>> >>> From: ran...@sibernet.com >>> Sent: Tuesday, June 11, 2019 11:10 AM >>> To: oi-dev@openindiana.org; develo...@lists.illumos.org >>> Subject: [developer] suspend/resume in Illumos >>> >>> I have a question for developers here: >>> >>> How important is suspend/resume for OI/Illumos (including S4)? >>> >>> One of the incomplete projects left behind was S4 (lack of need, and >> a >>> >>> hard to identify bug stifled it's integration). It is non-trivial, >> and >>> >>> needs updated s/r core code (added configuration and significant >>> >>> restructuring, as well as likely assistance from developers >> knowlegable in >>> >>> other Illumos internals), but if this is an uninteresting feature, it >> is >>> >>> likey not worth the effort (recent bugs suggest that few if anyone >> use >>> >>> it); however, it wouldn't be too hard to resurect (though would still >> take >>> >>> several months of work). >>> >>>Cheers! >>> >>> Randy >>> >>> illumos / illumos-developer / see discussions + participants + >> delivery options Permalink >> -- >> illumos: illumos-developer >> Permalink: >> https://illumos.topicbox.com/groups/developer/Tb3e65f5ac470e30c-Ma4a7672659b46c13f040eb9e >> Delivery options: >> https://illumos.topicbox.com/groups/developer/subscription > > For my 2c, I have to use OI in a VM rather than baremetal on my laptop (would > love to some day; it is part of my daily desktop for years now) because of a > mix of these issues. While graphics and wifi drivers might be worked around > by careful choice of hardware for a new rig, effective lack of > sleep/hibernate is a big problem. > > My sessions of desktop OS uptime tend to be weeks and months long, many apps > and tabs open... so rebooting every morning is not quite an option. > > Jim > > -- > Typos courtesy of K-9 Mail on my Android -- illumos: illumos-developer Permalink: https://illumos.topicbox.com/groups/developer/Tb3e65f5ac470e30c-M87936b070d0aa9c1490f0794 Delivery options: https://illumos.topicbox.com/groups/developer/subscription ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] [developer] suspend/resume in Illumos
My gut instinct is that this isn’t that interesting – most everyone is running illumos in either VMs, or in datacenter applications where suspend/resume has little if any applicability. While the work itself is probably interesting, and it may enable new applications for illumos, the concern I’d have would be detraction from other more pressing work, without any clear use cases for it. That said, if someone (you?) wanted to spend cycles on this for personal satisfaction, I hardly see any reason to discourage it, and I’m fairly certain if the risks of the new code being introduced are small (or well managed by sufficient testing for example), I can’t see any other reason we would reject a suitably formed RTI. Sent from Mail for Windows 10 From: ran...@sibernet.com Sent: Tuesday, June 11, 2019 11:10 AM To: oi-dev@openindiana.org; develo...@lists.illumos.org Subject: [developer] suspend/resume in Illumos I have a question for developers here: How important is suspend/resume for OI/Illumos (including S4)? One of the incomplete projects left behind was S4 (lack of need, and a hard to identify bug stifled it's integration). It is non-trivial, and needs updated s/r core code (added configuration and significant restructuring, as well as likely assistance from developers knowlegable in other Illumos internals), but if this is an uninteresting feature, it is likey not worth the effort (recent bugs suggest that few if anyone use it); however, it wouldn't be too hard to resurect (though would still take several months of work). Cheers! Randy -- illumos: illumos-developer Permalink: https://illumos.topicbox.com/groups/developer/Tb3e65f5ac470e30c-M221586bbcf19e81e63ecf58f Delivery options: https://illumos.topicbox.com/groups/developer/subscription ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] [developer] The java bits from my build-elsewhere wad, and prior work (Illumos 4719)
Does hipster build stock illumos gate? I haven't tried omnios with dan's fixed yet but if we have a solid platform that is actually maintained that can build stock illumos then we can just stop worrying about OI. They can fix if or when they are motivated to do so. Sent from my iPhone On Oct 28, 2014, at 12:17 AM, Alexander Pyhalov via illumos-developer develo...@lists.illumos.org wrote: On 10/28/2014 10:10, Dan McDonald via illumos-developer wrote: Tell me -- is there ANY update on the dev repo? My OI VM runs oi_151a9, for example. Is there anyone I can/should speak with about this? Jon Tibble handles /dev currently. 151a9 is the latest /dev build. Last update was recently, it was bash bugfix. I don't know when new major update will happen. -- Best regards, Alexander Pyhalov, system administrator of Southern Federal University IT department --- illumos-developer Archives: https://www.listbox.com/member/archive/182179/=now RSS Feed: https://www.listbox.com/member/archive/rss/182179/21239177-3604570e Modify Your Subscription: https://www.listbox.com/member/?member_id=21239177id_secret=21239177-2d0c9337 Powered by Listbox: http://www.listbox.com ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Fwd: [developer] Please review 4989 - BIS
Thank you for your opinions. I didn't think anyone ran configurations like you describe, but now I know someone does. My feeling is that your use case is still rather niche at least within this community. As such I won't tell you what you should or should not do with illumos, but I hope you understand if those of us contributing time and money focus on those things that we feel are the most important or have the greatest traction amongst our user base. Especially in the core which we perceive to represent our shared values. We have tried to focus on the things everyone can agree upon there. If you want to drive in a different direction you are welcome to do so. Based on the comments already made it seems like the areas that will most appeal to you are in the distros. Perhaps you're already a contributor there. If not you should give it a shot. I am going to take a pass on refuting the technical arguments that you've made. There are numerous errors there but I don't think it serves anyone's purpose for us to continue the debate. Sent from my iPhone On Jul 23, 2014, at 4:25 PM, Nikola M. via illumos-developer develo...@lists.illumos.org wrote: On 07/22/14 08:07 PM, Garrett D'Amore wrote: Running illumos on bare metal makes great sense; as a hypervisor, you want to do that. But that use case is completely at adds with the idea of running dual boot. That two things (VMs and dual boot) are not against each other, and I don't see why say they are mutually exclusive?? They are not and there are many reasons why would one use dual boot. illumos and opensolaris-descendent distros use Boot Environments, (BEs) on top of ZFS, one can choose during boot, and I have not hear anyone bitching about that valuable option, yet less about one more menu item in GRUB, that does not boot system from ZFS dataset, but from other disk/partition...? Difference between these two is close to none from user perspective, and I don't understand why you are bitching around about it, anyway. The dual boot use case is/was primarily intended for folks to be able to use have multiple OS' on their hardware, and predates virtualization technology. These days, dual booting is just plain silly, and I cannot Not only you are wrong about what users need, and arguing with yourself actually, but later things that you said explain why people Want to be able to boot more then one OS on same desktop/laptop system. Testing how things (and new hardware) are done with hardware to be able to report bugs about it. (Who would want USB 3.0 working and any hardware at all working, but those using dual boot?) Also one can not expect system to behave same way on bare metal and virtualized and expecting to have same performace from ZFS on disk(s) and zfs in virtualization, that use image file on top of, say, NTFS and are barely stupid to compare. Under virtualization, illumos can not run KVM/Virtualbox, beacue it does not have control over CPU and virtualization UNDER illumos is exactly what one would use dual-booted illumos distro to test for.. .. so tester can upload locally tested VMs with zones up to the server. Main problem is that illumos lack Virtualization I/O drivers for KVM, so that locally configured KVM in illlumos with zones, could be easily transferred on the servers in production, where bandwidth is better. (Ask Joyent why they do NOT offer illumos inside KVM , but only Linux and windows - because there are no illumos I/O drivers for KVM as a guest) That is why people would like to use illumos as Desktop On bare metal locally and GDA, you should better think why illumos still does not have decent guest KVM I/O drivers, then demonstrating lack of understanding for illumos users? drivers. These days I think anyone who dual boots and isn't writing hardware drivers is either doing so as result of an installation decision made years ago -- understandable, or is just insane.) I think that any leader of open source project, yet leader of an whole OS kernel development could be called insane if he wants to stop people from using OS in a certain way. Dual-boot IS a way for New people to use illumos distros and promote platform and you can laugh as much as you want but people Value what they see with their own eyes and thet they can install themselves and run, right away and that includes shrinking partition to fit ZFS on same disk. It is understandable that people have one HD in their laptop/desktop, and that they want full speed for their applications of different kind on different OSes and that people want to have Machine in their hands as close as possible to server they would be deploying. That are also Solaris roots anyway, to basically have a Server on a desk, so you can manage it locally as the server in production would be managed and then use setting on large server - that is what you said once GDA, anyway
Re: [oi-dev] Fwd: [developer] Please review 4989 - BIS
Well said Keith. The idea here is to give OI (and any other distributors who might happen to care) a chance to react, and work together with us; not to give OI veto powers over a direction that makes obvious sense. Right now, parted and co. are rotting bits in illumos. Nobody maintains them. Most of us don't want them, and few have even used them. I have used parted *once* in my entire life. That's it. And that was about six years ago. Can't imagine using it today. If OI (or someone else) wants them, they can always get them from source history and set up a separate package to deal with them. That's always been relatively straight-forward. In fact, these bits should have been in a separate repo pretty much from the time they were first introduced. Now we can correct that. Running illumos on bare metal makes great sense; as a hypervisor, you want to do that. But that use case is completely at adds with the idea of running dual boot. The dual boot use case is/was primarily intended for folks to be able to use have multiple OS' on their hardware, and predates virtualization technology. These days, dual booting is just plain silly, and I cannot imagine that I will ever configure a system for dual boot -- not just with illumos, but with *any* OS. Its just too damned inconvenient to reboot to get to a different environment. (Ok, special exception for lab systems, where I need to run hardware sensitive tests -- like device drivers -- from different OS images. But I absolutely neither need nor want to shrink partition tables there. In fact, most often I have totally separate physical disks. This use case is also atypical -- being primarily folks who work on physical device drivers. These days I think anyone who dual boots and isn't writing hardware drivers is either doing so as result of an installation decision made years ago -- understandable, or is just insane.) I have to confess that I use VMware (a commercial v12n product) for my illumos work these days -- in fact right now I have a couple of different OS' running on my laptop at the same time -- MacOS, 2 instances of illumos, an instance of Windows, and an instance of CentOS. It just wouldn't be practical to do this multi boot. I do believe that the main performance problems with building illumos inside VirtualBox have been resolved. I have heard a number of anecdotal reports suggesting this -- I've not personally verified it myself, however (being quite happy with VMware.) On Tue, Jul 22, 2014 at 9:41 AM, Keith Wesolowski via illumos-developer develo...@lists.illumos.org wrote: On Tue, Jul 22, 2014 at 06:27:33PM +0200, Nikola M. via illumos-developer wrote: OI is not prepared for this change untill parted and gparted are put inside OI to serve it's users like they used to. (Would also thing other distros should be informed about is at least) If Gparted and parted are not illumos problem anymore, then don't let there be more problems for users. We have been notified. You guys are the only ones who seem to care, which is not surprising since this use case is no longer seen in the markets most other distributors have focused on. Since nothing in ON depends on this, the correct decision is the one that's been taken: to remove it. As a courtesy, distributors were pinged so that anyone who wants to continue shipping this software will have an opportunity to make other arrangements for doing so. That's why this thread exists. As distributors and members of the illumos community, it is our dual responsibility to ensure that ON has the right contents and that our respective customer bases are properly served by the products we ship. It does not behoove us to insist that ON deliver something inappropriate to its general architecture solely for the benefit of our own customers. That's why you have oi-userland, we have illumos-extra, and other distributors have similar analogues. Having to make one's own provisions for alternate delivery is simply part and parcel of being a distributor and should not induce the anger and hostility I'm reading here. --- illumos-developer Archives: https://www.listbox.com/member/archive/182179/=now RSS Feed: https://www.listbox.com/member/archive/rss/182179/21239177-3604570e Modify Your Subscription: https://www.listbox.com/member/?member_id=21239177id_secret=21239177-2d0c9337 Powered by Listbox: http://www.listbox.com ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Fwd: [developer] Please review 4989 - BIS
Btw, VirtualBox works on many platforms -- there it support for Windows, Mac, Linux, Solaris, and illumos hosts. It supports the same operating systems as guests. I don't think its quite up to the same performance and integration standards as VMware, but its not far off either; I do have a Mac mini that runs VirtualBox to occasionally boot up Windows, and it works fine. (Couldn't justify a VMware license for the minimal use case there -- I use that system to run my R/C flight simulator.) On Tue, Jul 22, 2014 at 9:27 AM, Nikola M. via illumos-developer develo...@lists.illumos.org wrote: On 07/22/14 05:11 PM, Garrett D'Amore wrote: ntfs-3g doesn't depend on ntfsprogs. I'd not heard that GParted wasn't supported on illumos, although I'm not terribly surprised. These days, dual boot seems to be infrequently used -- long since supplanted by use of virtualization technology (which is lots easier for everyone to use.) Does anyone within reach of this email still use dual boot systems? (Hmm... I had been doing so as recently as two years ago, and I still have one system that is configured that way, but I've not booted 'the other system' in a very long time indeed.) GParted was introduced to facilitate having users try out OpenSolaris on their laptops running Windows. It was seen as a key enabler for those masses of low income students in China that ponytail was so intent on luring with the desktop focus Sun had just prior to its acquisition by Oracle. Its unclear that the strategy had even small amounts of success in that regard; VirtualBox was a much better approach IMO. If OI/hipster are prepared for this change, then I think it can proceed. OI is not prepared for this change untill parted and gparted are put inside OI to serve it's users like they used to. (Would also thing other distros should be informed about is at least) If Gparted and parted are not illumos problem anymore, then don't let there be more problems for users. Also, if there were not 'ponytail', we probably won't have Opensolaris and therefore, illumos. And yes I am using laptop in dual-boot that had windows first installed. (an old laptop now but that should improve) Probably next laptop will be same configured if not triple booted with Linux. And no, I am not Chinese if that matters... And yes it is crucial to give to people CD (or point them to USB image) and say: You have everything you need to install it in dual-boot without touching your current system to get know with the platform. Someone thinking that dual-boot is not important - is problem of perspective with interacting with New people. VirtualBox on illumos only works with OI. VirtualBox till recently was known for being slow for compiling illumos inside of it, maybe now is faster? Nonetheless, saying that people are using this and that should be backed up with some kind of research and my humble opinion is that Desktop/OI is important for illumos and removing things from illumos should be better coordinated (and explained). Yes, people will keep using dual-booting windows,Linux and I hope they would use OI to administer servers running on illumos distros. As I understand illumos exists to run on bare metal and provide VMs for other platforms and not other way around (What's new with illumos I/O drivers for KVM as a guest?) Saying to people not to run it on bare metal is not helping with defending platform market place as a whole and wide it's use base. And 'ponytail' was right on that. At the end of the day, best thing with OI Hipster is that it is using fresh build of updated illumos, and one using Openiindiana (Presumably running on laptop..) can in time observe things that affect users, kernel people don't care about. So they don't end up in messed up in a products users/customers would use. Last thing I witnessed is that Standby on my (dual-boot) laptop stopped working a while ago (it just locks with black screen and it used to work as far as March/2014 with no problem). nikolam --- illumos-developer Archives: https://www.listbox.com/member/archive/182179/=now RSS Feed: https://www.listbox.com/member/archive/rss/182179/ 21239177-3604570e Modify Your Subscription: https://www.listbox.com/ member/?member_id=21239177id_secret=21239177-2d0c9337 Powered by Listbox: http://www.listbox.com ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] [developer] 2837 - remove print/lp* from gate and use CUPS from userland
I'd love to see it go. But I will wait for others to complain first. One idea would be to eject it from the gate and put it into a new repo where it could also be updated if people still want it. Sent from my iPhone On May 6, 2014, at 12:48 AM, Alexander Pyhalov develo...@lists.illumos.org wrote: Hello. When I tried to rebuild apache 1.3 again I found out that mod_ssl doesn't like OpenSSL 1.0. Of course, I could look at it and try update it, but does someone really use apache 1.3? Now it's only used as illumos-gate build dependency. Last time the question of removing print/lp* from the gate was rejected partially because cups didn't provide trusted printing support. Our (OI /hipster) version of cups has TX patches. However, I haven't checked that it works. As I understand, most distributions have already stripped this code. Isn't it a good time to reconsider the question - either update dependency to apache 2 or remove it? -- Best regards, Alexander Pyhalov, system administrator of Computer Center of Southern Federal University --- illumos-developer Archives: https://www.listbox.com/member/archive/182179/=now RSS Feed: https://www.listbox.com/member/archive/rss/182179/21239177-3604570e Modify Your Subscription: https://www.listbox.com/member/?member_id=21239177id_secret=21239177-2d0c9337 Powered by Listbox: http://www.listbox.com ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] [developer] 2837 - remove print/lp* from gate and use CUPS from userland
I will probably set up a seperate repo for this. I'd like it to be buildable following the same pattern and tools as illumos itself in order to minimize pain for distro builders. This would be the pattern that could be used when ejecting other bits as well. Like the dhcp server. :-) Sent from my iPhone On May 6, 2014, at 7:43 AM, Peter Tribble peter.trib...@gmail.com wrote: What part of the lp stack actually uses apache? I suspect it's only ipp, mod_ipp specifically, and that the rest of the lp stack has no dependency at all. I would be perfectly happy to see all the ipp stuff ripped out (I've never used it, and my understanding is that CUPS provides a much better implementation anyway) especially if it allows us to eradicate apache-13. However., I'm not sure that this extends to the rest of the legacy lp stack. The argument that legacy stuff could simply be dropped off to one side in a legacy repo would be far stronger if we actually had such a repo in place. I regard creating that infrastructure as a necessary prerequisite to any significant pruning of the codebase. (Although I'm not sure it needs a full-blown repo. Tarballs of the source that's ripped out, placed in a well-known location, ought to be adequate.) On Tue, May 6, 2014 at 3:07 PM, Garrett D'Amore develo...@lists.illumos.org wrote: I'd love to see it go. But I will wait for others to complain first. One idea would be to eject it from the gate and put it into a new repo where it could also be updated if people still want it. Sent from my iPhone On May 6, 2014, at 12:48 AM, Alexander Pyhalov develo...@lists.illumos.org wrote: Hello. When I tried to rebuild apache 1.3 again I found out that mod_ssl doesn't like OpenSSL 1.0. Of course, I could look at it and try update it, but does someone really use apache 1.3? Now it's only used as illumos-gate build dependency. Last time the question of removing print/lp* from the gate was rejected partially because cups didn't provide trusted printing support. Our (OI /hipster) version of cups has TX patches. However, I haven't checked that it works. As I understand, most distributions have already stripped this code. Isn't it a good time to reconsider the question - either update dependency to apache 2 or remove it? -- Best regards, Alexander Pyhalov, system administrator of Computer Center of Southern Federal University --- illumos-developer Archives: https://www.listbox.com/member/archive/182179/=now RSS Feed: https://www.listbox.com/member/archive/rss/182179/21239177-3604570e Modify Your Subscription: https://www.listbox.com/member/?; Powered by Listbox: http://www.listbox.com --- illumos-developer Archives: https://www.listbox.com/member/archive/182179/=now RSS Feed: https://www.listbox.com/member/archive/rss/182179/21175229-59db2a15 Modify Your Subscription: https://www.listbox.com/member/?member_id=21175229id_secret=21175229-7dd7c4fa Powered by Listbox: http://www.listbox.com -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] [developer] recent nightly changes and other consolidation
In my opinion, the other consolidations should not be using illumos’ nightly.
The needs of other consolidations are usually quite different from illumos, and
vice versa. Trying to build “one nightly to rule them all” is difficult
without close coordination between consolidations maintainers. Post diaspora,
that coordination no longer exists.
Indeed, /opt/onbld indicates “ON” (short for OS/Net), which is the
consolidation that illumos is derived from. I’d recommend that other
consolidations create their own forks of /opt/jdsbld or /opt/gnomebld/ or
whatever suits their fancy.
--
Garrett D'Amore
Sent with Airmail
On March 10, 2014 at 10:59:38 PM, Alexander Pyhalov (a...@rsu.ru) wrote:
Hello.
After integration of 4522 the build doesn't fail nearly often enough we
have some problems using nightly to build non-illumos consolidations.
At least I couldn't fix slim_source build. Not sure about other.
The question is the following:
could nightly be modified so that build warnings are treated as
build_extras, i.e. existing of $TMPDIR/build_warnings${SUFFIX} leads to
build_extras_ok=n , not build_ok=n
at
https://github.com/illumos/illumos-gate/blob/master/usr/src/tools/scripts/nightly.sh#L224
?
Or is it better just to use patched nightly while building these
consolidations?
--
Best regards,
Alexander Pyhalov,
system administrator of Computer Center of Southern Federal University
---
illumos-developer
Archives: https://www.listbox.com/member/archive/182179/=now
RSS Feed: https://www.listbox.com/member/archive/rss/182179/21239177-3604570e
Modify Your Subscription:
https://www.listbox.com/member/?member_id=21239177id_secret=21239177-2d0c9337
Powered by Listbox: http://www.listbox.com
___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] [developer] GSoC? Decision time....
Yes, this is a good GSoC project. I’m happy to mentor a student, modulo my concerns about working with remote students. (I don’t want to mentor students from India, China, etc. because in my experience I have not been successful in supporting them effectively. I’m much more likely to be happy working with a student who can ideally meet me in person at least once or twice in the term, or at least one in a timezone that makes it possible for reasonable collaboration to occur. Again, this is just *my* preference as a mentor — I see nothing wrong with other mentors wanting to work with remote students if they feel they can give such students sufficient support; I just know I’ve not been successful in doing so the last few years.) The successful student should have some experience with one or more of SCSI, SATA, device drivers, file systems. A student without background in *any* of those will not be very likely to succeed in this project in the time allotted for GSoC, IMO. -- Garrett D'Amore Sent with Airmail On February 27, 2014 at 11:06:22 AM, Adam Števko (adam.ste...@gmail.com) wrote: Hi, another possible project for GSoC could be adding TRIM support in illumos. According to my information, only some sd driver modifications are needed. SSDs are becoming more widespread and illumos is the only OS which does not have proper TRIM support I know about. Is this a suitable task for GSoC? I suppose there are many engineers on the list with needed expertise, who could mentor a student. Cheers, Adam On Feb 15, 2014, at 1:35 PM, ken mays maybird1...@yahoo.com wrote: Hello, Note: OI is nothing more than a 'server OS' distribution with additional software. Leave it at that. OI surely can mentor students as there are 'students' that already work on that project. As for illumos, I note that there 'should be' a general focus on projects that a group of students can work on for the summer or accomplish in the 3-month span. Porting device drivers is such a task. Many 'experts' here on kernel and device driver programming. I'd like to see students work on USB 3.1/Thunderbolt 2 drivers for illumos. A few storage partners use illumos and supporting device drivers related to storage makes sense - not so much graphic drivers. That brings into focus the reality of how illumos is being used on the 'bigger scale' of things. The illumos kernel developers that can mentor students based on projects they may work on internally and can hopefully lead that work into future jobs for the student or a great job reference. As for OI GSoC, a project like 'Implement the 2013Q3 Intel Graphics Stack' is a great project which involves upstream's Xnv implementation. Note: I'd donate high-end graphic cards/workstations to students accomplishing those goals. Sincerely, Ken Mays On Friday, February 14, 2014 2:53 PM, Garrett D'Amore garr...@damore.org wrote: Lets all agree that we don’t want any simple efforts to just package software as part of GSoC, whether for any distribution. Let’s also agree that if some very compelling project (forward and innovative thinking, not just making illumos try to compete with Linux on Linux’s terms) for Desktop technology comes up, we can evaluate such a project on its merits, and consider it as a candidate for GSoC slots. Let’s also agree that opinions of folks not actively volunteering to mentor really don’t count for much here. Its the time on the part of the mentors and admin, and Google’s money at stake. Unless a project poses a risk to the “reputation” for illumos, it shouldn’t matter to other parties. Thanks. -- Garrett D'Amore Sent with Airmail On February 14, 2014 at 9:19:35 AM, Keith Wesolowski (keith.wesolow...@joyent.com) wrote: On Fri, Feb 14, 2014 at 04:20:43PM +, Alasdair Lumsden wrote: However there are plenty of people who do want to run it on the desktop, and who are you to tell them they should not do this? I'm not telling people what to work on, since they're not employed by me. I'm trying to make sure that the illumos community represents itself favourably and accurately to the wider world, especially when trying to recruit young engineers to work on our operating system. --- illumos-developer Archives: https://www.listbox.com/member/archive/182179/=now RSS Feed: https://www.listbox.com/member/archive/rss/182179/21239177-3604570e Modify Your Subscription: https://www.listbox.com/member/? Powered by Listbox: http://www.listbox.com illumos-developer | Archives | Modify Your Subscription ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev - signature.asc, 817 bytes___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] [developer] GSoC? Decision time....
Lets all agree that we don’t want any simple efforts to just package software as part of GSoC, whether for any distribution. Let’s also agree that if some very compelling project (forward and innovative thinking, not just making illumos try to compete with Linux on Linux’s terms) for Desktop technology comes up, we can evaluate such a project on its merits, and consider it as a candidate for GSoC slots. Let’s also agree that opinions of folks not actively volunteering to mentor really don’t count for much here. Its the time on the part of the mentors and admin, and Google’s money at stake. Unless a project poses a risk to the “reputation” for illumos, it shouldn’t matter to other parties. Thanks. -- Garrett D'Amore Sent with Airmail On February 14, 2014 at 9:19:35 AM, Keith Wesolowski (keith.wesolow...@joyent.com) wrote: On Fri, Feb 14, 2014 at 04:20:43PM +, Alasdair Lumsden wrote: However there are plenty of people who do want to run it on the desktop, and who are you to tell them they should not do this? I'm not telling people what to work on, since they're not employed by me. I'm trying to make sure that the illumos community represents itself favourably and accurately to the wider world, especially when trying to recruit young engineers to work on our operating system. --- illumos-developer Archives: https://www.listbox.com/member/archive/182179/=now RSS Feed: https://www.listbox.com/member/archive/rss/182179/21239177-3604570e Modify Your Subscription: https://www.listbox.com/member/?member_id=21239177id_secret=21239177-2d0c9337 Powered by Listbox: http://www.listbox.com ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] [developer] GSoC? Decision time....
Count me as a conditional mentor. I’ll go ahead and register. I really don’t want to mentor overseas people though — indeed I really only want to work with students who are able to meet in person at least once or twice during the period and over phone/skype at regular intervals. The rationale here is more about my ability to be an effective mentor than anything I have against remote workers in particular — the past few times I’ve mentored I just think I’ve not been effective at helping my students. -- Garrett D'Amore Sent with Airmail On February 13, 2014 at 9:14:40 AM, Albert Lee (tr...@nexenta.com) wrote: On Thu, Feb 13, 2014 at 11:02 AM, Garrett D'Amore garrett.dam...@gmail.com wrote: We have about 24 hours to decide whether we are going to do GSoC this year. Do we have mentoring volunteers and a coordinator willing to do so, and with sufficient time? I can mentor someone in So Cal, but experience is that most candidates for GSoC come from overseas. After talking to others, I've been convinced that it's a good idea to continue participating this year, and I'm willing to be the organisation admin provided we try to size projects appropriately to account for risk, testing and review. I'm working on the application. If anyone has strong objections let me know. If OI is interested in applying as well we should coordinate to see if a combined application is appropriate. Slots can be divided amongst the respective mentors. Gordon has volunteered as a mentor. -Albert -- Albert Lee tr...@nexenta.com Nexenta Systems, Inc. illumos-developer | Archives | Modify Your Subscription___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] [developer] GSoC? Decision time....
But they do. Openindiana is still the reference as the only disto that can build vanilla an unmodified illumos-gate. Unless that has changed? Resources are tight enough that if there are mentors for OI willing to help out I see no issue. Unless we have a larger number of mentors and viable candidates than slots. I doubt that is going to happen this year based on the responses so far. I also haven't heard any of OI developers offer to mentor so it may be a moot question. Sent from my iPhone On Feb 13, 2014, at 9:27 AM, Keith Wesolowski keith.wesolow...@joyent.com wrote: On Thu, Feb 13, 2014 at 12:13:42PM -0500, Albert Lee wrote: After talking to others, I've been convinced that it's a good idea to continue participating this year, and I'm willing to be the organisation admin provided we try to size projects appropriately to account for risk, testing and review. I'm working on the application. If anyone has strong objections let me know. If OI is interested in applying as well we should coordinate to see if a combined application is appropriate. Slots can be divided amongst the respective mentors. Sounds good; thanks, Albert. I'd prefer very strongly to have OI apply separately if they want to participate. A combined application encourages the belief that OI occupies a privileged position in the community relative to other distributions, which as we all know is not the case. I also fear that it might make it difficult to convey the right message around what illumos is and the type of work we're interested in sponsoring (namely, OS work). For the same reasons, I would also oppose a combined application with any other distribution. --- illumos-developer Archives: https://www.listbox.com/member/archive/182179/=now RSS Feed: https://www.listbox.com/member/archive/rss/182179/21239177-3604570e Modify Your Subscription: https://www.listbox.com/member/?member_id=21239177id_secret=21239177-2d0c9337 Powered by Listbox: http://www.listbox.com ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] mercurial is updated to 2.7
On Aug 19, 2013, at 6:11 AM, David Höppner 0xf...@gmail.com wrote: On 19 August 2013 15:01, Alexander Pyhalov a...@rsu.ru wrote: What determines this check? Can these checks be relaxed or onbld scripts are expected to fail with new mercurial? I think that are just versions know to work. It fails with other version unconditionally. That's right. There were problems with mercurial incompatibilities in the past, so the decision was made to hard code versions that had been tested. Most of ON development these days is done using git, but I think there may be some hold outs (Nexenta?) who still use hg. - Garrett ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Copyright for contributors - not in files, OI branded zones, binary compatibility
On Jul 22, 2013, at 8:57 AM, Alan Coopersmith alan.coopersm...@oracle.com wrote: On 07/22/13 07:30 AM, Garrett D'Amore wrote: unless it had explicit approval to do so from any joint contributors. Remember the terms of the Sun Contributor Agreement granted Sun co-ownership and the right to release the code under any license of Sun's choosing, such as a proprietary license in any Solaris 10 backport. Oh right. The SCA. Damn, forgot about that! - Garrett ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Copyright for contributors - not in files, OI branded zones, binary compatibility
On Jul 22, 2013, at 2:03 AM, Joerg Schilling joerg.schill...@fokus.fraunhofer.de wrote: Garrett D'Amore garrett.dam...@dey-sys.com wrote: CDDL should not contain changes to itself, nor additional copyright notices of any kind. Its inappropriate (and in violation of the license terms) to modify the CDDL license or boilerplate on code that you are not the sole author of. That boiler plate has *nothing* to do do with the copyright notices, except that without a copyright notice, it becomes impossible to verify *ownership* of the contribution, which is vital. I am not sure what you understand by boilerplate, but I believe that people usually understand by boilerplate the copyright notice that is typically at the beginning of a file. It is of course apropriate to change the boilerplate, in special as Sun agreed with the community to put CDDL version 1.0 only in that text and this text was later mofified to read any CDDL version… Sun should *not* have made any such modification to a file that had contributors to which it was note the sole owner, unless it had explicit approval to do so from any joint contributors. The CDDL itself forbids modification or alteration of the copyright or license notices. Now that Sun was sold to Oracle and Oracle stopped contributing to the project, we need to be very careful and I thus strongly recommend to change the CDDL boilerplate to again contain CDDL version 1.0 only in case someone edited a file. Without doing that, Oracle could in theory create a CDDL-1.x or a CDDL-2.x that says everything could be used by Oracle as closed source. Yes. Its actually a little worse than that -- the boilerplate *itself* is possibly subject to copyright, and using Sun's boilerplate in new files may actually require crediting Sun/Oracle with joint ownership. These problems are precisely why I've authored new boilerplate, stating explicitly 1.0, made the boilerplate public domain explicitly, and posted that boilerplate in usr/src/prototypes. I encourage anyone writing *new* files to use those files as starting points. For folks editing existing code, if the file already carries a notice you cannot modify if. But if the license does not already explicitly say 1.0, you can insert a new notice like this: /* * Portions Copyright 2013 Joe Contributor. Contributions by Joe Contributor are made available under * the terms of the CDDL 1.0 only. */ That makes it pretty clear. :-) - Garrett 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] Copyright for contributors - not in files, OI branded zones, binary compatibility
On Jul 22, 2013, at 9:48 AM, Jim Klimov jimkli...@cos.ru wrote: On 2013-07-22 17:59, Garrett D'Amore wrote: On Jul 22, 2013, at 8:57 AM, Alan Coopersmith alan.coopersm...@oracle.com wrote: On 07/22/13 07:30 AM, Garrett D'Amore wrote: unless it had explicit approval to do so from any joint contributors. Remember the terms of the Sun Contributor Agreement granted Sun co-ownership and the right to release the code under any license of Sun's choosing, such as a proprietary license in any Solaris 10 backport. Oh right. The SCA. Damn, forgot about that! Would I be wrong to assume that this was in place for OpenSolaris code (and indeed Oracle closed up their Solaris), while the new illumos contributors did not sign an SCA with Sun and thus are not subject to its terms? Did the (ex-)Sun/Oracle employees, including those currently active in illumos community, sign it? Even if yes, does it hold valid for post-split codebase? I think this needs a lawyer to answer. My feeling is that even for those of who did sign the SCA (I did), I think it would be difficult for Oracle to state that contributions to illumos constitute contributions to OpenSolaris and are therefore subject to the SCA. If they did, I'd be willing to go to court to fight that. - Garrett ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Copyright for contributors - not in files, OI branded zones, binary compatibility
The prototypes follow this (the following is the file usr/src/prototypes/README in illumos-gate): To ensure that everyone can use the same boilerplate text without triggering copyright ownership because of the boilerplate itself, I hereby place the following text in the public domain, which should be used to reference the CDDL version 1.0 for each new file introduced in illumos. - Garrett D'Amore /* * This file and its contents are supplied under the terms of the * Common Development and Distribution License (CDDL), version 1.0. * You may only use this file in accordance with the terms version * 1.0 of the CDDL. * * A full copy of the text of the CDDL should have accompanied this * source. A copy of the CDDL is also available via the Internet at * http://www.illumos.org/license/CDDL. */ /* * Copyright 2012 contributor. All rights reserved. */ On Jul 22, 2013, at 12:10 PM, Joerg Schilling joerg.schill...@fokus.fraunhofer.de wrote: Alan Coopersmith alan.coopersm...@oracle.com wrote: On 07/22/13 09:19 AM, Joerg Schilling wrote: Well, the CDDL does not mention unmodifyable parts, http://opensource.org/licenses/CDDL-1.0 section 3.3: You must include a notice in each of Your Modifications that identifies You as the Contributor of the Modification. You may not remove or alter any copyright, patent or trademark notices contained within the Covered Software, or any notices of licensing or any descriptive text giving attribution to any Contributor or the Initial Developer. But this does not cover the CDDL template text... ...anyway, this template text needs a change in any case as opensolaris.org is no longer existent. http://www.opensolaris.org/os/licensing does not reproduce the license text. 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] Copyright for contributors - not in files, OI branded zones, binary compatibility
On Jul 17, 2013, at 7:19 PM, Nikola M. minik...@gmail.com wrote: On 07/17/13 11:15 PM, Alexander Pyhalov wrote: Nikola M. писал 17.07.2013 21:47: OI Hipster, (illumos-5c069a6) , last two updates have Xchat dumps core /crashing and X lock have no OI logo. About xchat - I've tried it. It didn't dump core, but at start complained about some symbols in tcl libraries. Perhaps, it also should be rebuilt. We need to do something with JDS... It will be always broken if we don't have a tool to automatically rebuild it. --- System Administrator of Southern Federal University Computer Center Hi, I was just looking around changes in hipster, And then I saw this: # Copyright (c) 2013 Alexander Pyhalov (https://github.com/OpenIndiana/oi-userland/commit/ab3ce40009249e514e51b0af8d2b8fee490c631a) Please remove this from everywhere it is, since it feels a bit stupid to put one person credit in there/anywhere in changed files, moreover, that is not the place for that as I know, but in changes logs. It is whole distribution copyright file, it is not part of CDDL and I feel like those making changes should, like, restrain themselves from putting such things in the distribution. While I don't have any particular interest here, I will say that copyright ownership and attribution is up to the contributor to determine. The distro can choose to make certain policies, but as for *illumos*, we encourage everyone to assert their copyright as they contribute. We believe that the community is better protected by having a widely distributed ownership, as that makes it much harder for some other entity to pick up the source and close it up. :-) changelogs are the place to record changes, not to record ownership. ownership -- in the form of copyright notices -- is best asserted as close to the content being claimed as possible. For files, that is usually in the file itself. :-) Just a thought, before someone important (not me) starts complaining.. of putting your own Copyright everywhere. You use CDDL, you don't need your copyright _anywhere_ in the distro.. You're wrong on that point. CDDL is the *license*. The license means *nothing* without an *owner*, which is what Copyright establishes. - Garrett Oh yes, I would also like to have some testing before even hipster gets out, these things (like breaking firefox, etc, did not happen ih Hipster until now). I am interested in learning how to update things, etc, too. (JDS etc) What would happen to the rest of the apps if changes are such that applications stops working on a large scale? (Solaris was always proud of backward compatibility on binary level) It could be thinking about having OI-branded zones, that could have applications from OI /dev 151a8 running if older executables start failing on hipster on a larger scale. (like it seems they are failing with the recent changes) Nikola M. ___ 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] Garrett D'Amore interview
Yep. The original questions were different, but reflected a misunderstanding on Chris' part. To be completely honest, I'd rather have either left the original questions as is, or redone the interview after the original misunderstanding about my role with OI was cleared up. - Garrett On Jun 23, 2013, at 10:30 PM, Jonathan Adams t12nsloo...@gmail.com wrote: It probably would have been better if you'd asked him questions about Illumos. It's not quite the same as asking Xerox about Windows XP, but it kinda has the same feel :) Jon On 23 June 2013 11:31, Chris Jones c/o Unixmen chrisjo...@unixmen.com wrote: Hi Garrett. Our interview has been published at Unixmen. See here. http://www.unixmen.com/exclusive-interview-garrett-damore/ Regards Chris Jones ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Nfs 4.1 / pnfs
Vitaliy's work is incomplete, and probably cannot be used without substantial effort. I'm not aware of *any* NFS v.1 implementations that operate properly on either illumos or Solaris. - Garrett On Jun 17, 2013, at 11:09 AM, Randy S sim@live.nl wrote: Hello all, I'm looking into the use of nfs 4.1 / pnfs in OI. I have found https://bitbucket.org/gusev_vitaliy which is , I believe, an implementation of nfs 4.1 in illumos. However, I cannot find any more info on how to go about implementing it and or if there are any dependencies to take care of. Maybe somebody here can push me in the right direction to use nfs4.1 / pnfs in OI (or any illumos based distro) Kind regards, Randy ___ 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] Nfs 4.1 / pnfs
On Jun 17, 2013, at 12:43 PM, Randy S sim@live.nl wrote: Thanks Garrett for your answer. Btw, I was under the impression that nexenta also uses an illumos based distro with these nfs versions active as a base for one of their storage clusters. When I left, they had been using a bunch of patches from illumos, applied on top of onnv_134. Really really stale. They had some local changes, but the NFS v4.1 code was at that time not deemed ready, and it was deprioritized. What may have happened since then, who knows? Originally the update to a modern illumos was schedule for NexentaStor 4.0, but I think it would be fair to grant that release the moniker Duke -- as in Duke Nukem Forever. :-) Like DNF, the NexentaStor 4 may someday release, but it will be so far off schedule that there are few users who remember what the schedule was supposed to be. :-) I have just read a thread on the Oi discuss list where somebody succeeded in deploying glusterfs I believe. My goal is to achieve redundant / fail-safe data storage accross multiple nodes . Now I'm not that familiar with GlusterFS but I'm going to read up on that, especially in combination with ZFS Sure. At one point Ceph was also looking at ZFS as a backing store. Be aware that cluster filesystems are *not* a silver bullet -- they require extra planning, and many of them have unfortunate performance or semantic characteristics. (Usually you have to trade off either performance, or consistency guarantees.) Shared storage clusters are often simpler to set up, with more understandable performance characteristics. (They do cost more though, usually.) Of course, application level redundancy is almost always better, if your application can support it. - Garrett Thanks for your input. Randy From: garrett.dam...@dey-sys.com Date: Mon, 17 Jun 2013 12:25:52 +0400 To: oi-dev@openindiana.org Subject: Re: [oi-dev] Nfs 4.1 / pnfs Vitaliy's work is incomplete, and probably cannot be used without substantial effort. I'm not aware of *any* NFS v.1 implementations that operate properly on either illumos or Solaris. - Garrett On Jun 17, 2013, at 11:09 AM, Randy S sim@live.nl wrote: Hello all, I'm looking into the use of nfs 4.1 / pnfs in OI. I have found https://bitbucket.org/gusev_vitaliy which is , I believe, an implementation of nfs 4.1 in illumos. However, I cannot find any more info on how to go about implementing it and or if there are any dependencies to take care of. Maybe somebody here can push me in the right direction to use nfs4.1 / pnfs in OI (or any illumos based distro) Kind regards, Randy ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.orghttp://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] Fwd: 52 OpenSXCE Screenshots documenting x86/x86_64 LiveDVD install
I didn't see a twitter friend request but to be honest I rarely even use twitter. I would not make too many decisions based on my twitter activity (and mostly lack thereof) if I were you. I will contact you out of band to discuss other items. Sent from my iPhone On Jun 1, 2013, at 3:34 PM, Martin Bochnig mar...@martux.org wrote: -- Forwarded message -- From: Martin Bochnig mar...@martux.org Date: Sat, Jun 1, 2013 at 10:31 PM Subject: Re: 52 OpenSXCE Screenshots documenting x86/x86_64 LiveDVD install To: develo...@lists.illumos.org, disc...@lists.illumos.org On Sat, Jun 1, 2013 at 8:45 PM, Martin Bochnig mar...@martux.org wrote: http://www.opensxce.org/images/screenshots/ I'm not sure if Illumos actually deserves me, OpenSXCE or all the Illumos logos in OpenSXCE. OpenSXCE is the vsuccessor to MartUX, and I worked on it since 20050614. Garrett does not even accept me as twitter friend, and nobody from the commercial Illumos sponsors ever offered me anything. Not 1 dollar, no job, no help. Maybe I should cut all Illumos advertisements from OpenSXCE. And offer it commercially. You folks love imperialism??? Then take it. -- regards %martin bochnig http://svr4.opensxce.org/sparc/5.11/ http://opensxce.org/ http://wiki.openindiana.org/oi/MartUX_OpenIndiana+oi_151a+SPARC+LiveDVD http://www.youtube.com/user/MartUXopensolaris https://twitter.com/MartinBochnig ___ 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] Fwd: 52 OpenSXCE Screenshots documenting x86/x86_64 LiveDVD install
We should chat on Skype. I can certainly add you on twitter. I do think that if you can commercialize it, then it's worth doing. I know that there are folks who would like to be able to pay for commercial support for a Solaris 10 compatible upgrade. There are challenges of course but I think it may be worth following up on. As for other employers I know that most of the work I have is not in Germany but in Saint Petersburg RU and in Cambridge UK. That said if you are hungry I can see if I can find some tasks for you to perform. But of course your attitude on the mailing lists is sometimes very disruptive and counterproductive to your efforts. Comments like the ones you made about me don't make me immediately want to commence new work with you. Something for you to think about. - Garrett Sent from my iPhone On Jun 1, 2013, at 3:34 PM, Martin Bochnig mar...@martux.org wrote: -- Forwarded message -- From: Martin Bochnig mar...@martux.org Date: Sat, Jun 1, 2013 at 10:31 PM Subject: Re: 52 OpenSXCE Screenshots documenting x86/x86_64 LiveDVD install To: develo...@lists.illumos.org, disc...@lists.illumos.org On Sat, Jun 1, 2013 at 8:45 PM, Martin Bochnig mar...@martux.org wrote: http://www.opensxce.org/images/screenshots/ I'm not sure if Illumos actually deserves me, OpenSXCE or all the Illumos logos in OpenSXCE. OpenSXCE is the vsuccessor to MartUX, and I worked on it since 20050614. Garrett does not even accept me as twitter friend, and nobody from the commercial Illumos sponsors ever offered me anything. Not 1 dollar, no job, no help. Maybe I should cut all Illumos advertisements from OpenSXCE. And offer it commercially. You folks love imperialism??? Then take it. -- regards %martin bochnig http://svr4.opensxce.org/sparc/5.11/ http://opensxce.org/ http://wiki.openindiana.org/oi/MartUX_OpenIndiana+oi_151a+SPARC+LiveDVD http://www.youtube.com/user/MartUXopensolaris https://twitter.com/MartinBochnig ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI 'hipster' reboot effort
On May 18, 2013, at 8:49 AM, David Höppner 0xf...@gmail.com wrote: no. Discussion was about discontinuing the 32-bit kernel and to enable 64-bit usr/src/cmd. Userland will be 32- and 64-bit. Upstream oracle builds 32- and 64-bit libraries, while standalone programs are converted to 64-bit only. And I think that's a great approach for illumos to take as well. We have to support the 32-bit run time probably ~forever, but we can stop delivering 32-bit *commands*; especially we should not deliver both 32-bit and 64-bit programs -- assuming we are not also delivering a 32-bit kernel. I'd possibly be OK with the concept of moving 32-bit x86 into a fork of illumos (another arch port, along the difference between sparc and x86), so that folks / distros who wanted to deliver a 32-bit system for older CPUs could still do it, but without burdening everyone else (and also without making the 32-bit build carry the 64-bit stuff either. :-) - Garrett -- David On 18 May 2013 07:13, Branden Harper bhar...@chaosweb.us wrote: Along those lines: there was some discussion about discontinuing 32 bit support in OI. Is this project planning to move to 64 bit only? On May 17, 2013 10:12 PM, Colin Ellis panamaya...@gmail.com wrote: Hi Andrej, is there a bug tracker for this branch and a list of required package updates somewhere? I'd like to prioritize my efforts in line with what others need. Also what compilers are used on this new hipster release? On Fri, May 17, 2013 at 7:14 PM, Andrzej Szeszo asze...@gmail.com wrote: Hi All Seeing that the project is slowing down a bit, I have decided that I will try to help it get some momentum back. Firstly, if you rely on stable OI releases, Jon Tibble will carry on producing traditional releases and they will be made available in the /dev repo and as installable ISO/USB images. OI 151a8 should be out real soon now. /dev releases follow traditional Sun/Oracle releng process, which is very time consuming. Mainly for that reason it may take a very long time before any build system update will be reflected in the package repository. OI 'hipster' is trying to change the process by switching to a rolling release model. There is single top-level build repo on Github: https://github.com/OpenIndiana/oi-userland. If you want to change something or add new packages - simply send a pull request. Changes to the build repo are automatically picked up by Jenkins instance, packages are built and then published to the http://pkg.openindiana.org/hipster repo. It is all set up and working now. http://pkg.openindiana.org/hipster repo currently consists of /dev contents + JT's /dev-test OI 151a8 bits + Milan Jurik's JDS work + Jenkins built packages. The plan is to improve what's out there incrementally. Eventually it should be possible to build complete OS from the Github repo. To use /hipster repo, install OI 151a7 and run (as root): pkg set-publisher -O http://pkg.openindiana.org/hipster openindiana.org pkg update -v Few people started submitting changes already. Thanks for that! If you have something to be added or changed in the repo, simply send us pull request. Couple useful links: Jenkins dashboard: http://hipster.openindiana.org:8080/ Component build logs: http://hipster.openindiana.org/i386/logs/ Andrzej ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI project reboot required
On May 12, 2013, at 9:05 AM, Magnus mag...@yonderway.com wrote: On May 12, 2013, at 12:02 PM, Jim Klimov wrote: I believe, 32-bit should be retained. While it is of little utility for ZFS and other huge-RAM jobs, it may be required for some netbooks, older hardware repurposed for tests and SOHO servers, as well as for resource-constrained testing VMs. So I'd vouch for this fork/patch approach if this upstream is still followed. Not to mention intriguing projects like http://wiki.illumos.org/display/illumos/Raspberry+Pi+Bring-Up ARM11 is only 32-bit, and has nothing to do with the discussion of whether we would retain *x86* 32-bit mode support. - Garrett ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI project reboot required
On May 12, 2013, at 11:31 AM, Jim Klimov jimkli...@cos.ru wrote: On 2013-05-12 19:06, Garrett D'Amore wrote: So, out of curiosity -- *who* is actively running illumos on 32-bit kit today? I'm not interested in hypothetical uses or kit that is sitting around in your garage waiting for you to do something with it…. I'm interested in people who would be immediately impacted and severely so if illumos were not available on 32-bit CPUs right now. (To give a counter example: I have a 32-bit Atom netbook, that I have OpenIndiana on. I turn it on once every year or so… if that often … so I can't seriously claim that I would be negatively impacted if illumos were to move to 64-bit only.) Indeed, I can't vouch for such systems, even my old home-NAS which was my first victim of illumos/OI endearment had a Pentium-D with x86_64 support (though likely not virtualization acceleration features - which would IIRC require VMs to be 32-bit). This box would be in my production today, had it not broken while I am on a prolonged trip away from that home; but it won't be impacted by a 64-bit only OS, indeed (it did have some VMs for a test farm though, and they might be impacted). Your VMs should be migratable to a more modern hypervisor, if the one you have can't run x64. Also I know of many small (SOHO) storage boxes which can be made to work with OpenSolaris and illumos-based OSes, and of those only the HP N36 and N40L have (known to me) 64-bit AMD CPUs and ECC support; most other such boxes are built around Atom, and often 32-bit with some 2GB RAM. While this is not interesting for intensive production use, some users of these boxes as reliable (ZFS) home storage might be hurt by move to 64-bit only OS. Arguably though, lack of ECC did probably burn my home-NAS causing some corruptions poorly-explicable otherwise. While I wouldn't recommend non-ECC ZFS NASes for any use, at least as a newly built rig, people that have a black box which just works, and aren't keen on spending time and money to buy and setup regular upgrades, are kind of stuck with it until the HW dies. The thing is… most of these in place systems aren't likely to want or need the continuous stream of updates. We can argue about bug fixes, and security considerations, but your average home NAS isn't sitting out there exposed on the internet. Anyone building a new box like this would use a newer Atom that supports x64. (And Atom is entirely unsuited to this due to lack of ECC, as you mentioned, but hey, most SOHO users don't care about that, although they should. The ones who use ZFS because they worry about silent data corruption are probably *also* smart enough to understand the risks of running without ECC.) I think *most* users of these SOHO boxes are *not* using illumos, even those who use illumos in other capacities, but are instead relying on FreeNAS, or the commercially supplied solution. - Garrett ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI project reboot required
I have a hard time believing you would choose to switch to Linux instead of taking the time to upgrade the hardware. A two or three year or even five year old system will probably be a big upgrade and cost less than the labor to switch to Linux. Sent from my iPhone On May 12, 2013, at 12:13 PM, Dmitry Kozhinov d...@desktopfay.com wrote: I am running a small web and ftp server at university on a 32-bit AMD Athlon. So I would be affected. However I cannot argue for retaining 32-bit support in OI, because any baggage certainly should be dropped in order for OI project to proceed. I can upgrade the hardware (unlikely); I can switch to Linux (reluctantly). - Dmitry. So, out of curiosity -- *who* is actively running illumos on 32-bit kit today? I'm not interested in hypothetical uses or kit that is sitting around in your garage waiting for you to do something with it…. I'm interested in people who would be immediately impacted and severely so if illumos were not available on 32-bit CPUs right now. ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI project reboot required
Don't misunderstand me. I want to eliminate 32 bit kernels and delivery of certain 32 bit versions of system utilities. This should in no way affect any 3rd party apps. We need to keep the 32 bit app runtime for the foreseeable future. Sent from my iPhone On May 12, 2013, at 12:51 PM, Nikola M. minik...@gmail.com wrote: On 05/12/13 07:10 PM, Garrett D'Amore wrote: On May 12, 2013, at 9:02 AM, Jim Klimov jimkli...@cos.ru wrote: I believe, 32-bit should be retained. While it is of little utility for ZFS and other huge-RAM jobs, it may be required for some netbooks, older hardware repurposed for tests and SOHO servers, as well as for resource-constrained testing VMs. So I'd vouch for this fork/patch approach if this upstream is still followed. We've been doing this for years now. I'm now starting to think -- 3 years later on -- that this argument feels specious today. Who runs illumos on a netbook? I did, once. Not any more. (And modern netbooks have 64 bit support!) Older hardware must be *really* old. Over 5 years. For servers, probably over 10 years. I've thrown away my Pentiums and Pentium IIs. I suppose there could be some Pentium IIIs and IVs out there, or AMD Athlons (pre-Athlon64), but they'd all be really really slow by today's standards. Do people run illumos on such kit? I'm highly doubtful, unless that kit is around just to answer the question of whether 32-bit kernels still work. :-) Maybe it's called backward compatibility. I think Firefox and Thunderbird are 32-bit. Isn't the Multiarch what defined Solaris, like always? I don't want we should loose Solris10 zone if someone needs that in some moments untill some moment in the future. (There are still people not migrated from S10) There is still many older computers that could be useful with Illumos distro. Some Oracle decisions are a bit also insane, like removing support for Floppy disk (why removing when not already used much) and support for Smart card identification for a Workstation/server. Openindiana, Illumos have also an advantage of supporting older hardware, that Oracle removed support for. We should not forget that market of people using Just FINE servers that large corporations throw out but could be used for years. Removing support for still widest-supported architecture on the planet could be a bit short-sighted in our current market position (not counting those high-end cloud Illumos consumers, but ordinary people). If there is some netbook that needs to be used, or older but fine notebook as a control console, Illumos distro could work on it for years, since one of the `advantages` of slow development moving of Illumos could be lower need of changing hardware over years. Or bigger stability and backward compatibility. Of course, nothing is set in the stone, it will be how developers want. If 32-bit needs to be moved to separate place or cut of from newest advanced be it. But not if it is not necessary. GDA: Will there ever be Release or Version of Illumos? Unlike current rolling-releases? Will Illumos ABI,API remain stable, like on Solaris? ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI project reboot required
On May 11, 2013, at 10:05 AM, Nikola M. minik...@gmail.com wrote: On 05/10/13 02:19 AM, Garrett D'Amore wrote: more constructive than whinging about it will be to find ways to either a) make a commercially viable case for it so people can get paid to work on it, or b) lead a volunteer effort to make this work. I think that without Desktop that is running on the server, I can not sell Illumos based distribution as a server product. That is because small companies and offices expect to have GUI working, so they can log in and possible do something with the machine. I suppose that machine without GUI would look to them as a blackbox if there is just command line. And yet, many people are building products on top of illumos that *are* selling well, and don't provide a graphical login (at least not in the traditional sense -- some of them offer a browser based login.) SmartOS, Nexenta, GreenBytes, etc…. even Sun traditionally sold more headless systems than systems with a graphical desktop. (All those rack mount systems don't need a graphical desktop -- but they *should* offer a compelling experience using other management tools -- like Browser or native mobile apps to help with systems management.) There is no desktop per se and server as a product per se. It is the server distribution that has desktop environment and programs for convenience. If I am selling it, I am selling a server. And having Desktop environments on server is nice. Not having desktop environment on server in 2013 is NOT NICE. Actually, I think this attitude is dated for the reverse reason. In 2013 *desktop* doesn't matter, and that trend has only been accelerating. Because people access their systems using their personal Macs, or more often using thin clients (tablets, mobile devices, etc.)… 10 years ago your arguments were much more valid, IMO. The question is no longer about whether I need a desktop UI on my server, but is now moving to whether I need a desktop at all. (I think a bunch of us *do*, but we're a shrinking population.) [ cut! ] One thing many people do not realize is that because of advanced Illumos technologies, Illumos-based distributions have a potential to be super-desktops in some future. Maybe that IS insane, but I tend to see the future where I use GUI to manage servers and do things I can not do with CLI-only. Hey, now you're talking! If were (or anyone) is going to invest in an illumos desktop, why not do it in a way that makes sure that what we're doing is *better* than just another Linux distro. Trying to keep playing catchup with Ubuntu is IMO a wasted effort. If on the other hand you can *surpass* them in some meaningful ways, *then* you've got my attention. The problem is that nobody has been able to do that yet. If Fedora would ditch desktop upon install, and Ubuntu started releasing only server edition without Desktop environment, what would be left of them selling to customers? (Even if server do not run Desktop) What would you show to them on the presentation? Black screen of 1985? They show GDM today. But who really cares about that? Of the people who are decision makers in any company, how many of them choose a Linux graphical desktop? The exception here is the Chromebook experience and OLPC…. they were able to do something cool and make a compelling argument. But nobody else has built a compelling Linux or Unix desktop with a reason to exist besides being free. And there is no commercial value in just being free -- you can't make up in volume unless you have some revenue. :-) I always planned to eventually sell Illumos distro as a server, but I want a customer to SEE it and say: OK, NICE, whatever. And not: Oh, no.., whatever. And that is how money could flow. If I have something to contribute back , but without GUI, I don't think it can sell. I think if you believe your buyers care about the desktop, then I think you probably don't understand your buyers. Or possibly I don't understand your market -- but in the *server* space almost *nobody* cares about the desktop UI. - Garrett ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Orange Indiana?
On May 10, 2013, at 9:27 AM, Martin Bochnig mar...@martux.org wrote: The question remains, if it really needs to be IPS based. Or if it can be SVR4 and CSW style pkgutil.net. If you read Garrett's mails he also asked this question from time to time, just the day before yesterday again. *illumos* uses IPS. That's not likely to change anytime soon, if only because the pain of changing packaging systems is too high a cost to bear. That said, its *easy* to make systems that take IPS metadata, and build binary packages in various other formats. Its been done many times -- IPS to tar, IPS to SVR4, and IPS to .deb. I've even written an image builder that parses IPS using shell scripts. Easy peasey. So a distro can choose whatever format they like. I recommend (highly) continuing to use IPS metadata as the source form, if only because it is the only packaging format that actually aims to completely describe the resultant end-system in parseable metadata rather than relying on scripting languages to help out. (SMF boot helpers notwithstanding….) This would mean that others could use the source formats to deliver whatever binaries they like. But rather than just getting lost in endless discussions, I rather continue with the long promised (delayed) x64 version ... Then you can better feel if it would be acceptebable to you (SPARC users can already test, but as far as I understand it, few of you still have a SPARC). Actually I suspect lots of us still have SPARC kit in garages, closets, etc. Just most of us long since turned them off due to poor tradeoffs. (High noise, high heat, power consumption. Low performance -- at least the sparc kit that most of us have laying around.) The src and pkgdefs are here and I'm willing to release everything. Doing it properly by committing change after change into hg can take decades. So either I just create diffs or upload tar's or create a history-less hg or what you want. Nice work Martin. :-) I like your style (delivering the work rather than discussion about the work. :-) - Garrett regards %martin bochnig http://svr4.opensxce.org/sparc/5.11/ http://opensxce.org/ http://wiki.openindiana.org/oi/MartUX_OpenIndiana+oi_151a+SPARC+LiveDVD http://www.youtube.com/user/MartUXopensolaris https://twitter.com/MartinBochnig ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI project reboot required
Fundamentally, the question you all should be asking is, what is the purpose of the project? The problem with OI has always been lack of a clear vision. The original purpose, to be a free community-run clone of Solaris 11, had no future. It was doomed to fail because it was an attempt to follow a leader who who did not want to be followed and was making changes that specifically made such an attempt extraordinarily difficult (like changing closed source dependencies) -- and the leader had also itself lost its vision, or at least altered it, such that it was never going to the same places that the folks behind OI wanted to go. I'm a big fan of trying to build cool and interesting technologies. Of innovation. Can OI innovate? Its not clear to me. Thankfully, *illumos* is certainly innovating. Other distros are innovating. Some in cases that lead very very far from the vision or model of OI. (SmartOS has led the way the most -- challenging many of us to rethink how we manage systems, in ways that ultimately have been extremely beneficial for those who were able to cross the cognitive hurdles presented by its new administrative model.) Can OI find a niche that sets itself apart from excellent options like SmartOS and OmniOS? Is there even a purpose to such differentiation? I don't know the answers to these questions. I do think that there is always going to be substantial tension between those who want to keep compatibility with their old stuff (whether the old stuff be legacy closed source applications, scripts that they wrote 15 years ago, decades old SPARC kit, ancient laptops, or 10 Mbps ethernet with AUI transceivers), and the people who want to innovate and explore modernization (Gary Mills' work to support login names 8 characters is a prime example of this tension). Its a tricky balance to find, and many of the hardest working people (Martin Bochnig comes to mind, for example) are firmly in the don't break my old stuff camp. The problem is that this camp is inherently change resistant -- and yet fundamentally OI was already too different from previous Solaris releases to satisfy those folks. Where this is leading me is this…. 1. Is there enough market demand/interest/skills/resources to justify a legacy style distro (something more like Solaris 10 than Solaris 11/OI, including SPARC distro support, etc.) It seems there is almost enough talent here -- perhaps if those forces worked together more collaboratively we'd see something good come about? 2. Is there a need for a more forward looking distro apart from the work being done in OmniOS? (To be clear, I'm not affiliated with OmniTI in any way -- I just hate to see pointless duplication of effort) Again, I don't know the answers to these questions, but I *strongly* believe that anyone thinking of stepping up to reboot the OI project (or create any new one) needs to have a much clearer vision -- and needs to be a strong enough leader to more or less enforce this vision. A democracy here won't work -- precisely because of the pressures I've already indicated. In my opinion it would be better to spawn two separate projects, each of which creates value to serve their adherents, than to have single project that cannot make any progress because of the inherent inability to resolve the differences between the two main camps. What I *will* say is this… regardless of what happens, I'm very pleased that illumos will carry on -- and continues to be a home for innovation, thanks in no small part to the efforts of folks like Joyent, OmniTI, Nexenta, DEY, and perhaps many others who've been working more quietly. I'm incredibly grateful to the team that put OI together -- it filled an important gap in the ecosystem, and contributed significantly to the uptake of illumos -- so regardless of what ultimately becomes of the project, a big thank you to the various parties who put it together. - Garrett On May 9, 2013, at 1:01 AM, Andrzej Szeszo asze...@gmail.com wrote: Hi All (Instead of replying to a message in one of the other threads I thought I will create a new one.) Just wanted to say that I don't see a future for the project in its current form. There is simply too many packages and too much baggage for a handful of people to look after. I think the project needs a new vision and a reboot. If you have any ideas for the project and can write scripts/makefiles to generate a distro/live CDs/etc. - speak up! You don't have to be a leader if you don't want to :) Regards, Andrzej ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI project reboot required
On May 9, 2013, at 1:05 PM, Milan Jurik milan.ju...@xylab.cz wrote: Hi, OK, so start yet another distro :-) OI needs one thing it does not have - release engineering team. Jon is too busy and I cannot do that. I am happy to work on some things from time to time for fun but my job is more and more time consuming and I enjoy it (and my private life also). And to be fair, with total lost of interest in desktop systems in Illumos by core team, I have less and less motivation to work on it. I'm not sure who the core team for illumos is -- I'd guess I'm part of it, since I started the darn project, but we don't have any definition of core team, apart from the Developer Council. As the developer council is made of up some of the most widely recognized illumos/Solaris leadership, and almost *never* actually makes any official decisions, its hard to say there is any group of people that you'd say has no interest in desktop systems. What *is* true is that there is zero commercial investment in illumos on the desktop, while there is substantial commercial investment on server side innovation. This is not a bad thing -- we (the commercial investors in illumos -- the folks who use and develop it as part of our day jobs) simply recognize that like any tool, illumos has some tasks that it is well suited for, and others where other tools make more sense. Some may attribute this type of thinking to nefarious purposes, but it really comes down to something much much simpler. Economics. Maintaining a desktop capable system is *hard*. Making one that can compete against capable offerings from Apple, Microsoft, Google, and Canonical is *really* hard. And *those* guys are fighting a battle to keep the very desktop itself, relevant, in the face of tablet devices. And so how do you make a commercial case for investing in illumos on the desktop? There are some specious arguments for supporting legacy uses, facilitating developer adoption, etc., but none of them have actually borne fruit, and there are known non-trivial hurdles for such cases. Indeed, the very failure of OpenSolaris itself can be cited as an example of this failure -- Sun with not inconsiderable investment and resources, was unable to make a commercially viable desktop based on Solaris technology, even though they were clearly willing to do so even at the *expense* of their otherwise lucrative server business. So most of us have learned from those failures (even though they may not have been our own), and moved on. (Admittedly there are still people in Oracle working on the Solaris desktop, but AFAICS that mostly amounts to acting as a gateway to Microsoft systems via Rdesktop, or acting as a glorified webtop / kiosk front end. And I think you'd be hard pressed to show those efforts as being profit centers within Oracle. They're mostly seen as supportive of Oracle's other more core business needs.) Upshot, *today* anyone who thinks there is a commercial future in illumos on the desktop is probably smoking something. There are a few people who would be willing to pay for it, but it needs more than a few dozen people willing to pay a couple hundred dollars (more often substantially less) to make this a viable and interesting (economically) venture. What that means is that illumos desktop technologies have been relegated, at least for the time being, to the realm of hobbyists. In some cases, very talented hobbyists -- even in some cases people who work professionally on illumos server technologies --, but hobbyists nonetheless. All this said, I'd love for someone to come up with a believable, realistic story for making a commercial desktop product on illumos. I think it would be good for illumos. But in the absence of more compelling evidence to the contrary, I'd question the sanity, or sobriety, of anyone who seriously thought that commercial investment in illumos on the desktop made sense today. - Garrett ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI project reboot required
On May 9, 2013, at 4:00 PM, Bob Friesenhahn bfrie...@simple.dallas.tx.us wrote: On Thu, 9 May 2013, Garrett D'Amore wrote: Upshot, *today* anyone who thinks there is a commercial future in illumos on the desktop is probably smoking something. There are a few people who would be willing to pay for it, but it needs more than a few dozen people willing to pay a couple hundred dollars (more often substantially less) to make this a viable and interesting (economically) venture. There is little commercial future in the desktop for Linux distributions as well yet almost all of them have a graphical desktop. Admittedly true. And yet, most of them *started* on the desktop. Linux's roots are in the desktop. Most of those distros took off because they had a groundswell of support from developer users who wanted it on the desktop -- they didn't have servers, and options like VMware simply didn't exist at the time. I'd argue that this is largely an artifact of history. I would be entirely *unsurprised* if distro vendors like RedHat and Oracle simply *ditched* their desktop support at some point in the future -- its clear to me at least that folks aren't running those distros on the desktop. In fact, I can't think of *anyone* who's paying for a desktop OS that doesn't come from either Apple or Microsoft. Availability of a graphical desktop is seen as a requirement for common acceptance. Historically true, but I seriously doubt it now. SmartOS is the counter example from this community. I think there are others. For example, OpenBSD was highly popular for a long time for its security emphasis, but I don't know *anyone* who ran it on a desktop. The widespread availability of virtualization like VMware, VirtualBox, and Parallels means that there is little need to take over the user's desktop to provide a reasonable environment. Most people these days develop using SSH, etc. The folks I know who use Linux would, apart from a few extremists, not care whether the desktop ran Linux, FreeBSD, or Solaris, as long as it Just Worked and provided a familiar UNIX-like backend. (I contend that these principles have lead strongly to the uptake of MacOS in the developer community…. I use an Apple laptop for my own environment, even though I wouldn't *dream* of using MacOS in a server capacity.) For me, Terminal.app and ssh is along with VMware gives me everything I need for doing cool things with illumos on my desktop. I explicitly *disable* the graphical login on illumos. :-) Much/most of the graphical desktop development taking place for Linux does not seem to be done by the companies which popularly peddle it (e.g. Canonical has been more of a desktop packager except for its useless Unity). Only partly true (Qt is the counter example). But yes, a lot of the desktop development in Gnome and company is done by community members who are passionate about this. And guess what -- almost all those guys are Linux bigots. There's a huge trend in those spaces to adopt technologies that are Linux-specific, to the point of near active hostility towards other FOSS. That creates a huge barrier for leveraging their efforts. Do we have the kind of volunteerism here to take up a duplicate effort? And why just duplicate? If we have *that* kind of interest and volunteerism, I'd recommend actually doing something *cooler* and better. Of course, that flies in the face of legacy compatibility…. The argument about no commerical future is becoming worn out and tired since that (commercial purpose) is not why OpenIndiana/Illmos users want to log into a graphical desktop. Worn out and tired it may be, and *yet* people complain about the lack of leadership and progress. I don't know about you, but I have to pay for housing, groceries, and gasoline (among other things). So I have to work at things that pay the bills. I am lucky enough that this maps well to things that are also interesting to me. Maybe its unfortunate that folks aren't finding ways to make a living at this, so that a developer community will spring up around it. But more constructive than whinging about it will be to find ways to either a) make a commercially viable case for it so people can get paid to work on it, or b) lead a volunteer effort to make this work. The problem with b is that its a very large, and often thankless, job. People spend more time complaining about broken things on the desktop, than they do actually helping fix things. Individual leaders get exhausted, and move on. This is a recurring theme in this community -- Nexenta desktop, StormOS, AuroraUX, OI, etc. So, it comes, for me at least, back to a. Figure out a way to make a commercially viable story so that you keep a small group of developers paid. Right now, I don't know of any such story, and when I bring this up, the responses like yours Bob, amount to nothing more than putting your head
Re: [oi-dev] State of development
I've tried to stay away from commenting on this thread, but…. The problem with OI is lack of sufficient man power and leadership. There are other problems as well (vision is one I referred to in the past). But most urgently, to keep OI going, with any kind of cadence, it needs more volunteers. The comments below point to lack of a plan . What's even worse than lack of a plan is lack of resources to *execute* a plan. Release a full desktop distribution is *non-trivial*, and the road is littered with failed efforts due to insufficient resource, or lack of sufficient motivation. (Nexenta used to have a desktop distro… that's how they started before they moved to storage -- the work/payoff ratio doing a desktop simply doesn't pay.) I'm happy to report that illumos' future is no longer tied to OI's. But I'd still love to see more folks pitch in and help drive it. As for myself, I simply haven't the time to do so; illumos and my own commercial venture (not to mention my family!) leave me little time for hobby work anymore. :-) - Garrett On Apr 16, 2013, at 6:17 PM, Chris Jones c/o Unixmen chrisjo...@unixmen.com wrote: As others have stated, a road-map outlining planned target dates for releases and updates is definately needed and is what everyone wants to see. Otherwise, any project can seem stale and inactive. I have been a long time reader of this mailing list and contact people via email regularly and I know OpenIndiana is far from dead and inactive. But looking at the information and resources on offer on the web, there's not really anything useful that suggests what is going on with the project and where it is heading. And there also needs to be clear information about who is in charge of what in the community. Who is the Project Leader? Who is in charge of development and organization of such tasks? If it is all there in the dark alleys of the internet somewhere, it certainly isn't easy to find. Regards Chris Jones -- -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1.4.13 (GNU/Linux) mQENBFFPo3sBCADxDbIkPcOR0/xdrCemg1rcoFrKBpcQfH+44NZrvMfOW0TO2snZ vbyZm9+wRMwDDyMqnFtsFnO3zYGlLGjzbDWFZKGk/2FWnAYz9MFCtvn6G1PaQ3PF 5UwIDrCChb3aZrkrbmzp2nxh9qP2AiiL0mbYOWv+57EsYqrS6bXEy1S9zNTyb/CC pba59NQHma+BS8wc9AuzwP7DYoKdd93TJUrNpccHA/et4TK7G9Grehj/AdyhkTQT XqQCi5wkn+nBBJNawOBgB2hX/LsARJcOYWKWCDwfQV+wl3uNCukit7ZE3oAofSiq CGbqYRTEtzci/dly1Yfj9k48GRFbniYrMxMLABEBAAG0JENocmlzIEpvbmVzIDxj aHJpc2pvbmVzQHVuaXhtZW4uY29tPokBPgQTAQIAKAUCUU+jewIbAwUJACjqpQYL CQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQpmxmkTpS3RPbkwf+MWRgEONrZlpy IgiFtEfpvIix0umbRo6AgFMc9WNbU5M8lT+7tAHX3DjiOd+9WMqrQXapXtMM1mRh ip+gLPNZ63BT3NlRKjvosatAQhLqR42MwHtA/cd2Oaf//3BDIAg1L71O/2Y9NB7d C/DkJjDQX4xjRKkspmLuiDuZN/KiPhxB293eGdhCIa0wzo74rWiEBvVqAUDPZgnC 0LxUGk0lZzyqoVeeSrojWPxt2d4FEw6ytMutQyZ4N2MbE/iBMYSHuYt5IEsLXGQS 7PwiHKXrOo8kitXfYfDBQrpjWpO0KnHKNd+5SrEisCjr7Fers9r7kH5O/E2C1w4h MZoLN6EhwA== =j5I7 -END PGP PUBLIC KEY BLOCK- ___ 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] [developer] BMC driver on Illumos
On Mar 28, 2013, at 12:05 PM, Jim Klimov jimkli...@cos.ru wrote: So, for the case of dedicated-hardware watchdogs, this is the part of your post which I can't find as relevant: The usual thing is to hook this up to a system timer, which will catch hard hangs. What I mean is that what most systems do is not express an API out to userland, but just have something that runs out of the timer that tickles the hardware watchdog register. This guards against the hard hang of the entire system/scheduler, but it does nothing to ensure that some upper layer services are still being handled. Now I've not looked at Linux and how it uses watchdogs… but I've experience with a few different embedded systems, and the above handling is almost precisely what I've seen done. NetBSD was nice because it instead offered a watchdog facility that extended into userland, allowing the service check to be done by a userland daemon, which is far more interesting than just that the clock interrupt handler is still working properly. :-) - Garrett Sorry for the long ramble, //Jim On 2013-03-28 18:21, Garrett D'Amore wrote: On Mar 28, 2013, at 9:39 AM, Jim Klimov jimkli...@cos.ru wrote: On 2013-03-28 16:18, Sašo Kiselkov wrote: I'm building a system that's relying as much as possible on stock parts, so custom kernel modules and hacking is something I'd like to avoid. I'm not going to be around forever to keep the system going, or to continually work on ways of deploying an old hack on a new install. I know *you* do have better contributions to make, but a watchdog driver is AFAIK about knowing what byte to write to what IO port to set, reset and query the timeout, and possibly configure what the watchdog does when the timer expires without updates. This info might be gleaned from Linux and BSD drivers for different watchdog chips. I think it might be a useful project for a student to make. Possibly too low-profile for a GSoC, but good to learn about driver development, porting code, etc. And quite useful for the community ;) As a result of such a project, we'd get one more kernel-hacker ;) I've done such work for NetBSD systems. These things are usually pretty trivial from a hardware standpoint. The harder thing is when these things are exposed as registers that are on an otherwise bog-standard part. In that case, you have to either modify an existing driver, or come up with some more tricky hack. (Its easier when this function is exposed as a separate PCI function or something like that. But that's very rarely the case with something like this. Usually they are part of the low level system chipset -- they kind of need be in order to do something like generate an NMI or cause a power reset.) Then the other side of the problem is determining how you are going to trigger this. The usual thing is to hook this up to a system timer, which will catch hard hangs. But many apparent hangs are really not hangs in this sense -- there could be a high-priority process that is starving other processing for example, or a deadlock in the filesystem. Those kinds of hangs won't be detected by such a deadman. The ideal type of design would be to have a user-space accessible deadman, that allowed user processes to configure, and then tickle the deadman to keep it alive. This would allow you to have a critical user space process validate that *it* is still serving whatever it needs to. This kind of task requires a little design work -- and probably should be hooked back into some common deadman framework. NetBSD has such a framework if I recall correctly. This project would be in-scope for GSoC effort, because I can see a few other options like using the system timer as a deadman (its already there btw!) if no other hardware watchdog is present. The framework should abstract all those and present a single syscall or ioctl interface to manage it. ___ 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?
Originally Alasdair indicated that he wanted OI to be part of the illumos foundation, so this approach of earmarking the donation makes sense. Note that in the future I hope that illumos will reserve a percentage of earmark donations for its general fund but since we have not set up the administration to deal with that yet, it seems like right now is a great time to donate and ensure that 100% of your donation goes exactly to OI. - Garrett On Sep 5, 2012, at 8:08 PM, Jonathan Adams t12nsloo...@gmail.com wrote: On 5 September 2012 16:47, Deirdre Straughan deirdre.straug...@joyent.com wrote: snip I know that it's really none of my business, since I have yet to actually give anything except support/bugs to the community ... I think that the money being placed with the Illumos Foundation, with potential ring-fencing for OI is a sane idea. If large enough, perhaps it could be used to fund travel for an OI representative at illumos/ZFS Days in October: http://zfsday.com/ Your thoughts? I personally would prefer it to be set aside for OI specific bounties ... but anything that enables OI to have a more visible/vocal voice in the Illumos community could only be seen as a good thing. ___ 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?
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
Re: [oi-dev] [developer] Remnants... (was:Re: Resignation as OI Lead)
Very briefly, I think there has been significant innovation occurring in the stack -- the biggest and most obvious we all know about: * ZFS - lots and lots of goodness here, and the set of contributors is quickly expanding. * DTrace - again, lots of enhancements here. * KVM - while not integrated into -gate yet, Joyent's work here is outstanding, and became a core part of the base for quite a few of the distros Additionally, other development projects that have delivered or working on delivering value: * Martin is working on a full X bring up on SPARC. No mean feat. * Joyent has ported like ~gazillion packages to illumos kernel (via pkgin) * mdb (our excellent kernel debugging stack) got a recent set of significant improvements (through the illumos hackathon.) * Nexenta continues to plug away at porting and updating software for illumian, which in theory should be shareable with OI and OmniOS. (The idea behind illumian was to facilitate collaboration between Nexenta and OI engineers -- to eliminate the debates/barrier caused by different package manages. Sorry that in retrospect it hasn't worked out so well.) * As far as I know, illumos has the *only* open source functional localedef. (Ok, there is a crappy Perl wrapper that implements a minimalist version of the POSIX spec on top of Darwin, but its so unusable for real work that it hardly warrants mention.) * As far as I know, illumos has one of the most performant strcoll() implementations *anywhere* (much faster than either Solaris' or *BSDs; I've not compared Linux, but admittedly its GPL and not usable in our CDDL libc.) * We continue to collaborate with BSDs. The work to integrate mdocml, for example, is an effort intended to modernize our documentation tools and increase opportunities for sharing with the BSD community. * EMULEX has contributed a reasonably complete set of their drivers to illumos. * Areca contributed their source code for some of their HBAs to illumos. * LSI contributes indirectly through commercial partners @ Nexenta and Joyent * Intel collaborates pretty extensively -- albeit indirectly through commercial concerns such as Joyent. * There is an ongoing effort to modernize our WiFi stack and add full WPA. * There is an ongoing effort to update our boot loader to support EFI BIOS and other features. (Largely through adoption of GRUBv2.) These are just some of the areas of innovation and contribution that I'm aware of and can publicly discuss. (There are some that can't be discussed yet, but will become public later.) Of course, some areas of our code base are still under-maintained. And some areas devolve into bike shedding. (Anything with userland -- grep -r being a good example -- seems to invite constant and often fruitless debate.) This is part of being a *community* run OS. But, when I think back to where we were just over 2 years ago when I founded the project, I am *amazed* at the *huge* growth of this project, and the amount of investment and energy going into it. I'd even go so far as to say that the whole thing has been nothing short of a wild success. Can we do more? Of course! But let's not forget where we came from. Only 2 years ago, the future of Solaris technology in the community (OpenSolaris) was effectively *dead*, with no viable follow-on platforms and zero commercial partners. Today we have a thriving ecosystem filled with people doing interesting things. Many of which even I don't know about. (It seems almost every day that I hear about someone else using illumos or illumos-derived tech in a way or application that I didn't know about.) If you can't see the bright future ahead, then I venture to say that either your eyes are closed, or you're looking somewhere else (behind or to the side) instead of forward. So, to all of you who've helped make this all possible, *thank you*. And to those of you who continue to do so, *kudos*. I look forward to working with you in the future to continue innovating and improving upon this amazing and wonderful technology base. - Garrett ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] [developer] how to fix support for system_locale in sysidcfg for non global zone installation
Garrett D'Amore garr...@damore.org On May 29, 2012, at 8:15 AM, Joerg Schilling wrote: Garrett D'Amore garr...@damore.org wrote: BTW: illumos does not support SVr4 packaging, SchilliX-ON does. That is a false statement. We have support for SVR4 packaging in the illumos gate. The *distros* have not elected to deliver SVR4 packages, and furthermore, we don't have tools *in-tree* to generate SVR4 packages from the IPS manifests, but I submit writing such a tool would be a nearly trivial matter. (In fact, I've written a tool that parses IPS manifests to build a distribution for my company, although it lacks any packaging metadata, as our distro is just an ISO. But I could have just as easily emitted pkginfo and prototype files to generate SVR4 package binaries.) We *do* have most (all?) of the SVR4 tool set in-tree though. So you just verified that your statement is false as you confirmed that Illumos does not create SVr4 packages. Does not create != does not support. - Garrett 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 --- illumos-developer Archives: https://www.listbox.com/member/archive/182179/=now RSS Feed: https://www.listbox.com/member/archive/rss/182179/21239177-c925e33f Modify Your Subscription: https://www.listbox.com/member/?member_id=21239177id_secret=21239177-4dba8197 Powered by Listbox: http://www.listbox.com ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] [developer] First illumos-userland hackathon
I'm glad to see this, although a little disappointed that its strictly an illumos userland bit -- why not also include some opportunity for illumos-gate. - Garrett On Mar 23, 2012, at 8:58 AM, Bayard Bell wrote: Thanks to Linda Kateley, Nexenta's community manager, we are holding a hackathon for illumos-userland in Amsterdam on May 23, alongside the European Open Storage Summit: http://www.meetup.com/illumos-User-Group/events/56953802/ Closer to the date we will be putting up an ideas page. If you're interested in contributing to this porting and packaging project, join us on the userland list: https://www.listbox.com/subscribe/?listname=userl...@lists.illumos.org We're currently spinning up our first dev cycle with our revised development and contribution process: http://strictlygeeking.blogspot.com/2012/03/new-development-and-contribution-model.html If you haven't been previous involved in development, please have a look at our documentation, which will be improving in the next month as we pick up the pace: http://wiki.openindiana.org/oi/Building+with+illumos-userland If there are things you'd like to see added or updated in userland, please see if it's already in our tracker and submit a new issue if it isn't already: https://www.illumos.org/projects/illumos-userland/issues/ Hope to see you there. Cheers, Bayard --- illumos-developer Archives: https://www.listbox.com/member/archive/182179/=now RSS Feed: https://www.listbox.com/member/archive/rss/182179/21239177-c925e33f Modify Your Subscription: https://www.listbox.com/member/?member_id=21239177id_secret=21239177-4dba8197 Powered by Listbox: http://www.listbox.com ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] [developer] First illumos-userland hackathon
I'm thinking I may be coming to the OSS in AMS. (I'm trying to get Nexenta to fund my airfare though - I can give one more or talks on illumos, etc.) I may come anyway. If I do, we should chat further about this. - Garrett On Mar 23, 2012, at 10:11 AM, Bayard Bell wrote: On Fri, Mar 23, 2012 at 4:41 PM, Garrett D'Amore garr...@damore.org wrote: I'm glad to see this, although a little disappointed that its strictly an illumos userland bit -- why not also include some opportunity for illumos-gate. I've definitely been encouraging people with a primary interest in porting and packaging who are interested in distro development to get more involved with illumos-gate as our closest upstream. I've done a scan of issues in the OI tracker recently, and there's a decent amount of stuff that needs upstream resolution, so one of the things I might do is create upstream issues for that and walk people through fixing as many of those as possible. The distros are definitely one place where the rubber hits the road for illumos-gate, and I'd like to see more of that fed back into illumos-gate for resolution. If people in the community are willing to use our stuff in anger, we should oblige them with a measure of support. One of the things that's on my list to get going is a community backline, which would pull issues from all the distros (SmartOS, illumian, OI), get them proposed diagnosed, identify already existing fixes (Joyent's way ahead on this with SmartOS), and drive resolution in illumos-gate. If I were putting this in a larger context, I'd say we've addressed our first challenge as a community, which is showing that we can have a critical mass of developers successfully working under distributed ownership, moving our codebase forward. Our next challenge seems to me to be providing processes for maintaining production quality, including providing a degree of shared risk management for distro support, emphasizing the ever-moving target that is working code without getting caught up in the kings and presidents governance questions. If we mean to embrace the devops concept, this seems a strategic way to do it. Cheers, Bayard --- illumos-developer Archives: https://www.listbox.com/member/archive/182179/=now RSS Feed: https://www.listbox.com/member/archive/rss/182179/21239177-c925e33f Modify Your Subscription: https://www.listbox.com/member/?member_id=21239177id_secret=21239177-4dba8197 Powered by Listbox: http://www.listbox.com ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] 1410 package zilstat
Frankly, I'd rather see this integrated into illumos proper. It has dependencies upon interfaces in the kernel, and IMO it belongs with the kernel. (Likewise, I'd like to see Richard's arcstat integrated.) - Garrett On Sep 3, 2011, at 11:07 AM, Josef 'Jeff' Sipek wrote: Any issues with merging this? http://hg.31bits.net/oi/oi-build-jeffpc/rev/523f4ae9161d Thanks, Jeff. -- Failure is not an option, It comes bundled with your Microsoft product. ___ 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] OpenSSL 1.0.0 replacing 0.9.8 in userland-gate = massive headache
So, I believe that 3 might not be such a bad option, because I think technically the openssl package and APIs have historically been considered Private (i.e. unstable and not for use by ISVs.) This is the Solaris view of it at any rate. - Garrett On Sep 3, 2011, at 1:56 PM, Alasdair Lumsden wrote: Hi All, In Oracle's official userland-gate, they have replaced OpenSSL 0.9.8 with 1.0.0. This has massive ramifications, because everything linked against OpenSSL 0.9.8 breaks as soon as library/security/openssl gets upgraded, including pkg, which is all kinds of fun. There are two realistic options, and one unrealistic idealistic option: 1. Don't bother upgrading to OpenSSL 0.9.8, worry about it another day 2. Do the upgrade, but also ship an openssl 0.9.8 compatibility package and make the new one depend on it - this lets old software continue to run whilst recompiles pick up the new OpenSSL. Slowly transition to OpenSSL 1.0.0. I've made such a package by pkgrecv'ing openssl 0.9.8, hacking out everything except the libraries and republishing it locally as library/security/openssl/compatibility/0.9.8 - works fine. 3. Do the upgrade. Rebuild everything against OpenSSL 1.0.0, and release rebuilt software with the openssl 1.0.0 upgrade, in one simultaneous release. Obviously 3 has ramifications beyond the base system, because any third party software that depends on OpenSSL 0.9.8 will break. This is why having a compatibility package is probably necessary regardless. I've provided a list of software below that depends on OpenSSL, which affects these consolidations: gnome ips l10n oi-build osnet sfw vpanels Thankfully those are all ones we can easily rebuild, (indeed, sfw is gone), with the exception of gnome (JDS) which, without a replacement for Distro Importer in the new continuous integration world, is quite tricky. My personal preference is 2, although ideally we need to convert OpenSSL 0.9.8 to oi-build format to make the compatibility package, for sustaining/security patches. Hacking the package together was good for a proof of concept but we need to be able to rebuild it/update it. Comments welcome! Cheers, Alasdair consolidation/sfw/sfw-incorporation - sfw sfw crypto/gnupg - oi-build sfw database/postgres-82 - sfw sfw database/postgres-82/contrib - sfw database/postgres-82/developer - sfw database/postgres-82/library - sfw database/postgres-83 - sfw sfw database/postgres-83/contrib - sfw database/postgres-83/developer - sfw database/postgres-83/library - sfw database/postgres-84 - sfw sfw database/postgres-84/contrib - sfw database/postgres-84/developer - sfw database/postgres-common - sfw database/postgres/pg_upgrade - sfw database/postgres/pgadmin - sfw desktop/gftp - gnome desktop/irc/xchat - gnome desktop/remote-desktop/rdesktop - oi-build gnome desktop/system-monitor/gkrellm - gnome desktop/torrent/transmission - gnome diagnostic/httping - oi-build sfw diagnostic/nmap - oi-build sfw library/gnome/gnome-vfs - gnome library/libtorrent - oi-build sfw library/neon - oi-build sfw library/openldap - sfw library/perl-5/net-ssleay - sfw library/perl-5/postgres-dbi - sfw library/print/cups-libs - oi-build sfw library/python-2/m2crypto - oi-build ips ips library/python-2/m2crypto-26 - oi-build library/python-2/pycurl - oi-build ips ips library/python-2/pycurl-26 - oi-build library/python-2/pyopenssl-24 - sfw library/python-2/pyopenssl-26 - oi-build sfw library/raptor - gnome library/security/pam/module/pam-pkcs11 - oi-build sfw library/security/trousers - oi-build sfw library/xmlrpc-c - sfw mail/fetchmail - oi-build sfw mail/mutt - oi-build sfw network/chat/irssi - gnome network/dns/bind - oi-build oi-build sfw sfw network/nntp/slrn - oi-build sfw network/ssh - osnet osnet network/ssh/ssh-key - osnet network/tor - sfw package/svr4 - osnet print/cups - oi-build sfw print/filter/hplip - oi-build sfw redistributable - runtime/erlang - oi-build sfw runtime/python-24 - gnome runtime/python-25 - gnome runtime/python-26 - gnome runtime/ruby-18 - oi-build sfw runtime/tcl-8/tcl-openssl - oi-build sfw service/database/postgres-82 - sfw service/database/postgres-83 - sfw service/database/postgres-84 - sfw service/network/dns/bind - oi-build sfw service/network/load-balancer/pen - sfw service/network/ntp - oi-build sfw service/network/smtp/sendmail - osnet service/network/ssh - osnet service/network/wpa - osnet service/security/kerberos-5 - osnet service/security/stunnel - sfw system/boot/wanboot - osnet system/input-method/iiim - l10n system/library - osnet system/library/security/crypto/pkcs11_kms - osnet system/management/cim/pegasus - sfw system/management/ipmitool - oi-build sfw system/management/rad - vpanels system/management/visual-panels - vpanels system/management/web/openwsman - sfw system/management/webmin - sfw web/browser/elinks -
Re: [oi-dev] Git as a version control system for new OI projects
On Thu, 2011-06-23 at 01:12 +0400, Alexey Zaytsev wrote: On Thu, Jun 23, 2011 at 00:05, Julian Wiesener j...@vtoc.de wrote: Hi, as i stated before, i would like to see an proposal than includes some details about what problems a toolswitch will solve. I've absolutely no preference as i used both tools. However, if we do a switch, we should have good reasons for that. There is no reason besides more people want git. Everything that can be done with git can be done with hg. And the two dvcs are such a huge step from cvs/svn that looking from the 10-years old standpoint, there is hardly any difference. But, we are looking from the year 2011. 1) More people know and use git. And it's a fact that hardly needs any proving. The Linux kernel, Glibc, X.org, Gnome and KDE, are all maintained in git. Now the two major hg users I see are mozilla and python. Not puny, but clearly a different weight category. And I wanted to name OpenOffice, but it looks like the developers abandoned it to fork LibreOffice, and guess which vcs they chose.. You forgot an important one. Oracle for Solaris development. That's why we are using hg actually -- the decision to use hg was made some years ago when git was not a viable alternative. I recognize the situation is different now, but it really does come down to a religious war. 2) Some features are not working as well in hg. Local branches require jumping hoops. In git, you are usually branching without a second thought. This is the one argument I have heard. I guess I'm skeptical that crazy amounts of local branching are a good idea, but I've never really tried such a work flow. I worry about massive amounts of branching leading to integrations with unintended dependencies, but maybe I'm just being paranoid. I tend to use hg combined with zfs clones to give me a really good work flow with lots of individual workspaces with isolated changes. Admittedly I'm making underlying use of ZFS to make this work, but it works for me. The 'git remote' equivalents are rather pale. I've heard that hg is easier to use then git, and maybe this was the case in 2005, but git usability has gone a long way since then (I've started using git in 06), and I fail to see how hg is any easier now. It seems noticeably harder for any non-trivial stuff I'm doing in git. It would be nice to hear what's so easy in hg that's still hard in modern git. I've not used git much, so I can't comment here except to say that hg is fairly intuitive, especially for people coming from teamware (which many of our users used to use -- that's what Sun used internally before converting to hg.) There's also hg-git, so you know what: you can use git and I don't care. :-) And I don't have to. I can continue to use hg. So a big fat +1 to git. Also we should keep in mind, that we still want to use our upstreams, and we should have a simple way to keep our repos in sync with their repos or merge updates. Just check how many upstreams are git, and how many are hg. ;) Nearly all of OI's upstreams are at Oracle, and are in hg. - Garrett ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] gates, queues
illumos is already using ssh as the primary hg mechanism, fyi. Seems to work far better than http. -- Garrett D'Amore On May 25, 2011, at 3:45 PM, Bayard Bell buffer.g.overf...@googlemail.com wrote: One other keepalive on this thread is that I'd really like for us to move to using ssh as the primary means for publishing source, at least for clone/pull. HTTP is fine for browsing/eyeballing, but anyone who means to build off the source should be able to do server authentication as an integrity measure, which means either ssh or https. This protects against things like name service-based MITM, which is quite easy to do (additional note: nice if we got DNSSEC going for openindiana.org). Following the line of thinking even as it becomes a distinct question from source structure and integrity: as we're trying to improve our security posture in rolling out stable, I'd at least suggesting releasing stable with signed packages, so that binary distribution is also protected, albeit by cryptographic protection of the packaging envelope rather than transport integrity. I don't have experience of the latter, but a) I have some background with cryptography and willing to learn new applications and 2) suspect that Triskelios and others from Illumos will have some experience of it from within Sun/Oracle. We can discuss on #oi-dev and/or at the next meeting. I reckon the EC folks have their hands full at the moment, so I thought it better to post notes here as I'm thinking these things through rather than pumping them onto IRC. On 24 May 2011, at 17:00, Bayard Bell wrote: I'm bumping this, as part of the problem that needs sorting is where to manage security patches that need doing around 151. I had an agenda item for last week's meeting to discuss this. Hopefully we'll be able to discuss this at today's meeting (which *is* happening? ;-). On 18 May 2011, at 18:54, Bayard Bell wrote: Just a couple of notes as I've been been a bit frustrated with the way that merge queues are used in OI. I've got nothing against merge queues, it just seems that the source should be offered with merges already done. OI source should be accessible in the repos for cloning or browsing without requiring someone to merge. That's not to say that the patches shouldn't also be just as accessible, as well as the upstream source. It doesn't seem auspicious to me that the top of the OI builds docs contain a pointer to a page on using MQ. What I'd prefer to see is a source namespace that looks like: hg.openindiana.org\ upstream\ illumos-gate\ onnv_147\ [etc.] userland-gate\ build-165\ [etc.] [etc.] oi\ illumos-gate\ oi_147\ [etc.] userland-gate\ oi_147\ [etc.] mq\ illumos-gate\ onnv_147-oi_147\ [etc.] userland-gate\ build-165-oi_147\ [etc.] If people want to see what's in OI or pull OI source, there it is. OI releases under active development may be a separate case that require people to pull merge queues. I've also been thinking about how to maintain patches for CVE audits/incident response going forward. What I'd suggest, building on the previous suggestion is just to have a second series of merge queue that goes on top of an OI release and is regularly merged into the release, so that it can remain private. Thus: sec_mq\ illumos-gate\ oi_147\ [etc] userland-gate\ oi_146 [etc.] I'll admit some of this is just plain branding: OI, as source should be able to be somewhat self-referential. If people want to understand how it works back upstream, fine, but the current system comes across to me as a bit baroque. I'm sure I don't entirely appreciate the reasoning of the current system, but hopefully your responses will get me there. Cheers, Bayard ___ 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] [hhinn...@apple.com: Re: [cfe-dev] libc++ ABIstability]
Just a quick note. I fully support moving to an open C++ library, but be advised that we will still need the closed Sun binaries in order to support legacy apps. Of course I think nobody should use C++ but that is a different rant and probably highly controversial. :) -- Garrett D'Amore On May 24, 2011, at 12:07 PM, Alasdair Lumsden alasdai...@gmail.com wrote: Hi Guido, Thanks for forwarding this, libc++ sounds rather promising. Without us testing it there's no way to know for sure what kind of issues we'll see in the field, so I'll mention in the policy document draft that libc++ is a candidate for our default open C++ library subject to testing. We'll need to come up with an easy way of firing off builds with a different compiler and C++ library selected. In Userland this should be pretty easy to do, there's a makefile called shared-macros.mk which contains compiler definitions: http://hg.genunix.org/userland.hg/file/520697a05dde/make-rules/shared-macros.mk I'm not sure we would switch between the different c++ libraries but I imagine it won't be too hard to work out, although if its hardcoded in GCC like the linker collect2 runs then I'll be a little less happy. Cheers, Alasdair On 23 May 2011, at 21:22, Guido Berhoerster wrote: - Forwarded message from Howard Hinnant hhinn...@apple.com - Date: Mon, 23 May 2011 16:08:23 -0400 From: Howard Hinnant hhinn...@apple.com To: Guido Berhoerster g...@openindiana.org Cc: cfe-...@cs.uiuc.edu Subject: Re: [cfe-dev] libc++ ABI stability On May 23, 2011, at 2:27 PM, Guido Berhoerster wrote: Hello, does the LLVM project make (or plan to make) any commitment with regard to the ABI stability of libc++? The plan is to keep the ABI semi-stable. The high level parts of the library are ABI-versioned using the C++11 feature inline namespaces. The current version is 1. This is considered an ABI version. And the ABI for any given version is meant to be fixed. Every once in a great while (e.g. maybe for the next C++ standard), we could issue a new ABI, which would then live in a different inlined namespace (e.g. std::_2). There would be config macro to choose the ABI. Some lower-level parts of the library are not ABI versioned. They live in namespace std only. These will remain stable until the sun swells up and swallows the earth (after that I can't vouch for it). These low level parts include: * operator new/delete * get/set new_handler * typeinfo * the exception classes The exception classes not only have a stable ABI, their ABI is identical to that of gcc-4.2. This means you can throw exceptions across dyld boundaries and not worry which C++ std::lib the recipient of your exception is using (as long as that library is also ABI compatible with gcc-4.2). Howard - End forwarded message - -- Guido Berhoerster ___ 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] 148b Audio Issues
I have an envy24 driver nearly ready to integrate, but I have held off as I don't have the hardware. If you want to send me the hardware, I can look at it. That said, the problem with the audio810 driver is not with the driver, but the Gnome configuration. You need to tell Gnome you want to use this device. The best way to do that is with the gstreamer-properties application.Using that you can select OSS audio output and the specific device to use. That should solve the problem for you. -- Garrett D'Amore On May 23, 2011, at 12:21 AM, Ken Gunderson kgund...@teamcool.net wrote: On Sun, 2011-05-22 at 15:18 -0400, Albert Lee wrote: On Sun, May 22, 2011 at 1:18 PM, Ken Gunderson kgund...@teamcool.net wrote: Howdy: No audio here on 148b. I note a couple bugs filed in Redmine, but not listed as show stoppers for 151. Shouldn't this be on the radar for 151 based release or am I missing something? Sporting two different audio devices on this Tyan K8E based test rig: 1) AC97 nVidia onboard a) previously worked w/o problem on Open/Solaris. b) wants to use audio810 driver c) plays test sound via Multimedia Systems Selector d) played a cd via Sound Juicer once, but otherwise have been unable to repeat. e) scanpci output: pci bus 0x cardnum 0x04 function 0x00: vendor 0x10de device 0x0059 nVidia Corporation CK804 AC'97 Audio Controller CardVendor 0x10f1 card 0x2865 (Tyan Computer, Tomcat K8E (S2865)) STATUS0x00b0 COMMAND 0x0007 CLASS 0x04 0x01 0x00 REVISION 0xa2 BIST 0x00 HEADER 0x00 LATENCY 0x00 CACHE 0x00 BASE0 0xf000 SIZE 256 I/O BASE1 0xec00 SIZE 256 I/O BASE2 0xfebfd000 SIZE 4096 MEM BASEROM 0x addr 0x MAX_LAT 0x05 MIN_GNT 0x02 INT_PIN 0x01 INT_LINE 0x0b 2) Audiotrak Prodigy HD. Envy24 based PCI add in card. a) Never worked on any previous Open/Solaris b) wants to use audiohd driver c) does not play test sound via Multimedia Systems Selector d) but apparently might should work per hcl wiki note pertaining to generic Envy24. e) scanpci output: pci bus 0x0001 cardnum 0x09 function 0x00: vendor 0x1412 device 0x1724 VIA Technologies Inc. VT1720/24 [Envy24PT/HT] PCI Multi-Channel Audio Controller CardVendor 0x3137 card 0x4154 (Card unknown) STATUS0x0210 COMMAND 0x0005 CLASS 0x04 0x01 0x00 REVISION 0x01 BIST 0x00 HEADER 0x00 LATENCY 0x20 CACHE 0x00 BASE0 0xa400 SIZE 32 I/O BASE1 0xa000 SIZE 128 I/O BASEROM 0x addr 0x MAX_LAT 0x00 MIN_GNT 0x00 INT_PIN 0x01 INT_LINE 0x07 That the onboard succeeds in playing test sound but I cannot get audio playback from neither Rhythmbox, Totem, or Juicer seems odd. The Audiotrak is a relatively high grade two channel card targeting more audiophile rather than gamer type end user. I'd be willing put on loan to US based driver developer if it would help polish up support for Envy24 based cards. I also have another Envy24 based card (Chaintech). -- Ken Gunderson kgund...@teamcool.net Driver issues should be filed against illumos-gate (not OpenIndiana) here: http://www.illumos.org/projects/illumos-gate/issues Use cat /dev/sndstat and audiotest for diagnostics. Thanks, Albert. I guess I assumed Gnome's Multimedia Systems Selector test was just front end to make these calls. Definitely better to use lower level tests though: kvg@allakaket:~$ ls -l /dev|grep audio lrwxrwxrwx 1 root root7 2011-05-20 18:45 audio - sound/0 lrwxrwxrwx 1 root root 10 2011-05-20 18:45 audioctl - sound/0ctl lrwxrwxrwx 1 root root 18 2011-05-20 18:45 dsp0 - sound/audiohd:0dsp lrwxrwxrwx 1 root root 19 2011-05-20 18:45 dsp1 - sound/audio810:0dsp lrwxrwxrwx 1 root root 20 2011-05-20 18:45 mixer0 - sound/audiohd:0mixer lrwxrwxrwx 1 root root 21 2011-05-20 18:45 mixer1 - sound/audio810:0mixer lrwxrwxrwx 1 root root 40 2011-05-20 18:45 sndstat - ../devices/pseudo/audio@0:sound,sndstat0 kvg@allakaket:~$ audiotest /dev/dsp0 Sound subsystem and version: SunOS Audio 4.0 (0x00040003) Platform: SunOS 5.11 oi_148b i86pc *** Scanning sound adapter #1 *** /dev/sound/audiohd:0dsp (audio engine 0): audiohd#0 - Performing audio playback test... left OK right ...OK stereo ..OK measured sample rate 47911.00 Hz (-0.19%) *** All tests completed OK *** kvg@allakaket:~$ audiotest /dev/dsp1 Sound subsystem and version: SunOS Audio 4.0 (0x00040003) Platform: SunOS 5.11 oi_148b i86pc *** Scanning sound adapter #2 *** /dev/sound/audio810:0dsp (audio engine 1): audio810#0 - Performing audio playback test... left OK right ...OK stereo ..OK measured sample rate 47697.00 Hz (-0.63%) dsp0 reports all is fine and dandy but the test doesn't actually produce any sound. dsp1 produces sound but none of the Gnome apps, e.g
Re: [oi-dev] libstdc++ locale support on Solaris/OI
illumos doesn't have the POSIX 2008 locale APIs. I've considered adding them... it would not be too difficult, although we would need to eliminate some process global state ... are there applications that consume these? If there are, then its worth the time and effort. -- Garrett D'Amore On May 23, 2011, at 3:15 AM, Alasdair Lumsden alasdai...@gmail.com wrote: Hi All, When discussing the option of using gcc as the default compiler for software on OI, the lack of IEEE 1003.1-2001 support in libstdc++ was cited as a reason for sticking with Sun Studio. There's a bug open on the GCC bug tracker for it here: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41495 As you can see someone has got a mostly working patch available, which potentially could be finished to address this. I posted a comment on the bug tracker, and someone responded they could be interested in working on it. I'd appreciate it if others also interested in this could provide feedback on the bug, especially Jonathan Wakely's question to which I don't know the answer: Does OpenIndiana support the new POSIX.1-2008 APIs, e.g. wctype_l and towupper_l? I also had a look at the --enable-clocale option: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/~checkout~/gcc/libstdc++-v3/docs/html/configopts.html?rev=1.21.2.10.4.3.2.2content-type=text/html --enable-clocale=OPTION Select a target-specific underlying locale package. The choices are 'ieee_1003.1-2001' to specify an X/Open, Standard Unix (IEEE Std. 1003.1-2001) model based on langinfo/iconv/catgets, 'gnu' to specify a model based on functionality from the GNU C library (langinfo/iconv/gettext) (from glibc, the GNU C library), or 'generic' to use a generic C abstraction which consists of C locale info. As part of the configuration process, the C library is probed both for sufficient vintage, and installed locale data. If either of these elements are not present, the C++ locale model default to 'generic.' On glibc-based systems of version 2.2.5 and above with installed locale files, 'gnu' is automatically selected. Does anyone know if the GNU option is viable? It specifies it takes functionality from glibc, which obviously we don't have, but then cites langinfo/iconv/gettext, the latter 2 of which we do have. And lastly, could someone confirm whether the Apache stdcxx C++ library is a viable full alternative to libstdc++ that we could use to avoid the locale issue? If so, does anyone foresee any issues of pairing gcc with libstdc++ to take over from Sun Studio as our compiler of choice for OI (I'm talking theoretically, ignoring the work involved of making everything actually compile with it). Cheers, 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
Re: [oi-dev] Artwork?
illumos kind of has a mascot in the phoenix... admittedly not a very friendly one, but a starting point perhaps? On 03/30/11 08:34 AM, Hernan Saltiel wrote: Ideas for the mascot? This would be a starting point for the stickers, t-shirts...and why not, some theming too! We thought about this in the past...with no success :) Best regards, HeCSa. On 3/30/11, Nikola M.minik...@gmail.com wrote: On 03/29/11 03:54 PM, Shawn Thompson wrote: I was thinking that maybe we could evolve from Nimbus somehow. Somehow keeping elements/ideas from it, but applying them in new ways. I was looking at that Murrine engine, it has a lot of options, and I mean a lot. And don't forget, if we do change the default, there's nothing stopping you from keeping the old theme as a sort of classic option. Well great ;) Just to make sure persons making new Gui look and feel acquire also knowledge of its integration with JDS, and making it available (as additional IPS publisher or distributed otherwise) for testing in present dev releases. And then people will express what they want or not for default, etc. It certainly came into my mind that also many other things are needed in artistic section besides GUI look. Like T-shirt design (evolved from latest OpenSolaris one and as addition to it and new one), Logo design for big stickers for machines and small stickers for machines, Live and textual install CD/DVD print design (also there is Osol one to start with), Mascot for distribution.. But that is all with consultation with project leaders. ___ 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] GSOC2011
On Mon, 2011-03-21 at 13:00 +0300, Andrey Sokolov wrote: I'd like to participate in Linux binary support without zones project. Is it possible? ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev Yes. I've thought a bit about this problem, and recommend we have a chat at some point. I'd recommend you start by filling out those parts of the application template that you can already do, and then lets take some time to talk further. - Garrett ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] GSOC2011
On Mon, 2011-03-21 at 16:16 +0200, Cyril Plisko wrote: On Mon, Mar 21, 2011 at 1:54 PM, Andrey Sokolov kere...@solaris.kirov.ru wrote: Hi Deano, I would like to write a program that will convert linux binaries to opensolaris binaries. The program will change dynamic relocation records. I did a little experiment: http://forum.os-solaris.ru/index.php?topic=223.0 I have converted a simple linux binary to opensolaris binary using hex editor. Instead of [destructively] change the Linux binary in order to run it under Solaris, wouldn't it be better to do the job on the fly via dynamic linker ? Linux binaries conveniently use /lib/ld-linux.so.1 (as opposed to /lib/ld.so.1 for Solaris). So one would imaging that if you will provide a /lib/ld-linux.so.1 that knows how to fix the relocations that would get you what you need, w/o touch the binaries. Does it make sense ? This was pretty much my idea on the topic. There may be a need for a system call translation as well. Still, I think the *first* attempt should stick to library interfaces, and as much as possible reuse the lib interfaces we already have. There are likely some interfaces that will need work to make them function in a more linux friendly fashion. In a world where we had truly achieved success here, it would be possible to run, e.g. skype, without having to resort to branded zones. (Admittedly skype is a hard program to support, but it's a particular itch I want to see scratched. :-) - Garrett ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Popular Software list
I also think it would be a good idea for us to collect a list of software that we still want or have to use another computer for. For example, I use Ubuntu to get at Skype, Chrome, and GNUcash. (The last of these is because I have no time to figure out how to build it for Solaris/illumos.) Given a list, and a votes column, it might help folks decide what they should put their packaging efforts on. Just an idea - Garrett On Tue, 2011-03-08 at 13:35 +, Deano wrote: Hey, This is very low-tech approach for now, but I’ve added a wiki page where we can add software we use and have installed and where it came from. The idea is that as OI follows the Solaris tradition of having lots of repositories rather than a big single one, a user can use this to look up a particular app and where its available from (i.e source, default IPS, SFE ). It’s also allows people to enter a not supported app, so that we have some form of “popular but not supported” list. Being as its so low-tech (just a wiki table) I will volunteer to maintain it until I feel more cleverer and make it a proper DB or something… http://wiki.openindiana.org/oi/Popular+Software Please help fill it, I’ll break it down into sub categories etc. as it fill up. Thanks, Deano ___ 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] [illumos-Developer] Proposed plan for the next releases of OpenIndiana
Sounds good to me. Going forward, we need to recognize that we need to decouple our releases from Oracle build numbers. Albert Lee tr...@opensolaris.org wrote: Hi all, At today's developer meeting, we've gone over our release plans and this is a summary of what we will do going forward: Our experimental build[1] based on illumos and Oracle 148 will continue receiving updates in preparation for our next development build. Our next development build will be based on illumos and Oracle's 151a consolidations, and will be published to /dev, at which point /dev-il will no longer exist as a separate repository. Our stable release will be based directly on the aforementioned development build, addressing any major issues after the initial development release. This release will be published to /stable (and/or /release?). I'd like to know if this sounds sane to everyone (anyone?), and if there are additional concerns that we may have missed. Thanks! [1] Our preliminary illumos-based build is at http://pkg.openindiana.org/dev-il . The media was well-received at the illumos exhibit at SCALE 9x. We're working on some additional changes to complete illumos integration and will keep the versions of all consolidations at Oracle's 148. -Albert ___ Developer mailing list develo...@lists.illumos.org http://lists.illumos.org/m/listinfo/developer ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] illumos based OpenIndiana DVD
On Tue, 2011-02-22 at 18:41 +0100, Joerg Schilling wrote: Garrett D'Amore garr...@nexenta.com wrote: I think in general, the idea of swapping back and forth between different versions of ONNV is not going to work out so well. There are challenges related to dependencies between ON (or illumos-gate) and the rest of the system, and having multiple moving targets is going to be impractical for end-users or even distribution builders to work with. My read of Schillix-ON is that you want to build a different distribution, with a different core (based on SVR4 as well it seems), so you can tune your distro for the decisions you make around your fork of ON. Schillix-ON deliveres SVR4 packages (98% ready) as well as IPS packages. This permits any downstream to use the code. While that's fine, I am not sure it is fair to ask either end-users or distribution builders to cope with the notion of swapping a different ON derivative out given the rather insane dependency graph that is associated with ON. I am in hope that it is possible to discuss the issues and to agree on the same naming scheme. The issues go far beyond just simple naming. For example, we have totally different g11n locale packages in illumos-gate now. Our libc is quite different now because of all the changes I made to support localization, and the l10n data files have a totally different format. That's just one example. Going forward, I expect we'll have some interesting ZFS features as well which may introduce on-disk format changes. (These are being worked on with a larger group of ZFS engineers that extend far beyond just illumos -- people working on ZFS in MacOS, FreeBSD, and Linux for example). There's a lot of collaboration going on. Sadly, you've elected not to be a party to any of this -- and from what I can tell it is for the simple reason that we're not driving forward with integrating star into illumos. I guess its easier for you to fork the entire operating system than to accept that star might not be accepted for integration. Anyway, the upshot of all these changes is that it will be increasingly difficult for a distribution maintainer to manage the increasing divergence in the forks. We already have that problem with upstream OpenSolaris -- and its only going to get worse. Adding another degree of freedom would only significantly complicate the problem, and IMO without much benefit to the distribution builders or the maintainers. It would be more practical (from their standpoint) to ask them whether they should choose a different upstream kernel to standardize on than illumos. Of course, I have a vested interest in seeing illumos succeed, and I believe that there is a lot more momentum behind illumos than Schillix-ON -- but the OpenIndiana guys are free to elect differently. - Garrett ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Security Work
Please make sure I get any security notices for things that are relevant to illumos or ON. - Garrett On Mon, 2011-01-24 at 13:04 +, Alasdair Lumsden wrote: Hi All, I've put together two security resources (You'll need to be in the security group of the wiki to see this - if you're a long standing OI-Dev developer mail me offlist and we can discuss getting you access). http://wiki.openindiana.org/display/security/Release+2010.02 http://wiki.openindiana.org/display/security/Security+Issues+with+oi_148 The initial supported list has expanded somewhat when critical dependencies are taken into account: Sendmail Perl Python Apache PHP MySQL Postgresql Tomcat GCC OpenSSL Java RSync ISC Bash Curl GNU bzip2 gzip unzip zip wget sudo zlib sqlite-3 libjpeg libpng apr apr-util expat libltdl libxml2 libxslt ncurses readline tcl-8 tk-8 net-snmp libx11 On the wiki page I still need to fill in their version and consolidation, and update the security issues page for them - if anyone else would like to help me do that, let me know (I'd appreciate it). At the moment our staffing numbers to maintain this are quite low and as such it's a lot of work. But as the saying goes, many hands make light work. So I'd like to ask if anyone would object to me posting to OpenIndiana-Discuss asking for security volunteers? We'll need to ensure we get trustworthy people capable of helping rather than hindering. I'm thinking volunteers would be best served by having a mentor, and that we should group the software together by consolidation. We may want to write a job spec and split it into two parts - one Monitoring and Alerting, for less technical people, and the other Patching and building for those who can learn to build consolidations. I'd appreciate feedback. Cheers, 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
Re: [oi-dev] [illumos-Developer] OpenIndiana and illumos, part 2
Thanks for helping to make my goals clear, Albert. Let me elucidate a bit more. I'm specifically not interested in distro that attempts to rehash what Oracle is doing, or one who's sole benefit is a more liberal license than what Oracle provides. For a variety of technical reasons, I don't even think such a distribution is *possible* -- at least not without the complete source code (and the right to use it!) for all of Oracle's Solaris code. I *do* need a distribution that is more closely aligned with the goals of illumos, which includes significant innovation. Today there is nothing filling that gap properly. I'm happy to have OpenIndiana be that distribution, but some changes in the way OI runs itself (and more specifically in what OI drives for) are required to get there. If I see that OI is interested in filling that role and willing to make the necessary changes, then I'm willing to invest resources to help. However, if OI wants to remain truly independent of illumos, and still wants to aim for compatibility with Oracle Solaris, or OpenSolaris, as a primary goal, even at the cost of innovation in illumos, then I don't think OI can fill the needs of illumos. In which case I need to invest elsewhere, even if it first seems like a duplication of effort. Let me spell this out a bit more clearly. There are large financial motivators behind illumos, and a number of us have staked not just our spare time but our entire careers and in some cases our businesses on this bet. So, we're going to see our goals through, one way or the other. The question is whether OI is going to come along for the ride, or be left behind. If that sounds a bit melodramatic, then I'm sorry, but I do think its important the folks involved in deciding the future of OI understand what's at stake from illumos' perspective. This is far more than a part time hobby thing. - Garrett ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
