Andrzej Szeszo | 18 May 2013 03:14
Picon
Gravatar

OI 'hipster' reboot effort

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.
(Continue reading)

Marion Hakanson | 13 May 2013 23:55
Favicon

Re: OI project reboot required

garrett.damore <at> dey-sys.com said:
> So, out of curiosity -- *who* is actively running illumos on 32-bit kit
> today?  I'm not interested in hypothetical uses or kit that is sitting around
> in your garage waiting for you to do something with it…. I'm interested in
> people who would be immediately impacted and severely so if illumos were not
> available on 32-bit CPUs right now.  (To give a counter example: I have a
> 32-bit Atom netbook, that I have OpenIndiana on.   I turn it on once every
> year or so… if that often … so I can't seriously claim that I would be
> negatively impacted if illumos were to move to 64-bit only.) 

And,

garrett.damore <at> dey-sys.com said:
> Older hardware must be *really* old.  Over 5 years.  For servers, probably
> over 10 years.  I've thrown away my Pentiums and Pentium IIs.  I suppose
> there could be some Pentium IIIs and IVs out there, or AMD Athlons
> (pre-Athlon64), but they'd all be really really slow by today's standards.
> Do people run illumos on such kit?  I'm highly doubtful, unless that kit is
> around just to answer the question of whether 32-bit kernels still work. :-) 

I do.  Been running OI on my Pentium IV 2.8GHz machine since oi148, which
is when I converted it from Solaris-10.  It has 2GB RAM and a couple 1TB
drives in a mirror acting as ZFS backup server for other family members'
Mac's, and also gets used daily as my personal home desktop machine (Firefox,
Thunderbird, OpenOffice, xsane, gimp, exmh/MH, rcs/svn, wireshark, etc).  And,
it runs a Solaris-10 zone brought forward to run two binaries I haven't yet
found the time to port/compile on OI, gnucash and gnome-perfmeter.

But hey, don't let me hold up progress.  I'm used to feeling like the last
person in the world still using a Solaris-based desktop.  If I had the money,
(Continue reading)

Martin Bochnig | 11 May 2013 01:43

May 18th (this year...): Launch date of OpenSXCE x86_64

Thank you Garrett, all.
Ok, I don't like to dictate anything.
Just try and C.

Q:

When will it ship.

A:

In the past I never held a single date, to make such predictions is usually difficult.
This time, though, it is different, because during creation of the SPARC version, I modified all pkgdefs in advance always also for i386 and amd64, in the same source tree.
So there is little guessing involved, as I had already compiled almost everything on x86 in October (at the then current state), and afterwards _always_ keept the pkgdefs in sync by definition, until in had to stop on January 30th. For example, before I continued with SPARC in October, I tar'ed everything over after the compile on x86.

So the only real task involved: Move my disks containing the devel pool over to my prepared DualCore Celeron 2.4GHz (with Sandy bridge), re-build it, just "make install -k"'ing the SVR4 packages and also build JDS and its packages, the same accordingly for all gates.
The only actual work is to fix a few packaging build errors , where it fails. So on those places where it was difficult to write the pkgdefs for x86 blindly, while I did this on SPARC.

The 1rst part of the selfhosting work is also completed on SPARC, this actually had distracted me last week from continuing with x86.
Now I identiefied the very files that are missing. However, this is not yet reflected by corrected pkgdefs. I think most of us find it more important to have something to run and test on x86. So let me suspend selfhosting, although only the last mile needs to be gone. All focus shifted to the May 18th release of our first x86_64 version of OpenSXCE.

I won't have time to read/answer/write email.
So the next thing you will hear from me is the download link, on May18th.

p.s.  Garrett: I fully understand why you prefer IPS as the basis in Illumos.
Only to avoid a misunderstanding, OpenSXCE does not use IPS's manifests in any way.
Here again, why:

http://openindiana.org/pipermail/openindiana-discuss/2012-December/010921.html

