Ideal Situation:

everything under /var/aegir aegir:aegir
files 775
directories 775

drupal files directories are aegir:www-data
drupal files directories are 777
drupal settings.php need to be readable by www-data group

aegir is in the www-data group
www-data is in the www-data group

Therefore, the commands to fix aegir permissions (after adding aegir to www-data group)

cd /var
chown -R aegir:aegir /var/aegir/
chmod -R 775 /var/aegir/
find /var/aegir/ -name files -type d -exec \
 chown -R aegir:www-data {} \;
find /var/aegir/ -name files -type d -exec \
 chmod -R 777 {} \;
find /var/aegir/ -name settings.php -exec \ 
chown -R aegir:www-data {} \;

If you ever write macros for openoffice, you can set background color of cells by setting the BackgroundColor property to an RGB value using the RGB function.

myval = RGB ( R, G, B ) 

R, G, and B are integers from 0-255 for Red, Blue and Green respectively. Any color program can get you those values from any point on your screen.

But what if you use the macro recorder to do part of your script and then you are confronted with a BackgroundColor value like 16765728 for a rich yellow? How would one look at the code and adjust the color?

What the hell is 16765728? It's 8 digits long, so is it hex like #FF33FF but with the last two digits for an alpha transparency value? No, it's not, cause the digits sizes in order seem to bear no relationship to the RGB values for that color (determinined separately as 255 211 32)... Is it some padded decimal to octal conversion or something? No, cause it has 8 in it. ???!! grrr...

So, it turns out to be this...

(R * 2^16) + (G * 2^8 ) + B

i.e. for RGB ( 255, 211 32 )
16765728 = 255 * 2^16 + 211 * 2^8 + 32
16765728 = 16711680 + 54016 + 32

Maybe that is an obvious value storage strategy to datastructure wizards who think that in field delimiters are dangerous, but to me it just makes openoffice basic impenetrable. I'll need a spreadsheet just to calculate how to program my spreasheet. Maybe I can just do integer division in my head, and watch the modulos.

1. Always remember to install guest additions in virtualbox guest before getting upset that folder sharing isn't working....

2. Turn off automatic updates in windows guests until you have manually run windows updates... freaking annoying to have to reboot randomly in between.

If you keep a web development server you may often find yourself installing and moving stuff around as superuser. This results in a lot of directories and areas that are root:root (owned by root, in root group). This can be a problem for web applications, that need their web accessible files and below to be read by the webserver user.

So first you will do something like

chown -R root:www-data yourstartdir

for these webaccessible directories specifically. Replace www-data with the user that your webserver runs as (www-data is the default user for apache2 on debian or ubuntu linux.) Read your security notes for the application first to make sure the application doesn't need a special user scheme to enforce security on their application. Pay attention also to which directories are web accessible (below the web document root). I'll assume you do your homework.

OK, so what was the point of this post? OH YES! You may want to help yourself out by specifying that all directories and files created in your web accessible area in the future should belong to the same group as their parent, preserving apache's ability to process them. This trick of making the filesystem remember to assign the same group is called setting the GID bit.

You do this by running

chmod g+s yourdir

But what if you have a directory structure already built before you remember to set the gid bit?

What you want to do on a classic unix is to use find to retrieve directories (not files) below your start directory, and then setting the perms on them to something reasonable plus the gid bit.

find yourstartdir -type d -exec chmod g+s {} \;

A debian developer recently argued on a mailing list that the Affero GPL does not meet the debian free software guidelines. He wants packages developed under that software license to not be allowed in Debian.

The author essentially says that modifying an AGPL program is too much extra work, because one has to think of the users and keep their ability to download the sourcecode intact, rendering it too difficult to develop using AGPL software in some cases. This basic premise is repeated through many bullet points in his email below:

http://lists.debian.org/debian-vote/2009/11/msg00000.html

It is interesting to note that the author does not link to the Debian Free Software Guidelines, so I will do so here. They are a good read, and this work helped bridge the gaps between the permissive and copyleft licenses in the late 1990's, and it still the definitive work on the subject in my mind:

