Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
466
News and Announcements / Re: Zentyal Desktop 0.1 published (first alpha version)
« on: October 28, 2010, 08:07:27 pm »
sorry for perhaps a late reply but i have to argue against a nautilus approach.
1: nautilus is not the only gvfs enabled file-browser. its allready said that pcmanfm should also be supported, and thought it indead supports gvfs in the new alpha versions of pcmanfm2 i would recomend to use thunnar instead.
thunar is already out of beta and it can run on a current xfce 4.6.x and will most likely be the default in xfce 4.7 desktop, but it could also easily be installed on lxde, openbox or gnome desktop.
Q: so why not just nautilus instead of thunar?
A: [1]nautilus is dependant to much on gnome, why gnome is a good desktop its quite resources hungry meaning that your system will be slower.
[2] zentyal desktop will at some point be included in a thin/thick client environment. that means that the bigger your netboot will be the slower it gets. meaning that you would be better of using lxde or xfce than a full-blown gnome.
so whatever you deside think about this: what will happen when we include this in our LTSP.
1: nautilus is not the only gvfs enabled file-browser. its allready said that pcmanfm should also be supported, and thought it indead supports gvfs in the new alpha versions of pcmanfm2 i would recomend to use thunnar instead.
thunar is already out of beta and it can run on a current xfce 4.6.x and will most likely be the default in xfce 4.7 desktop, but it could also easily be installed on lxde, openbox or gnome desktop.
Q: so why not just nautilus instead of thunar?
A: [1]nautilus is dependant to much on gnome, why gnome is a good desktop its quite resources hungry meaning that your system will be slower.
[2] zentyal desktop will at some point be included in a thin/thick client environment. that means that the bigger your netboot will be the slower it gets. meaning that you would be better of using lxde or xfce than a full-blown gnome.
so whatever you deside think about this: what will happen when we include this in our LTSP.
467
Installation and Upgrades / Re: Windows thin clients powered by Zentyal?
« on: October 17, 2010, 06:30:57 pm »
hi sam,
please be a little more specific,
what do you mean by windows thin clients?
what are they supposed to be doing,
and why do you recuire windows-based thin clients.
if you're saying that you want thin clients to load windows hosted on zentyal server.
i would have to say that its not possible by default, but it stil can be done if you spend the time and effort on it.
as zentyal is ubuntu based you could find ways to do it still but at this point its out of the scope.
there are however plans developed to get a ubuntu desktop based system that supports terminal-services -like features. you may want to take intrest in that topic ...
if you want any more details or have aditional questions please ask them and give us the proper information to wat you want exactly..
please be a little more specific,
what do you mean by windows thin clients?
what are they supposed to be doing,
and why do you recuire windows-based thin clients.
if you're saying that you want thin clients to load windows hosted on zentyal server.
i would have to say that its not possible by default, but it stil can be done if you spend the time and effort on it.
as zentyal is ubuntu based you could find ways to do it still but at this point its out of the scope.
there are however plans developed to get a ubuntu desktop based system that supports terminal-services -like features. you may want to take intrest in that topic ...
if you want any more details or have aditional questions please ask them and give us the proper information to wat you want exactly..
468
Installation and Upgrades / Re: Zentyal-desktop_NG
« on: October 03, 2010, 06:17:05 pm »
sorry for the rather late response,
first of all let me appriciate all the hard work and the commitment to ebox,
for a thin client i would think that LTSP is a nice ubuntu-supported system so i think that your choice is worth a lot.
now sinse thin clients are rather slow in general (atom / via based mostly) i would recoment a lite but verry functional desktop
in my honnest opinion start with something lite as xfce or even lxde as they use ´slightly´ less resources than a fullblown gnome does. - if it is possible that is...
loggin in with your ebox login-details should be intergrated, as well as roaming profiles.
the desktop should in my honnest opinion only supply the bare esentialse like office, browsing, email (groupware), a document viewer and not mutch more than that, maybe pidgin could be added to connect to an internal jabber server if its installed.
first of all let me appriciate all the hard work and the commitment to ebox,
for a thin client i would think that LTSP is a nice ubuntu-supported system so i think that your choice is worth a lot.
now sinse thin clients are rather slow in general (atom / via based mostly) i would recoment a lite but verry functional desktop
in my honnest opinion start with something lite as xfce or even lxde as they use ´slightly´ less resources than a fullblown gnome does. - if it is possible that is...
loggin in with your ebox login-details should be intergrated, as well as roaming profiles.
the desktop should in my honnest opinion only supply the bare esentialse like office, browsing, email (groupware), a document viewer and not mutch more than that, maybe pidgin could be added to connect to an internal jabber server if its installed.
469
Installation and Upgrades / Zentyal-desktop_NG
« on: September 19, 2010, 04:53:16 pm »
Dear all,
even though being a home user (using ebox as a file/print server with added ubuntu (torrent) software, and other 'private' services. i do take some intrest in this,
this is why im considering that i might be profitable to take it to the next level,
we all know that ebox / zentyal is a good and stable product, but in my honnest opinion it still lacks useful features, for that reason it would suite that more modules would be added.
one of them, i think, should be, terminal-services like clients, running Xorg, and for example a vnc-client to connect to a complete zentyal optimized version of ubuntu 10.4
now there mainly 2 ways of getting this done,
1: install a virtualmachine hypervisor, like KVM, Qemu (in usermode virtualisation mode) or Virtualbox.
2: install (x)ubuntu-desktop within a chroot, using LTSP
what you want depends on your requirements, the hardware that runs your zentyal-server and a number of other things,
- this topic start is meant to start a discussion on how it should be done, the possibilities we have, and in the end if its worth the trouble of doing it.
if im to do this however, it should be clear that any code that i will write for this, will be released under the GPL version 3, and the GPL licence ONLY.
any code submitted, or any external modules used should therefor. be GPL v3 compatible,
if this in anyway is impossible, or not desired, i will refrain from doing any work at all.
please keep it ontopic.
even though being a home user (using ebox as a file/print server with added ubuntu (torrent) software, and other 'private' services. i do take some intrest in this,
this is why im considering that i might be profitable to take it to the next level,
we all know that ebox / zentyal is a good and stable product, but in my honnest opinion it still lacks useful features, for that reason it would suite that more modules would be added.
one of them, i think, should be, terminal-services like clients, running Xorg, and for example a vnc-client to connect to a complete zentyal optimized version of ubuntu 10.4
now there mainly 2 ways of getting this done,
1: install a virtualmachine hypervisor, like KVM, Qemu (in usermode virtualisation mode) or Virtualbox.
2: install (x)ubuntu-desktop within a chroot, using LTSP
what you want depends on your requirements, the hardware that runs your zentyal-server and a number of other things,
- this topic start is meant to start a discussion on how it should be done, the possibilities we have, and in the end if its worth the trouble of doing it.
if im to do this however, it should be clear that any code that i will write for this, will be released under the GPL version 3, and the GPL licence ONLY.
any code submitted, or any external modules used should therefor. be GPL v3 compatible,
if this in anyway is impossible, or not desired, i will refrain from doing any work at all.
please keep it ontopic.
470
Installation and Upgrades / Re: Add-On: BackupPC request.
« on: August 16, 2010, 08:25:01 am »
im sorry to say but i find this 'security' argument really 'thin' ...
its so thin that it will break before you even truely concider it.
it sounds to me like: using NAT (network addres translation) for a firewall.
-----
i may have said it allready but here to say it again, backup is for desaster recovery, and nothing should be able to interfeer with it. If that is even possible you did a verry poor job indead.
now lets clearefy what i ment earlier, - backup pc pulls data server side.
that has 2 downsides:
1. to takes a whole lot of computting power, on the server.
2. it takes al lot of bandwidt...
1: even though it may seem rather unimportand, but that is really a mistake.
backing up is more than.
serv> hé im the server, do you want a backup?
pc> euuhhh
serv> well i think im just going to get all your data>
pc> euhhhhh
the problem with this, is that the server's cpu will now have to do everything.
i/o listing (of the filesystem), getting the data (with no form of compression what so ever).
so as soon as you want to start pulling data, no advanced technolegy features can/ will be used.
but even when you finaly browsed the 'smb' sharess, and you coppied over the data, you still want one more thing to be done. - (at least i would).. that is, you want your data to be compressed a bit to save pressious dataspace on your server. mind you! compression takes a lot of computting power.
wouldn't it be better to do all of that clients side:
<server> hee im the server, and its time to do a backup,
<client> oh okey mr server, hang on im going to do a bit of work now,
<client> here is the file mr. server i compressed it allready, so mr. router wont be mad this time its now only 1.3gb (instead of 10gb)
----
its so thin that it will break before you even truely concider it.
it sounds to me like: using NAT (network addres translation) for a firewall.
-----
i may have said it allready but here to say it again, backup is for desaster recovery, and nothing should be able to interfeer with it. If that is even possible you did a verry poor job indead.
now lets clearefy what i ment earlier, - backup pc pulls data server side.
that has 2 downsides:
1. to takes a whole lot of computting power, on the server.
2. it takes al lot of bandwidt...
1: even though it may seem rather unimportand, but that is really a mistake.
backing up is more than.
serv> hé im the server, do you want a backup?
pc> euuhhh
serv> well i think im just going to get all your data>
pc> euhhhhh
the problem with this, is that the server's cpu will now have to do everything.
i/o listing (of the filesystem), getting the data (with no form of compression what so ever).
so as soon as you want to start pulling data, no advanced technolegy features can/ will be used.
but even when you finaly browsed the 'smb' sharess, and you coppied over the data, you still want one more thing to be done. - (at least i would).. that is, you want your data to be compressed a bit to save pressious dataspace on your server. mind you! compression takes a lot of computting power.
wouldn't it be better to do all of that clients side:
<server> hee im the server, and its time to do a backup,
<client> oh okey mr server, hang on im going to do a bit of work now,
<client> here is the file mr. server i compressed it allready, so mr. router wont be mad this time its now only 1.3gb (instead of 10gb)
----
471
News and Announcements / Re: First version of the new FTP module released!
« on: July 16, 2010, 07:40:53 pm »I'm afraid that in addition to ftp, the only new module we can promise for 2.0 is one for thin clients management. Take into account that the change from Ubuntu 8.04 to 10.04 has required a lot of effort so we can't add as much features as we would have liked to.
to be honnest and with all due respect but isn't that a shame. (a verry big shame).
if this is true, than why in all loving things are you working toward a 2.0 version instead of (for example 1.6)
id say and thats from a fair experience in project development, that a lower version increase with fewer expectations could help speed up the 'getting' ready for a quick release.
but that in all is not all to usefull to debate.
id rather see a 'test release of the 1.5 stuf.. even if its 'beta' quality a set of ready made ISO's would encourage peole to test this. and to find buggs
472
Installation and Upgrades / Re: Add-On: BackupPC request.
« on: March 08, 2010, 10:04:57 am »
there is a better option that backupPC -
bacula, Yes it requires a client installtion (witch in my opinion is more a good than a bad thing,
this will for example handle a lot of processing of the backup client-side, rather than server-side,
this is good because now a cheaper, server can service more clients,
remember that most OS'sen even windows can run on just about any Intel Pentium 4(r) 2+ ghz. - where most people have dualcore (e4400 / athlon 4000+ x2's ) so plenty to offload the file server.
bacula can run in both mysql or (in our case) postgresql, and seems to work well with samba and ldap,
ther is however 1 downside, - it has a php / rather than a perl web-frontend, this means that, someone has to port the php script to perl,
however, php is not a real hard language to read, so a skill perl programmer could probbably why up a module for bacula quite fast..
ALL configuration for bacula is done in its data-base so its not raly hard to manage from ebox's point of view.
bacula COULD and SHOULD be tightly intergrated as a default module.
the biggest problem of backula is however this:
how should one generate bacula config scripts for the clients.
bacula, Yes it requires a client installtion (witch in my opinion is more a good than a bad thing,
this will for example handle a lot of processing of the backup client-side, rather than server-side,
this is good because now a cheaper, server can service more clients,
remember that most OS'sen even windows can run on just about any Intel Pentium 4(r) 2+ ghz. - where most people have dualcore (e4400 / athlon 4000+ x2's ) so plenty to offload the file server.
bacula can run in both mysql or (in our case) postgresql, and seems to work well with samba and ldap,
ther is however 1 downside, - it has a php / rather than a perl web-frontend, this means that, someone has to port the php script to perl,
however, php is not a real hard language to read, so a skill perl programmer could probbably why up a module for bacula quite fast..
ALL configuration for bacula is done in its data-base so its not raly hard to manage from ebox's point of view.
bacula COULD and SHOULD be tightly intergrated as a default module.
the biggest problem of backula is however this:
how should one generate bacula config scripts for the clients.