[TUHS] Illumos )

[TUHS] Illumos )

[Larry McVoy]

Yo Jacob,

I'm ex-sun but I don't know too much about Illumos.   Care to give us 
the summary of why I might care about it?

On Wed, Dec 31, 2014 at 01:16:00AM -0500, Jacob Ritorto wrote:
> Hey, thanks, Derrik.
>   I don't mess with Linux much (kind of an Illumos junkie by trade ;), but
> I bet gcc would.  I did out of curiosity do it with the Macintosh cc (Apple
> LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)) and it throws
> warnings about our not type-defining functions because you're apparently
> supposed to do this explicitly these days, but it dutifully goes on to
> assume int and compiles our test K&R stuff mostly fine.  It does
> unfortunately balk pretty badly at the naked returns we initially had,
> though.  Wish it didn't because it strikes me as being beautifully simple..
> 
> thx again for the encouragement!
> jake
> 
> 
> On Wed, Dec 31, 2014 at 1:02 AM, Derrik Walker v2.0 <dwalker at doomd.net>
> wrote:
> 
> > On Wed, 2014-12-31 at 00:44 -0500, Jacob Ritorto wrote:
> >
> > >
> > > P.S. if anyone's bored enough, you can check out what we're up to at
> > > https://github.com/srphtygr/dhb.  I'm trying to get my 11yo kid to
> > > spend a little time programming rather than just playing video games
> > > when he's near a computer.  He'a actually getting through this stuff
> > > and is honestly interested when he understands it and sees it work --
> > > and he even spotted a bug before me this afternoon!  Feel free to
> > > raise issues, pull requests, etc. if you like -- I'm putting him
> > > through the git committing and pair programming paces, so outside
> > > interaction would be kinda fun :)
> > >
> > >
> > > P.P.S.  We're actually using 2.11bsd after all..
> > >
> > I'm curious, will gcc on a modern Linux system compile K&R c?
> >
> > Maybe when I get a little time, I might try to see if I can compile it
> > on a modern Fedora 21 system with gcc.
> >
> > BTW: Great job introducing him to such a classic environment. A few
> > years ago, my now 18 year old had expressed some interest in graphics
> > programming and was in awe over an SGI O2 I had at the time, so I got
> > him an Indy.  He played around with a bit of programming, but
> > unfortunately, he lost interest.
> >
> > - Derrik
> >
> >
> > _______________________________________________
> > TUHS mailing list
> > TUHS at minnie.tuhs.org
> > https://minnie.tuhs.org/mailman/listinfo/tuhs
> >

> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs


-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

[TUHS] Illumos )

[Wesley Parish]

Illumos is a branch (or fork: I'm not sure which word is most appropriate here)
of OpenSolaris: if my memory serves me right (always a bit ask) it's a
debianized OpenSolaris
http://wiki.illumos.org/display/illumos/illumos+Home

OpenIndiana is another such project
http://openindiana.org/

and I think there are some other OpenSolaris branch/fork tree available, but i
don't know anything about them. Their primary importance, from my POV, is that
they keep the POSIX space open for experimentation: a Linux monoculture's as
deadening as a MS Windows monoculture or a [choose your own poison] monoculture ...

Wesley Parish

Quoting Larry McVoy <lm at mcvoy.com>:

> Yo Jacob,
> 
> I'm ex-sun but I don't know too much about Illumos. Care to give us 
> the summary of why I might care about it?
> 
> On Wed, Dec 31, 2014 at 01:16:00AM -0500, Jacob Ritorto wrote:
> > Hey, thanks, Derrik.
> > I don't mess with Linux much (kind of an Illumos junkie by trade ;),
> but
> > I bet gcc would. I did out of curiosity do it with the Macintosh cc
> (Apple
> > LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)) and it
> throws
> > warnings about our not type-defining functions because you're
> apparently
> > supposed to do this explicitly these days, but it dutifully goes on
> to
> > assume int and compiles our test K&R stuff mostly fine. It does
> > unfortunately balk pretty badly at the naked returns we initially
> had,
> > though. Wish it didn't because it strikes me as being beautifully
> simple..
> > 
> > thx again for the encouragement!
> > jake
> > 
> > 
> > On Wed, Dec 31, 2014 at 1:02 AM, Derrik Walker v2.0
> <dwalker at doomd.net>
> > wrote:
> > 
> > > On Wed, 2014-12-31 at 00:44 -0500, Jacob Ritorto wrote:
> > >
> > > >
> > > > P.S. if anyone's bored enough, you can check out what we're up to
> at
> > > > https://github.com/srphtygr/dhb. I'm trying to get my 11yo kid to
> > > > spend a little time programming rather than just playing video
> games
> > > > when he's near a computer. He'a actually getting through this
> stuff
> > > > and is honestly interested when he understands it and sees it work
> --
> > > > and he even spotted a bug before me this afternoon! Feel free to
> > > > raise issues, pull requests, etc. if you like -- I'm putting him
> > > > through the git committing and pair programming paces, so outside
> > > > interaction would be kinda fun :)
> > > >
> > > >
> > > > P.P.S. We're actually using 2.11bsd after all..
> > > >
> > > I'm curious, will gcc on a modern Linux system compile K&R c?
> > >
> > > Maybe when I get a little time, I might try to see if I can compile
> it
> > > on a modern Fedora 21 system with gcc.
> > >
> > > BTW: Great job introducing him to such a classic environment. A few
> > > years ago, my now 18 year old had expressed some interest in
> graphics
> > > programming and was in awe over an SGI O2 I had at the time, so I
> got
> > > him an Indy. He played around with a bit of programming, but
> > > unfortunately, he lost interest.
> > >
> > > - Derrik
> > >
> > >
> > > _______________________________________________
> > > TUHS mailing list
> > > TUHS at minnie.tuhs.org
> > > https://minnie.tuhs.org/mailman/listinfo/tuhs
> > >
> 
> > _______________________________________________
> > TUHS mailing list
> > TUHS at minnie.tuhs.org
> > https://minnie.tuhs.org/mailman/listinfo/tuhs
> 
> 
> -- 
> ---
> Larry McVoy 	 lm at mcvoy.com http://www.mcvoy.com/lm 
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuh s
>  

[TUHS] Illumos )

[John Cowan]

Wesley Parish scripsit:

> [The] primary importance [of Solaris forks], from my POV, is that they
> keep the POSIX space open for experimentation: a Linux monoculture's
> as deadening as a MS Windows monoculture or a \[choose your own poison\]
> monoculture ...

Well, BSD does that.  But Solaris is the only descendant of System V for
which we have source, which means that in non-Posix cases it can give
us helpful information how the original Unix code fared after leaving
the Labs.  By comparison, both Linux and BSD are clones.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
Rather than making ill-conceived suggestions for improvement based on
uninformed guesses about established conventions in a field of study with
which familiarity is limited, it is sometimes better to stick to merely
observing the usage and listening to the explanations offered, inserting
only questions as needed to fill in gaps in understanding. --Peter Constable

[TUHS] Illumos )

[Diomidis Spinellis]

On 31/12/2014 15:13, John Cowan wrote:
> Wesley Parish scripsit:
>
>> [The] primary importance [of Solaris forks], from my POV, is that they
>> keep the POSIX space open for experimentation: a Linux monoculture's
>> as deadening as a MS Windows monoculture or a \[choose your own poison\]
>> monoculture ...
>
> Well, BSD does that.  But Solaris is the only descendant of System V for
> which we have source, which means that in non-Posix cases it can give
> us helpful information how the original Unix code fared after leaving
> the Labs.  By comparison, both Linux and BSD are clones.

Thank you for stressing the importance of Solaris as a Unix descendant 
for which source code is available.  It's a pity that we don't have 
public source code for the Solaris versions 2.1 to 10, so there's a 15 
year gap between System V R4 and the first release of Open Solaris.

I don't agree that BSD systems are a clone of Unix.  There are bits in 
them that were written at Bell Labs.  The earliest example I've found up 
to now comes from timezone.c, and was written at least 36 years ago 
(1979-01-10 14:58:45).

Compare the 7th Edition implementation of timezone()

http://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/libc/gen/timezone.c

with lines 110-128 of the current FreeBSD _tztab() implementation.

https://github.com/freebsd/freebsd/blob/master/lib/libc/gen/timezone.c

(How did I find it?  For the past six months I've been running git blame 
on various tags of https://github.com/dspinellis/unix-history-repo.)

Happy new year everybody!

-- 
Diomidis Spinellis      http://www.spinellis.gr

[TUHS] Illumos )

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1166 bytes --]

On Wed, Dec 31, 2014 at 12:42 PM, Diomidis Spinellis <dds at aueb.gr> wrote:

> Thank you for stressing the importance of Solaris as a Unix descendant for
> which source code is available.
>
​Amen​.   BTW:
I really don't consider Solaris a pure System V ​either.  Larry and his
siblings hacked on it pretty heavily.    SGI's Iris and NCR's RAS were much
closer to "pure" Summit code and that was not "Research" UNIX.   They all
devolved.




> It's a pity that we don't have public source code for the Solaris versions
> 2.1 to 10, so there's a 15 year gap between System V R4 and the first
> release of Open Solaris.
>
> I don't agree that BSD systems are a clone of Unix.
>
​Ditto.   To me, anything post First Edition of Research UNIX is UNIX.
Where hacking started and was slowly changed.   But the core BTL DNA was is
left intact.    Idris, Linux, Minux, etc. were clones, where the API was
followed and the DNS regenerated.

​Either way, it really does not matter too much.

Clem​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20141231/06392d71/attachment.html>

[TUHS] Illumos )

[Larry McVoy]

On Wed, Dec 31, 2014 at 03:32:07PM -0500, Clem Cole wrote:
> On Wed, Dec 31, 2014 at 12:42 PM, Diomidis Spinellis <dds at aueb.gr> wrote:
> 
> > Thank you for stressing the importance of Solaris as a Unix descendant for
> > which source code is available.
> >
> ???Amen???.   BTW:
> I really don't consider Solaris a pure System V either.

Nope, not by a long stretch.  System V had an awful VM / file system layer,
Solaris took the one from SunOS 4 and wedged it in there.

> Larry and his siblings hacked on it pretty heavily.

Not me, man.  I hated Solaris with a passion.  I liked SunOS 4.x, I hacked
the heck out of that.

[TUHS] Illumos )

[Jacob Ritorto]

Wow, Larry, were you one of the guys in Sun who actually lobbied to abandon
Solaris 2 and resurrect SunOS 4.x when Solaris 2.3 flopped?

  Sorry for the late answer to your original question about why we should
care about Illumos, but here's my take and some personal observations /
conclusions to boot:


  With a huge sustained effort by many of the people who wrote and/or
maintained it, Solaris was finally mostly open-sourced just before Sun
died.  There was so much good technology in the OS that it would've been a
real shame to relegate it to the Oracle people who would (did) eventually
close it, effectively killing Solaris.

 Illumos is the OS/net piece, not a distro, and takes the reins from the
moment that Oracle re-closed Solaris as the base and repo-of-record for a
number of distributions, such as the ones mentioned above, OpenIndiana,
OpenSXCE, Tribblix and most importantly to me, SmartOS from Joyent.  I
don't (yet) work for Joyent, so don't take this as a sales spin or anything
-- it's just that the company I worked for last year underwent a rather
amazing and inspirational cultural as well as technology / performance
growth when we switched the stack from CentOS to SmartOS.  It was really
cool to see the eyes opening while working with some pretty brilliant
programmers who effectively 'grew up on linux' when they saw how
engineered, featureful and just generally "sorted out" SmartOS was.  They
started using dtrace to dig into performance problems, smf to manage
services, speed of containers / zones instead of full linux VMs everywhere,
real (not hypervisor-emulated) I/O using zfs straight to SSD arrays, etc.
They saw that, in fact, a well written and architected operating system
actually does matter quite a lot for their day to day work.

  And it's all seriously free and open source.  Like, Real Actual unix, not