http://www.debian.org/social_contract

In my opinion to remove the AGPL from debian would hinder software authors' ability to protect the freedom of users who interact with their software over a network. Authors want to give their software to all users, not give their software to companies trying to lock users into a service. Companies are not prevented from locking users in by siloing their data away, but at the very least they have to give them the source code of the applications they are interacting with. When you accept code from these authors, you are agreeing to taking whatever steps are necessary to providing those same rights + your modifications to your network users.

Let's go through the points that folks are complaining about.

2.1 & 2.2 .. yes, you may have to take some effort or cost to preserve your users' freedom. The GPL also requires you to go to the effort or cost of including the source code to recipients or distributing the source code afterward via various mediums. In fact, interacting with GPL software over a network is kind of a loophole that the AGPL is closing. It's a 21st century version of the GPL. Can you imagine shipping source code on tape? Allowing download is not inconvenient.

Presumably the AGPL software you are using will already have a code delivery mechanism built in (as it itself probably complies with the license originally). You shouldn't take this mechanism out, and if you use the code in a way that breaks the original mechanism no longer works, yes, you have to port and repair that mechanism for your new version -- or else hope you have no users whose freedom you are not respecting.

2.2(I think he means 2.3) Yes, people downstream from you may misconfigure the software either out of malice or stupidity. Having malicious or stupid downstream community members does not put you in violation of the AGPL, it puts THEM in violation, so this is not an issue at all for developers. If you work for these "downstream" malicious people, however, and they are asking you to do malicious things like removing offer of source... find some other software to build your service on.

3.1 Yeah if you are using a headless, low bandwidth machine with no interface, it might be a bit harder to offer sourcecode to your users. The AGPL understands that in some cases the offer of source is not appropriate. For instance if your machine has no networking (no network users) then you don't need to give out your modifications (no one to give them too.) However, your case above doesn't cut it. If this machine is so crippled that it has no functionality, and no interface, what use is it? Microcontrollers and DNS servers maybe? But surely those have interfaces, just not a standard web or desktop interface.

Get creative! Nothing says that you have to deliver AGPL software from the same machine that provides the service, just that it has to be the same source code that the service is running. You could put a minified download url in your commandline telnet client, or stuff one into an obsolete data field in your DNS reponses. Have the server at the end of that url do the data serving. Give the patches back to the original author and ask if they can be upstreamed so you can just point people to him/her. I don't know, but your software absolutely has an interface if I has network interaction. Yes, if you are using AGPL'ed software that is this low level, then you will have to have to get creative to give a prominent offer.

It can be hard to offer source over an API only interface. In this case I would recommend exploring offering source for the buried software that communicates over an API in the interface of a related program that humans do interact with. I.E. you can't get source from my router software in the TCP/IP packets themselves, but you can get it from the router's web interface just fine.

Side note: I would like to see some innovation for those API only cases where machines could request source from other machines. They would share it, faster and faster, patching and compiling it down to new bytecode DNA, running it and taking over the world (just kidding). But some soft of API level "offer of source" would solve your problem. Maybe an offer of source protocol to serve the same purpose as the machine readable creative commons license badges? You don't have to write one, but it might be a nice tool for someone to develop.

I know you think it is burdensome to keep having to keep offering source as long as you have network users for an AGPL'd service, but them's the breaks. If you have a network server, you are responsible for having a network server capable of offering source, sorry.

Anyway, I think debian should allow authors to require those downstream to share even when it requires a bit more work and creativity. This is free software in the classic copyleft sense, free for users and developers in any field of endeavor as long as they are passing freedom along to the next link in the chain.

Debian should cite its Social Contract (scroll up from DFSG) on point 4 where they say "Our priorities are our users and free software".

In the 21st century our users are the people interacting with the services we build on free software. We should take debian's advice and include them.

My friend Andy pointed me to this post on someone who tried ubuntu and went back to MacOs because of many small problems he had. It's a clearly written piece, where he is able to keep his frustration mostly at bay to write lucidly about why he feel ubuntu falls down for him.

There is a story about how keybindings don't globally work, how the open source community doesn't really help with niche issues, and how things just don't feel integrated etc... His conclusion is that linux needs paid for applications to close the gap.

It's a thoughtful post, but I have had almost the opposite reaction in terms of look and feel and the "wholeness" of the experience on Linux versus the Mac. I run ubuntu on a MacBook Air because I feel it offers a more integrated work environment and better Free & free applications than MacOS. My impression is that Gnome is actually more consistent overall than MacOS when it is a vanilla install with gtk applications, and I've also found things like keybindings and personalization to be better when one chooses to dig in and start changing things. It really is the best of both worlds in my experience.

Some apps do flub clipboard integration, openoffice being the most commonly used, but OO.o has clipboard problems on windows too. Mousebuttons seem to mostly work like MacOS even with my trackpad...hm...

As far as the community, I can only say that the open source community has been much more welcoming and responsive to me personally than either the Mac community or Apple inc despite my years as a machead and devoted customer.

Perhaps he is right that the difference is between paying your way vs pitching in to meet niche needs, but I can't see the economics really working out in the situation he uses as an example.

You wouldn't get a taker for $15 to add keybindings to an application in the mac world either... you need hundreds of people asking for that feature before it is worth the developers' time. If hundreds of people are asking for a feature in the open source world, it is also going to get done. If you're the only one asking for a feature in either the proprietary software world or the open source world you are SOL. Wait, except that in the open source world you can add the feature yourself given the right skills. In the mac world you would either have to pay an exorbitant amount of money for custom development, or write the app from scratch.

The one thing that apple users have over linux users is the howls that go up when an app doesn't behave in a mac-like way in terms of keyboard shortcuts or what have you. You won't find the critical mass of people to grab torches in the open source world simply because it is acknowledged that there is "more than one way to do it". There is a great benefit to having only one way to do it if you are part of the crowd that digs that way.

Perhaps there is also something to be said for proprietary applications in terms of the polish that gets added version over version in an attempt to get people's upgrade dollars, but I find that open source applications which gain critical mass build a community which provides a similar level of quality with much more flexibility and breadth of functionality.

For the normal, non technical user I feel both Mac and ubuntu would have similar tech support footprints, and perceptions of quality. Linux has come that far in 5 years. I would probably recommend a mac if it wasn't someone really close to me, because I would feel less responsible to provide tech support given that they are paying Apple. If it was someone in my immediate family what I could support locally, I would suggest ubuntu. Ultimately, ubuntu is free to try, even on their current computer. If it doesn't turn them on, point them to their local Apple store. It's their choice, just like it's our choice.

For a more technical user, I would ask whether they are interested in open source community and ideals. If so, go with linux. Otherwise, it's about even.

Anyway, same facts, different emotions. I totally respect his perspective, and I am really glad we get to choose between the two.

I recently wanted to try thunderbird 3 / icedove 3 on debian. I have a powerpc, and there is no one currently building for that architecture.

Download packages from here
http://pkg-mozext.alioth.debian.org/packages/sid/source/

get the icedovexxxx.diff.gz, the icedovexxxx.orig.tar.gz and the icedovexxxx.dsc

put in a folder on your computer

cd there

dpkg-source -x icedovexxxx.dsc
(this is unpacking tarball, and applying diff, creating dirs etc..)

cd into resulting directory (you want to be in the dir with the debian directory)

dpkg-buildpackage -rfakeroot
(this should build the package, but will first whine about all the dependencies you don't have)

install them with:

apt-get install build-essentials (plus the list of 20 things the above command complained about)

then try again
dpkg-buildpackage -rfakeroot

It will take a long time to compile.....

You should get a deb package at the end which you can install with. It will be created in the directory above this one.

cd ..

dpkg -i icedovexxxxxx.deb icedove-gnome-supportxxxxxxxxxxxxx.deb

run it!