|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-users] Announcing XenMaster
I'll set it up and give it a shot.. Heck I'd love to have a usable frontend for my junior admins to use. On Sat, Feb 11, 2012 at 11:53 PM, Jordan Tomkinson <jordan@xxxxxxxxxx> wrote: > > > On Sun, Feb 12, 2012 at 8:03 AM, George Shuklin <george.shuklin@xxxxxxxxx> > wrote: >> >> >> >> ...but sorry, why do you use a richfat and plumby Java backend? There are >> a lot of smaller, ressource efficient, incomplex and easier to handle open >> source technologies - even full oo - available to build such a HTML >> management front- and even backend? >> >> We agree that in comparison to xm/xl/xe, running a Java stack might seem >> to be a bit on the heavy side. Yet we'd like to note that our back-end is >> nothing like Tomcat or Glassfish, it contains only the bare minimum needed >> to do its work. >> >> To elaborate choosing Java for our back-end: >> - Java applications can be deployed on a wide variety of operating >> systems, if not all. >> - Eventually the back-end will also be orchestrating pools or clusters. >> - The back-end parses responses and shrinks updates down to only the bare >> minimum, limiting bandwidth use by the front-end. >> - The back-end allows access to your servers over a single TCP/IP port, >> the Xen-API will not be publicly exposed. >> - Again we’re not running a whole Java EE stack, the front-end is a webapp >> that lives on its own and communicates with the backend over a WebSocket >> connection. >> - Coupled with Cassandra, the back-end is the only thing that needs to be >> run (one single instance), for any number of hosts. >> >> >> I'm very against Java. After Oracle license change sun-jre package was >> forced to be removed from the most distros. Right now Oracle does not >> properly supports any dpkg (deb) based Linux distrubition, providing only >> RPMs and some creepy tarball. This actually means 'very bad linux support'. >> And if we looks how Oracle do business we can see no future for nice >> multiplatform support. Yes, there is open-source implementation for JRE, but >> it still uncomplete, and, again, resistance to publish opensource code for >> certification is looking ugly. >> >> So using a 'half-opened' open-source solution, where specification is >> controlled by not-very-opensource-friendly company for new open-source >> product is really bad idea. >> >> >> HTML5 is much more open standard, so using html5 is more proper solution. >> >> ... OK, let's forget Linux. Looks at windows. IE will supports HTML5 out >> of box. And future is looking promising. And how about Java? Yes, you need >> to download it, install is separately, it starts to nagging about updates, >> and it does not supports for windows system updates, so you need to update >> it manually. Again, comparation Java VS HTML5 is not toward Java. >> >> > > I have to agree with George here, the mere mention of java makes me want to > burn this thing before it can breed. > no matter how small you plan on making it, it could be done more efficiently > in any other language. > instead of allocating resources to my virtual machines we are now expected > to allow how many hundreds of megabytes of memory to java ? > > No thanks, you can keep it. > > _______________________________________________ > Xen-users mailing list > Xen-users@xxxxxxxxxxxxxxxxxxx > http://lists.xensource.com/xen-users _______________________________________________ Xen-users mailing list Xen-users@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-users
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |