Wandering Thoughts archives


Syndication feeds (RSS) and social media can be complementary

Every so often I read an earnest plea to increase the use of 'RSS', by which the authors mean syndication feeds of all formats (RSS, Atom, and even JSON Feed). Some times, as in this appeal (via), it's accompanied by a plea to move away from getting things to read through social media (like Twitter) and aggregators (like lobste.rs). I'm a long term user and fan of syndication feeds, but while I'm all in favour of more use of them, I feel that abandoning social media and aggregators is swinging the pendulum a bit too far. In practice, I find that social media and aggregators are a complement to my feed reading.

(From now on I'm just going to talk about 'social media' and lump aggregators in with them, so I don't have to type as much.)

The first thing I get through social media is discovering new feeds that I want to subscribe to. There's no real good substitute for this, especially for things that are outside my usual areas of general reading (where I might discover new blogs through cross links from existing ones I read or Internet searches). For instance, this excellent blog looking at the history of battle in popular culture was a serendipitous discovery through a link shared on social media.

The second and more important thing I get through social media is surfacing the occasional interesting to me content from places where I don't and wouldn't read regularly. If I'm only interested in one out of ten or fifty or a hundred articles in a feed, I'm never going to add it to my feed reader; it simply has too much 'noise' (from my perspective) to even skim regularly. Instead, I get to rely on some combination of people I follow on normal social media and the views of people expressed through aggregator sites to surface interesting reading. I read quite a lot of articles this way, many more than I would if I stuck only to what I had delivered through feeds I was willing to follow.

(Aggregator sites don't have to involve multiple people; see Ted Unangst's Inks.)

So, for me subscribing to syndication feeds is for things have a high enough hit rate that I want to read their content regularly, while social media is a way to find some of the hits in a sea of things that I would not read regularly. These roles are complementary. I don't want to rely on social media to tell me about things I'm always going to want to read, and I don't want to pick through a large flood of feed entries to find occasional interesting bits. I suspect that I'm not alone in this pattern.

A corollary of this is that social media is likely good for people with syndication feeds even in a (hypothetical) world with lots of syndication feed usage. Your articles appearing on Twitter and on lobste.rs both draws in new regular readers and shares especially interesting content with people who would at best only read you occasionally.

tech/SyndicationFeedsAndSocialMedia written at 21:42:56; Add Comment

Some views on having your system timezone set to UTC

Some people advocate for setting the system timezone on servers to UTC, for various reasons that you can read about with some Internet searches. I don't have the kind of experience that would give me strong opinions on this in general, but what I do know for sure is that for us, it would be a bad mistake to set the system timezone to UTC instead of our local time of America/Toronto. In fact I think we are a great example of a worst case for using UTC as the system timezone.

We, our servers, and most of our users are located in Toronto. Most of the usage of our systems is driven by Toronto's local time (and the Toronto work week), which means that so is when we want to schedule activities like backups, ZFS snapshots, or daily log rotations. When users report things to us they almost always use local Toronto time (eg, 'I had a connection problem at 10am'), and when they aren't in Toronto they generally don't use UTC for their reports. If we used UTC for our system timezone, almost everything we do would require us to translate between UTC time and local time; looking at logs, scheduling activities, investigating problem reports, and so on. Using Toronto's local time means we almost never have to do that.

(And when something happens to our servers because of a power outage, a power surge, an Internet connectivity problem, or whatever, almost all of the reporting and time information on it will be in Toronto local time, not UTC. Almost no one reports things relevant to us in UTC.)

Given all of this, dealing with the twice-yearly DST shift is a small price to pay, and in a sense it is honest to have to deal with it. Our users experience the DST shift, after all, and their usage shifts one hour forwards or backwards relative to UTC.

If we had servers located elsewhere (such as virtual machines in a cloud), we would probably still operate them in Toronto local time. Almost all of the reasons for doing so would still apply, although there might be some problems that now correlated with the local time of the datacenter where they were located.

The more you diverge from this, the more I suspect that it potentially makes sense to set your system timezone to UTC. If you have people working around the world, if your servers are scattered across the globe, if usage is continuous instead of driven by one location or continent, and so on, the less our issues apply to you and the more UTC is a neutral timezone. Running software in UTC also avoids it having to deal with time zone shifts for DST, which means that you don't necessarily have to test how it behaves in the face of DST shifts and then fix the bugs.

(Software sometimes can't avoid dealing with DST shifts at some level in the stack, because it handles or displays times as people perceive them and people definitely perceive DST shifts. But handling time for people is a hard issue in general with no simple solutions.)

sysadmin/ServerUTCTimeViews written at 00:30:59; Add Comment

Page tools: See As Normal.
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.