a clone.  The way it was meant to be.  They actually really care, not just
about being "good enough", but about continuing to develop the operating
system in an artful, elegantly simple, efficient and practical way.

  This, to me, is the perfect contrast to the Linux culture that seems to
wantonly embrace the 'copy/paste coding' / 'bazaar' / 'good enough'
mentality and seems to do no innovation but just produce knockoff,
un-architected partial functional clones of what the unix people invented.
But they miss the interacting, distributed, tolerant and very polyclutural
computing environment concepts every time.  I think they're effectively
dragging the unix ecosystem into the shitter.  Not that this hasn't been
done before, but at least before it was ill-thought-out litigious zeal, not
junk code and minimum-viable-product quality problems.  This brings to mind
the one major, albeit non-technical, problem I recognize Linux (actually,
perhaps it was just GNU) as having truly solved - they made it really
stinking clear that your license has to be open.  OSI approved open
source.  And that accomplishment, of itself, makes it totally worth
tolerating its existence.

  Please accept my apologies if I've offended you with the opinionated
content there.  These are my honest observations after four decades of
doing this, but may seem like flame bait to many.  I don't write about this
stuff often and I figure: if anyone's going to be able to understand and
respond with constructive input to this train of thought, it's the unix
historians here.

  Anyway, a friend I admire quite a lot took the time to put some of this
Sun history and Illumos fork stuff into a talk at LISA a few years back and
I think he did a really nice job.  Have a look if you like:
www.youtube.com/watch?v=-zRN7XLCRhc

  Some other interesting reading from another brilliant guy I worked with a
little, who got so disheartened about the failure of tech -- partially
Linux monoculture, partially other sad moves -- just walked away from tech
to farming instead: http://dtrace.org/blogs/wesolows/2014/12/29/fin/

  Then there's Kamp's recent article:
https://queue.acm.org/detail.cfm?id=2349257

Thanks for your time and interest; In earnest,
jake


On Wed, Dec 31, 2014 at 3:36 PM, Larry McVoy <lm at mcvoy.com> wrote:

> On Wed, Dec 31, 2014 at 03:32:07PM -0500, Clem Cole wrote:
> > On Wed, Dec 31, 2014 at 12:42 PM, Diomidis Spinellis <dds at aueb.gr>
> wrote:
> >
> > > Thank you for stressing the importance of Solaris as a Unix descendant
> for
> > > which source code is available.
> > >
> > ???Amen???.   BTW:
> > I really don't consider Solaris a pure System V either.
>
> Nope, not by a long stretch.  System V had an awful VM / file system layer,
> Solaris took the one from SunOS 4 and wedged it in there.
>
> > Larry and his siblings hacked on it pretty heavily.
>
> Not me, man.  I hated Solaris with a passion.  I liked SunOS 4.x, I hacked
> the heck out of that.
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20141231/29783dc5/attachment.html>

[TUHS] Illumos )

[Larry McVoy]

On Wed, Dec 31, 2014 at 05:19:15PM -0500, Jacob Ritorto wrote:
> Wow, Larry, were you one of the guys in Sun who actually lobbied to abandon
> Solaris 2 and resurrect SunOS 4.x when Solaris 2.3 flopped?

Over and over and over again.  You have no idea.

>   Anyway, a friend I admire quite a lot took the time to put some of this
> Sun history and Illumos fork stuff into a talk at LISA a few years back and
> I think he did a really nice job.  Have a look if you like:
> www.youtube.com/watch?v=-zRN7XLCRhc

Yeah, I know Bryan pretty well, we used to be neighbors in Noe Valley
and have spent a fair amount of time discussing OS stuff.  Here's 
Bryan, Jeff Bonwick, and Bill Moore at my place in the Santa Cruz 
mountains:

http://www.mcvoy.com/lm/photos/2007/05/257.html

and Bill and Linus talking file systems at the same party:

http://www.mcvoy.com/lm/photos/2007/05/255.html

The best shot was the next morning when the women were gathered around
Linus asking him how he lost weight:

http://www.mcvoy.com/lm/photos/2007/05/276.html

His answer?  "Eat less."  "Did you stop drinking?"  Hell no, I like my beer!"

Fun times.  

I don't agree that Linux is as bad as you have described,
Linus has pretty reasonable taste.

Solaris may be sorted but /proc in Linux is oh-so-much-more-useful.

My view is Linux is pragmatic about stuff, Solaris was dogmatic about it.
Yeah, the latter leads to better thought out stuff but the former tends
to be useful sooner.

--lm

[TUHS] Illumos )

[Larry McVoy]

On Wed, Dec 31, 2014 at 02:42:49PM -0800, Larry McVoy wrote:
> On Wed, Dec 31, 2014 at 05:19:15PM -0500, Jacob Ritorto wrote:
> > Wow, Larry, were you one of the guys in Sun who actually lobbied to abandon
> > Solaris 2 and resurrect SunOS 4.x when Solaris 2.3 flopped?
> 
> Over and over and over again.  You have no idea.
> 
> >   Anyway, a friend I admire quite a lot took the time to put some of this
> > Sun history and Illumos fork stuff into a talk at LISA a few years back and
> > I think he did a really nice job.  Have a look if you like:
> > www.youtube.com/watch?v=-zRN7XLCRhc
> 
> Yeah, I know Bryan pretty well, we used to be neighbors in Noe Valley
> and have spent a fair amount of time discussing OS stuff.  Here's 
> Bryan, Jeff Bonwick, and Bill Moore at my place in the Santa Cruz 
> mountains:
> 
> http://www.mcvoy.com/lm/photos/2007/05/257.html

Sorry, I should assume people know who is who, that's Bryan on the left,
Jeff is making like a chicken, Bill on the right.

