Nice going guys!!
Per ichat's request, I updated the Amahi Roadmap page with my perspective of what should go into the version 5 that's brewing.
The Official Roadmap Draft for Amahi 5 and later versions..
Re: The Official Roadmap Draft for Amahi 5 and later versions..
Last edited by cpg on Wed Oct 28, 2009 3:07 am, edited 1 time in total.
My HDA: Intel(R) Core(TM) i5-3570K CPU @ 3.40GHz on MSI board, 8GB RAM, 1TBx2+3TBx1
Re: The Official Roadmap Draft for Amahi 5 and later versions..
Hello all, - i've added yet a few ideas to the roadmap,
specially the idea of an amahi sublayer, would be a really valued addition to the procject,
if its possible to bundle all the distro-specific commands in a string-like file (resembling how language handling is done)
it would verry much help developers to port amahi to other distro's like the much spoken of ubuntu version.
this would require the knowlegde of a linux (distro) guru who truely understands the diferences between most common used distro's.
based on that knowledge we need to build a draft to explain what commands (for example the package-installer) are distro-specific and how we can handle different tools that have different commands but also display thair userinfo all in a different output, order and logics.
to make Amahi able to run distro-independent we should thus add some way of interpretation between the "management GUI's" and the actual system itself
this may not be a feature that is plausible to be in the Amahi 6.0 release unless there is a significant contribution in knowledge and code examples
specially the idea of an amahi sublayer, would be a really valued addition to the procject,
if its possible to bundle all the distro-specific commands in a string-like file (resembling how language handling is done)
it would verry much help developers to port amahi to other distro's like the much spoken of ubuntu version.
this would require the knowlegde of a linux (distro) guru who truely understands the diferences between most common used distro's.
based on that knowledge we need to build a draft to explain what commands (for example the package-installer) are distro-specific and how we can handle different tools that have different commands but also display thair userinfo all in a different output, order and logics.
to make Amahi able to run distro-independent we should thus add some way of interpretation between the "management GUI's" and the actual system itself
this may not be a feature that is plausible to be in the Amahi 6.0 release unless there is a significant contribution in knowledge and code examples
Amahi Roadmap and Project managment:
Even though im considered to be an IT Specialist,
you shouldn't ask me linux (command) specific questions,
for in general i'm only able to help with more generic problems.
Even though im considered to be an IT Specialist,
you shouldn't ask me linux (command) specific questions,
for in general i'm only able to help with more generic problems.
Re: The Official Roadmap Draft for Amahi 5 and later versions..
wrt to the package installer: it is possible to install yum on Ubuntu, and I think this would greatly speed up development in that area: http://packages.ubuntu.com/karmic/yum (it is also available in older releases).
The differences between the distro's are not _that_ big, but as they say, the devil is in the details![Smile :)](./images/smilies/icon_e_smile.gif)
The location of some config files might be different (can be resolved by symlinking or checking certain paths during the ./configure phase)
The tools are more or less the same. I've been using Debian on my local desktop (currently Ubuntu) and RH, Debian, SUSE on servers. The differences are really _really_ minor for normal usage. Tools are usually also packaged for different distro's (e.g. the chkconfig command on RHEL/fedora/centos which on Debian is the update-rc.d command, but you can install chkconfig on Debian as well - not sure about the other way around).
The main point however is versioning. You'll have to make certain that you will configure/install against the lowest common denominator.
That might lead to packaging the required version of $lib/$module/$tool in the Amahi repo. This _is_ to be preferred for users, but not for cpg who's footing the bill of the amahi repos. I wil ask for info with a dutch mirror maintainer (debian, fedora, centos, bsd mirror) how that kind of stuff is handled.
Personally I would like the hdactl stuff & the apps in /opt and userspace data in /mnt/data/($sharename) but that's a structure thing and highly debatable since it's based on personal preference. I might be able to discuss this with said maintainer or his colleagues (unix/linux gurus working for a _very_ reputable unix training/consulting/programming firm in NL) to think about the best way to structure this kind of application.
The differences between the distro's are not _that_ big, but as they say, the devil is in the details
![Smile :)](./images/smilies/icon_e_smile.gif)
The location of some config files might be different (can be resolved by symlinking or checking certain paths during the ./configure phase)
The tools are more or less the same. I've been using Debian on my local desktop (currently Ubuntu) and RH, Debian, SUSE on servers. The differences are really _really_ minor for normal usage. Tools are usually also packaged for different distro's (e.g. the chkconfig command on RHEL/fedora/centos which on Debian is the update-rc.d command, but you can install chkconfig on Debian as well - not sure about the other way around).
The main point however is versioning. You'll have to make certain that you will configure/install against the lowest common denominator.
That might lead to packaging the required version of $lib/$module/$tool in the Amahi repo. This _is_ to be preferred for users, but not for cpg who's footing the bill of the amahi repos. I wil ask for info with a dutch mirror maintainer (debian, fedora, centos, bsd mirror) how that kind of stuff is handled.
Personally I would like the hdactl stuff & the apps in /opt and userspace data in /mnt/data/($sharename) but that's a structure thing and highly debatable since it's based on personal preference. I might be able to discuss this with said maintainer or his colleagues (unix/linux gurus working for a _very_ reputable unix training/consulting/programming firm in NL) to think about the best way to structure this kind of application.
echo '16i[q]sa[ln0=aln100%Pln100/snlbx]sbA0D2173656C7572206968616D41snlbxq' | dc
Galileo - HP Proliant ML110 G6 quad core Xeon 2.4GHz, 4GB RAM, 2x750GB RAID1 + 2x1TB RAID1 HDD
Galileo - HP Proliant ML110 G6 quad core Xeon 2.4GHz, 4GB RAM, 2x750GB RAID1 + 2x1TB RAID1 HDD
Re: The Official Roadmap Draft for Amahi 5 and later versions..
unless you would adapt the update pocess a slight bit...The main point however is versioning. You'll have to make certain that you will configure/install against the lowest common denominator.
That might lead to packaging the required version of $lib/$module/$tool in the Amahi repo. This _is_ to be preferred for users, but not for cpg who's footing the bill of the amahi repos. I wil ask for info with a dutch mirror maintainer (debian, fedora, centos, bsd mirror) how that kind of stuff is handled.
if you use apt- for instance, you COULD use meta-packages hosted on amahi, and than use the ubuntu repos do download packages... install them, and than apply any modds in the conig of those packages if and where neaded... ...
in practice - you would have a virtuall repos for ubuntu files with amahi packages... and referals to ubuntu ones...
for example
Code: Select all
apt-get install ftp://files.amahi.org/~*~/samba-new.deb
Code: Select all
apt-get install http://mirror1.ubuntu.downloads.org/2009/04/network/samba-new.deb
it aso means that 1 guy is also packagng scriptfiles all day.... and constantly checking if update x doesn't break feature y....
Amahi Roadmap and Project managment:
Even though im considered to be an IT Specialist,
you shouldn't ask me linux (command) specific questions,
for in general i'm only able to help with more generic problems.
Even though im considered to be an IT Specialist,
you shouldn't ask me linux (command) specific questions,
for in general i'm only able to help with more generic problems.
Re: The Official Roadmap Draft for Amahi 5 and later versions..
yet another concern of mine:
can anyone confirm if apache is running root ????
if this is so than why are we running both the system management console and the user-land apps with root:root,
is it not wise: to run a amahi-serv demon i.e: a custom really smal footprint httpd for the amahi-manager
and any apps that really must have root access.. nearly none should though...
and more standard configure apache for stuff like calandar's - php- stuff, and the like,
i.e. ive seen an amahi version of phpbb fyling from here to there... - i for one would never use it,
but also i would forbid it ran from the same deamon my server-critical app run on...
i even dare going so far as to say that phpbb latest -1 will allow me to gain root access to you server within a night's sleep if you run php without safe-mode (wich some other app in the reps require...
if we really run root (like i heared someone say) i think we should look for a way to fix this ...
because iirc - apach DID run root????
can anyone confirm if apache is running root ????
if this is so than why are we running both the system management console and the user-land apps with root:root,
is it not wise: to run a amahi-serv demon i.e: a custom really smal footprint httpd for the amahi-manager
and any apps that really must have root access.. nearly none should though...
and more standard configure apache for stuff like calandar's - php- stuff, and the like,
i.e. ive seen an amahi version of phpbb fyling from here to there... - i for one would never use it,
but also i would forbid it ran from the same deamon my server-critical app run on...
i even dare going so far as to say that phpbb latest -1 will allow me to gain root access to you server within a night's sleep if you run php without safe-mode (wich some other app in the reps require...
if we really run root (like i heared someone say) i think we should look for a way to fix this ...
because iirc - apach DID run root????
Amahi Roadmap and Project managment:
Even though im considered to be an IT Specialist,
you shouldn't ask me linux (command) specific questions,
for in general i'm only able to help with more generic problems.
Even though im considered to be an IT Specialist,
you shouldn't ask me linux (command) specific questions,
for in general i'm only able to help with more generic problems.
Re: The Official Roadmap Draft for Amahi 5 and later versions..
Apache does not run as root. it runs as User apache with a group of apacheyet another concern of mine:
can anyone confirm if apache is running root ????
[...]
because iirc - apach DID run root????
This behavior is configured in the file /etc/httpd/conf/httpd.conf
Re: The Official Roadmap Draft for Amahi 5 and later versions..
trying to find, - the link where i wread it to see if i misswread...
i think i might have...
but tnx for the quick reply it had me worried for a bit...
i think i might have...
but tnx for the quick reply it had me worried for a bit...
Amahi Roadmap and Project managment:
Even though im considered to be an IT Specialist,
you shouldn't ask me linux (command) specific questions,
for in general i'm only able to help with more generic problems.
Even though im considered to be an IT Specialist,
you shouldn't ask me linux (command) specific questions,
for in general i'm only able to help with more generic problems.
Re: The Official Roadmap Draft for Amahi 5 and later versions..
the main thing i never hear anything aboput is uniformity (is that a word?)
We have wonderfull apps! WONDERFULL management tools.. i truely think Amahi made my networking management a lot easier..
but one thing that didnt make it easier.. every app has its own layout, every tool has its own layout..
the minute you step away from amahi, you'll have to figure out how this app works and where that app's buttons are..
what we need, aside from yet more apps..
are a few php scripters, or whatever.
some that can make most of the tools (like a forum, mailclient, those kind of things) but then completely in sync with the amahi looks!
THATS something i truelly believe makes life easier for the n00bs we're targetting for..
also, we need people who are good in marketing, get this advertising machine running, find ways to generate some income, so that it pays for itself at least the costs of webhosting and such.
whilst i see tons of good idea's, i'd personally go for the stabilty way.. make sure everything is absolutely bug-free.
THEN go from there, and have everything "as we go" but make sure the base platform is ABSOLUTELY bug free!
(although i dare say it allready is? i never have any issues with mine, and i run F12)
We have wonderfull apps! WONDERFULL management tools.. i truely think Amahi made my networking management a lot easier..
but one thing that didnt make it easier.. every app has its own layout, every tool has its own layout..
the minute you step away from amahi, you'll have to figure out how this app works and where that app's buttons are..
what we need, aside from yet more apps..
are a few php scripters, or whatever.
some that can make most of the tools (like a forum, mailclient, those kind of things) but then completely in sync with the amahi looks!
THATS something i truelly believe makes life easier for the n00bs we're targetting for..
also, we need people who are good in marketing, get this advertising machine running, find ways to generate some income, so that it pays for itself at least the costs of webhosting and such.
whilst i see tons of good idea's, i'd personally go for the stabilty way.. make sure everything is absolutely bug-free.
THEN go from there, and have everything "as we go" but make sure the base platform is ABSOLUTELY bug free!
(although i dare say it allready is? i never have any issues with mine, and i run F12)
LANTEA: Amahi 7 (vm), HP Proliant Microserver, 8GB RAM, 2x 1TB HDD, 1GB eth
Re: The Official Roadmap Draft for Amahi 5 and later versions..
also:
lets first make sure all the backup systems are working.
backup complete clients, media folders, documents, whatever..
also implement a way to backup the Server itself, in case of general failure.
lets first make sure all the backup systems are working.
backup complete clients, media folders, documents, whatever..
also implement a way to backup the Server itself, in case of general failure.
LANTEA: Amahi 7 (vm), HP Proliant Microserver, 8GB RAM, 2x 1TB HDD, 1GB eth
Re: The Official Roadmap Draft for Amahi 5 and later versions..
ok, the common looks are going to be available in plugins (aka as "engines" in the new rails 2.3, and can be quite powerful subsystems). welcome "ruby scripters" ![Smile :)](./images/smilies/icon_e_smile.gif)
as for backups, keim captured some of the discussion in the IRC channel today!:
http://wiki.amahi.org/index.php/Backup_settings
![Smile :)](./images/smilies/icon_e_smile.gif)
as for backups, keim captured some of the discussion in the IRC channel today!:
http://wiki.amahi.org/index.php/Backup_settings
My HDA: Intel(R) Core(TM) i5-3570K CPU @ 3.40GHz on MSI board, 8GB RAM, 1TBx2+3TBx1
Who is online
Users browsing this forum: No registered users and 3 guests