This will happen as soon as I finish my Ansible playbook to get all my current Ubuntu tweaks and dev env setup implemented so I have a repeatable setup and can safely do a fresh install of my desktop as needed with zero manual work.
Dotfiles alone didn't cut it and VPS provisioning frameworks like Ansible are great examples how desktops could be built as well :-)
Feel free to track the progress at https://github.com/ahtik/dotdotbox
I'll try to keep it as universal as possible so it can be shared and tweaked in collaboration.
I've been thinking about setting up an Ansible script, I've never used it before though. How would this work on a new machine? Is it something you run post-OS install? I want to try it out with Arch Linux.
A playbook contains tasks like installing, removing packages, editing config files etc. The beauty of it is that if done correctly you can run the same playbook over and over again against the same computer and each task can be smart enough to know if it needs to be run or not. This makes updating your computer with the same or updated playbook very fast.
With Ubuntu it's easy to get to the post-OS install, it's more involved with Arch Linux. I would first create an Arch box with Vagrant using Virtualbox. And then create a playbook that works with that virtual Arch box. If the box and ansible playbook is good enough then https://wiki.archlinux.org/index.php/Moving_an_existing_inst...
At least in theory, I haven't moved Arch between VM and a real host myself... Of course you can also just do a manual Arch install and then run the playbook but that would miss half the fun of doing less by doing more.
1) Get the right packages (eg: dpkg --get-selections > my-pacakges.list; dpkg --set-selections < my-packages.list). This part ansible can do fine -- but not really any better than your distributions package tool (for this particular use-case)
2) Set up your account (This can be done with kicstart, FAI or preseed.cfg) If you only have one user, this might not be worth automating. This is also a task ansible can handle fine.
3) Set up your preferences/restore your home folder etc.
This is the area that tends to take the most time and care.
Personally I've pretty much stabilized on a very spartan xmonad config (driven from ~/.xsession), and have a mercurial repo with various dot-files that I just clone and symlink to (and I have a bash-script that takes care of setting up the symlinks) -- I also manually set up a python virtualenv (which bin I add to my path), an ~/opt hierarchy managed by xstow (I usually recreate this, as the whole point is to follow upstream, unpackaged software) and a ~/bin folder that's also in a mercurial repo (a few shell scripts for toggling vga/internal displays for my laptop and some similar small utilities).
Now, "manually" symlinking your dot-files probably isn't the best idea -- the main reason I do it this way, is that I've had to manage my profile across different distributions (and for a time also on Solaris) -- and then just keeping home in version control can be a little to simplistic (now with mercurial/git I suppose using named branches for the various machines might be a viable option though -- not sure if I want a check-out command in my .bashrc/.xsession though -- too much can go wrong... eg if git/mercurial for some reason isn't available won't run without errors...).
OTOH, Long Term Support. You shouldn't have to upgrade for awhile if its a pain for you.
11.10 was when I switched over to Mint and never looked back, and it seems that doing so was a wise move, given the Amazon adware/spamware/spyware that Canonical saw fit to include in more recent versions.
http://www.markshuttleworth.com/archives/1182
Even though Mint includes proprietary binaries (like Flash and Audio/Video codecs), which may or may not contain opaque questionable material, at least the third party non-open-source software is something that (arguably) improves the distribution and actually serves a purpose for me, as the end user.
Mint has changed over time too, though, and now I'm thinking about moving to a personally customized Debian image, and a hobbyist project. Hopefully it won't prove to be too demanding to pull off.
What I did was decide to sit down and do an Arch install. Yes it takes time, and yes you have to know what you're doing. But I invested the time up front, and now it runs very reliably, and faster on the same machine.
I say if you want to GSD the best thing to do is set up something like Debian, Arch or Gentoo and invest the time setting it up so you can use it without problems later. I don't know about you but I have better things to do than screw with an OS all time, I have real work to do. These "harder" distros are great for that.
How hard is it to get a custom system up and running from Arch? I haven't done anything like that in a few years although I've had a lot of experience with setting up custom FreeBSD systems. Is it more or less like that?
What I'm reaching for is something that "just works" and that I can work on reliably instead of having to fix obscure problems all the time. I figure once I set something up that works, I can simply create an image of it to use later.
It helps to have a good knowledge of Linux to do it, because you know where things should go and where to look if there is a problem, but it doesnt' require you to become a kernel hacker just to get it to a prompt.
To me, distribution projects like Debian, Arch & Gentoo serve as a useful source for complete repositories of working, interoperable packages, moreso than they serve as a convenient provider of a working operating system.
I tend to chalk up buggy, quirky work-arounds and long waits for bug fixes in Linux as the price I'm willing to pay to be able to see the source, and receive the software for free. Annoying glitches are something I wouldn't tolerate from Apple or Microsoft, if I'm going to shell out for the high price tags placed on their operating systems.
To be fair, Unity in 11.10 was quite broken and slow and resource hungry, but they fixed that in 12.04 and 12.10. I understand if people don't like Unity, but it's been getting faster and better than in the earlier versions. Personally I use cinnamon.
I will be upgrading fairly early; probably at the end of April. I have a big deadline in late April and upgrading Ubuntu will be my reward/punishment. I suppose I will listen for any disgruntled users before I make the plunge, however, and reassess if things look too problematic.
Note: this is for a work machine, but a PC, not a server or something like that.
They decided to delay the spring release in 2006 to june, so it ended up as 6.06 instead of 6.04.
Personally, I'd wait at least 3 months, and follow bug reports before switching.
I think I will upgrade when it is available on Linode.
I am not really that used to build my own packages, but it is something I want to learn. And I didn't know that I could download from another version, I will look into it, thanks ! :)
apt-get build-dep beanstalkd
apt-get source beanstalkd # or in your case, download the newer source-package
cd ./beanstalkd-1.x.x
dpkg-buildpackage -rfakeroot -us -uc
Moving to new LTS right away is often a suicide mission.