Once again, FOSDEM will have a cross-distribution miniconference on 1 & 2 February 2014. We’d like to invite submissions of talks, Birds of a Feather (BoF) sessions, or round-table discussions from any interested representatives of Linux distributions or individuals who have a topic of interest related to Linux distributions.
Proposals should be submitted through the FOSDEM proposal system (Pentabarf) here:
You’ll add your session title, speaker bio, and abstract for the talk. If you’ve presented or submitted at FOSDEM previously, you should have an account in Pentabarf. If you haven’t created an account, but have presented at FOSDEM previously please contact me before creating an account – the odds are you have an account that was created previously by the FOSDEM organizers.
Deadline for submissions is 22 December 2013. Since we’re on a tight timeline, this is unlikely to be extended.
In addition to speakers, we also need one moderator for each day, and a video volunteer for each day. The moderator will introduce the speaker, keep time, and pass the microphone around for questions. The video volunteer will handle recording of sessions with provided equipment. (Don’t worry, we’ll also provide training as well.)
The call for participation is going out a bit late, so please do speak up quickly if you’re interested in participating! Also, please do help spread the word so we can ensure the best possible program for this year’s FOSDEM.
Last year I attended AWS re:Invent, kinda, sorta. We were in Las Vegas to put on the first Apache CloudStack conference and most of my time and brainpower were consumed with last-minute planning for that event. I did spend time in the developer area, on exhibit floor, and some of the after-parties – but it wasn’t a usual conference for me.
This year, I’m actually not consumed with pre-conference planning (though the CloudStack Collaboration Conference is happening next week in Amsterdam, and I’m sad I won’t be able to attend), so I’ve been paying attention to re:Invent.
Generally, I tend to attend more community/FOSS and techie shows than big vendor blow-outs like AWS re:Invent. The very scale of the event is really impressive, and I have to give Amazon kudos for the slickness of the presentations and how smoothly the event is running. The registration, for instance, was totally slammed on day one – yet they kept the lines moving really well and even had a DJ (!) playing tunes in the corner to make the wait a little better.
The content on the other hand… well, it’s a bit generic and the keynote yesterday was definitely not what I was hoping for or expecting. First, I was surprised and disappointed at the amount of time Amazon spent calling out competitors (IBM, for an admittedly silly marketing stunt) and dissing private cloud. Does Amazon offer a solution that’s really appealing for certain applications or certain types of companies? Yup. Is public cloud ever going to be the majority of the compute market? I’m not convinced.
The keynote yesterday felt like a plea to enterprise, and way too much preaching to the converted and marketing fluff that we already knew anyway. Yeah, we get it: AWS is big, lots of customers (oooh, pretty NASCAR slides) and so forth. At least they did announce a few new services during the keynote, so attendees got a little excitement.
For me, the biggest part of any event is the “hallway track.” On one hand, it’s pretty good here because there’s about 9,000 people – you can easily find interesting people who are doing fun stuff with AWS and other tech, so that’s been good.
The bad, really bad, is the conference scheduling site is terrible and there’s no attendee directory whatsoever. I was doubly disappointed when I looked on Lanyrd and found only about 40 people signed up. It would have been great if I could have searched a directory (opt-in, of course) to try to connect with people ahead of time to meet and talk about their cloud usage.
Maybe next year. Overall, I think re:Invent is worth the time, money, and trip if you’re using AWS or are trying to disrupt AWS – but there are a number of things Amazon could do to make the conference more friendly for attendees and partners.
Email is a fantastic tool, when used correctly. It almost never is. Rikki Endsley asked me if I’d like to write something for USENIX ;login; logout, and it happened to be right after processing a slew of terrible email: people sending two-line replies at the end of several hundred lines of text, inexcusable top-posting, HTML-ized email sent to lists that reject HTML email (rightly), etc.
Practicing a little courtesy when doing email takes a little extra time, but it makes it so much easier for the people who have to read your email.
Anyway, here’s the piece (in PDF form) over on the USENIX site, please give it a read!
What Every Admin Should Know About Email »
I think Lawrence Lessig puts his finger on it pretty well with this post about the problems with Apple’s “communication” strategy about bugs/feature removal in upgrades:
But the argument I want to advance here is different. It is that in the “hybrid economy” that the Internet is, there is an ethical obligation to treat users decently. “Decency” of course is complex, and multi-faceted. But the single dimension I want to talk about here is this: They must learn to talk to us. In the face of the slew of either bugs or “features” (because as you’ll see, it’s unclear in some cases whether Apple considers the change a problem at all), a decent company would at least acknowledge to the public the problems it identifies as problems, and indicate that they are working to fix it.
Why is that what decency requires? And why, then, is the pathologically constipated way in which Apple communicates with its customers indecent?
Because when you see the incredible effort that is being devoted to dealing with these either bugs or features, there is an obvious incredible waste of time and resources that Apple could avoid simply by saying what they know.
For many users, communication is one of the strongest arguments for open source.
The fact that the source is open may not make a lick of difference to people who aren’t good with code, and/or are uninterested in spending the time to maintain or add features, or fix bugs. But they can have a direct line of communication with the developers who are working on features. Maybe a project you’re using goes in a direction you don’t like (for example) but at least you see the “WONTFIX” in the bug tracker. With Apple? Who the heck knows?
Many of the freedoms that are important to open source/free software folks seem like abstractions to non-developers. Apple provides a really good object lesson that shows that there are concrete reasons, beyond just hacking the code, that users should prefer open source.
Going all the way to Washington D.C. for USENIX LISA next week? There’s lots to do at LISA (hint: Red Hat events, Fedora events) but if you want to get out and meet some of the local DevOps type folks who might not be at LISA, you might want to check out the DevOpsDC meetup on Tuesday night:
Introduction to Ansible with Michael DeHaan
Ansible is a radically simple IT orchestration engine that makes your applications and systems easier to deploy. Avoid writing scripts or custom code to deploy and update your applications— automate in a language that approaches plain English, using SSH, with no agents to install on remote systems.
Right now the group has 35 slots available, and I suspect as LISA gets closer they’re going to fill up quick. If you’re going to be in town, sign up and learn about Ansible. (And say “hi,” if you see me at the event – looking forward to meeting new DevOps folks!)
One of the best system administrator conferences around, hands-down, is USENIX LISA. Also, one of the longest-running admin-oriented conferences to boot. I’ve been going to LISA since 1999 or 2000 (off and on) and I’ve always enjoyed the talks, the hallway track, and the general atmosphere at the event.
If you’re going to be attending LISA next week, in lovely Washington D.C., you’ll not want to miss the Fedora booth on Wednesday and Thursday. Note that you can score tickets to the exhibit hall even if you’re not attending the full conference. Sign up for those on the USENIX LISA website:
The hours are:
- Wednesday: Noon to 7:00 p.m.
- Thursday: 10:00 a.m. to 2:00 p.m.
You’ll notice that’s not a huge amount of exhibition hall time, but more than enough to drop by and talk shop with fellow Fedorans.
Also, we have a Birds of a Feather on Wednesday from 7:30 to 8:30 and that will include snacks and drinks. Don’t miss that one, it’ll be a great opportunity to talk about what’s going on in Fedora, what’s coming in the next release, and plans for Fedora 21 and beyond.
Doing much work in the cloud? If so, I’d encourage you to take a few minutes to spin up the latest beta test candidate cloud image for Fedora 20. (This is not the final beta release, this is a candidate for the beta release that’s coming shortly.)
You can grab the images for x86_64 or i386. If you’re using Amazon Web Services (AWS) it’s even easier, as all you need to do is use the AMI IDs:
ami-e7a1f38e : us-east-1 image for x86_64
ami-6ba6f402 : us-east-1 image for i386
See Matthew Miller’s note to the Fedora Cloud mailing list for more info on the test cases and the changes to
cloud-init for this release.
Note that I spun these up as well and didn’t run into any real issues. The more the merrier, though!
Please excuse the garbled proverb, I don’t mean to say that people in Rome shouldn’t use GitHub. Instead, I’m talking about using the right tool for the job and the community. Sometimes the “right” tool is completely wrong, because the audience is wrong for the tool.
Collaboration works well when you use the right tools. For developers, that’s often git and GitHub. Wanna work on some code? Throw it up on GitHub. Check out the code, make your changes, and commit. Most developers working in open source today are likely to know git well enough to work with you. (Note that I’m using “GitHub” as shorthand for any git repository/service, really.)
At the edges of developer communities, though, there’s a temptation to use developer tools for non-development work. For example, creating marketing materials and documentation.
For some documentation projects, git is probably the right tool. Especially if you’re doing books and trying to document along with a release cycle. But for creating marketing materials or “living” documents that change a lot? Probably not such a great idea.
Use the tools that are lightweight and easy for anyone to work with, preferably something browser-based and that allows revision control. (e.g., a wiki.) While there are flaws with those tools, they’re “good enough” and – most importantly – they pass the “native” test for people who are contributing to non-code projects. Do they have a browser? Check. Can they figure out how to use the wiki in 5 minutes? Check. Do they need to create an account with a third party service or download a tool they wouldn’t otherwise need? Nope. All good.
Resist the urge to impose your favorite tools on an unsuitable audience. It’s always tempting to go with what you know best or optimize for your own use case, but resist the urge when it’s going to be detrimental to getting maximum participation and building community.