<?xml version="1.0" encoding="utf-8" standalone="yes" ?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Systems Administration on tychoish</title>
    <link>https://tychoish.com/tags/systems-administration/</link>
    <description>Recent content in Systems Administration on tychoish</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-us</language>
    <lastBuildDate>Thu, 08 Mar 2012 00:00:00 +0000</lastBuildDate>
    
	<atom:link href="https://tychoish.com/tags/systems-administration/index.xml" rel="self" type="application/rss+xml" />
    
    
    <item>
      <title>Cron is the Wrong Solution</title>
      <link>https://tychoish.com/post/cron-is-the-wrong-solution/</link>
      <pubDate>Thu, 08 Mar 2012 00:00:00 +0000</pubDate>
      
      <guid>https://tychoish.com/post/cron-is-the-wrong-solution/</guid>
      <description>Cron is great, right? For the uninitiated, if there are any of you left, Cron is a task scheduler that makes it possible to run various scripts and programs at specified intervals. This means that you can write programs that &amp;quot;do a thing&amp;quot; in a stateless way, set them to run regularly, without having to consider any logic regarding when to run, or any kind of state tracking. Cron is simple and the right way to do a great deal of routine automation, but there are caveats.</description>
    </item>
    
    <item>
      <title>Allowable Complexity</title>
      <link>https://tychoish.com/post/allowable-complexity/</link>
      <pubDate>Fri, 03 Feb 2012 00:00:00 +0000</pubDate>
      
      <guid>https://tychoish.com/post/allowable-complexity/</guid>
      <description>I&#39;m not sure I&#39;d fully realized it before, but the key problems in systems administration--at least the kind that I interact with the most--are really manifestations of a tension between complexity and reliability.
Complex systems are often more capable flexible, so goes the theory. At the same time, complexity often leads to operational failure, as a larger number of moving parts leads to more potential points of failure. I think it&#39;s an age old engineering problem and I doubt that there are good practical answers.</description>
    </item>
    
    <item>
      <title>The Overhead of Management</title>
      <link>https://tychoish.com/post/the-overhead-of-management/</link>
      <pubDate>Thu, 01 Jul 2010 00:00:00 +0000</pubDate>
      
      <guid>https://tychoish.com/post/the-overhead-of-management/</guid>
      <description>Every resource, every person, every project, every machine you have to manage comes with an ongoing cost. This is just as true of servers as is it is of people who work on projects that you&#39;re in charge of or have some responsibility for, and while servers and teammates present very different kinds of management challenges, working effectively and managing management costs across contexts is (I would propose) similar. Or at least similar enough to merit some synthetic discussion.</description>
    </item>
    
    <item>
      <title>technology as infrastructure, act three</title>
      <link>https://tychoish.com/post/technology-as-infrastructure-act-three/</link>
      <pubDate>Mon, 20 Jul 2009 00:00:00 +0000</pubDate>
      
      <guid>https://tychoish.com/post/technology-as-infrastructure-act-three/</guid>
      <description>Continued from, Technology as Infrastructure, Act Two.
Act Three All my discussions of &amp;quot;technology as infrastructure&amp;quot; thus far have been fairly high level. Discussions of particular business strategies of major players (eg. google and amazon), discussions approaches to &amp;quot;the cloud,&amp;quot; and so forth. As is my way, however, I&#39;ve noticed that the obvious missing piece of this puzzle is how users--like you and me--are going to use the cloud. How thinking about technology as infrastructure changes the way we interact with our technology, and other related issues.</description>
    </item>
    
    <item>
      <title>technology as infrastructure, act two</title>
      <link>https://tychoish.com/post/technology-as-infrastructure-act-two/</link>
      <pubDate>Fri, 17 Jul 2009 00:00:00 +0000</pubDate>
      
      <guid>https://tychoish.com/post/technology-as-infrastructure-act-two/</guid>
      <description>Continued from, Technology as Infrastructure, Act One.
Act Two Cnet&#39;s Matt Assay covering this post by RedMonk&#39;s Stephen O&#39;Grady suggests that an &amp;quot;open source cloud&amp;quot; is unlikely because superstructure (hardware/concrete power) matters more than infrastructure (software)--though in IT &amp;quot;infrastructure&amp;quot; means something different, so go read Stephen&#39;s article.
It&#39;s my understanding that, in a manner of speaking, open source has already &amp;quot;won&amp;quot; this game. Though google&#39;s code is proprietary, it runs on a Linux/java-script/python platform.</description>
    </item>
    
    <item>
      <title>technology as infrastructure, act one</title>
      <link>https://tychoish.com/post/technology-as-infrastructure-act-one/</link>
      <pubDate>Thu, 16 Jul 2009 00:00:00 +0000</pubDate>
      
      <guid>https://tychoish.com/post/technology-as-infrastructure-act-one/</guid>
      <description>Act One This post is inspired by three converging observations:
1. Matt posted a comment to a previous post: that read:
&amp;quot;Cloud&amp;quot; computing. Seriously. Do we really want to give up that much control over our computing? In the dystopian future celebrated by many tech bloggers, computers will be locked down appliances, and we will rely on big companies to deliver services to us.
2. A number of podcasts that I listened to while I drove to New Jersey produced/hosted/etc.</description>
    </item>
    
    <item>
      <title>on package management</title>
      <link>https://tychoish.com/post/on-package-management/</link>
      <pubDate>Mon, 13 Jul 2009 00:00:00 +0000</pubDate>
      
      <guid>https://tychoish.com/post/on-package-management/</guid>
      <description>I was writing my post on distribution habits and change, and I realized that I some elaboration on the concept of package management was probably in order. This is that elaboration.
Most linux--and indeed UNIX, at this point--systems have some kind of package management:
Rather than provide an operating as one-monolithic and unchanging set of files, distributions with package management provide systems with some sort of database, and common binary file format that allows users to install (and install) all software in a clear/standardized/common manner.</description>
    </item>
    
  </channel>
</rss>