Seven years ago I put on a Red Hat. I had been a part of the
community for a few years prior to that as well, first as a newbie in
#redhat looking for help, later as somebody providing help to others,
then as an early cabal member in the newly formed Fedora project, later
as a leader of Fedora Legacy. Along the way I've made some very strong
friendships that I hope will continue.
This is my last week as a Red Hatter.
I'd like to think that the Fedora project is a better place now than when I joined. I hope my time here has made a positive difference. My new role will leave me with less time to participate directly in Fedora, although I will likely continue maintaining a few packages here and there for my personal use.
I do plan on being at FUDCon in January, I hope to see many of you there.
I'll likely be shutting down this particular blog this week, but a new one will start and I'll link to it from here if you really like me and wish to keep tabs on what I'm doing :)
Monday, November 26, 2012
Friday, October 12, 2012
Text Mode for Fedora 18
Anaconda has been through a pretty major UI rewrite. Anybody that has tried either Fedora 18 Alpha or any of the nightly images since then should be well aware of this.
The UI rewrite was done for many reasons and accomplishes many goals. I'm not going to rehash that here. What I am going to talk about is what happened to text mode.
Text mode in F17 and before was ncurses based. This gave some kind of pretty UI to do things. There were drawbacks though. ncurses didn't work on all the terminals people throw at Anaconda, in particular dumb serial terminals and x3270, the terminal for s390x. Because of that we also had a (non-interactive) very simple display mode called 'cmdline'. This just did simple line printing of progress during a kickstart. Unfortunately due to the way the old UI was coded there wasn't a good complete separation of presentation from computation so many things were written 3 times. Once for gui, once for text, and once for cmdline. Fun right?
With Fedora 18 there is one text UI. It is used on full featured consoles as well as dumb ones. It doesn't use ncurses, it just uses simple line printing. It can be used over serial (interactively!) and over x3270 (non-interactively). It is a simple question and answer prompt.
The design of text mode for F18 and beyond is closely modelled after the design of the GUI for F18 and beyond. A hub and a set of spokes, so that users can do tasks in whatever order they wish, potentially while things happen in the background. There is a main setup hub where the user can set a time zone, set a root password, and do some basic storage configuration (pick target disks and a strategy to clear space on those disks). Once all tasks are complete the user can progress into the actual installation where we just throw up a running list of tasks the backend is accomplishing.
There are very few things you can do with text mode in Fedora 18. You cannot pick languages, and you cannot pick installation source. These can be provided via boot time arguments. You also cannot do advanced storage configuration which would need a kickstart file to accomplish via "text mode". We are planning to add some functionality for Fedora 19, but we haven't decided which items and how rich those items will be. Text mode is still de-emphasized in favor of direct GUI or remote GUI by way of VNC. For kickstarts however text mode is still pretty great. The minimal UI does not prevent a fully customized kickstart from being executed.
Give text mode a spin! It's simple, fast, unobtrusive, and gets the job done.
The UI rewrite was done for many reasons and accomplishes many goals. I'm not going to rehash that here. What I am going to talk about is what happened to text mode.
Text mode in F17 and before was ncurses based. This gave some kind of pretty UI to do things. There were drawbacks though. ncurses didn't work on all the terminals people throw at Anaconda, in particular dumb serial terminals and x3270, the terminal for s390x. Because of that we also had a (non-interactive) very simple display mode called 'cmdline'. This just did simple line printing of progress during a kickstart. Unfortunately due to the way the old UI was coded there wasn't a good complete separation of presentation from computation so many things were written 3 times. Once for gui, once for text, and once for cmdline. Fun right?
With Fedora 18 there is one text UI. It is used on full featured consoles as well as dumb ones. It doesn't use ncurses, it just uses simple line printing. It can be used over serial (interactively!) and over x3270 (non-interactively). It is a simple question and answer prompt.
The design of text mode for F18 and beyond is closely modelled after the design of the GUI for F18 and beyond. A hub and a set of spokes, so that users can do tasks in whatever order they wish, potentially while things happen in the background. There is a main setup hub where the user can set a time zone, set a root password, and do some basic storage configuration (pick target disks and a strategy to clear space on those disks). Once all tasks are complete the user can progress into the actual installation where we just throw up a running list of tasks the backend is accomplishing.
There are very few things you can do with text mode in Fedora 18. You cannot pick languages, and you cannot pick installation source. These can be provided via boot time arguments. You also cannot do advanced storage configuration which would need a kickstart file to accomplish via "text mode". We are planning to add some functionality for Fedora 19, but we haven't decided which items and how rich those items will be. Text mode is still de-emphasized in favor of direct GUI or remote GUI by way of VNC. For kickstarts however text mode is still pretty great. The minimal UI does not prevent a fully customized kickstart from being executed.
Give text mode a spin! It's simple, fast, unobtrusive, and gets the job done.
Thursday, October 11, 2012
Just in case you were wondering...
I've just made the Fedora 18 installer work well on s390x again. You know, for the 10s of you out there that care.
You're welcome.
You're welcome.
Root password in Fedora 18
As part of the Anaconda UI redesign, we had hoped to offload root password setting to the installed host. We had envisioned a scenario where the installer locked the root account and post-install software such as Firstboot or Gnome Initial Experience would take care of adding a user to the system and marking that user as a "super" user. This would obviate the need for a root password, as the super user could use sudo to accomplish admin tasks.
That's how things looked prior to Fedora 18 Alpha, but in testing it became apparent that we couldn't always count on Firstboot or GIE to set things up right, or even be present.
This was particularly true of text mode, where the only packages installed was the bare minimal set. So first text mode grew a password spoke, and we made it mandatory.
Then I wrote a password spoke for GUI mode which lived in the main setup hub. For Alpha this was an optional spoke and it defaulted to a locked root account. Some thought was put into flipping the optional vs mandatory state based on install data, such as whether or not Firstboot was selected for install. Part of being able to do that was moving the spoke from the main setup hub to the install (or configuration) hub. If it lives in this hub we should have finalized data about what packages were selected for install. However doubts arose as to whether "part of the payload" was enough data to ensure that Firstboot or GIE actually ran and we were worried we could still lead users into being locked out of their freshly installed system.
So, for Beta, I've just pushed a set of changes that will make the password spoke a mandatory spoke. You must visit the spoke before you can complete the install. You can still mark the root account as disabled, just by leaving the password fields blank, but you do so at your own risk. This configuration is likely to remain for Fedora 18.
That's how things looked prior to Fedora 18 Alpha, but in testing it became apparent that we couldn't always count on Firstboot or GIE to set things up right, or even be present.
This was particularly true of text mode, where the only packages installed was the bare minimal set. So first text mode grew a password spoke, and we made it mandatory.
Then I wrote a password spoke for GUI mode which lived in the main setup hub. For Alpha this was an optional spoke and it defaulted to a locked root account. Some thought was put into flipping the optional vs mandatory state based on install data, such as whether or not Firstboot was selected for install. Part of being able to do that was moving the spoke from the main setup hub to the install (or configuration) hub. If it lives in this hub we should have finalized data about what packages were selected for install. However doubts arose as to whether "part of the payload" was enough data to ensure that Firstboot or GIE actually ran and we were worried we could still lead users into being locked out of their freshly installed system.
So, for Beta, I've just pushed a set of changes that will make the password spoke a mandatory spoke. You must visit the spoke before you can complete the install. You can still mark the root account as disabled, just by leaving the password fields blank, but you do so at your own risk. This configuration is likely to remain for Fedora 18.
Thursday, June 7, 2012
11 files changed, 87 insertions(+), 97 deletions(-)
I've just posted my largest change to the installer code base yet. This pile of changes moves some functionality out of the installer itself and into the pre-exec environment of dracut and systemd.
For a while now, anaconda has had the ability to fire up an sshd server in the install environment. It's useful to be able to ssh into the system as it's being installed and poke around on the shell. Doubly useful when doing remote installs of headless systems. Required for doing installs on systems that have crap for a (remote) console like s390x.
Anaconda had 2 ways of bringing up sshd, on s390x a replacement for /sbin/init would get ran and bring up the sshd server automatically. But on other arches it was up to anaconda itself to bring up the ssh server, if the "sshd" boot option was encountered. Along with the sshd boot argument there was a kickstart argument "sshpw" that would get handled to set a password for the user(s) who could log in via ssh. Of course, s390x couldn't make use of this because sshd was started prior to anaconda, and in fact, anaconda wouldn't start until somebody ssh'd in as the "install" user. Hurray for differences!
Now that we've got systemd bringing things up and anaconda isn't "init" any more , it's just a service and target, we can do some fun things. We can create our own anaconda-sshd.service to go along with our own sshd config specific to anaconda. We can use a systemd generator to look for "inst.sshd" boot argument (all anaconda boot args were renamed to start with inst. in F17) or s390x arch and if found make the anaconda-sshd.service be a part of the anaconda.target. The anaconda-sshd.service makes use of an ExecStartPre script to parse the "sshpw" kickstart line (if it exists) and setup users/passwords accordingly, before sshd itself is brought up.
This accomplishes a few goals:
For a while now, anaconda has had the ability to fire up an sshd server in the install environment. It's useful to be able to ssh into the system as it's being installed and poke around on the shell. Doubly useful when doing remote installs of headless systems. Required for doing installs on systems that have crap for a (remote) console like s390x.
Anaconda had 2 ways of bringing up sshd, on s390x a replacement for /sbin/init would get ran and bring up the sshd server automatically. But on other arches it was up to anaconda itself to bring up the ssh server, if the "sshd" boot option was encountered. Along with the sshd boot argument there was a kickstart argument "sshpw" that would get handled to set a password for the user(s) who could log in via ssh. Of course, s390x couldn't make use of this because sshd was started prior to anaconda, and in fact, anaconda wouldn't start until somebody ssh'd in as the "install" user. Hurray for differences!
Now that we've got systemd bringing things up and anaconda isn't "init" any more , it's just a service and target, we can do some fun things. We can create our own anaconda-sshd.service to go along with our own sshd config specific to anaconda. We can use a systemd generator to look for "inst.sshd" boot argument (all anaconda boot args were renamed to start with inst. in F17) or s390x arch and if found make the anaconda-sshd.service be a part of the anaconda.target. The anaconda-sshd.service makes use of an ExecStartPre script to parse the "sshpw" kickstart line (if it exists) and setup users/passwords accordingly, before sshd itself is brought up.
This accomplishes a few goals:
- ssh bring up is the same on s390x vs other arches
- passwords are configurable for s390x just like other arches
- anaconda code doesn't have to deal with service bring up
- gets us closer to s390x bring up without having to replace init
- results in net-negative code in the repository
Wednesday, May 30, 2012
Using Thunderbird Efficiently
I get a lot of email. Some of it I even respond to. A lot of it I would like to respond to it, or follow up on it in some way at some point in time, just not immediately. I don't have all of my email being dumped into a single folder, and I use multiple email accounts too. What do I do?
I needed a setup that would allow me to:
Tags kinda work, but an IMAP server might not support them, and thus you wouldn't be able to share tags across clients. The next option is marking a message as "Starred".
A star seems to be well supported by IMAP servers, and across the clients I was playing with. This solves the "Mark messages for follow up" problem. Thunderbird conveniently has a keyboard short cut, 's', to toggle a message's starred state.
The next requirement was getting a quick look at the things I needed to follow up on. Thunderbird can search your messages, and you can include the starred state in the query. Further, you can save your search as a folder for convenient access. See this article for how to setup a saved search. I'll spare you the details here.
Now that I've got a folder I can click on to see what needs to be followed up on, I need to get context for those messages. Right now I'm just looking at a flat list of starred messages, no thread details. Enter a lovely feature: "Open in Conversation".
This is an extremely useful feature for me. Not only will it open up a new tab (which is awesome by the way), it'll populate that tab with a threaded view of all the mails related to that starred mail. All the mails. That includes my own replies.
In a multi-pronged thread with multiple participants, one can quickly lose context as to what's been replied to and what hasn't. Being able to see my own replies intermixed with the rest of the thread is pretty awesome.
Now, if you're following along at home and have noticed that your "Open in Conversation" menu entry is greyed out, fear not! This feature depends on the "Global Search and Indexer" being enabled.
If this isn't enabled, enabling it will spike your CPU for a bit as TB gathers information about all your mail. After that initial hit, I haven't noticed any performance overhead.
--
So that's how I stay on top of my email. It keeps me efficient, and lessens the likelihood of something falling through the cracks. A friend who's been a TB user for years wasn't aware of this feature and after describing it to him I realized other people might not be aware, so here ya go!
Happy Emailing!
I needed a setup that would allow me to:
- Mark messages in a way to follow up later
- Get a quick look at all the messages I've marked for follow up
- Have that quick look work across multiple folders/accounts
- Be able to get context for the message, including my replies
 | ||