"""

There would have been 2 fundamental approaches: Easy and tougher. The first would be to take all IPS manifests and convert them semi-automated to SVR4 prototype/pkginfo/depend files. And simply to keep all the new pkg sets and pkg names and dependencies just intact. This would certainly be nice and interesting. Maybe someone want's to do that, too :) However, this would break dependency resolution backwards compatibility to all legacy SVR4 packages in existance. For this reason, I neglected it. The second one was, to reverse-engineer everything back to the old times. And that's what I did. Not just for Illumos/OSnet, but for ___all___ consolidations. Not just to get old pkgdefs to build without failiure (where they are available), but also to re-assign more than 15 thousand (!) unassigned files to new pkgdefs (this number for Illumos ON alone!!!) Also it was necessary to take older G11N checkouts (just as one example), because we need the good old /usr/openwin internationalization stuff as well, for OpenXsun. """




Somebody can try it the other (way easier and million times more convenient) way.
But then this breaks legacy SUNW* deps.
tnx


%martin



_______________________________________________
oi-dev mailing list
oi-dev <at> openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev
James Winter | 10 May 2013 16:58
Picon

Orange Indiana?

What if we created a "branch" from the kernel that would then allow 
portability across all platforms.  Kinda like the Motorola / Android / 
Ubuntu project they had a few years back.  In the project they had 1 
android phone that when placed on a dock was able to use the android 
kernel and run an Ubuntu desktop natively.

Totally agree on the developer / sysadmin perspective that the "daily 
driver"
just "needs to work" so I have used Apple in the past.  Fed up with the 
walled garden mentality of the iPhone I started to look at the different 
brands and marketing approaches that have been used in the past to work 
on a project that would be affordable, have a commercial branch for 
support and be up to date.  If (any of) the commercial branch(s) create 
changes within the code, they would be required to release the code 
after a "grace period" (thinking about monthly releases if viable so 32 
days for the release of the commercial changes to give the open group ~ 
a month to add it in for the next release and those that wish to pay for 
the support services would have the improvements, patches and releases 2 
months in advance if not added already into the open group)

I would be open to discussion about starting a commercial group based on 
the Open Indiana / illumos platform.

James R. M. Winter
Andrzej Szeszo | 9 May 2013 10:01
Picon
Gravatar

OI project reboot required

Hi All

(Instead of replying to a message in one of the other threads I thought I will create a new one.)

Just wanted to say that I don't see a future for the project in its current form. There is simply too many packages and too much baggage for a handful of people to look after.

I think the project needs a new vision and a reboot. If you have any ideas for the project and can write scripts/makefiles to generate a distro/live CDs/etc. - speak up! You don't have to be a leader if you don't want to :)

Regards,

Andrzej

_______________________________________________
oi-dev mailing list
oi-dev <at> openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev
G B | 6 May 2013 16:40
Picon
Favicon

Building OpenIndiana

I there a page that lists the steps to build OpenIndiana that is current?  I've looked at the building Illumos wiki and a couple of building OI pages, but am unsure of the exact steps.  There is a page that says oi-build is the new way, so that must negate what is on the Illumos page.
 
If someone can edit the build page with the necessary steps I'd appreciate it so I can attempt it.
 
Thanks
_______________________________________________
oi-dev mailing list
oi-dev <at> openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev
Jean-Pierre | 25 Apr 2013 15:21
Picon

Broadcom wireless drivers for OpenIndiana

I have uploaded to
http://jp-andre.pagesperso-orange.fr/ndis.1.3.0.rc2.tar.gz
a release candidate for an ndis emulator which can emulate the
NDIS5 interface in 64-bit mode for Broadcom wireless drivers
designed for Windows.

This is a source tarball for which completing a Makefile really
usable on OpenIndiana is left as an exercice for the user.
Please read the included bcm4312.htm files for the procedure
to compile and install.

I have tested the emulator with my wireless device (vendor 14E4
device 4315) and the three versions of the Broadcom driver
described below. Jim Klimov has sucessfully tested the latest
version with his own device (vendor 14E4 device 4727).

Only WEP encryption is available so far (WPA is not supported).

