On Wed, Jan 5, 2011 at 11:01 AM, Thomas Dziedzic wrote:

...

Hello, ArchLinux Tus

Xyne has agreed to sponsor me as a TU. I am very excited at the potential opportunity to become more directly involved with the development of ArchLinux.

I atteneded Southern Utah University (SUU) where I studied Computer Science. While at SUU I set up one of the first American ArchLinux mirrors, a mirror which is still in operation – locke.suu.edu. At SUU I also worked as a research assistant and developed a (now defunct) Linux distribution based on Arch called Axiom Linux for rediculously parallel compute clusters. It was based on Larch and involved a modified Arch installer, (this was before

...

aif days).

Since then I have worked as a trainer for Red Hat, then a systems software developer for a United States DOD contractor and I am presently employed as a Sr Systems Engineer at Beyond Oblivion.

My contributions to Arch so far have been:

Created and maintained a working puppet package for Arch, and updated the existing puppet pacman code.

Ported libguestfs to Arch, this involved working with the libguestfs developers to create a build port specific to Arch since the build

...

requires the creation of a specialized Arch Qemu Vm image.

Set up MooseFS support for Arch – This is a VERY cool project that I strongly recommend people take a look at : moosefs.org

I have been working on standardizing the Ocaml packages for Arch and currently maintain about 25 Ocaml packages.

I am the author of the Varch Project:

http://code.google.com/p/varch/

My packages and project staging repo is at:

http://code.google.com/p/enterprise-archlinux/

I am working on a project that I hope will greatly benefit Arch called quarters:

http://code.google.com/p/quarters/

It is still sparse, I just started a re architect

And my packages for you to look over:

https://aur.archlinux.org/packages.php?SeB=m&K=thatch45

All in all, I am deeply passionate about open source and Linux, I believe in the pragmatic approach to Linux and have continued to find Arch as one of, if the the, superior Linux distribution out there today, not only in principal, but also in engineering.

My hope is to assist in bringing ArchLinux further into the forefront of

On Wed, Jan 5, 2011 at 11:49 AM, Thomas S Hatch wrote: the process the

...

overall Linux community and to continue to port enterprise grade software to Arch.

Hopefully my current contributions suffice to allow me to work as a TU, if there is anything in my contributions or packages that needs improvement, or if there is anything else I can do to improve my standing, please let me know so I can make my application as spotless as possible.

-thatch45

-Thomas S Hatch

quarters seems like an interesting project. Also, can you give examples of enterprise grade software you would bring into [community], are you talking about the packages you currently maintain? Overall awesome, and +1 from me once you answer my question =)

At this point yes, mostly things like puppet and libguestfs (of course puppet still relies on ruby 1.8, so that will have to wait a bit still). One of my goals is really to bring more automation and virtualization support to Arch. Also to bring in things like func and certmaster, and to package more automation systems than just puppet. I also want to bring a number of technologies used by Red Hat to Arch, and by technologies I mean more along the lines of copying things that we know have worked for other distros. This would involve the quarters project and varch of course (so koji for redhat == quarters for Arch; thincrust for redhat == varch for Arch). but also get a number of the fedorahosted projects that could benefit Arch ported over (I still need to query which ones to bring over). That, and anything I can come up with that would benefit Arch of course :)

On Wed, Jan 5, 2011 at 11:45 AM, Thomas Dziedzic wrote:

...

On Wed, Jan 5, 2011 at 11:01 AM, Thomas Dziedzic wrote:

...

On Wed, Jan 5, 2011 at 11:49 AM, Thomas S Hatch wrote:

...

Hello, ArchLinux Tus

Xyne has agreed to sponsor me as a TU. I am very excited at the

...

...

...

opportunity to become more directly involved with the development of ArchLinux.

I atteneded Southern Utah University (SUU) where I studied Computer Science. While at SUU I set up one of the first American ArchLinux mirrors, a mirror which is still in operation – locke.suu.edu. At SUU I also worked as a research assistant and developed a (now defunct) Linux distribution

...

...

...

Arch called Axiom Linux for rediculously parallel compute clusters. It was based on Larch and involved a modified Arch installer, (this was before

on the

...

aif days).

Since then I have worked as a trainer for Red Hat, then a systems software developer for a United States DOD contractor and I am presently employed as a Sr Systems Engineer at Beyond Oblivion.

My contributions to Arch so far have been:

Created and maintained a working puppet package for Arch, and updated

