3 ms·

I'm a bit confused about your last sentence. Are you saying that the dev OSes will cause more outages, but we can automated that they won't be major? The firs

I'm a bit confused about your last sentence. Are you saying that the dev OSes will cause more outages, but we can automated that they won't be major? The first thought that popped into my head while reading this article was how ZFS snapshots would work for versioning system deployments. Though I'm sure that's snapshots at a lower level than most people would actually use.

strlen 17y ago
> I'm a bit confused about your last sentence. Are you saying that the dev OSes will cause more outages, but we can automated that they won't be major? I am saying that the "dev OSes" (really, I just meant Linux), if not automated, are difficult to manage. However, in a "worse is better" sense that means there's wealth of operations tools available for them (e.g., puppet, chef, bcfg2). Linux administrators are extremely used to working with these tools and developing their own. At present web-scale (i.e., no longer a few Ultra-2s for front-end and an E10K for database) if there's no automation, outages are going to happen as result of routine failures (e.g., database master -- or Hadoop namenode -- goes down, there's no automation to fail it over). ZFS snapshots are awesome (I've had a chance to deploy a project to a Solaris environment with ZFS -- and snapshots meant much less worries about data loss). Unfortunately, the only choices for ZFS are FreeBSD and Solaris (I wouldn't try ZFS-Fuse). However, FreeBSD provides no easy way to do many things automatically that are possible in Linux (e.g., no fully un-attended installation, although that's less of a problem with virtualization). Solaris has issues of its own and unfortunately, presently, the biggest issue isn't even technical.