Jeff and Bill were the main ZFS guys (I hired Jeff at Sun, he was one of
my students at Stanford; Bill worked for me on BitKeeper and went on to
do ZFS and then a storage startup that EMC bought for a bazillion dollars,
Bill now lives on the largest lot in Los Altos :)

Smart guys, it was fun listening to that crowd chat.

[TUHS] Illumos )

[Larry McVoy]

On Wed, Dec 31, 2014 at 02:50:35PM -0800, Larry McVoy wrote:
> On Wed, Dec 31, 2014 at 02:42:49PM -0800, Larry McVoy wrote:
> > On Wed, Dec 31, 2014 at 05:19:15PM -0500, Jacob Ritorto wrote:
> > > Wow, Larry, were you one of the guys in Sun who actually lobbied to abandon
> > > Solaris 2 and resurrect SunOS 4.x when Solaris 2.3 flopped?
> > 
> > Over and over and over again.  You have no idea.
> > 
> > >   Anyway, a friend I admire quite a lot took the time to put some of this
> > > Sun history and Illumos fork stuff into a talk at LISA a few years back and
> > > I think he did a really nice job.  Have a look if you like:
> > > www.youtube.com/watch?v=-zRN7XLCRhc
> > 
> > Yeah, I know Bryan pretty well, we used to be neighbors in Noe Valley
> > and have spent a fair amount of time discussing OS stuff.  Here's 
> > Bryan, Jeff Bonwick, and Bill Moore at my place in the Santa Cruz 
> > mountains:
> > 
> > http://www.mcvoy.com/lm/photos/2007/05/257.html
> 
> Sorry, I should assume people know who is who, that's Bryan on the left,

s/should/shouldn't/

Sigh.  I swear I wasn't drinking, just a brain fart.

> Jeff is making like a chicken, Bill on the right.
> 
> Jeff and Bill were the main ZFS guys (I hired Jeff at Sun, he was one of
> my students at Stanford; Bill worked for me on BitKeeper and went on to
> do ZFS and then a storage startup that EMC bought for a bazillion dollars,
> Bill now lives on the largest lot in Los Altos :)
> 
> Smart guys, it was fun listening to that crowd chat.
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

[TUHS] Illumos )

[Erik E. Fair]

> Date: Wed, 31 Dec 2014 17:17:16 -0800
> From: Larry McVoy <lm at mcvoy.com>

> Sigh.  I swear I wasn't drinking, just a brain fart.

Tonight's the night for drinking - wash away 2014 in a bath of your
favored libation!

	Happy New Year from blustery Lake Tahoe,

	Erik <fair at netbsd.org>

[TUHS] Illumos )

[Tim Bradshaw]

On 31 Dec 2014, at 22:42, Larry McVoy <lm at mcvoy.com> wrote:

> My view is Linux is pragmatic about stuff, Solaris was dogmatic about it.
> Yeah, the latter leads to better thought out stuff but the former tends
> to be useful sooner.

I think that this is exactly right. I used Solaris for pretty much my whole 
career (BSD then SunOS then Solaris) and eventually I had to give up and just admit that, for reasons I don't understand but are probably to do with culture at Sun, Solaris was making a lot of decisions which smelt like ones that an academic who didn't need to actually care about use in the real world might make, while Linux almost never did that (it had/has other problems, specifically long-term interface stability).

The case that made me finally realise that Solaris Had Lost was ZFS, and specifically ZFS consistency check.  There is (was in ~2010) *no way to check a zpool outside the kernel*, so if you had a zpool which you thought might be damaged you were supposed to check it by importing it.  So all that check code which had to deal with possibly completely random crap in the pool ran in the kernel where any kind of serious mistake involved, if you're lucky, the machine crashing, and if you're not lucky some awful data-corruption problem.  But that's OK, because the ZFS code is all perfect, and never has any problems at all, of course.

[TUHS] Illumos )

[Jacob Ritorto]

On Mon, Jan 5, 2015 at 7:02 AM, Tim Bradshaw <tfb at tfeb.org> wrote:

> On 31 Dec 2014, at 22:42, Larry McVoy <lm at mcvoy.com> wrote:
>
> > My view is Linux is pragmatic about stuff, Solaris was dogmatic about it.
> > Yeah, the latter leads to better thought out stuff but the former tends
> > to be useful sooner.
>
> I think that this is exactly right.


I'm mostly agreeing with the gist of this, although I'd shy away from
taking it as an absolute.  I think the motivation for the dogmatic
behaviour stems from not wanting to utterly immerse in the "just hack it"
mindset.  They were from the cathedral days and, from experience of the
previous iterations of it, participated in the contemporary bazaar mindset
with caution and reservation.  One example is the penchant for (arguably
over-) applying higher level design to a problem instead of just doing
something myopic and 'good enough' to get through a minimum viable product
scenario.  It's a gradient, not a slippery slope and finding the sweet spot
within it is, of course, an exercise in pragmatism.


> [...] Solaris was making a lot of decisions which smelt like ones that an
> academic who didn't need to actually care about use in the real world might
> make, while Linux almost never did that (it had/has other problems,
> specifically long-term interface stability).


Even in SmartOS (Illumos-derived and vociferously "not-Solaris-anymore"),
which amplifies both the pragmatism and the 10000' view design tenets, I
still run into that. An a low-hanging example, while the rest of the
world's happily wheelbarrowing everything into /usr/local and one has to
"follow the rules" and use /opt, it's smacks of an unnecessary kick in the
eye that, unix dissenters could argue, just breaks shit for spite.  I
understood it culturally -- for SVR4-steeped folks, it was a parseable
style pattern / smell -- when you saw a machine configured around
/usr/local, you braced yourself for an unbridled shitshow.  We all kind of
stepped back and grew some pragmatism around that, though -- Joyent, after
much griping from me and my co-workers, came out with sngl containers to
stop this hubris so we could use Chef recipes more easily, albiet rather
late in the game (2012-ish).  Now you can more readily build stuff as a
toddler builds with his blocks.  The brilliant bit is that with SmartOS,
you now academic design, stability, speed and real world usability.

 There's certainly a platform for debate, perhaps in another thread, around