On Wed, Jan 5, 2011 at 12:10 PM, Thomas S Hatch wrote: potential based the

...

...

...

existing puppet pacman code.

Ported libguestfs to Arch, this involved working with the libguestfs developers to create a build port specific to Arch since the build process requires the creation of a specialized Arch Qemu Vm image.

Set up MooseFS support for Arch – This is a VERY cool project that I strongly recommend people take a look at : moosefs.org

I have been working on standardizing the Ocaml packages for Arch and currently maintain about 25 Ocaml packages.

I am the author of the Varch Project:

http://code.google.com/p/varch/

My packages and project staging repo is at:

http://code.google.com/p/enterprise-archlinux/

I am working on a project that I hope will greatly benefit Arch called quarters:

http://code.google.com/p/quarters/

It is still sparse, I just started a re architect

And my packages for you to look over:

https://aur.archlinux.org/packages.php?SeB=m&K=thatch45

All in all, I am deeply passionate about open source and Linux, I believe in the pragmatic approach to Linux and have continued to find Arch as one of, if the the, superior Linux distribution out there today, not only in principal, but also in engineering.

My hope is to assist in bringing ArchLinux further into the forefront of the overall Linux community and to continue to port enterprise grade software to Arch.

Hopefully my current contributions suffice to allow me to work as a TU, if there is anything in my contributions or packages that needs improvement, or if there is anything else I can do to improve my standing, please let me know so I can make my application as spotless as possible.

-thatch45

-Thomas S Hatch

quarters seems like an interesting project. Also, can you give examples of enterprise grade software you would bring into [community], are you talking about the packages you currently maintain? Overall awesome, and +1 from me once you answer my question =)

At this point yes, mostly things like puppet and libguestfs (of course puppet still relies on ruby 1.8, so that will have to wait a bit still). One of my goals is really to bring more automation and virtualization support to Arch.

Also to bring in things like func and certmaster, and to package more automation systems than just puppet.

I also want to bring a number of technologies used by Red Hat to Arch, and by technologies I mean more along the lines of copying things that we know have worked for other distros. This would involve the quarters project and varch of course (so koji for redhat == quarters for Arch; thincrust for redhat == varch for Arch). but also get a number of the fedorahosted projects that could benefit Arch ported over (I still need to query which ones to bring over).

That, and anything I can come up with that would benefit Arch of course :)

Ok, but do keep in mind to bring in packages with over 10 votes, otherwise +1 from me :)

Of course! I have no intention of just dumping a bunch of packages into community that don't have the votes! Thanks for the +1!

On Wed, Jan 5, 2011 at 11:10 AM, Kaiting Chen wrote:

On Wed, Jan 5, 2011 at 12:49 PM, Thomas S Hatch wrote:

...

I am working on a project that I hope will greatly benefit Arch called quarters:

http://code.google.com/p/quarters/

It is still sparse, I just started a re architect

Hi dude I took a very *quick* look at your project. It looks like most of your build logic can be replace with just `extra-$arch-build`. Are you planning on leveraging more of 'devtools' for your re-architecture? --Kaiting.

-- Kiwis and Limes: http://kaitocracy.blogspot.com/

Oh yes! When I started the first time I was not as aware of the available dev tools, it is one of the big motivations for the rearchitect! Besides, you never get software right the first time anyway :)

2011/1/5 Cédric Girard

On Wed, Jan 5, 2011 at 6:49 PM, Thomas S Hatch wrote:

...

Set up MooseFS support for Arch – This is a VERY cool project that I strongly recommend people take a look at : moosefs.org

Thanks for speaking about this. I was looking for something able to do exactly what MooseFS does.

Good luck with you application !

-- Cédric Girard

If you have any questions about MooseFS feel free to ask me, it has been an amazing application for my company!

On Wed, Jan 5, 2011 at 12:05 PM, Kaiting Chen wrote:

On Wed, Jan 5, 2011 at 1:55 PM, Thomas S Hatch wrote:

...

If you have any questions about MooseFS feel free to ask me, it has been an amazing application for my company!

I'm about to do some minor hijacking of your application thread. How does MooseFS compare with Lustre? --Kaiting.

-- Kiwis and Limes: http://kaitocracy.blogspot.com/

