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.

Messages - ichat

Pages: 1 ... 30 31 [32]
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.

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..

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.

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.

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) 

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

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.   

Pages: 1 ... 30 31 [32]