Phew! It's been quite a few months since my last blog, and lots of stuff has happened - I finally got my PhD, so now I can work on KDE without any guilt, and as a result I've gotten my SVN account so that I can wreak some havoc(K)!
From my last blog:
"Anyway, that's all for now - I hope to blog about some non-KDE4Daily-related stuff in the near future :)"
Well, it looks like I suck, but hopefully soon I'll be able to blog about some of the (small amount of) upstream work I've been doing on trying to bring back some of the file management features to Konqueror that went missing during the port to KDE3 to KDE4, and hopefully, eventually, improve on them. Konqui fans - look out for a Konqui4 File Management - State of the Union that I'll be putting together with ppenz within the next month or so!
As for this blog: I've noticed, on IRC and the forums, that many people seem to be having problems getting a KDE development environment set up. Since KDE4Daily releases track the most recent Kubuntu release, and I couldn't be bothered to update my 8.04 Desktop and Laptop to 8.10, this time around KDE4Daily was entirely developed and tested within a self-contained chroot nicknamed, appropriately enough, Khrooty4Daily. It could of course have been performed within a VM, but chroots have a few advantages (and disadvantages) compare to VMs that make it more appropriate for development, IMO: not least, the comparative ease of transferring files to and from the host machine; sharing the hosts RAM; and of course running at native speed which is much more pleasant for compiling and debugging.
Khrooty4Daily offers an easy way to check out and compile KDE sources: all of the cmake stuff is there, the .bashrc macros are present and correct, there's a full and up-to-date KDE install ready to be run, tested and hacked on, and there is a very rich set of package dependencies provided which will allow you to compile pretty much anything from SVN with as many of the optional features as I could satisfy the requirements for. So I was toying with the idea of cleaning and tarring it up and providing it to the community, but since it's going to be a very large blob (probably someone between 1-1.5GB compressed as a rough estimate) that will take me ages to prepare and upload, I thought I'd scope out the level of interest for such a beast. Who thinks they would find this useful? It's not quite as completely insulated and self-contained as a VM, but it still provides a nice way of getting things running on your machine that you can just untar when you begin and rm -rf when you're done.
And also, I appeal to LazyWeb: what are the potential difficulties in providing a chroot environment? Will it work with all x86 distros? Since the root password for all Khrooty4Daily installs is the same and we are going to be mounting /dev/, /sys/ etc onto it, are there any security issues that people need to be aware of? Descriptions of any hitches at all that people have run into with using chroots would be much appreciated as I've only been able to test it in a Kubuntu 8.04 host so far!
Subscribe to:
Post Comments (Atom)
2 comments:
Hey
I for one would find it very useful.
Great idea.
"are there any security issues that people need to be aware of?"
In my limited understanding, the "security issue" with chroot is when people start wrongly believing that from inside chroot you can't do bad things to the host environment, i.e. believing that chroot is a 'jail'.
There you have a very old e-mail:
http://lkml.org/lkml/1996/11/17/9
Quote:
"Just as an example, with the current chroot() behaviour we can do stuff
like this:
- install a new test-gcc in a chroot environment
- compile programs _outside_ the chroot-environment with
change_root /gcc /usr/bin/gcc file.c -o file.o
"
Then for what you are considering doing, the chroot is done on the user's local machine, to which they already have physical access, contrary to your former KDE4Daily solution; so I can't see any security issue.
Post a Comment