There has been a growing trend among bloggers, particularly among those aggregated on Planet Debian, in which the blogger writes regularly (usually monthly) about their activity in the Free Software communities since their last report.
This can be used as a way to "keep yourself honest" in the sense that if you're committed to reporting your activity on a month by month basis, you kinda need some activity to report. It can be used as a way to keep your colleagues and co-conspiritors in F/LOSS informed about what you're working on, and cool things you've done which they might be interested in. It might be a useful way to motivate yourself when each period of time you get to write a nice blog posting all about the wonderful things you've achieved and the projects you've improved along the way.
Recently I've been persuaded to join the trend and I'm looking forward to experiencing the effects I've mentioned above. I'd like to suggest that all of you go out and write yourself a blog post all about the wonderful things you've done and then commit yourself to doing so again in X amount of time in the future.
Sometimes you'll want to leave a free software project. It might be one you founded or one you've joined. You may have spent years contributing to it. You may have formed friendships with other contributors: working together on something for a long time tends to be a catalyst for that. However, things change and you may want to leave. You might no longer be using the software. You might not have time to contribute. There might be disagreements about where the project is going or how it is going to be operating. You might be moving to a different continent. You may be switching careers entirely. You may be founding an unrelated company.
A term for this is 'retiring'. Depending on the project, there may be a processs to follow, or you may just wing it.
More importantly, there're various aspects to consider when retiring, especially if you've been involved for a long time.
- Why are you leaving? It's best to be honest about this, particularly to yourself. Don't rage quit.
- Will the project survive you leaving?
- How will users of the software be affected?
- What about other collaborators on the project?
- Will there be people to pick up the slack and take over responsibilities? Will they know what to do? Can they ask you for help afterwards?
- Is there any publicity likely to follow from the retirement? (Probably not, except for high-profile projects.)
- Are there any assets (computers, etc) that need to be dealt with?
Retiring from a free software project is a lot like leaving paid employment. If you do it well, you make sure all your old commitments and responsibilities are handed over to new people, and no-one is affected too adversely from the change. As a result, you'll be remembered with fondness and you're always welcome back.
Unlike paid employment, there's few hard and fast rules in Free Software. It's important to remember that though your contributions are valued, you're not obliged to continue them if you don't want to.
Occupational Burnout is a thing which people worry about a lot in the "real world" and it's why we encourage people, particularly information workers, to take regular breaks, to not think about their job outside of work. Indeed, burnout has been referred to as a disease and as such we recommend strongly that you avoid it.
Sadly, those of us who are blessed with the ability and the interest in contributing to F/LOSS tend to work hard, and then effectively "work as play" hard too; which can lead to burning out even more quickly. It can be even worse when the stress originates in your F/LOSS activity because it can be seen as making your 'funtime' less enjoyable.
Burning out is a leading cause of people having to retire from F/LOSS projects and as such, it's really important that you know when to step away from F/LOSS and have a break. You might prefer to spend a few days entirely away from your computer or just spend it immersed in a game. If you're particularly lucky/unlucky then you might just be able to work on a different project for a little while instead. Whatever you do to relax, be sure to increase your explicit relaxation time along with time you're spending on F/LOSS to keep yourself happy and healthy, and able to contribute for a nice long time to come.
Your homework this week is to just think about what you enjoy doing which isn't work or F/LOSS related at all, and go do it. Just shoo!
Four years ago, Lars posted our first article on software freedom. This started an epic effort to help educate those who want to get into free-software. We pledged to discuss technical topics such as shell and C, and non-technical topics such as diversity and motivation. Through our time we've had opinionated series on the truisms of software, or strong technical sets around topics such as systemd.
To give you some numbers, in the past four years we've published two hundred and eleven (or two hundred and twelve if you include this one) articles, by seven authors. Eighty-three were by Richard Maw, seventy-four (seventy-five) by yours truly, and forty-one by Lars Wirzenius. Our most prolific guest author was Will Holland who has contributed seven, Richard Ipsum and Jonathan Maw have contributed two each. Jon Dowland has contributed one, and one of our articles was deliberately anonymously posted one Christmas.
We've received thirty-eight comments spread over twenty-four of the articles. Our most prolific commenters have been Gravious and Richard Maw; otherwise they're spread relatively thinly among the approximately nineteen other commenters. More than fifteen of the thirty-eight comments were by authors, usually in response to comments on their articles.
We have six items in our suggestion-box (thank you) though some are us acknowledging comments. We're grateful for every suggestion and every bit of encouragement you've provided over the years, via the site, IRC, Twitter, etc.
Over the years, our core contributors have had their own ups and downs, and yet
we've pretty much managed to get an article out every week no matter
what. Indeed we missed one week (I believe) in all that time, and that was
because we typoed the date in our publishing queue, and none of us caught it in
review. Sadly, it gets harder and harder though, and so please do pop over to
the suggestion box if there're topics you'd like to see us cover (even if you
just want an expansion of something we've previously discussed). Perhaps come
and join us in #yakking on the OFTC IRC network, and if you're feeling very
enthusiastic then come and discuss guest-posting since we're always grateful
for contributions.
Here's to another four years of articles which you consider worth reading…
Up until now we've only considered time in relation to the machine we're using.
This is only useful for recording events in the vicinity of that machine.
To coordinate events happening elsewhere in the world such as it being midday at Greenwich observatory, it is necessary to synchronise clocks.
We've briefly introduced these concepts in our introduction to time, but more detail is warranted.
Real time
"Real time" or "Wall clock time" is the globally coordinated time system, so if the time of an event is recorded in one location the record of that time can be transmitted elsewhere and they can reason about when this was in relation to their own clocks so they can tell how long ago it happened.
This is handled by computers containing a special piece of hardware called a Real-Time Clock which tracks the current time.
Time Zones
Times were historically defined by the position of the sun in the sky, but the sun is in different positions in the sky depending on where you are, so the coordinated time in any given location depends on where you are.
If you pick any particular location for your definition of coordinated time, you need to know the difference in time from that location to elsewhere for people who have used that place for their time base.
Rather than everywhere tracking what time it is, areas pick a common baseline and everyone in that area uses that time. These are called [Time Zones][] and are usually arranged along political lines.
In practice most computers think in terms of the UTC time zone, and use records of what the difference in time is between the local time zone and UTC.
The difference is normally but not exclusively measured in an integral number of hours since that time in UTC.
Indian standard time is 5½ hours after UTC. North Korea's time is 8½ hours after UTC.
Time zones don't remain fixed. They are political entities so change on political decisions.
Most of the western world observes some form of Daylight saving time where the current time zone depends on what day of the year it is.
This means some times do not exist in every time zone since the time zone is not defined for every part of the year.
As a consequence some local times do not exist everywhere in the world, and the local time is a product of an agreed time in one part of the world, where the local time is being measured, and any political decisions.
An extreme example of this is Samoa skipping the 30th December 2011 and jumping from one time zone to another.
For future proofing you would ideally record the coordinates alongside the UTC time so if a time zone's geopolitical boundaries change the local time at those coordinates may be known.
Synchronisation
Your computer's RTC will continue to measure time while your computer is off so when you turn it back on the time is mostly correct.
RTCs are not perfect however, they diverge from real time because they measure time slightly faster or slower.
Handily, because computers are networked they can ask each other what the time actually is. The protocol for doing this is called NTP.
Once a computer has determined the correct time it can use adjtimex(2) to either accelerate or slow the clock until correct, or just set the time to what value it should have.
It is preferable to speed or slow the clock to correct the time unless your computer is still early on in the boot process since you are likely to have programs that will get confused if the time changed a huge amount, but if your computer's clock is sufficiently far ahead or behind then it's impractical to accelerate or slow the clock to the correct time.
Linux's interface to the real time is via the CLOCK_REALTIME clock,
though CLOCK_REALTIME_COARSE exists if it's more important that
the time is retrieved quickly rather than the result is precise.
Now that we've got a globally coordinated notion of time you can coordinate events globally.
Unfortunately humans aren't trained to think in terms of position and UTC so we need a way to translate this into something human readable, which will be the focus of the next article.