the merits of understanding and engineering everything -vs.- building with
blocks.



>
> The case that made me finally realise that Solaris Had Lost was ZFS, and
> specifically ZFS consistency check.

There is (was in ~2010) *no way to check a zpool outside the kernel*, so if
> you had a zpool which you thought might be damaged you were supposed to
> check it by importing it.


  I'm afraid there's bias confirmation and a zeal for driving nails into
coffins happening here.  Bear in mind that unix didn't even have fsck for a
decade after its release (it appeared after v7 released), while conversely,
zfs had the manual scrub command and other manual zfs recovery tools
(which, much like fsck and icheck, et al, admittedly required expert
knowledge to wield successfully) before it released.  Yes, the default is
that the system will panic or pass over a zfs it can't mount, but that's by
design and when I was in that situation myself, even as a zfs noob, I
managed to figure out how to recover without damaging my pool.  Would you
care to compare this experience to some of the battles we've all personally
waged with fsck?  In the unix tradition, zfs is a designed and deliberate
iteration (innovation) on the filesystem concept, not a "pragmatic,"
good-enough, minimum viable product hip-shot, and the obvious fact that it
isn't what we're used to doesn't make it bad.  While there are certainly
plenty of Solaris coffin nails, this ain't one.

  Here's my favourite Solaris coffin nail: Oracle's last five years of
lawnmowing, almost zero innovative milestones and clueless customer base
and community erosion and desecration.  I do now agree that Solaris is
finally and irredeemably dead.  Their lack of understanding and stewardship
has tragically transitioned it from the being the definitive unix system
to, in essence, a proprietary firmware for expensive iron.  But in the same
breath I'd also assert that Illumos and its derivatives have taken all the
good from it, continue to drive the fork forward in a wonderful variety of
ways, and are the repo- and distros-of-record for this flavour of unix.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150105/e2836386/attachment.html>

[TUHS] Illumos )

[Andy Kosela]

On Mon, Jan 5, 2015 at 11:04 AM, Jacob Ritorto <jacob.ritorto at gmail.com> wrote:
> Here's my favourite Solaris coffin nail: Oracle's last five years of
> lawnmowing, almost zero innovative milestones and clueless customer base and
> community erosion and desecration.  I do now agree that Solaris is finally
> and irredeemably dead.  Their lack of understanding and stewardship has
> tragically transitioned it from the being the definitive unix system to, in
> essence, a proprietary firmware for expensive iron.  But in the same breath
> I'd also assert that Illumos and its derivatives have taken all the good
> from it, continue to drive the fork forward in a wonderful variety of ways,
> and are the repo- and distros-of-record for this flavour of unix.

This is your way of putting history together, but I think that
objective view on the matter potray this a little bit differently.  I
personally know a lot of Fortune 500 shops still using Oracle Solaris
and happily migrating from Solaris 10 to Solaris 11, instead of
embracing Illumos and myriad of its incarnations.  You know why?

There could be only one answer -- all of those shops depend heavily on
other technologies provided by Oracle like databases and middleware,
and by sticking to one support vendor they actually save a lot.  There
is even more -- I see an increasing trend in adopting Oracle Linux in
enterprise in place of Red Hat Enterprise Linux also because of the
integration with Oracle databases and other Oracle technologies.

It is a shame that Oracle closed Solaris source, but to be honest
their integration of hardware and software is still unmatched if you
ask me.  If you take a look at their hardware and software plans they
have pretty solid plans going into 2019 for new new CPU's and Solaris
versions[1].  Their T4 and T5 chips are pretty sweet and perform
really well as compared to x86; they still also put a lot of
improvements into ZFS[2], so to say that Oracle Solaris is dead is a
gravely exaggeration.  In contrast Joyent is still just a small
start-up.  And start-up's come and go as we have seen recently with
the history of Joyent spin-off TextDrive run by Dean Allen.  I don't
see Oracle going anywhere in the next 25 years or so.

just my .02
--Andy

[1] http://www.oracle.com/us/products/servers-storage/servers/sparc/oracle-sparc/sparc-roadmap-slide-2076743.pdf
[2] https://blogs.oracle.com/darren/en_GB/entry/new_zfs_encryption_features_in

[TUHS] Illumos )

[Kurt H Maier]

Quoting Andy Kosela <akosela at andykosela.com>:

> There could be only one answer --

Vendor lock-in is not going to save Oracle Solaris, in exactly
the same way DB2 did not save AIX.

khm

[TUHS] Illumos )

[Tim Bradshaw]

On 5 Jan 2015, at 17:04, Jacob Ritorto <jacob.ritorto at gmail.com> wrote:

>  I'm afraid there's bias confirmation and a zeal for driving nails into coffins happening here.  Bear in mind that unix didn't even have fsck for a decade after its release (it appeared after v7 released), while conversely, zfs had the manual scrub command and other manual zfs recovery tools (which, much like fsck and icheck, et al, admittedly required expert knowledge to wield successfully) before it released. 

I own a vintage car, by which I don't mean the spurious things people now call 'vintage' but a car registered in 1930 or before.  It's a lovely thing to drive.  But it has no seatbelts, the fuel tank is over your knees and immediately behind the top of the engine (I try not to think about what that means in an accident) and rod brakes which you adjust with wingnuts.  I would not be happy with these features in a new car.

> Yes, the default is that the system will panic or pass over a zfs it can't mount, but that's by design and when I was in that situation myself, even as a zfs noob, I managed to figure out how to recover without damaging my pool.  Would you care to compare this experience to some of the battles we've all personally waged with fsck?  

Again: the 'fsck on old systems' comparison is simply not relevant, sorry: we have learnt a lot of stuff since then.  One thing we should have learnt is that you want code to run with the minimum possible privilege, because running things with too much privilege has led to appalling disasters which I'm sure I don't need to mention.  That means, for instance, that you should run nothing in the kernel that does not have to be there.  One thing which clearly does not have to be there is consistency checkers and debuggers for filesystems, of whatever kind. There is absolutely nothing in the design of ZFS which prevents that being done.

