Wesley Parish scripsit: 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(a)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

On Wed, Dec 31, 2014 at 12:42 PM, Diomidis Spinellis <dds(a)aueb.gr> wrote: ​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. ​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​

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(a)mcvoy.com> wrote:

On Wed, Dec 31, 2014 at 02:42:49PM -0800, Larry McVoy wrote: 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.

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(a)netbsd.org>

On Mon, Jan 5, 2015 at 7:02 AM, Tim Bradshaw <tfb(a)tfeb.org> wrote: 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. 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. There is (was in ~2010) *no way to check a zpool outside the kernel*, so if 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.

Quoting Andy Kosela <akosela(a)andykosela.com>: Vendor lock-in is not going to save Oracle Solaris, in exactly the same way DB2 did not save AIX. khm

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

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.

On Tue, Jan 6, 2015 at 8:53 PM, Dave Horsfall <dave(a)horsfall.org> wrote: ​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

Dave Horsfall <dave(a)horsfall.org> writes: 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"

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(a)fastmail.us wrote: