Amahi Forums

Here's the questions from the wiki:

Some open questions/topics:

• Can we somehow live with RPMs in the short term (which is what we have today)? Using something that we have today would make it easier right away, i.e. if we can go with a repo that we already have, it would be a massive step to get started.
• Should we start with ubuntu desktop or ubuntu server? - my first impression would be server, which makes more sense. Any gotchas with that?
• How are updates handled in ubuntu?

And here's my view on things:

1. I don't think we should stick with RPMs. While it is a LOT easier to package RPMs, most Ubuntu users have become used to Apt and the Debian style of packaging things. This will also help the updating side [switching to Apt], as they will automatically appear within the Update Manager if the repository is up. Plus, we already have deb scripts.

2. The current Fedora version we have runs as a desktop machine by default. Ubuntu 10.04 is probably light enough, if not easier, on the memory than Fedora 12 on install in the Desktop edition. I also bet that if we develop for the desktop, we'll have fewer questions since there will be a GUI. I love working at the command line, but most do not. We can change a few things in the scripts to allow the user to access the installer from the outside; it's not hard, fortunately, for the server edition to work either.

3. In Ubuntu, updates are handled through two programs: update-manager and unattended-upgrades. The latter is disabled by default and the user must enable automatic download and install of such updates. We'll probably need to write a script that will change that for the user. The user can always be directed to use update-manager as necessary, however

1. I don't think we should stick with RPMs ... Plus, we already have deb scripts.

Agree. IIRC this was a very early question that does not apply any more, precisely because we have the scripts!

2. The current Fedora version we have runs as a desktop machine by default. Ubuntu 10.04 is probably light enough, if not easier, on the memory than Fedora 12 on install in the Desktop edition. I also bet that if we develop for the desktop, we'll have fewer questions since there will be a GUI. I love working at the command line, but most do not. We can change a few things in the scripts to allow the user to access the installer from the outside; it's not hard, fortunately, for the server edition to work either.

Centering on the user aspect is the right call, I think. I also think that it probably works on the server later.

3. In Ubuntu, updates are handled through two programs: update-manager and unattended-upgrades. The latter is disabled by default and the user must enable automatic download and install of such updates. We'll probably need to write a script that will change that for the user. The user can always be directed to use update-manager as necessary, however

I see. Generally I would be a bit skeptic of unattended updates for stuff that the Amahi team has overview over. Surprising people with updates is a bit risky, if one fails or breaks something.

Looks like you have something going on, so that's pretty exciting!

1. I don't think we should stick with RPMs. While it is a LOT easier to package RPMs, most Ubuntu users have become used to Apt and the Debian style of packaging things. This will also help the updating side [switching to Apt], as they will automatically appear within the Update Manager if the repository is up. Plus, we already have deb scripts.

Agreed, no sense in working with a non-native package format.

2. The current Fedora version we have runs as a desktop machine by default. Ubuntu 10.04 is probably light enough, if not easier, on the memory than Fedora 12 on install in the Desktop edition. I also bet that if we develop for the desktop, we'll have fewer questions since there will be a GUI. I love working at the command line, but most do not. We can change a few things in the scripts to allow the user to access the installer from the outside; it's not hard, fortunately, for the server edition to work either.

When you have a web interface, especially one that include apps for accessing the command line, I don't think the "average guy" user would miss the gui. I guess it all depends on if we push for the amahi box to be a separate entity from the primary desktop machine. If the have a need for amahi they already have multiple machines anyway.

3. In Ubuntu, updates are handled through two programs: update-manager and unattended-upgrades. The latter is disabled by default and the user must enable automatic download and install of such updates. We'll probably need to write a script that will change that for the user. The user can always be directed to use update-manager as necessary, however

Ubuntu 10.04 can be directed to install security updates automatically and to alert for all others. The security updates tend to be more stable and to cause less issues so they can normally be enabled without much worry.

When you have a web interface, especially one that include apps for accessing the command line, I don't think the "average guy" user would miss the gui. I guess it all depends on if we push for the amahi box to be a separate entity from the primary desktop machine. If the have a need for amahi they already have multiple machines anyway.

For the average linux user (a typical geek), the install could very well be handled via the command line and another computer. But I must remind that not all of the userbase here is completely fluent with the command line. I also remember cpg saying something about the amount of users we can lose by adding another step in the process in IRC, something like we lose 50% for every click or command. cpg, could you elaborate?

I also must add that is quite a bit more difficult to make amahi work via a minimal text install. I ended up attempting this on Fedora 12 (graphics issues) and had issues trying to get it installed. I ended up reverting to Fedora 10 and Amahi 4 as I got tired of debugging.

Ubuntu 10.04 can be directed to install security updates automatically and to alert for all others. The security updates tend to be more stable and to cause less issues so they can normally be enabled without much worry.

Indeed, that was the point I was attempting to get across. unattended-updates is the system process that install these security updates. Indeed, they are very easy to turn on, and I bet it would take very little to modify the system configuration in our code.

Speaking of which, I'll try to get a branch put together here soon on the git server so everyone can start helping. My code is in their working directories right now and so I have a lot of housecleaning to do! It's also a bit messy; I haven't coded in the OS detection routine yet. I also plan to get another wiki page set up so we have a task list, if that's alright with cpg.

Speaking of which, I'll try to get a branch put together here soon on the git server so everyone can start helping. My code is in their working directories right now and so I have a lot of housecleaning to do! It's also a bit messy; I haven't coded in the OS detection routine yet. I also plan to get another wiki page set up so we have a task list, if that's alright with cpg.

That would be great!

BTW, I almost have Fedora 12 install working with just 4 clicks to either CLI or GUI install.

Just some questions:
The bugs in the Ubuntu tracker are all marked as 100%. Does this mean that they are all resolved and that there is hope for a version?
The FAQ states that the 32-bit version is needed. Is this a hard requirement, or should it also work on 64-bit installs?
If there is a beta that can be tested for you, where is it located? And how would one gather the information needed for the bug reports?