> In the unix tradition, zfs is a designed and deliberate iteration (innovation) on the filesystem concept, not a "pragmatic," good-enough, minimum viable product hip-shot, and the obvious fact that it isn't what we're used to doesn't make it bad.  While there are certainly plenty of Solaris coffin nails, this ain't one.

I'm extremely happy that ZFS is not a traditional filesystem, because the traditional volume-manager / filesystem model sucks, to put it mildly: I have spent enough of my life dealing with it that I just want it to be over. I just want ZFS to be properly engineered.  Instead, what will (has, probably) happen is a ZFS clone will appear for Linux, which will be properly engineered.  Such is the fate of Solaris: pride does, indeed, come before a fall.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150106/def16a4a/attachment.html>

[TUHS] Illumos )

[Jose R. Valverde]

On all of this discussion I mostly miss the word of old age and experience. 
Probably because the downing of the Bazaar came to crystallize the old
wisdom.

Let me explain: it is true that a cathedral is very well engineered. But it
is no less true that after any long experiece, it is but a glorified version 
of the humble bazaar shop.

When you start building and designing a cathedral you do it considering the
materials, tools and knowledge that you have at hand at the time. But times,
they are a'changin. And sooner or later the cathedral will not be fit for
your needs and you will need to build another. The life cycle may be longer,
or not, but it is still the same. You must throw away the design and start
a-new from scratch sooner or later.

To continue the analogy. I was often puzzled by ancient megalythic monuments.
I recently visited a multi-dolmen site. They transpire an evolution from the 
cave in a mountain to huge stones making up an artificial mountain and cave,
to smaller megalyths, to pyrammids, to probably smaller stone temples,
possibly to the brick and mortar ziggurats of the early bronze age... with
the obvious return to stone in the Classic to Neoclassic period and back to
brick and mortar today... 

At any rate, caves probably became inconvenient in the Neolythic when hunters
became farmers in the plains and they had to "reinvent" them. The Bronze Age
allowed reducing the size of the megalyths. The Iron Age allowed making regular
stones... and so on.

In the end, you start with Unix and one day you need to add unforeseen technology
such as VM, so you redesign and rebuild it. Then you need plug-and-play, so you
redesign and rebuild it. Then you want support for zillions of devices and need
to separate/modularize the kernel from device drivers, and redesign and rebuild
it to a micro-kernel-like system, and then you want to have zillions of hackers
or developers, and you need to redesign/rebuild it, and then you want isolation
and redesign it to have jails/VMs/whatever, and so on.

So, pray, what is the difference? For anything we build, we will have to re-design
and rebuild it sooner or later, because it no longer satisfies our needs or 
because new, better, more modern tools and needs come into existence. The life
cycle may be millenia, centuries, decades, years, months or weeks, but you
can never foresee all future needs, you will always have to re-design and 
re-build. You will always be "building", be it complex cathedrals of chaotic
bazaars. In the end they are both the same.

It is not the Cathedral versus the Bazaar. It is all about building for your
needs.

In the Classic times of the Roman monuments, every household also had its own
lair, shrine, for the family "good ancestors" which remained as gods (lares). 
You need both, the Cathedral and the Bazaar at all  times. A good mason, a good 
architect or a good IT professional understands of "building", and should not 
need to care whether his assignment is a temple or a shrine.

IMMHO

				j
-- 
		Scientific Computing Service
	Solving all your computer needs for Scientific
			Research.

		http://bioportal.cnb.csic.es

[TUHS] Illumos )

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2585 bytes --]

On Mon, Jan 5, 2015 at 12:04 PM, Jacob Ritorto <jacob.ritorto at gmail.com>
wrote:

> Bear in mind that unix didn't even have fsck for a decade after its
> release (it appeared after v7 released),


​That is actually not wholly true - although in practice you are probably
right.   The late Ted Kowalski starting writing fsck as an undergrad at
Michigan in about 1976 and then finished it up as a grad student at CMU in
1977 with a summer of work in between at BTL [if I have the dates right --
Armando I think you OYOC at the same time as Ted - is that about right].


BTW:  fsck was the program Ted introduced me to C, as I was BLISS hacker
before that. Anyway, all of that was done on 6th edition not 7th.   Fsck
was first released as part of Unix TS inside the labs and migrated
independently of any base distribution - although it was included as part
of BSD.   Ted has been Bill Joy's roommate at Michigan and I never knew how
UCB got it, but I'm guessing it was that connection because it was already
at UCB by the time I arrived.  I never knew for sure, but I think from a
legal standpoint it was assumed a CMU program, so BTL could not make claims
on it - since you right it was not part of V7 either.

Also, for those of you that never saw Unix before fsck or before the work
that Goble did at Purdue to get the write ordering down, you have no idea
what it was like to put a file system back together.   The sync;sync;sync
stuff was because of the lack write ordering; but even with that, small
file system corruptions where common.  fsck was a huge improvement.

Also in an earlier thread people we asking about small address space. One
of the issues Ted had to deal with early in the life of fsck was that the
size of a file system on something like the  RP06 was too large for the
data structures (just think the RP06 had a formatted capacity of less than
200 Mbytes and we partitioned them into smaller file systems).  So, some of
you will remember. that when fsck started up, it asked for a temp file
[which could be tricky if you were trying to fix the root file system].
In fact, one of the things I worked on was the code that allowed us the
deal with the temp file so we could swap those large structures in and out
memory and still work on and 11/40 without I/D space. If you look at the
early fsck code on Warren's site, I suspect you can find it - crude as it
may be -- it worked pretty well.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150106/51eddbf0/attachment.html>

[TUHS] pre-FSCK days

[Ronald Natalie]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 785 bytes --]

Yep I remember those days.    In order to get signed on to work in the UNIX computer center I had to demonstrate I knew the structure of the V6 filesystem and what icheck and dcheck reported, what the common errors were, and how to fix them.