Supported devices by driver 4.170.25.12, September 21, 2007
(from Dell R174291.exe) :

Vendor 14E4 device 4311
Vendor 14E4 device 4312
Vendor 14E4 device 4315
Vendor 14E4 device 4318
Vendor 14E4 device 4319
Vendor 14E4 device 4320 rev 03
Vendor 14E4 device 4324 rev 03
Vendor 14E4 device 4328

Supported devices by driver 4.170.77.3, March 22, 2008
(from HP sp39912.exe), same as above, plus :

Vendor 14E4 device 4307
Vendor 14E4 device 432B

Supported devices by driver 5.60.350.6, March 23, 2010
(from HP sp48616.exe), same as above, plus :

Vendor 14E4 device 4353
Vendor 14E4 device 4357
Vendor 14E4 device 4727

Enjoy,

Jean-Pierre
G B | 23 Apr 2013 14:17
Picon
Favicon

Vulnerabilities

Are vulnerabilities like these below fixed by illumos?  I know the "security" page on OI is dead and has never had any markups since it was created, and I am reasonably certain there isn't an OI Security officer to handle matters. 
 
If they are fixed in illumos, then what is the process of having them available via 'pkg image-update' without having to go to the next release e.g., 151a8?
 
sun -- sunos
Unspecified vulnerability in Oracle Sun Solaris 8, 9, 10, and 11 allows remote attackers to affect confidentiality and integrity via vectors related to NFS client mounts and IPv6. 2013-04-17 6.4 CVE-2013-0405
sun -- sunos
Unspecified vulnerability in Oracle Sun Solaris 10 allows remote attackers to affect integrity via unknown vectors via vectors related to Kernel/IPsec. 2013-04-17 4.3 CVE-2013-0406
sun -- sunos
Unspecified vulnerability in Oracle Sun Solaris 10 allows local users to affect availability via vectors related to CPU performance counters drivers. 2013-04-17 5.0 CVE-2013-0408
sun -- sunos
Unspecified vulnerability in Oracle Sun Solaris 8, 9, and 10 allows local users to affect confidentiality, integrity, and availability via vectors related to RBAC Configuration. 2013-04-17 5.9 CVE-2013-0411
sun -- sunos
Unspecified vulnerability in Oracle Sun Solaris 10 and 11 allows local users to affect confidentiality, integrity, and availability via unknown vectors related to Remote Execution Service. 2013-04-17 4.4 CVE-2013-0413
sun -- sunos
Unspecified vulnerability in Oracle Sun Solaris 10, when running on SPARC T4 servers, allows local users to affect availability via unknown vectors related to Kernel. 2013-04-17 4.7 CVE-2013-1494
sun -- sunos
Unspecified vulnerability in Oracle Sun Solaris 10 and 11 allows local users to affect availability via unknown vectors related to Kernel/IO, a different vulnerability than CVE-2013-1498. 2013-04-17 4.9 CVE-2013-1496
sun -- sunos
Unspecified vulnerability in Oracle Sun Solaris 10 and 11 allows local users to affect availability via unknown vectors related to Kernel/IO, a different vulnerability than CVE-2013-1496. 2013-04-17 4.9 CVE-2013-1498
sun -- sunos
Unspecified vulnerability in Oracle Sun Solaris 8, 9, and 10 allows local users to affect confidentiality via unknown vectors related to Utility/fdformat. 2013-04-17 2.1 CVE-2012-0568
sun -- sunos
Unspecified vulnerability in Oracle Sun Solaris 8, 9, 10, and 11 allows local users to affect availability via unknown vectors related to Libraries/Libc. 2013-04-17 2.1 CVE-2012-0570
sun -- sunos
Unspecified vulnerability in Oracle Sun Solaris 8, 9, 10, and 11 allows local users to affect availability via unknown vectors related to Utility. 2013-04-17 1.9 CVE-2013-0403
sun -- sunos
Unspecified vulnerability in Oracle Sun Solaris 10 allows local users to affect confidentiality, integrity, and availability via unknown vectors related to Kernel/Boot. 2013-04-17 3.7 CVE-2013-0404
sun -- sunos
Unspecified vulnerability in Oracle Sun Solaris 8, 9, 10, and 11 allows local users to affect integrity and availability via unknown vectors related to Utility/pax. 2013-04-17 3.6 CVE-2013-0412
sun -- sunos
Unspecified vulnerability in Oracle Sun Solaris 11 allows local users to affect availability via unknown vectors related to Network Configuration. 2013-04-17 1.7 CVE-2013-1499
sun -- sunos
Unspecified vulnerability in Oracle Sun Solaris 10 allows local users to affect availability via unknown vectors related to Kernel. 2013-04-17 3.8 CVE-2013-1530
_______________________________________________
oi-dev mailing list
oi-dev <at> openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev
G B | 14 Apr 2013 16:51
Picon
Favicon

