David, Thanks for the thoughts. I have both general and specific comments.
When I built systems under ATT SVR3, SVR4, Solaris Zones, and Solaris > LDoms, I was always concerned about rules for scalability & self > configuration. > > There is so much effort around Orchestration today, adding intelligence to > central points, and not enough around intelligent systems which self > configure. > Quite. What worries me is that configuration management is now so concerned with systems being configured 100% perfectly that systems are no longer robust enough to be able to continue if things aren't quite right. They've become increasingly fragile as a result. > When Sun was talking about clustered filesystems merging with ZFS - I > thought this could have been revolutionary. Plug in a new box, have it join > the pool of redundant resources. Pull out a box, no loss of functionality. > The metadata servers are a point of failure, but that was acceptable 10 > years ago. > > Orchestration is too complex. Self configuration & communication beyond > point-to-point is where there is space for innovation. > So things like bonjour. Or even revisit the likes of Jxta and Jini. > Think about our past: > - Right thinking was unloading a disk less workstation off the dock & > placing a MAC address in a boot server to make a desktop work. > And servers. Take the little yellow slip off a Sun server, set up jumpstart, and your compute farm is good to go. Many of my Sun servers *never* had a serial console plugged in. You can largely do that now, still. > - Right thinking was taking a Sun Ray out of the closet and plugging it in > to make a workable desktop. > The whole SunRay area is another one lost completely. There are still people who do some sort of zero-admin desktop experience, but there's clearly room to improve. > - Right thinking was the example of loading Solaris 10 with dual identical > drives with zfs root - it knows mirroring with boot block replication was > the right thing to do. > - Right thinking was commands like "ruptime" - where the health of the > network was readily known so people & apps could automatically decide where > to put load. Worked out of the box. > Sort of. Clearly of its time. The whole idea was broken, but worked well enough for some purposes that people didn't worry too much. The protocol is broadcast, exposes a limited set of statistics of dubious utility, and has no knowledge of sensible workload placement. I used to use that sort of thing back in the 1980s, but it's essentially useless today. Thinking sideways, where are the tools like Grid Engine and NQS? Are they interesting, or does everyone think that Mesos or K8S is the way to schedule workloads across a distributed system? > - Right thinking was network capable "talk" commands, where users could > talk to users everywhere, transparently in the network. Worked out of the > box. > - Right thinking was "finger", where people understood presence of > individuals, and could communicate freely, transparently in the network. > Worked out of the box. > Never worked sanely on a distributed system, where users might be in multiple locations. > - Right thinking was "X", where application servers were decoupled from > display servers... where a single multithreaded application easily attached > to multiple users on a network and served up app displays while > communicating over simple in-memory constructs. (Games like xtank & xbattle > demonstrated how easy realtime multiuser collaboration with multiple > displays & a single running image was with less than a floppy worth of > binaries.) > While the trend might be towards distributed *computation*, the trend is towards centralized *interfaces* to that work. > - Right thinking was network capable store-and-forward mail built into the > box with relatively simple ability to mail to other boxes over a network. > Worked out of the box. Still used. > - Right thinking was queuing via "lp" to printers over a network with > adapters to push to/from anything. (People buy very complex publish & > subscribe systems today, but it is the same concept.) > - Right thinking was Threaded "NNTP" readers, to subscribe and push > content to the desktop... content could go anywhere. RSS grew from > Microsoft axing this protocol with IE. (This need will not go away - think: > orbit, moon, mars, asteroid belt, etc.) > - Right thinking was bundling NFS & automounting. Just plug in & access > it, if you know the path. > - Right thinking was ubiquitous http and web browsers with search > engines... which we had long before that with anonymous ftp sites and query > hosts. > > If I had 1 hour in a room with Illumos developers - I would appeal > innovation should ONLY be around 1:m protocols on networks for self > configuration... without central orchestration, without TCP, without > reinventing protocols, without central directories, with dynamic > distributed & replicated directories. > You need a single source of truth, but I would agree that it should be a distributed implementation. I've been wondering about things like using AWS metadata to autoconfigure Amazon instances as a specific example of this class of asking the environment around you to decide what to do next. > Data replication of critical data (to many nodes), metadata replication > (all OS configuration), read-only OS snapshots, no dependency on ZFS only > (revive UFS with snapshots for limited use cases, other future open source > FS's), > Tribblix supports UFS root. It's fine if you're resource constrained, but has serious limitation as other parts of the OS make assumptions about the root filesystem. > self-replication of packages across a cluster (like pkgadd on a global > zone to guest zones), cheap flash for volatile local data with ability to > check & lock out bad spots (instead of crash & burn with junk USB sticks > today), self load balance everything, run apps anywhere & display anywhere > (X revival), run on a SPARC or Intel or Raspberry Pi (roadmap of past to > present to future... or scalability from massive to medium to small if you > prefer.) > Distributed seems to be a theme. Along with autonomous behaviour. > Honestly, everything exists, just tweaking is needed with combining things > into core bundles, and then tweak a few things. Connect everything by > network. Scale is not Google, it is the depths of the ocean, our Solar > System (tcp is insufficient.) Think: Robotics. Apply: Farming with planting > & weeding & harvesting, ad-hoc drone WiFi networks in natural disasters, > pollinating bee barren fields in china. Imagine: Ender's Game. > > We've lived in a decade of little innovation. We know where to go. It is > not hard. We base too much work on high level frameworks & languages with > lots of bugs & significant dependencies... while lower level, well known, > well debugged, well defined protocols should be the preference. With the > end of heterogeneous computing, it is now time to end central orchestration > & central directories, do it anywhere & everywhere, and allow others to > join us for the fun. Illumos can be this. > > Thanks, David Halko > http://www.netmgt.blogspot.com/ > > Sent from my iPhone > > On Sep 13, 2017, at 4:01 PM, Peter Tribble <[email protected]> > wrote: > > In my OpenSolaris t-shirt collection, I have one with the slogan: > > "Innovation happens everywhere" > > I'm not sure this is *entirely* true; Solaris 10 was a massive nexus > of innovation that has proliferated out to other operating systems > over the last decade. Frankly, there's not much else been happening > in systems development. > > From what I can see, between the cloying boredom of Linux monoculture > and the dead hand of POSIX "standardisation", systems have stagnated. > > Even in illumos, we're largely doing a bit of light gardening - a bit > of weeding here, a bit of pruning there, replanting the odd bush. But > no real landscaping is being done. > > Which begs the question - is systems innovation done and dusted? > > Or is there more to come? > > And if there is more, what sort of new features are wanted? > > At which point I open up the floor to anyone who wants to contribute. > > (Note: I'm not talking about a gaps analysis. We [illumos] need more > drivers, more applications ported. We already know that, and it's just > copying, not innovation. So there is an interesting subject there, but > if someone wants to follow that then please create a new thread.) > > Cheers, > > -- > -Peter Tribble > http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ > > *illumos-discuss* | Archives > <https://illumos.topicbox.com/groups/discuss/discussions/T784fc87098d66577-Me687aea232d0d7aa3626d301> > | Powered by Topicbox <https://topicbox.com> -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ ------------------------------------------ illumos-discuss Archives: https://illumos.topicbox.com/groups/discuss/discussions/T784fc87098d66577-Mf1050b2e05dad499cf954c38 Powered by Topicbox: https://topicbox.com