Two things changed.   First FSCK was wriiten, but even to make that useful, some fixes were done to the ordering of operations in the kernel so that the file system wouldn’t be left in a degenerate state after crashes.    Before these changes were made inode link counts less than the number of directory links and dups in free were common.   After the changes to the FS, you’d get missing blocks and a few 0-0 inodes (or ones where the links count was higher than the links).    These while wasteful were not going to cause problems.

[TUHS] Illumos )

[Dave Horsfall]

On Tue, 6 Jan 2015, Clem Cole wrote:

> Also, for those of you that never saw Unix before fsck or before the 
> work that Goble did at Purdue to get the write ordering down, you have 
> no idea what it was like to put a file system back together.

Somewhere, deep in Minnie's bowels, is the article I wrote, explaining 
exactly how to use icheck/ncheck/dcheck/clri etc.  I'm told it's saved the 
bacon of quite a few people (assuming it was savable at all).

> The sync;sync;sync stuff was because of the lack write ordering; but 
> even with that, small file system corruptions where common.

It was drilled into us that the correct usage was:

# sync
# sync
# sync

This gives the disk buffers time to actually flush (the writes were merely 
scheduled, and were asynchronous).

-- 
Dave Horsfall DTM (VK2KFU)  "Bliss is a MacBook with a FreeBSD server."
http://www.horsfall.org/spam.html (and check the home page whilst you're there)

[TUHS] Illumos )

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 544 bytes --]

On Tue, Jan 6, 2015 at 8:53 PM, Dave Horsfall <dave at horsfall.org> wrote:

> Somewhere, deep in Minnie's bowels, is the article I wrote, explaining
> exactly how to use icheck/ncheck/dcheck/clri etc.
>

​Shows I am old - it would fun to read that again.  I never saw the
article, I learned from doing it (wrong probably) a few times ;-)
Then Ted gives us fsck  . . .

Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150107/35139e59/attachment.html>

[TUHS] Illumos )

[scj]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1828 bytes --]

My memories are somewhat fuzzy on this issue, but I vividly remember the
file corruptions.  The earliest Unix systems had a file format that
limited the size of a file to a size that proved to be too small.  So Ken
put in a "large file" format as well.  All files started out as small, but
as they grew they had to be rejiggered to become large files.  If the
system crashed while this rejiggering was going on, the file was toast.

The saving grace was that most of us were using model 33 or 37 teletypes,
so we had our edit history on paper.  When the system crashed, I picked up
a highlighter I kept next to the terminal, reeled in the paper that had
piled up behind the terminal, and highlighted the lines that would need to
be entered again.

One memorable day, I was working at home and the system crashed right
before lunch.  It was several hours before I could get back to the
terminal, and I discovered to my horror that our cat had mistaken the pile
of paper behind the terminal for her litter box.  Yes, I really did pick
up a highlighter and followed the usual plan, but I had to get another
color since the yellow didn't show up very well...

A later revision of the file system eliminated the small/large file
distinction, and disc corruptions became a rare event...

> On Tue, Jan 6, 2015 at 8:53 PM, Dave Horsfall <dave at horsfall.org> wrote:
>
>> Somewhere, deep in Minnie's bowels, is the article I wrote, explaining
>> exactly how to use icheck/ncheck/dcheck/clri etc.
>>
>
> ​Shows I am old - it would fun to read that again.  I never saw the
> article, I learned from doing it (wrong probably) a few times ;-)
> Then Ted gives us fsck  . . .
>
> Clem
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>

[TUHS] sync; sync; sync; halt (was: Re: Illumos ))

[Tom Ivar Helbekkmo]

Dave Horsfall <dave at horsfall.org> writes:

> It was drilled into us that the correct usage was:
>
> # sync
> # sync
> # sync
>
> This gives the disk buffers time to actually flush (the writes were merely 
> scheduled, and were asynchronous).

There is another reason why multiple syncs before halting the system
were needed.  There was no fancy I/O order juggling, so everything was
written in the same chronological order as it was scheduled.  If you
look at 6th edition source code, you'll find that a call to sync would
invoke the internal routine update(), which does three things in order:

1: schedule writes of superblocks, and wait for them to complete
2: update in-memory inode time stamps wherever needed
3: schedule writes of inodes and data blocks that are now dirty

What this means is that the second sync, by waiting for its own
superblock writes, will wait until all the inode and file data flushes
scheduled by the first one have completed.

What I haven't been able to figure out from a few minutes studying the
code, is whether the third sync is really needed, or just a "belt and
suspenders" thing.  I've heard it claimed that the flushing of inodes
and/or file data going on while the second sync is waiting for its
already scheduled superblock writes to complete will cause the third one
to be needed.  That would mean either that flushing dirty file blocks
could cause inode updates, or that flushing inodes could cause
superblock updates.  Anyone know the internals well enough to say?

-tih
-- 
Popularity is the hallmark of mediocrity.  --Niles Crane, "Frasier"

[TUHS] sync; sync; sync; halt (was: Re: Illumos ))

[random832]

On Fri, Jan 16, 2015, at 03:40, Tom Ivar Helbekkmo wrote:
> What this means is that the second sync, by waiting for its own
> superblock writes, will wait until all the inode and file data flushes
> scheduled by the first one have completed.

Everything I've read indicates that nothing in the sync call actually
waits on anything, and that it's actually just the time taken to type
the second and third command on a 110 baud terminal gives the first one
time to finish executing.

[TUHS] sync; sync; sync; halt (was: Re: Illumos ))

[Brantley Coile]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1208 bytes --]

Sixth Edition and 7th Edition are different.  Looking at the code, 6th Edition waits on the updates, but 7th Edition delays the writes(bdwrite()) and then calls bflush() when all finished.  The three sync’s were indeed to give the disk driver time to do all the IO sitting on the queue.  The HP driver used disksort() so those blocks wouldn’t necessarily be written in the order they were touched.