Hijack away, as long as I get the vote :) So the big difference with MooseFS is that it will run on commodity hardware and can be set up by a monkey. So you don't need hardware HPC equipment, just a bunch of computers with hard drives. This means it can scale and works well for both small and very large deployments. I set it up to test it on just a couple of virtual machines and it ran like a dream, and it also runs like a dream on my company's 165 TB setup supporting over 12 million files. There are a lot of other differences, but all in all, MooseFS is much MUCH more KISS than Lustre, effectively delivers the same product, is very fast for a distributed file system and is a snap to set up! Grab a couple of machines and try it out!

On Wed, Jan 5, 2011 at 12:37 PM, Kaiting Chen wrote:

On Wed, Jan 5, 2011 at 2:11 PM, Thomas S Hatch wrote:

...

Hijack away, as long as I get the vote :)

So the big difference with MooseFS is that it will run on commodity hardware and can be set up by a monkey. So you don't need hardware HPC equipment, just a bunch of computers with hard drives. This means it can scale and works well for both small and very large deployments. I set it up to test it on just a couple of virtual machines and it ran like a dream, and it also runs like a dream on my company's 165 TB setup supporting over 12 million files.

There are a lot of other differences, but all in all, MooseFS is much MUCH more KISS than Lustre, effectively delivers the same product, is very fast for a distributed file system and is a snap to set up! Grab a couple of machines and try it out!

Oh God it's FUSE. One more question then, how does it compare with GlusterFS? Which is also easy to set up, runs on FUSE, and can use commodity hardware. Thanks, --Kaiting.

-- Kiwis and Limes: http://kaitocracy.blogspot.com/

The difference is that Gluster is a nightmare! The problem with gluster is that the replication is tiered, and that there is no metadata. The client is then the master, this means that if you connect to gluster with a mis-configured client you can have large scale data corruption. Next since the replication of data is tiered you don't have true replication, so only the gluster server you connect to to save the data has the correct data, if that server goes down the replications are old and you have data corruption. The gluster devs actually had to recall gluster 3.1 because the data corruption was rampant. The difference between gluster and MooseFS is that MooseFS works! MooseFS also has a cool web frontend :) We were using gluster and the business cost became catastrophic, picking up the peices was a nightmare. MooseFS saves data to replication nodes in paralell! MooseFS maintains a master metalogger so client connections are agnostic. MooseFS maintains metadata replication so you can restore is something happens to the master. I take it you don't like FUSE? EVERYBODY is doing it ;) I am looking forward to Ceph, which does not require fuse, but I don't think it is going to be production ready for at least a year, and MooseFS easily compete with Ceph IMHO. If there are GlusterFS devs in the room, please disregard the previous rant :) -Tom

On Wed, Jan 5, 2011 at 1:35 PM, Kaiting Chen wrote:

On Wed, Jan 5, 2011 at 2:50 PM, Thomas S Hatch wrote:

...

The difference is that Gluster is a nightmare!

The problem with gluster is that the replication is tiered, and that there is no metadata. The client is then the master, this means that if you connect to gluster with a mis-configured client you can have large scale data corruption.

Next since the replication of data is tiered you don't have true replication, so only the gluster server you connect to to save the data has the correct data, if that server goes down the replications are old and you have data corruption.

The gluster devs actually had to recall gluster 3.1 because the data corruption was rampant.

The difference between gluster and MooseFS is that MooseFS works!

MooseFS also has a cool web frontend :)

We were using gluster and the business cost became catastrophic, picking up the peices was a nightmare.

MooseFS saves data to replication nodes in paralell! MooseFS maintains a master metalogger so client connections are agnostic. MooseFS maintains metadata replication so you can restore is something happens to the master.

I take it you don't like FUSE? EVERYBODY is doing it ;)

I am looking forward to Ceph, which does not require fuse, but I don't think it is going to be production ready for at least a year, and MooseFS easily compete with Ceph IMHO.

If there are GlusterFS devs in the room, please disregard the previous rant :)

Thanks for the very thorough answer. And yes I hate the idea of a filesystem in userspace. Everyone knows the FS's should be in kernel space! Mostly it's the fact that in my opinion bypassing the kernel's caching mechanism is entirely impractical for a high performance FS. Feel free to correct me if I'm wrong.

Anyways your application looks really good. Good luck! --Kaiting.

-- Kiwis and Limes: http://kaitocracy.blogspot.com/

Thanks Kaiting! I was looking back at my post and worrying that it was too much of a rant :) I spend a month full time testing and trying distributed filesystems and my conclusion was that MooseFS is the best one out there. I agree that fuse is something that should be used with caution, and that a filesystem does belong in kernel space. But in the situation of a distributed filesystem I thought that the benefits of fuse in allowing for higher flexibility made it a permissible option. All in all I think that fuse for network filesystems can be a huge advantage, on the other hand I am much more cautious about local filesystems that operate behind fuse. So to sum it up, I feel good with moosefs, sshfs, but am cautious when looking at things like zfs-fuse. But with that said, I don't believe in disparaging someone's project on the grounds of what it is, the fact that people are creating new things and sharing them is a wonderful thing! On the other hand, I will speak my mind when someone's project corrupts my data :)

On Wed, Jan 5, 2011 at 1:50 PM, Isaac Dupree

wrote:

On 01/05/11 13:55, Thomas S Hatch wrote:

...

If you have any questions about MooseFS feel free to ask me, it has been an amazing application for my company!

While we're asking, any thoughts about Tahoe-LAFS? - distributed, fault-tolerant AND with quite thought-out encryption. http://tahoe-lafs.org/ Googling suggests to me that it doesn't have its own FUSE but it is sometimes combined with sshfs (that's possible since Tahoe-LAFS provides an SFTP interface, among other interfaces).

-Isaac

Ah yes Tahoe, I didn't spend as much time with this one, but it looks promising! In my tests MooseFS was faster and the failure support was a bit better, I would have to really dig into my note to remember exactly what it was that turned me off on it. I remember it being fairly nice though! I will have to play with it some more!

Le 05/01/2011 22:21, Thomas S Hatch a écrit :

Oh, it is lower on my list, but I wanted to make SELinux more powerful in Arch too, I am one of the VERY few who not only know how to handle SELinux, and likes to use it :) You WHAT? You like to use it? You must be a masochist then ;)

I've been working around and on it for 2 years now and I wouldn't use it for any desktop (even though that's what I'm doing at work). Are you using the targeted mode or the strict one (I'm always using the strict mode)?

Le 05/01/2011 22:39, Thomas S Hatch a écrit :

On Wed, Jan 5, 2011 at 2:33 PM, Martin Peres wrote:

...

Le 05/01/2011 22:21, Thomas S Hatch a écrit :

Oh, it is lower on my list, but I wanted to make SELinux more powerful in

...

Arch too, I am one of the VERY few who not only know how to handle SELinux, and likes to use it :)

You WHAT? You like to use it? You must be a masochist then ;)

I've been working around and on it for 2 years now and I wouldn't use it for any desktop (even though that's what I'm doing at work).

Are you using the targeted mode or the strict one (I'm always using the strict mode)? Well of course you have to move in and around it using the strict mode! Do you know who developed that? The NSA, and don't tell them I said anything, but I don't trust those guys :)

Personally, I would not use SELinux on a desktop, I think that SELinux is best suited for machines with static configurations that servers content often to the open internet. So with that said, SELinux is best for DNS servers, Mail servers, routers etc.

And the strict policy is too strict, often it thinks that booting is a security violation!

See what I mean though? Most people don't like it, personally, I do NOT endorse turning it on by default, I think that that is a bit crazy. Oh sure, SELinux is simple on servers ;) My researchs are about dynamicaly loading policy modules according to the current user's task. It works kind of well.

I've written some helpers to generate security policies automatically, it makes you a working policy in less than 4 minutes (for firefox). You're done in a little more than 10 minutes (test & audit). Currently, I'm working on adding a memory access control in SELinux (just for fun, we'll see how it works). I know all of this is crazy, hence the reason I'm kind of fed up with SELinux even though it is really powerful! Anyway, I'm using Gentoo Hardened for my research. The only non-Arch OS I'm using.

Le 05/01/2011 22:54, Thomas S Hatch a écrit :

On Wed, Jan 5, 2011 at 2:51 PM, Martin Peres wrote:

...

Le 05/01/2011 22:39, Thomas S Hatch a écrit :

On Wed, Jan 5, 2011 at 2:33 PM, Martin Peres

...

wrote:

Le 05/01/2011 22:21, Thomas S Hatch a écrit :

...

Oh, it is lower on my list, but I wanted to make SELinux more powerful in

...

Arch too, I am one of the VERY few who not only know how to handle SELinux, and likes to use it :)

You WHAT? You like to use it? You must be a masochist then ;) I've been working around and on it for 2 years now and I wouldn't use it for any desktop (even though that's what I'm doing at work).

Are you using the targeted mode or the strict one (I'm always using the strict mode)?

Well of course you have to move in and around it using the strict mode! Do you know who developed that? The NSA, and don't tell them I said anything, but I don't trust those guys :)

