* [TUHS] Illumos ) @ 2014-12-31 6:22 Larry McVoy 2014-12-31 9:28 ` Wesley Parish 2014-12-31 9:46 ` [TUHS] Illumos ) arnold 0 siblings, 2 replies; 26+ messages in thread From: Larry McVoy @ 2014-12-31 6:22 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* [TUHS] Illumos ) 2014-12-31 6:22 [TUHS] Illumos ) Larry McVoy @ 2014-12-31 9:28 ` Wesley Parish 2014-12-31 13:13 ` John Cowan 2014-12-31 9:46 ` [TUHS] Illumos ) arnold 1 sibling, 1 reply; 26+ messages in thread From: Wesley Parish @ 2014-12-31 9:28 UTC (permalink / raw) 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 > ^ permalink raw reply [flat|nested] 26+ messages in thread
* [TUHS] Illumos ) 2014-12-31 9:28 ` Wesley Parish @ 2014-12-31 13:13 ` John Cowan 2014-12-31 17:42 ` Diomidis Spinellis 0 siblings, 1 reply; 26+ messages in thread From: John Cowan @ 2014-12-31 13:13 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* [TUHS] Illumos ) 2014-12-31 13:13 ` John Cowan @ 2014-12-31 17:42 ` Diomidis Spinellis 2014-12-31 20:32 ` Clem Cole 0 siblings, 1 reply; 26+ messages in thread From: Diomidis Spinellis @ 2014-12-31 17:42 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* [TUHS] Illumos ) 2014-12-31 17:42 ` Diomidis Spinellis @ 2014-12-31 20:32 ` Clem Cole 2014-12-31 20:36 ` Larry McVoy 0 siblings, 1 reply; 26+ messages in thread From: Clem Cole @ 2014-12-31 20:32 UTC (permalink / raw) [-- 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> ^ permalink raw reply [flat|nested] 26+ messages in thread
* [TUHS] Illumos ) 2014-12-31 20:32 ` Clem Cole @ 2014-12-31 20:36 ` Larry McVoy 2014-12-31 22:19 ` Jacob Ritorto 0 siblings, 1 reply; 26+ messages in thread From: Larry McVoy @ 2014-12-31 20:36 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* [TUHS] Illumos ) 2014-12-31 20:36 ` Larry McVoy @ 2014-12-31 22:19 ` Jacob Ritorto 2014-12-31 22:42 ` Larry McVoy 0 siblings, 1 reply; 26+ messages in thread From: Jacob Ritorto @ 2014-12-31 22:19 UTC (permalink / raw) 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> ^ permalink raw reply [flat|nested] 26+ messages in thread
* [TUHS] Illumos ) 2014-12-31 22:19 ` Jacob Ritorto @ 2014-12-31 22:42 ` Larry McVoy 2014-12-31 22:50 ` Larry McVoy 2015-01-05 12:02 ` Tim Bradshaw 0 siblings, 2 replies; 26+ messages in thread From: Larry McVoy @ 2014-12-31 22:42 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* [TUHS] Illumos ) 2014-12-31 22:42 ` Larry McVoy @ 2014-12-31 22:50 ` Larry McVoy 2015-01-01 1:17 ` Larry McVoy 2015-01-05 12:02 ` Tim Bradshaw 1 sibling, 1 reply; 26+ messages in thread From: Larry McVoy @ 2014-12-31 22:50 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* [TUHS] Illumos ) 2014-12-31 22:50 ` Larry McVoy @ 2015-01-01 1:17 ` Larry McVoy 2015-01-01 1:34 ` Erik E. Fair 0 siblings, 1 reply; 26+ messages in thread From: Larry McVoy @ 2015-01-01 1:17 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* [TUHS] Illumos ) 2015-01-01 1:17 ` Larry McVoy @ 2015-01-01 1:34 ` Erik E. Fair 0 siblings, 0 replies; 26+ messages in thread From: Erik E. Fair @ 2015-01-01 1:34 UTC (permalink / raw) > 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> ^ permalink raw reply [flat|nested] 26+ messages in thread
* [TUHS] Illumos ) 2014-12-31 22:42 ` Larry McVoy 2014-12-31 22:50 ` Larry McVoy @ 2015-01-05 12:02 ` Tim Bradshaw 2015-01-05 17:04 ` Jacob Ritorto 1 sibling, 1 reply; 26+ messages in thread From: Tim Bradshaw @ 2015-01-05 12:02 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* [TUHS] Illumos ) 2015-01-05 12:02 ` Tim Bradshaw @ 2015-01-05 17:04 ` Jacob Ritorto 2015-01-06 4:54 ` Andy Kosela ` (2 more replies) 0 siblings, 3 replies; 26+ messages in thread From: Jacob Ritorto @ 2015-01-05 17:04 UTC (permalink / raw) 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> ^ permalink raw reply [flat|nested] 26+ messages in thread
* [TUHS] Illumos ) 2015-01-05 17:04 ` Jacob Ritorto @ 2015-01-06 4:54 ` Andy Kosela 2015-01-06 11:10 ` Kurt H Maier 2015-01-06 15:37 ` Tim Bradshaw 2015-01-06 21:58 ` Clem Cole 2 siblings, 1 reply; 26+ messages in thread From: Andy Kosela @ 2015-01-06 4:54 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* [TUHS] Illumos ) 2015-01-06 4:54 ` Andy Kosela @ 2015-01-06 11:10 ` Kurt H Maier 0 siblings, 0 replies; 26+ messages in thread From: Kurt H Maier @ 2015-01-06 11:10 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* [TUHS] Illumos ) 2015-01-05 17:04 ` Jacob Ritorto 2015-01-06 4:54 ` Andy Kosela @ 2015-01-06 15:37 ` Tim Bradshaw 2015-01-09 9:23 ` Jose R. Valverde 2015-01-06 21:58 ` Clem Cole 2 siblings, 1 reply; 26+ messages in thread From: Tim Bradshaw @ 2015-01-06 15:37 UTC (permalink / raw) 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> ^ permalink raw reply [flat|nested] 26+ messages in thread
* [TUHS] Illumos ) 2015-01-06 15:37 ` Tim Bradshaw @ 2015-01-09 9:23 ` Jose R. Valverde 0 siblings, 0 replies; 26+ messages in thread From: Jose R. Valverde @ 2015-01-09 9:23 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* [TUHS] Illumos ) 2015-01-05 17:04 ` Jacob Ritorto 2015-01-06 4:54 ` Andy Kosela 2015-01-06 15:37 ` Tim Bradshaw @ 2015-01-06 21:58 ` Clem Cole 2015-01-06 22:02 ` [TUHS] pre-FSCK days Ronald Natalie 2015-01-07 1:53 ` [TUHS] Illumos ) Dave Horsfall 2 siblings, 2 replies; 26+ messages in thread From: Clem Cole @ 2015-01-06 21:58 UTC (permalink / raw) [-- 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> ^ permalink raw reply [flat|nested] 26+ messages in thread
* [TUHS] pre-FSCK days 2015-01-06 21:58 ` Clem Cole @ 2015-01-06 22:02 ` Ronald Natalie 2015-01-07 1:53 ` [TUHS] Illumos ) Dave Horsfall 1 sibling, 0 replies; 26+ messages in thread From: Ronald Natalie @ 2015-01-06 22:02 UTC (permalink / raw) [-- 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* [TUHS] Illumos ) 2015-01-06 21:58 ` Clem Cole 2015-01-06 22:02 ` [TUHS] pre-FSCK days Ronald Natalie @ 2015-01-07 1:53 ` Dave Horsfall 2015-01-07 16:26 ` Clem Cole 2015-01-16 8:40 ` [TUHS] sync; sync; sync; halt (was: Re: Illumos )) Tom Ivar Helbekkmo 1 sibling, 2 replies; 26+ messages in thread From: Dave Horsfall @ 2015-01-07 1:53 UTC (permalink / raw) 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) ^ permalink raw reply [flat|nested] 26+ messages in thread
* [TUHS] Illumos ) 2015-01-07 1:53 ` [TUHS] Illumos ) Dave Horsfall @ 2015-01-07 16:26 ` Clem Cole 2015-01-07 18:32 ` scj 2015-01-16 8:40 ` [TUHS] sync; sync; sync; halt (was: Re: Illumos )) Tom Ivar Helbekkmo 1 sibling, 1 reply; 26+ messages in thread From: Clem Cole @ 2015-01-07 16:26 UTC (permalink / raw) [-- 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> ^ permalink raw reply [flat|nested] 26+ messages in thread
* [TUHS] Illumos ) 2015-01-07 16:26 ` Clem Cole @ 2015-01-07 18:32 ` scj 0 siblings, 0 replies; 26+ messages in thread From: scj @ 2015-01-07 18:32 UTC (permalink / raw) [-- 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 > ^ permalink raw reply [flat|nested] 26+ messages in thread
* [TUHS] sync; sync; sync; halt (was: Re: Illumos )) 2015-01-07 1:53 ` [TUHS] Illumos ) Dave Horsfall 2015-01-07 16:26 ` Clem Cole @ 2015-01-16 8:40 ` Tom Ivar Helbekkmo 2015-01-16 13:39 ` random832 1 sibling, 1 reply; 26+ messages in thread From: Tom Ivar Helbekkmo @ 2015-01-16 8:40 UTC (permalink / raw) 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" ^ permalink raw reply [flat|nested] 26+ messages in thread
* [TUHS] sync; sync; sync; halt (was: Re: Illumos )) 2015-01-16 8:40 ` [TUHS] sync; sync; sync; halt (was: Re: Illumos )) Tom Ivar Helbekkmo @ 2015-01-16 13:39 ` random832 2015-01-16 14:14 ` Brantley Coile 0 siblings, 1 reply; 26+ messages in thread From: random832 @ 2015-01-16 13:39 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* [TUHS] sync; sync; sync; halt (was: Re: Illumos )) 2015-01-16 13:39 ` random832 @ 2015-01-16 14:14 ` Brantley Coile 0 siblings, 0 replies; 26+ messages in thread From: Brantley Coile @ 2015-01-16 14:14 UTC (permalink / raw) [-- 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* [TUHS] Illumos ) 2014-12-31 6:22 [TUHS] Illumos ) Larry McVoy 2014-12-31 9:28 ` Wesley Parish @ 2014-12-31 9:46 ` arnold 1 sibling, 0 replies; 26+ messages in thread From: arnold @ 2014-12-31 9:46 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2015-01-16 14:14 UTC | newest] Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-12-31 6:22 [TUHS] Illumos ) Larry McVoy 2014-12-31 9:28 ` Wesley Parish 2014-12-31 13:13 ` John Cowan 2014-12-31 17:42 ` Diomidis Spinellis 2014-12-31 20:32 ` Clem Cole 2014-12-31 20:36 ` Larry McVoy 2014-12-31 22:19 ` Jacob Ritorto 2014-12-31 22:42 ` Larry McVoy 2014-12-31 22:50 ` Larry McVoy 2015-01-01 1:17 ` Larry McVoy 2015-01-01 1:34 ` Erik E. Fair 2015-01-05 12:02 ` Tim Bradshaw 2015-01-05 17:04 ` Jacob Ritorto 2015-01-06 4:54 ` Andy Kosela 2015-01-06 11:10 ` Kurt H Maier 2015-01-06 15:37 ` Tim Bradshaw 2015-01-09 9:23 ` Jose R. Valverde 2015-01-06 21:58 ` Clem Cole 2015-01-06 22:02 ` [TUHS] pre-FSCK days Ronald Natalie 2015-01-07 1:53 ` [TUHS] Illumos ) Dave Horsfall 2015-01-07 16:26 ` Clem Cole 2015-01-07 18:32 ` scj 2015-01-16 8:40 ` [TUHS] sync; sync; sync; halt (was: Re: Illumos )) Tom Ivar Helbekkmo 2015-01-16 13:39 ` random832 2015-01-16 14:14 ` Brantley Coile 2014-12-31 9:46 ` [TUHS] Illumos ) arnold
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).