Bad news to report: for whatever reason, the UStream recording only included the last 10 minutes or so of the show. It shows the correct offset (56 minutes) where it starts, but the first 56 minutes? Not to be found.
Very, very disappointing. Only the 160-some-odd people who ended up tuning in live got to see it, which is a small % of the usual audience who tune in for the recorded shows afterwards.
I'm going to be looking into alternatives to UStream more aggressively this week due to this latest screw up. I have kdenlive freshly installed from the SVN and will be seeing if that might be the doorway to a reasonable alternative.
I'll keep you posted.
Monday, December 01, 2008
Sunday, November 30, 2008
that's one big avacado.
Tonight I made up some guacamole. I love the stuff. MMmmmmMMmm avocado goodness. In went one yellow and one red tomato, freshly squeezed lemon juice, finely diced garlic, diced white onion, a couple of finely diced red chilies, a little cumin, basil, sea salt and fresh ground pepper to taste. (Yes, no cilantro; I got out of the habit of using cilantro when P's mom, who hates the stuff, and I lived together.) In the large metal bowl I used for these things, I mashed it all up with a fork. I use a fork instead of the blender or other puree-er of food as I like my guacamole to have some texture. So nothing very out of the ordinary ... except the avocado.
I usually use 2-4 avacados, depending on whether I'm making a little bit of gauc for myself or enough for a bunch of guests. But tonight I only used one avacado. Despite using just one avacado, the mixing bowl is full and the proportion of avocado to other ingredient is perfect. This was managed because I purchased an extra large avocado. That's what the sign said, and they weren't joking: these things are massive. When P and I saw the bin of them in the grocery we just had to get one. There was probably somewhere between 4-6 avocados worth of fruit in this one extra large avocado.
The flavour is great, too, as I "had" to try some while making it to ensure a proper mix. =) It tastes just like any other avocado, it was wonderously, perhaps even a bit absurdly, large. And that humoured me for some reason. Perhaps I'm easily amused, after all. ;)
The guac is currently sitting in the fridge letting the flavours permeate the avacado mash fully. In a couple of hours I'll pull it out and wage battle against this extra large avocado goodness with a bag of tortilla chips. =)
Oh, and I finally downloaded the video from yesterday's KDE video cast and I'll be putting up a torrent for it tomorrow. Sorry for the delay, it was just a busier weekend than I anticipated. I'll post a link in my blog when the torrent goes live. Unlike the avocado, however, it will only be regular size.
I usually use 2-4 avacados, depending on whether I'm making a little bit of gauc for myself or enough for a bunch of guests. But tonight I only used one avacado. Despite using just one avacado, the mixing bowl is full and the proportion of avocado to other ingredient is perfect. This was managed because I purchased an extra large avocado. That's what the sign said, and they weren't joking: these things are massive. When P and I saw the bin of them in the grocery we just had to get one. There was probably somewhere between 4-6 avocados worth of fruit in this one extra large avocado.
The flavour is great, too, as I "had" to try some while making it to ensure a proper mix. =) It tastes just like any other avocado, it was wonderously, perhaps even a bit absurdly, large. And that humoured me for some reason. Perhaps I'm easily amused, after all. ;)
The guac is currently sitting in the fridge letting the flavours permeate the avacado mash fully. In a couple of hours I'll pull it out and wage battle against this extra large avocado goodness with a bag of tortilla chips. =)
Oh, and I finally downloaded the video from yesterday's KDE video cast and I'll be putting up a torrent for it tomorrow. Sorry for the delay, it was just a busier weekend than I anticipated. I'll post a link in my blog when the torrent goes live. Unlike the avocado, however, it will only be regular size.
Friday, November 28, 2008
Break even weeks on bugs.kde.org!
KDE developers around the world: we're currently just 14 closed bug reports away from a break even week! As of right now 475 bugs have been opened in the last 7 days, and people have resolved 461 reports.
I'd love to see KDE 4.2 get released with bugs.kde.org hosting less than 17,000 open reports and the only way to get there is to turn those status columns green!
Last week we delivered a crushing blow with twice as many closed as opened. If one removes the mass resolution of the 300+ aRts bugs with UNMAINTAINED, we were still 200 or so reports in the positive side of the ledger when Saturday rolled around.
Obviously, we won't have quite such a dramatic showing this week, but let's at least not lose ground after we've done so well recently.
Here's towards a better, slightly more perfect KDE 4.2.0! =)
I'd love to see KDE 4.2 get released with bugs.kde.org hosting less than 17,000 open reports and the only way to get there is to turn those status columns green!
Last week we delivered a crushing blow with twice as many closed as opened. If one removes the mass resolution of the 300+ aRts bugs with UNMAINTAINED, we were still 200 or so reports in the positive side of the ledger when Saturday rolled around.
Obviously, we won't have quite such a dramatic showing this week, but let's at least not lose ground after we've done so well recently.
Here's towards a better, slightly more perfect KDE 4.2.0! =)
KDE Videocast Episode 3, November 29!
Episode 3 of my KDE videocast will be broadcast live at 17:00 UTC on Saturday, November 29nd over at UStream.
This week's show will look like this:
A non-flv version with all the media and text files used in the show will be offered via bittorrent after the show so you can download it for offline viewing, in addition to the usual online clip at UStream. The torrent will also have the files provided individually this time versus the (bad idea) of a single archive.
See you there tomorrow!
This week's show will look like this:
Hello, viewers!
Week in review: KDE 4.2 Beta 1, Gran Canaria Desktop Summit and a developer activity recap.
The Headline: The realities of meeting modern user needs, or "Why do Amarok and Akonadi use MySQL?"
Feature of the Week: It's a two-fer! Migrating to Akonadi using kres-migrator and finding places with Marble's new search capabilities.
Town Hall: Bring your questions to #aseigo on irc.freenode.net, or leave one in the comment section below if you can't show up! I'll have my sack of answers at the ready at showtime.
Developer Corner: Using Phonon to add rich media support easily to your application.
Week in review: KDE 4.2 Beta 1, Gran Canaria Desktop Summit and a developer activity recap.
The Headline: The realities of meeting modern user needs, or "Why do Amarok and Akonadi use MySQL?"
Feature of the Week: It's a two-fer! Migrating to Akonadi using kres-migrator and finding places with Marble's new search capabilities.
Town Hall: Bring your questions to #aseigo on irc.freenode.net, or leave one in the comment section below if you can't show up! I'll have my sack of answers at the ready at showtime.
Developer Corner: Using Phonon to add rich media support easily to your application.
A non-flv version with all the media and text files used in the show will be offered via bittorrent after the show so you can download it for offline viewing, in addition to the usual online clip at UStream. The torrent will also have the files provided individually this time versus the (bad idea) of a single archive.
See you there tomorrow!
Thursday, November 27, 2008
abi checkers
Do you know of a tool that runs on Linux, preferably is FOSS, and can compare the ABI of two C++ libraries? If so, leave a link for me in the comments! =)
Wednesday, November 26, 2008
on my other perspective
I didn't mention it in my last blog entry on supppy chains because .. well .. it's not anything I can really say much about at this time, but: I'm currently spending some time consulting to a commercial project where one of the integral components is based on a Linux distribution. (Holy crap, how is that for vague?)
So for a good part of my days over the last while, I've had the experience of being downstream from KDE as well as the distributions who are KDE's downstreams. Some days it feels like I'm in a mobius loop as I shift positions in the production sequence. =)
It's been nice to be able to hold that perspective for extended periods of time, though. Being downstream (once removed!) from KDE (and the rest of the stack) is a rather different experience and mindset from being upstream to a distro. That's probably stating the obvious, but it's certainly another part of what has gotten me thinking about these issues more deeply.
Holding both experiences concurrently has given me the context to do things like explore negotiating with myself, role playing both sides of the conversation. (I don't actually self-negotiate when it comes to the real-world work issues; this is more a "mental exercises for hot showers" type material.)
More practically, I have to apply my goals and needs as a downstream without prejudice because I have a team that relies on and demands that; in a different point of the week (or sometimes the same day, even) I have to apply my goals and needs as an upstream without prejudice because, well, I have a team that relies on and demands that.
It is said that you can not slave for two masters, and at first I thought I'd run into issues with this until I realized that my master for whom I slave is one and the same: Free software. I just get to play the role of two different servants whose work must dovetail.
Given that these "supply chain" issues are kicking my ass in both of my servant roles, it's become something of an un-ignorable burning itch. Like athletes foot, or jock itch. Yeah, not pleasant.
I do also want to give a positive example (that I personally had nothing to do with) to show that this up/down coordination can work out well. The challenge was that a KDE4 user interface to network manager was needed.
Preferably it would be an improvement over the KDE3 one and it should work with the latest, greatest network manager stuff. Now, network manager is "upstream" to KDE and the distributions who really, really want this are downstream from us. Along comes Novell, one of our downstreams, and they say, "We really need both a better KDE network manager GUI for OpenSuse and it needs to use KDE4 libraries." They (Will Stephenson being huge in this role) start working on it. That work goes into the upstream repository while it is worked on, thus building a partnership through shared infrastructure.
Unfortunately KDE 4.2 goes into feature freeze before the network manager interface is ready. So people talk about it and determine that it could be in shape by the time 4.2.0 comes out, it just can't be part of the 4.2.0 release proper. OpenSuse could then ship this thing with their KDE4 packages even though it's not actually released via upstream yet. Sebastian Kugler, an "upstream" Plasma developer, starts pitching in to help make it happen. Everyone is informed and comfortable with the situation.
It seems to be working out well, but what happened differently here?
People along different parts of the production/supply chain got together and coordinated. Needs were communicated upwards in advance of crunch-time, and a coordinated effort emerged. Upstream was given a heads up about the inclusion of a non-released component that is just That Important(tm), and upstream actually got involved and puts resources on it to help ensure success. Upstream's happy because they get help from a much needed component from downstream, downstream's happy because they fill a need.
It's not a perfect world (perfect would have been inclusion with 4.2.0, or heck, even 4.0 if we really want to go for Perfect(tm)), but it's close enough (they are still using the KDE3 network manager in the meantime) and everyone is informed and comfortable with the plans. Needles to say, the user wins across the board and nobody is losing.
This all seems common sense, doesn't it?
Yet it is a much rarer occurrence in the FOSS desktop world than it ought to be. We are often chasing our upstreams, who are often running off on their own tangent, while we're doing the same thing to our downstreams. Every so often someone screws the upstream over because they don't feel they have a better choice, and the upstream gets miffed. All perfectly logical, but not very brilliant.
So why did common sense prevail in this case? In part because Will, Sebas and the Plasma team all know each other and get along. We talk often, have shared values and open lines of communication. Obviously this is not an easy dynamic to replicate.
So we know that with agreeable circumstances it can work out. We know that release schedules don't need to get in the way even if they don't line up perfectly. We know that resource allocation can be modified in response to voiced need. We know that different points in the chain can work together as if we were actually coordinated in some logical fashion. We do not have to guess at the plasusibility of it, then, we just need to figure out how to replicate the phenomenon.
What we are (or at least I am) missing are sure-fire ways to replicate these results when:
We don't all know each other, or know each other very well
We aren't in constant, regular communication with each other
We rely on each other for different pieces of the puzzle
We have independent bodies setting each group's agenda/roadmap
The topic isn't always as limited and focussed as "an interface for the user to activate a network connection".
And it all needs to fit into 40-60 hours a week. Cue the Mission Impossible theme song? =) It may sound like it when it's put that way, but I have faith that we can construct an 80% solution that will blow away our current 20%-because-we-get-lucky track record.
So for a good part of my days over the last while, I've had the experience of being downstream from KDE as well as the distributions who are KDE's downstreams. Some days it feels like I'm in a mobius loop as I shift positions in the production sequence. =)
It's been nice to be able to hold that perspective for extended periods of time, though. Being downstream (once removed!) from KDE (and the rest of the stack) is a rather different experience and mindset from being upstream to a distro. That's probably stating the obvious, but it's certainly another part of what has gotten me thinking about these issues more deeply.
Holding both experiences concurrently has given me the context to do things like explore negotiating with myself, role playing both sides of the conversation. (I don't actually self-negotiate when it comes to the real-world work issues; this is more a "mental exercises for hot showers" type material.)
More practically, I have to apply my goals and needs as a downstream without prejudice because I have a team that relies on and demands that; in a different point of the week (or sometimes the same day, even) I have to apply my goals and needs as an upstream without prejudice because, well, I have a team that relies on and demands that.
It is said that you can not slave for two masters, and at first I thought I'd run into issues with this until I realized that my master for whom I slave is one and the same: Free software. I just get to play the role of two different servants whose work must dovetail.
Given that these "supply chain" issues are kicking my ass in both of my servant roles, it's become something of an un-ignorable burning itch. Like athletes foot, or jock itch. Yeah, not pleasant.
I do also want to give a positive example (that I personally had nothing to do with) to show that this up/down coordination can work out well. The challenge was that a KDE4 user interface to network manager was needed.
Preferably it would be an improvement over the KDE3 one and it should work with the latest, greatest network manager stuff. Now, network manager is "upstream" to KDE and the distributions who really, really want this are downstream from us. Along comes Novell, one of our downstreams, and they say, "We really need both a better KDE network manager GUI for OpenSuse and it needs to use KDE4 libraries." They (Will Stephenson being huge in this role) start working on it. That work goes into the upstream repository while it is worked on, thus building a partnership through shared infrastructure.
Unfortunately KDE 4.2 goes into feature freeze before the network manager interface is ready. So people talk about it and determine that it could be in shape by the time 4.2.0 comes out, it just can't be part of the 4.2.0 release proper. OpenSuse could then ship this thing with their KDE4 packages even though it's not actually released via upstream yet. Sebastian Kugler, an "upstream" Plasma developer, starts pitching in to help make it happen. Everyone is informed and comfortable with the situation.
It seems to be working out well, but what happened differently here?
People along different parts of the production/supply chain got together and coordinated. Needs were communicated upwards in advance of crunch-time, and a coordinated effort emerged. Upstream was given a heads up about the inclusion of a non-released component that is just That Important(tm), and upstream actually got involved and puts resources on it to help ensure success. Upstream's happy because they get help from a much needed component from downstream, downstream's happy because they fill a need.
It's not a perfect world (perfect would have been inclusion with 4.2.0, or heck, even 4.0 if we really want to go for Perfect(tm)), but it's close enough (they are still using the KDE3 network manager in the meantime) and everyone is informed and comfortable with the plans. Needles to say, the user wins across the board and nobody is losing.
This all seems common sense, doesn't it?
Yet it is a much rarer occurrence in the FOSS desktop world than it ought to be. We are often chasing our upstreams, who are often running off on their own tangent, while we're doing the same thing to our downstreams. Every so often someone screws the upstream over because they don't feel they have a better choice, and the upstream gets miffed. All perfectly logical, but not very brilliant.
So why did common sense prevail in this case? In part because Will, Sebas and the Plasma team all know each other and get along. We talk often, have shared values and open lines of communication. Obviously this is not an easy dynamic to replicate.
So we know that with agreeable circumstances it can work out. We know that release schedules don't need to get in the way even if they don't line up perfectly. We know that resource allocation can be modified in response to voiced need. We know that different points in the chain can work together as if we were actually coordinated in some logical fashion. We do not have to guess at the plasusibility of it, then, we just need to figure out how to replicate the phenomenon.
What we are (or at least I am) missing are sure-fire ways to replicate these results when:
We don't all know each other, or know each other very well
We aren't in constant, regular communication with each other
We rely on each other for different pieces of the puzzle
We have independent bodies setting each group's agenda/roadmap
The topic isn't always as limited and focussed as "an interface for the user to activate a network connection".
And it all needs to fit into 40-60 hours a week. Cue the Mission Impossible theme song? =) It may sound like it when it's put that way, but I have faith that we can construct an 80% solution that will blow away our current 20%-because-we-get-lucky track record.
free software supply chains
Over the past few months I've been quietly tracking our upstream and downstream interactions. The motivation for this has been my experience with the KDE 4 series, in which we have both been on more people's radar (when was the last time NVidia mentioned KDE 3 in a driver release?) and seen more trainwrecks both up- and down-stream from us.
In particular, the "distribution backporting" issue has really gotten out of hand. It's no longer just individual unbaked features that are being backported and shipped with stable KDE releases, but now entire applications are being pulled from pre-beta SVN and shipped with stable KDE releases. I know of two different applications this has now happened to.
Just as disturbing, some downtreams feel that they have the right to speak for us as an upstream to their communities and have, by doing so, misled people and abused KDE's relationship with users in doing so.
Of course, I'm still reeling from the issues Plasma has run into all across the X.org and Qt map. Features those projects have advertised, in some cases for years, simply were not mature or tested until we showed up and found out the hard way by running headlong into pointy skewers of buggy or simply featureless code bases which got that way due to not having real world applications at the ready to tease them into shape.
The losers in this are all around: users get sub-par product, KDE's relationships are damaged both with users and downstreams, upstreams look incompetent when really they just got caught out unawares and downstreams provide a muddled experience in their delivery phases.
This is not a healthy situation. I hope that's stating the obvious and that we're all in agreement thus far.
Note that I haven't really said anything about who's to blame for this. Take the case of lacking real world applications to test our frameworks with: who is at fault? Should KDE have been there earlier pushing on these areas back when these features were first being trialed? Should those writing these frameworks have ensured there were real world type applications doing meaningful things with their new fangled hotness before claiming stability and maturity? Not easy questions, are they? Personally, I'm not one for fingerpointing unless you really get it obviously wrong after having had a workable solution pointed out to you. We aren't at that point, however, with nearly any of the above.
While tracking these issues and trying to make heads and tails of them, often with great frustration draped across my brow, I have also been looking for analogs elsewhere. Most problems have already been at least identified, and most problems that have been identified have a history of attempted solutions. Just because I haven't had to deal with a particular problem first hand doesn't mean someone else hasn't, and so I've been searching for solutions (good or bad) elsewhere.
In talking with some of our downstreams, I've found it increasingly useful to talk about things in terms of supply chains and the kinds of relationships that end up forming around them. Unlike "traditional" software development where the supply chain is tightly managed and usually completely or nearly completely internal, the open source model seems to me to be a lot more like the free market dynamics seen in commodity markets and how supply trickles on through the machinery to eventually create products the consumer purchases. At least, that's been my impression. Feel free to correct me in the comments section of this blog entry. ;)
Mapping our current situation on to that of supply chain dyanmics does give us a well studied and highly optimized set of solutions that other people have already torn their hair, hearts and souls out over. So I'll be slowly edumecating myself about SCM (no, not that SCM, this SCM), something I'm only mildly versed in at best, and thinking about how to apply it sensibly, if at all possible, to improve our current state of affairs. It could be a dead end, but it could also be a source of inspiration. There's only one way to find out.
I'm devoting brain time to this because it is going to be increasingly critical to get our act together if we want to take on the next level of competition we face in the market without gutting our values and our resources. We have to communicate and coordinate much, much better between the different points in our software supply chain and get our roles correctly aligned with each other. Right now it's very ad-hoc and the network of people has grown beyond that which is sustainable based on a who-knows-who game masquerading as personal relationships.
I hope to meet with several of our partners at the Gran Canaria Desktop Summit in mid-2009 to discuss these things directly, and to have brought myself up to speed enough on the issues to be able to formulate and deploye systematic support solutions. If you have a great SCM book you think I should be reading in the next couple months, please comment below. I'm also wondering how I might gain access to the Supply Chain Council's full SCOR reference manual.
In particular, the "distribution backporting" issue has really gotten out of hand. It's no longer just individual unbaked features that are being backported and shipped with stable KDE releases, but now entire applications are being pulled from pre-beta SVN and shipped with stable KDE releases. I know of two different applications this has now happened to.
Just as disturbing, some downtreams feel that they have the right to speak for us as an upstream to their communities and have, by doing so, misled people and abused KDE's relationship with users in doing so.
Of course, I'm still reeling from the issues Plasma has run into all across the X.org and Qt map. Features those projects have advertised, in some cases for years, simply were not mature or tested until we showed up and found out the hard way by running headlong into pointy skewers of buggy or simply featureless code bases which got that way due to not having real world applications at the ready to tease them into shape.
The losers in this are all around: users get sub-par product, KDE's relationships are damaged both with users and downstreams, upstreams look incompetent when really they just got caught out unawares and downstreams provide a muddled experience in their delivery phases.
This is not a healthy situation. I hope that's stating the obvious and that we're all in agreement thus far.
Note that I haven't really said anything about who's to blame for this. Take the case of lacking real world applications to test our frameworks with: who is at fault? Should KDE have been there earlier pushing on these areas back when these features were first being trialed? Should those writing these frameworks have ensured there were real world type applications doing meaningful things with their new fangled hotness before claiming stability and maturity? Not easy questions, are they? Personally, I'm not one for fingerpointing unless you really get it obviously wrong after having had a workable solution pointed out to you. We aren't at that point, however, with nearly any of the above.
While tracking these issues and trying to make heads and tails of them, often with great frustration draped across my brow, I have also been looking for analogs elsewhere. Most problems have already been at least identified, and most problems that have been identified have a history of attempted solutions. Just because I haven't had to deal with a particular problem first hand doesn't mean someone else hasn't, and so I've been searching for solutions (good or bad) elsewhere.
In talking with some of our downstreams, I've found it increasingly useful to talk about things in terms of supply chains and the kinds of relationships that end up forming around them. Unlike "traditional" software development where the supply chain is tightly managed and usually completely or nearly completely internal, the open source model seems to me to be a lot more like the free market dynamics seen in commodity markets and how supply trickles on through the machinery to eventually create products the consumer purchases. At least, that's been my impression. Feel free to correct me in the comments section of this blog entry. ;)
Mapping our current situation on to that of supply chain dyanmics does give us a well studied and highly optimized set of solutions that other people have already torn their hair, hearts and souls out over. So I'll be slowly edumecating myself about SCM (no, not that SCM, this SCM), something I'm only mildly versed in at best, and thinking about how to apply it sensibly, if at all possible, to improve our current state of affairs. It could be a dead end, but it could also be a source of inspiration. There's only one way to find out.
I'm devoting brain time to this because it is going to be increasingly critical to get our act together if we want to take on the next level of competition we face in the market without gutting our values and our resources. We have to communicate and coordinate much, much better between the different points in our software supply chain and get our roles correctly aligned with each other. Right now it's very ad-hoc and the network of people has grown beyond that which is sustainable based on a who-knows-who game masquerading as personal relationships.
I hope to meet with several of our partners at the Gran Canaria Desktop Summit in mid-2009 to discuss these things directly, and to have brought myself up to speed enough on the issues to be able to formulate and deploye systematic support solutions. If you have a great SCM book you think I should be reading in the next couple months, please comment below. I'm also wondering how I might gain access to the Supply Chain Council's full SCOR reference manual.
Saturday, November 22, 2008
KDE Video Cast, Episode 2: Torrent it!
I got up early this morning so I could luxuriate in a hot shower, get dressed and go over my notes before the video cast this morning. It was an hour earlier and the second episode, so live attendance was down a fair amount: it peaked at "only" 194, which was 27 fewer than last week. I expected a spike on the first week (curiosity) and I knew shifting the time by an hour would suck as well. Oh well =)
I did, however, manage to figure out how to put text messages on the stream as well as videos hosted on Youtube. Unfortunately, these only show during the live broadcast and are not part of the resulting recorded version. I put a link to the show notes on the screen during the live broadcast thinking that would help people downloading it later, but ... fail. Additionally, UStream dropped out twice. My internet connection was fine (I was still in the chats), the server side just thunked out twice in a few minute span.
On the plus side the audio was better, I used a solid color backdrop, and the downloaded version is in mpeg format this week instead of flv's that won't work for anyone. Also included in the torrent are the show notes and the media I reference in the show, including a short Kopete screencast and a couple of JavaScript Plasmoids.
I am learning exactly what I want from a DIY broadcast software and am becoming increasingly tempted to see what Solid+Phonon in KDE 4.3 are capable of doing for me. For now, I just learn the quirks of what's available and soldier on improving each episode incrementally.
You can grab the torrent here and enjoy it at your leisure. Cheers! =)
I did, however, manage to figure out how to put text messages on the stream as well as videos hosted on Youtube. Unfortunately, these only show during the live broadcast and are not part of the resulting recorded version. I put a link to the show notes on the screen during the live broadcast thinking that would help people downloading it later, but ... fail. Additionally, UStream dropped out twice. My internet connection was fine (I was still in the chats), the server side just thunked out twice in a few minute span.
On the plus side the audio was better, I used a solid color backdrop, and the downloaded version is in mpeg format this week instead of flv's that won't work for anyone. Also included in the torrent are the show notes and the media I reference in the show, including a short Kopete screencast and a couple of JavaScript Plasmoids.
I am learning exactly what I want from a DIY broadcast software and am becoming increasingly tempted to see what Solid+Phonon in KDE 4.3 are capable of doing for me. For now, I just learn the quirks of what's available and soldier on improving each episode incrementally.
You can grab the torrent here and enjoy it at your leisure. Cheers! =)
Thursday, November 20, 2008
Video Cast Episode 2, Nov 22nd!
This week's show will be one hour earlier than the usual schedule calls for: we'll be going live at 16:00 UTC on Saturday, November 22nd over at UStream.
This week's show will look like this:
An ogv will be available via bittorrent after the show so you can download it for offline viewing, in addition to the usual online clip at UStream.
As for why the bump up by an hour this week: There is a winter fair at the P-man's school on Saturday, and we'll be there for much of day. So I'll be broadcasting at 16:00 UTC instead. Apologies for the inconvenience, I hope you can still make it! We'll be back to the regular time next week.
Update: Due topopular demand metelliuscode's suggestion in the comments section, if you can't make the live broadcast for the Town Hall section but have a burning question to ask, leave it in the comments section of this blog entry and I'll pick one or two of the better ones to address during the Town Hall.
This week's show will look like this:
Hello, viewers!
Week in review: KOffice beta, Amarok release candidate, bugs.kde.org improves and developer activity recap.
The Headline: Entrepreneurial opportunities and the Free Software desktop: where is all the diversity?
Feature of the Week: New MSN bling and graceful interfaces in Kopete
Town Hall: Bring your questions to #aseigo on irc.freenode.net! I'll have my sack of answers at the ready.
Developer Corner: Writing a Plasmoid in JavaScript.
Week in review: KOffice beta, Amarok release candidate, bugs.kde.org improves and developer activity recap.
The Headline: Entrepreneurial opportunities and the Free Software desktop: where is all the diversity?
Feature of the Week: New MSN bling and graceful interfaces in Kopete
Town Hall: Bring your questions to #aseigo on irc.freenode.net! I'll have my sack of answers at the ready.
Developer Corner: Writing a Plasmoid in JavaScript.
An ogv will be available via bittorrent after the show so you can download it for offline viewing, in addition to the usual online clip at UStream.
As for why the bump up by an hour this week: There is a winter fair at the P-man's school on Saturday, and we'll be there for much of day. So I'll be broadcasting at 16:00 UTC instead. Apologies for the inconvenience, I hope you can still make it! We'll be back to the regular time next week.
Update: Due to
Subscribe to: Posts (Atom)
