On Tuesday morning I awoke to find in my inbox a cryptic message, sent during the wee hours of the morning, from Jeff Hoogland.
Shortly after our interview I made a liar out of myself and got bit by the Bodhi bug again.
The interview, of course, referenced the one published here on FOSS Force on the Monday before last, in which we discussed his leaving Bodhi for greener fields or Python or something. Hoogland finished Tuesday morning’s message with a link to a page on his Thoughts on Technology blog, where he was announcing his return to Bodhi Linux in his original role as project manager and lead developer.
Really? He was going back?
In the FOSS world, this was pretty big news. I got to work writing a story right away, taking time out to dash off a quick message to Hoogland.
I think this is good news, Jeff — as long as you think it’s good news.
I didn’t want to think he’d returned to his old duties under pressure from Bodhi’s user base or from others, because lifestyle decisions made under pressure seldom work out. I was reassured by his almost instant reply.
I think it is 🙂
Of course, I was curious about what had happened to fuel this sudden about-face. During our interview less than two weeks earlier, he’d given no clue that he considered a return to his old position even a possibility.
This prompted yet another message.
Can I ask you a few more questions?
He said “yes.”
What prompted you to return to your old role with the Bodhi project? Perhaps you could talk a bit about the reshuffling that was necessary for you to return.
Not going to lie, talking with you a few weeks ago had me feeling a bit nostalgic about the project. This past weekend was one of my first full weekends at home in the last four months. I sat down to finish cleaning up the Bodhi build scripts and before I knew it I was spinning up some fresh ISO images.
My schedule in the future is looking to be less hectic and I was able to set aside more time in the next six weeks to get things really ironed out for the new release. The new folks are still helping with the project, but I feel I asked too much of them by dumping the responsibility of a new major release on them.
Will you be setting things up so that the next time there needs to be a transition in leadership it’ll go smoothly?
Starting with the 3.1.0 release I plan to get more folks involved with the actual process I go through to build the OS and packages. I also plan to detail the process in full on our new wiki. The maintenance between major releases is fairly minimal compared to a new major release.
Will you be making any kind of changes to how the workflow is handled with Bodhi?
The main thing that is going to change is having more people “in the know” with the different parts of the project. While Bodhi has a variety of people who have contributed to it over the years, we have fallen into the trap of often only having one person who knows their way around specific parts (be it me making the packages/ISOs, or the website, or maintaining the servers). Having more people able to properly execute different tasks will make the project much more resistant to single individuals needing to take time off.
Are you still on track for a 3.0.0 stable release in February?
Yep! The RC2 release has been going over fairly well and the list of things that need to be fixed is minimal at this point. I am very happy with the quality of this pre-release image.
Will there be any surprises in store for users with the 3.0.0 release?
Hardly. I firmly live by the motto of keep things as simple as possible. In a perfect world the only difference an end user would know between their 2.4.0 system and a 3.0.0 system is that it is running on a newer Ubuntu version. Our 2.4.0 release is fast and good at staying out of the user’s way and our goal is to have 3.0.0 do the same.
Users with older systems will enjoy this 3.0.0 release as it will be one of the few Ubuntu 14.04 based releases to include a non-PAE install option, just like our previous major release did.
Christine Hall has been a journalist since 1971. In 2001, she began writing a weekly consumer computer column and started covering Linux and FOSS in 2002 after making the switch to GNU/Linux. Follow her on Twitter: @BrideOfLinux
I need to ask something, triggered by the last paragraph.
If someone with an older system installs the PAE version instead of the non-PAE version what are the pros and cons? A more appropriate question may be when must one install the non-PAE version?
TIA
@Dinos K:
The PAE (Processor Address Extension) kernel requires newer hardware to run. It won’t run on some really old machines, built before PAE was realized. However, you can run non-PAE kernels on newer hardware. Just that you won’t get all the features of a more modern kernel.
PAE allows for 4GB RAM and up, a major limitation of older 32bit systems. It was invented by Intel as a stop-gap measure to stay competative with AMD, who were making 64bit systems. until they came with 64bit themselves. The PAE kernel also supports other modern processor features no in the non-PAE kernel. In particular, SMP (multiple core support) is quite often left out on the non-PAE kernel.
In short, if you have a really old PC, for example; a 386/486 (pre Pentium Pro), you will simply not be able to boot a PAE kernel. So you will have to find a distro that offers a non-PAE-kernel based installer.
Involving other people in the work is a good idea, Jeff. I am a project leader in the educational field. I used to do all the job by myself not trusting others with the various tasks that we have to accomplish. And it was a very tiring job until one day I decided to try and give more responsibility to the rest of the team, and to my surprise they stepped up and showed good maturity. It was such a relief for me, and the quality of the work got better. Just attend to the process of building trust among the team at the beginning, and let it grow slowly.
I can picture The Hoog going “Just when I thought I was out, THEY PULL ME BACK IN.”
(as horrible as III was, its still a great line)