We used to use one sync and just watch the disk’s activity light.

Brantley
South Suite Software

On Jan 16, 2015, at 8:39 AM, random832 at fastmail.us wrote:

> On Fri, Jan 16, 2015, at 03:40, Tom Ivar Helbekkmo wrote:
>> What this means is that the second sync, by waiting for its own
>> superblock writes, will wait until all the inode and file data flushes
>> scheduled by the first one have completed.
> 
> Everything I've read indicates that nothing in the sync call actually
> waits on anything, and that it's actually just the time taken to type
> the second and third command on a 110 baud terminal gives the first one
> time to finish executing.
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs

[TUHS] Illumos )

[arnold]

Hi Larry.

Illumos is at least one continuation of Open Solaris after Oracle pulled
the plug on it. There are others.  It looks to me like an aim is to
fill the Enterprise OS slot.  I think many now-former Sun / Solaris kernel
guys are working on it.

I have not messed with it myself, I'm pretty happy running Linux
these days, but if you want the Enterprise features there (zFS, zones,
whatever else), it's probably worth looking into.

That's about all I know - people with more experience with it should
chime in. :-)

Arnold

Larry McVoy <lm at mcvoy.com> wrote:

> Yo Jacob,
>
> I'm ex-sun but I don't know too much about Illumos.   Care to give us 
> the summary of why I might care about it?
>
> On Wed, Dec 31, 2014 at 01:16:00AM -0500, Jacob Ritorto wrote:
> > Hey, thanks, Derrik.
> >   I don't mess with Linux much (kind of an Illumos junkie by trade ;), but
> > I bet gcc would.  I did out of curiosity do it with the Macintosh cc (Apple
> > LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)) and it throws
> > warnings about our not type-defining functions because you're apparently
> > supposed to do this explicitly these days, but it dutifully goes on to
> > assume int and compiles our test K&R stuff mostly fine.  It does
> > unfortunately balk pretty badly at the naked returns we initially had,
> > though.  Wish it didn't because it strikes me as being beautifully simple..
> > 
> > thx again for the encouragement!
> > jake
> > 
> > 
> > On Wed, Dec 31, 2014 at 1:02 AM, Derrik Walker v2.0 <dwalker at doomd.net>
> > wrote:
> > 
> > > On Wed, 2014-12-31 at 00:44 -0500, Jacob Ritorto wrote:
> > >
> > > >
> > > > P.S. if anyone's bored enough, you can check out what we're up to at
> > > > https://github.com/srphtygr/dhb.  I'm trying to get my 11yo kid to
> > > > spend a little time programming rather than just playing video games
> > > > when he's near a computer.  He'a actually getting through this stuff
> > > > and is honestly interested when he understands it and sees it work --
> > > > and he even spotted a bug before me this afternoon!  Feel free to
> > > > raise issues, pull requests, etc. if you like -- I'm putting him
> > > > through the git committing and pair programming paces, so outside
> > > > interaction would be kinda fun :)
> > > >
> > > >
> > > > P.P.S.  We're actually using 2.11bsd after all..
> > > >
> > > I'm curious, will gcc on a modern Linux system compile K&R c?
> > >
> > > Maybe when I get a little time, I might try to see if I can compile it
> > > on a modern Fedora 21 system with gcc.
> > >
> > > BTW: Great job introducing him to such a classic environment. A few
> > > years ago, my now 18 year old had expressed some interest in graphics
> > > programming and was in awe over an SGI O2 I had at the time, so I got
> > > him an Indy.  He played around with a bit of programming, but
> > > unfortunately, he lost interest.
> > >
> > > - Derrik
> > >
> > >
> > > _______________________________________________
> > > TUHS mailing list
> > > TUHS at minnie.tuhs.org
> > > https://minnie.tuhs.org/mailman/listinfo/tuhs
> > >
>
> > _______________________________________________
> > TUHS mailing list
> > TUHS at minnie.tuhs.org
> > https://minnie.tuhs.org/mailman/listinfo/tuhs
>
>
> -- 
> ---
> Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs

[TUHS] sync; sync; sync; halt (was: Re: Illumos ))

[Noel Chiappa]

    > From: Tom Ivar Helbekkmo

    > There was no fancy I/O order juggling, so everything was written in the
    > same chronological order as it was scheduled.
    > ...
    > What this means is that the second sync, by waiting for its own
    > superblock writes, will wait until all the inode and file data flushes
    > scheduled by the first one have completed.

Ah, I'm not sure this is correct. Not all disk drivers handled requests in a
'first-come, first-served' order (i.e. where a request for block X, which was
scheduled before a request for block Y, actually happened before the
operation on block Y). It all depends on the particular driver; some drivers
(e.g. the RP driver) re-organized the waiting request queue to optimize head
motion, using a so-called 'elevator algorithm'.

(PS: For a good time, do "dd if=/dev/[large_partition] of=/dev/null" on a
running system with such a disk, and a lot of users on - the system will
apparently come to a screeching halt while the 'up' pass on the disk
completes... I found this out the hard way, needless to say! :-)

Since the root block is block 1 in the partition, one might think that even
with an elevator algorithm, this would tend to guarantee that doing it would
more or less guarantee that all other pending operations would have completed
(since it could only happen at the end of 'down' pass); _but_ the elevator
algorithm is in terms of actual physical block numbers, so blocks in another
lower partition might still remain to be written.

But now that I think about it a bit, if such blocks existed, that partition's
super-block would also need to be written, so when that one completed, the
disk queue would be empty.

But the point remains - because there's no guarantee of _overall_ disk
operation ordering in V6, scheduling a disk request and waiting for it to
complete does not guarantee that all previously-requested disk operations
will have completed before it does.


I really think the whole triple-sync thing is mythology. Look through the V6
documentation and although IIRC there are instructions on how to shut the
system down, it's not mentioned. We certainly never used it at MIT (and I
still don't), and I've never seen a problem with disk corruption _when the
system was deliberately shut down_.

	Noel