Personally, I would not use SELinux on a desktop, I think that SELinux is best suited for machines with static configurations that servers content often to the open internet. So with that said, SELinux is best for DNS servers, Mail servers, routers etc.

And the strict policy is too strict, often it thinks that booting is a security violation!

See what I mean though? Most people don't like it, personally, I do NOT endorse turning it on by default, I think that that is a bit crazy.

Oh sure, SELinux is simple on servers ;) My researchs are about dynamicaly loading policy modules according to the current user's task. It works kind of well.

I've written some helpers to generate security policies automatically, it makes you a working policy in less than 4 minutes (for firefox). You're done in a little more than 10 minutes (test& audit).

Currently, I'm working on adding a memory access control in SELinux (just for fun, we'll see how it works).

I know all of this is crazy, hence the reason I'm kind of fed up with SELinux even though it is really powerful!

Anyway, I'm using Gentoo Hardened for my research. The only non-Arch OS I'm using.

Wow, this sounds like great stuff! I would love to get my hands on it, this could make policy tuning a walk in the park!

Is this open source? Can I see your code? What is it written in? The automated policy creation is in Python. The other project that detects the user's activity and changes the SELinux modules of an application is written in C/C++/Qt, there are also patches needed for Firefox and claws-mail. The basic idea is defined here: http://mupuf.org/blog/article/39/ (read the article). I've done at least two major rewrites since then to add features and improve the configuration files.

I'll ask my employers (my teachers/researchers I'm working with) if they are ok with open sourcing the python auditer. The other research project will be released for sure but I'm still working on it and it is not ready for a public release yet) There is still a lot of polishing to be done and I still have to write a paper on it to show the problem of automated policy creation and labelling. If you want more info, please send me a mail ;) I'll keep you updated on this! Good luck with your application :) Martin

On Wed, 2011-01-05 at 12:41 -0700, Thomas S Hatch wrote:

Thanks Xyne :)

On Wed, Jan 5, 2011 at 12:40 PM, Xyne wrote:

...

Thomas S Hatch wrote:

...

Hello, ArchLinux Tus

Xyne has agreed to sponsor me as a TU. I am very excited at the potential opportunity to become more directly involved with the development of ArchLinux.

/snip

I have indeed agreed to sponsor Thomas, so here I am sponsoring. :) Let the discussion period begin!

A top-poster! Burn him!

On Wednesday 05 January 2011 19:40:53 Xyne wrote:

Thomas S Hatch wrote:

...

Xyne has agreed to sponsor me as a TU. I am very excited at the potential opportunity to become more directly involved with the development of ArchLinux.

I have indeed agreed to sponsor Thomas, so here I am sponsoring. :) Let the discussion period begin!

We're ready for a vote on this, aren't we? :-D

The voting period for Thomas Hatch's application has begun: https://aur.archlinux.org/tu.php?id=46 Please make your way to the AUR and vote. :)

On Thursday 20 January 2011 15:32:49 Ionuț Bîru wrote:

The results are:

yes 20 no 0 abstain 8

Congratulations Tom! Welcome aboard the good ship TU! Pete.

On Thursday 20 January 2011 17:16:41 Peter Lewis wrote:

Congratulations Tom! Welcome aboard the good ship TU! We was waiting Xyne here, anyway your accounts on AUR/BBS/Flyspray are updated since yesterday ;)

Welcome aboard. -- Andrea

Le jeudi 20 janvier 2011 17:16:41, Peter Lewis a écrit :

On Thursday 20 January 2011 15:32:49 Ionuț Bîru wrote:

...

The results are:

yes 20 no 0 abstain 8

Congratulations Tom! Welcome aboard the good ship TU!

Pete.

Welcome ! ++

On Thu, Jan 20, 2011 at 3:34 PM, Brad Fanella wrote:

On Thu, Jan 20, 2011 at 9:32 AM, Ionuț Bîru wrote:

...

On 01/11/2011 08:24 PM, Xyne wrote:

...

The voting period for Thomas Hatch's application has begun: https://aur.archlinux.org/tu.php?id=46

Please make your way to the AUR and vote. :)

voting period has ended two days ago.

The results are:

yes 20 no 0 abstain 8

Congratulation for our new member. Here is the todo list:

https://wiki.archlinux.org/index.php/AUR_Trusted_User_Guidelines#TODO_list_f...

...

-- Ionuț

Not to sound like a broken record, but congratulations! :-)

Broken records with congratulations are welcome here :) Thanks!