| Tags |
 |
| Star me! |
The next requirement was getting a quick look at the things I needed to follow up on. Thunderbird can search your messages, and you can include the starred state in the query. Further, you can save your search as a folder for convenient access. See this article for how to setup a saved search. I'll spare you the details here.
Now that I've got a folder I can click on to see what needs to be followed up on, I need to get context for those messages. Right now I'm just looking at a flat list of starred messages, no thread details. Enter a lovely feature: "Open in Conversation".
 |
| These conversations kill |
 |
| See you in Hell! |
Now, if you're following along at home and have noticed that your "Open in Conversation" menu entry is greyed out, fear not! This feature depends on the "Global Search and Indexer" being enabled.
 |
| My name is Gloda |
--
So that's how I stay on top of my email. It keeps me efficient, and lessens the likelihood of something falling through the cracks. A friend who's been a TB user for years wasn't aware of this feature and after describing it to him I realized other people might not be aware, so here ya go!
Happy Emailing!
Tuesday, May 22, 2012
Well I've been waiting for this moment for all my life...
I can feel it coming in the Air tonight...
Excuse me a moment whilst I rock out to a killer electronic drum riff.
still there? Ok.
I've had a Macbook Air for a while now, not the original air, but the first redesign of it (sadly just before they did another redesign with a better chipset and backlit keyboard, oh well). When I first got it, I went a little crazy, and setup a triple boot system, OS X, Windows (Vista), and Fedora. Sadly, Fedora didn't work so hot. There were graphics issues, sound issues, touchpad issues, wireless issues, I mean, I think the issues had issues.
So instead of fighting all those issues, I did something even more silly. I found a virt software set in OSX that would allow me to attach a real partition to the guest. I setup a virtual disk image to do a minimal install of Fedora in, then edited the grub config so that it would actually load up the real disk partition as /. This actually worked, surprisingly well. I spent most the time in OSX with various X11 applications ran through ssh, and of course ssh'd into the guest to do all my command line work. It still felt dirty though. I would also let the guest boot up into graphical mode and make that go full screen in OSX Lion, which gave the illusion of using Linux native on the hardware. The upside was that the touchpad worked pretty well, and there weren't network issues. Video still sucked, no gnome-shell for me.
When I picked out the Air, I was thinking that it would be nice to have some hardware that was not the normal around the water cooler, so that we had a broader set of systems being used every day. I actually thought I could do something to fix issues that came up. Ha, hah. Turns out the most useful thing I could do was hand the system off to people who knew what they were doing.
Enter Super Hero mjg who decided (or got tasked with, I'm not sure which) that making Fedora work on Apple hardware like my Air was a thing he would do. And he sure did!
That's the Fedora 17 Final (RC3) Desktop Live image being installed to my Air. It couldn't have been easier. dd the iso to a USB stick, boot holding down option, plug in the stick (because I forgot to do that first) and pick the Fedora Media. Anaconda did all the right things (even when I didn't) and I now have a simple dual booting macbook.
F17 looks awesome. First time I've really used shell, and I like it. Audio works, graphics work, webcam works, touch pad (mostly) works, even the brightness and volume buttons work. I can't wait to haul it down to my local Starbucks on my bike, then show it off to my hipster friends, because you see, I was using Fedora on my Air before it was cool.
Well I've been waiting for this moment for all my life....
Excuse me a moment whilst I rock out to a killer electronic drum riff.
still there? Ok.
I've had a Macbook Air for a while now, not the original air, but the first redesign of it (sadly just before they did another redesign with a better chipset and backlit keyboard, oh well). When I first got it, I went a little crazy, and setup a triple boot system, OS X, Windows (Vista), and Fedora. Sadly, Fedora didn't work so hot. There were graphics issues, sound issues, touchpad issues, wireless issues, I mean, I think the issues had issues.
So instead of fighting all those issues, I did something even more silly. I found a virt software set in OSX that would allow me to attach a real partition to the guest. I setup a virtual disk image to do a minimal install of Fedora in, then edited the grub config so that it would actually load up the real disk partition as /. This actually worked, surprisingly well. I spent most the time in OSX with various X11 applications ran through ssh, and of course ssh'd into the guest to do all my command line work. It still felt dirty though. I would also let the guest boot up into graphical mode and make that go full screen in OSX Lion, which gave the illusion of using Linux native on the hardware. The upside was that the touchpad worked pretty well, and there weren't network issues. Video still sucked, no gnome-shell for me.
When I picked out the Air, I was thinking that it would be nice to have some hardware that was not the normal around the water cooler, so that we had a broader set of systems being used every day. I actually thought I could do something to fix issues that came up. Ha, hah. Turns out the most useful thing I could do was hand the system off to people who knew what they were doing.
Enter Super Hero mjg who decided (or got tasked with, I'm not sure which) that making Fedora work on Apple hardware like my Air was a thing he would do. And he sure did!
 |
| So you can wipe off that grin, I know where you've been |
That's the Fedora 17 Final (RC3) Desktop Live image being installed to my Air. It couldn't have been easier. dd the iso to a USB stick, boot holding down option, plug in the stick (because I forgot to do that first) and pick the Fedora Media. Anaconda did all the right things (even when I didn't) and I now have a simple dual booting macbook.
F17 looks awesome. First time I've really used shell, and I like it. Audio works, graphics work, webcam works, touch pad (mostly) works, even the brightness and volume buttons work. I can't wait to haul it down to my local Starbucks on my bike, then show it off to my hipster friends, because you see, I was using Fedora on my Air before it was cool.
Well I've been waiting for this moment for all my life....
Monday, May 21, 2012
It's a Brand New World!
It has been a few years since I was last heavily interested in how Anaconda did it's things. Having recently gotten back into it for my new role, it's kinda cool to see how much has changed.
Composing images:
buildinstall is out, lorax is in
mkintrd is out, dracut is in
Booting the installer
Loader is out, dracut is in
sysvinit/upstart is out, systemd is in
Installer Itself
Too much really to list here, I'm still trying to get a grip on it, and it's all changing again!
So I've had a fun few weeks getting used to the new way of doing things, stumbling around, mumbling about "In my day!" and waiving my cane. The reality is that these are all really cool improvements, and it's made working on changes quite a lot easier to manage. I don't like that feeling that the world has moved on while I wasn't looking, but then again, that's OK, that's what the world should do. I just get to be that New Guy again for a bit.
Composing images:
buildinstall is out, lorax is in
mkintrd is out, dracut is in
Booting the installer
Loader is out, dracut is in
sysvinit/upstart is out, systemd is in
Installer Itself
Too much really to list here, I'm still trying to get a grip on it, and it's all changing again!
So I've had a fun few weeks getting used to the new way of doing things, stumbling around, mumbling about "In my day!" and waiving my cane. The reality is that these are all really cool improvements, and it's made working on changes quite a lot easier to manage. I don't like that feeling that the world has moved on while I wasn't looking, but then again, that's OK, that's what the world should do. I just get to be that New Guy again for a bit.
Wednesday, April 18, 2012
I've seen the Future, and it involves punch cards??
I've now been working for Red Hat for roughly 6.5 years. That's a long time! I started out doing Release Engineering work for our internal Fedora project, somewhere around Fedora Core 5. One of my first tasks was to script a mass rebuild of all our packages for a new compiler and point out to people when their software failed to build. As an eager new employee I spend some time on the weekend sending out build failure reports (by hand) to one of our development mailing lists, and a funny thing happened. The CEO of the company (at the time Matthew Szulik) replied to one of my reports directly to me, saying that he was pleased to see somebody else burning the weekend hours. The C, E, Freaking, O! How cool was that??
Fast forward a release or two and now I'm helping to move Fedora out of Red Hat and into the world at large as a "Community Driven" project. Basically get our sources and build system to where more than just Red Hat employees can touch. This required a lot of careful thought, planning, and political smooth talking but we made it happen. A great group of engineers and managers all saw the greater potential for Fedora if we could just free it from the Mother Ship and worked very hard to convince other people and create software and infrastructure to make it happen. My role changed a bit at that time from just another release engineer to more of a group leader, a group of volunteers who wanted to help out with the tasks related to getting a Fedora release made.
Fast forward again a larger number of releases and we'll get to about 2 years ago. A FUDCon was about to start in "Toronto" CA and a big group of folks were on a chartered bus riding from "Boston" to the FUDCon event. As geeks do when stuck in a small space around other geeks, we talked about geeky things. The geeky thing that had been on my mind for a while now was trying to get Fedora sources moved out of an aging CVS based setup with buildsystem integration by way of various data files and Makefiles onto something a bit more.... modern. Anybody paying any sort of attention to source control systems in the past few years will have noticed a sharp uptick in the adoption of a new source control system called git. We desperately wanted to use git to manage Fedora package sources, and I desperately wanted to use something other than Makefiles to interact with the system and so we spent a good part of that ride throwing ideas around. Certainly not the first time we've done this, but something happened to click on that ride and half a plan was formed. There certainly is something magical about getting a group of people together and then removing a lot of the outside distraction, just to see what kind of awesome can be cooked up.
For the next 2 years or so I worked on first getting Fedora moved into git and replacing Makefiles with a python library and application, followed by doing the same for a much more complicated internal setup at Red Hat for all of Red Hat's products. The work on the latter is now (mostly) done and I had to make a decision. Did I want to keep working on Release Engineering type stuff, as I had for the previous 6.5~ years, or was I ready for something new? I certainly felt ready for something new. There is nothing wrong with releng work, I quite enjoyed it and I really liked the team I worked on, but 6 years is a long time for a geek to be focused on one type of work. So I looked around Red Hat to see if anything else was interesting to me, and I found an opportunity within the Installer team.
The Installer team primarily develops and maintains Anaconda, the software used to install Fedora and Red Hat Enterprise Linux (and it's many rebuilds) onto computers. There is a variety of other software involved, all playing supporting roles, but Anaconda is certainly the star of the show. As of Monday the 16th I've been the newest member on the Installer team.
What I'll be doing there is still being worked out; It depends somewhat on what interests me and what needs are there. Getting to the title of this entry, one of my first tasks is to get up to speed on IBM Z hardware (s390x). The team needs more than one person to have knowledge of how our software (installer and the OS) is brought up on these systems. I learned that even though IBM has been making new Z systems in recent years, they /still/ make use of a stack of virtual punch cards spooled into a virtual reader to allocate resources for an OS to come up. That's right, it's 2012, I'm looking into the future of my work here at Red Hat and I'm learning about punch cards. WAT?
I'll still be involved a bit with source control management for Fedora/RHEL, and may make some new features and fix bugs in the software we use to interact with git and our build systems, at least until we find a new sucker^w engineer to take on those responsibilities. But now instead of writing software that our developers make use of, I'll be writing software that our /customers/ make use of and that's both scary and very exciting!
I hope to blog a bit more often about my Adventures in Installer Land, thoughts and observations that are going to require more than 140 chars. For now, back to the punch cards!
Fast forward a release or two and now I'm helping to move Fedora out of Red Hat and into the world at large as a "Community Driven" project. Basically get our sources and build system to where more than just Red Hat employees can touch. This required a lot of careful thought, planning, and political smooth talking but we made it happen. A great group of engineers and managers all saw the greater potential for Fedora if we could just free it from the Mother Ship and worked very hard to convince other people and create software and infrastructure to make it happen. My role changed a bit at that time from just another release engineer to more of a group leader, a group of volunteers who wanted to help out with the tasks related to getting a Fedora release made.
Fast forward again a larger number of releases and we'll get to about 2 years ago. A FUDCon was about to start in "Toronto" CA and a big group of folks were on a chartered bus riding from "Boston" to the FUDCon event. As geeks do when stuck in a small space around other geeks, we talked about geeky things. The geeky thing that had been on my mind for a while now was trying to get Fedora sources moved out of an aging CVS based setup with buildsystem integration by way of various data files and Makefiles onto something a bit more.... modern. Anybody paying any sort of attention to source control systems in the past few years will have noticed a sharp uptick in the adoption of a new source control system called git. We desperately wanted to use git to manage Fedora package sources, and I desperately wanted to use something other than Makefiles to interact with the system and so we spent a good part of that ride throwing ideas around. Certainly not the first time we've done this, but something happened to click on that ride and half a plan was formed. There certainly is something magical about getting a group of people together and then removing a lot of the outside distraction, just to see what kind of awesome can be cooked up.
For the next 2 years or so I worked on first getting Fedora moved into git and replacing Makefiles with a python library and application, followed by doing the same for a much more complicated internal setup at Red Hat for all of Red Hat's products. The work on the latter is now (mostly) done and I had to make a decision. Did I want to keep working on Release Engineering type stuff, as I had for the previous 6.5~ years, or was I ready for something new? I certainly felt ready for something new. There is nothing wrong with releng work, I quite enjoyed it and I really liked the team I worked on, but 6 years is a long time for a geek to be focused on one type of work. So I looked around Red Hat to see if anything else was interesting to me, and I found an opportunity within the Installer team.
The Installer team primarily develops and maintains Anaconda, the software used to install Fedora and Red Hat Enterprise Linux (and it's many rebuilds) onto computers. There is a variety of other software involved, all playing supporting roles, but Anaconda is certainly the star of the show. As of Monday the 16th I've been the newest member on the Installer team.
What I'll be doing there is still being worked out; It depends somewhat on what interests me and what needs are there. Getting to the title of this entry, one of my first tasks is to get up to speed on IBM Z hardware (s390x). The team needs more than one person to have knowledge of how our software (installer and the OS) is brought up on these systems. I learned that even though IBM has been making new Z systems in recent years, they /still/ make use of a stack of virtual punch cards spooled into a virtual reader to allocate resources for an OS to come up. That's right, it's 2012, I'm looking into the future of my work here at Red Hat and I'm learning about punch cards. WAT?
I'll still be involved a bit with source control management for Fedora/RHEL, and may make some new features and fix bugs in the software we use to interact with git and our build systems, at least until we find a new sucker^w engineer to take on those responsibilities. But now instead of writing software that our developers make use of, I'll be writing software that our /customers/ make use of and that's both scary and very exciting!
I hope to blog a bit more often about my Adventures in Installer Land, thoughts and observations that are going to require more than 140 chars. For now, back to the punch cards!
Subscribe to:
Posts (Atom)