State of development

Presently my commercial websites and mail servers run on OpenBSD, but I am in the process of moving them to either OpenIndiana, FreeBSD, or NetBSD.  I have more than a decade using Solaris in the enterprise for some very large companies, so my knowledge of Solaris gives OI a step ahead of the competition.

FreeBSD does have DTrace and ZFS, but ZFS is installed by default by OI (of course).  But OI also gives me the opportunity to run Solaris binaries such as ooRexx and DB2 that the others cannot run.  FreeBSD does have ooRexx 3.0 available, but only for the i386 architecture, and I need amd64.

The OI website seems to not be mostly unmaintained and although the openindiana.org site is available, the few mirrors that did or do exist seem to be shutting down.

I would certainly like to use OI, but I'm concerned about the state.

OI's last release was Oct 2012, so my question is when is the next release (151a8) scheduled to be released? 
_______________________________________________
oi-dev mailing list
oi-dev <at> openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev
Jim Klimov | 28 Mar 2013 17:39
Picon

Re: [developer] BMC driver on Illumos

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 ;)

//Jim

_______________________________________________
oi-dev mailing list
oi-dev <at> openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev
Gordon Ross | 26 Mar 2013 21:20
Picon
Gravatar

"Heads up" for OI and other ips consumers: 3648 add ipkg brand scripts

Rich is right.  I was thinking a "heads up" might be enough,
but let me ask here:  Is it?  Or would you like me to submit
changes to remove these same scripts from pkg-gate?
(hg.openindiana.org/sustaining/oi_151a/pkg-gate)

Thanks,
Gordon

---------- Forwarded message ----------
From: Richard Lowe <richlowe <at> richlowe.net>
Date: Tue, Mar 26, 2013 at 4:01 PM
Subject: Re: [developer] Please review: 3648 add ipkg brand scripts
To: Gordon Ross <gordon.w.ross <at> gmail.com>

You're going to need to tell us how you plan to coordinate this with
OI and OmniOS

-- Rich

2013/3/24 Gordon Ross <gordon.w.ross <at> gmail.com>:
> OK, here's a webrev for this integration:
>   http://yalms.org/cr/illumos-ipkg/
>   https://www.illumos.org/issues/3648
>
> I did my best to show webrev that most of these
> are file copies, setting up a temporary parent WS
> with the relevant ipkg gate files copied to tmp/...
>
> Thanks,
> --
> Gordon Ross <gwr <at> nexenta.com>
> Nexenta Systems, Inc.  www.nexenta.com
> Enterprise class storage for everyone
>
>
> -------------------------------------------
> illumos-developer
> Archives: https://www.listbox.com/member/archive/182179/=now
> RSS Feed: https://www.listbox.com/member/archive/rss/182179/21175253-52f9b689
> Modify Your Subscription: https://www.listbox.com/member/?member_id=21175253&id_secret=21175253-417ceaa9
> Powered by Listbox: http://www.listbox.com

--

-- 
Gordon Ross <gwr <at> nexenta.com>
Nexenta Systems, Inc.  www.nexenta.com
Enterprise class storage for everyone

Gmane