From: Liam Helmer (linuxlists_at_thevenue.org)
Date: Fri 30 Jan 2004 - 21:47:34 GMT
It sounds to me like there's definitely interest. The thing is, you
haven't told anyone what freevps really does at this point. Virtually
nobody on this list, I imagine, is running that version of redhat and
that kernel. And, if they are, they're looking to upgrade, because it's
very hard to secure an old redhat distribution anymore! I've looked on
your site, and what it does is not that obvious. So, other than being
distro-spefic, how does FreeVPS now differ from vserver? What are the
design goals of FreeVPS? So far, you've mentioned that it's specific to
hosting providers. Will it work for desktop systems? Small office
systems? Distributed computing farms? Everywhere else vserver might be
being used? Although I'm sure that hosting providers use vserver a lot,
I'm also sure that there's other uses that are totally different.
Given that we're on this list, we're presumably enjoying the stuff the
vserver is doing, and we're not going to want to have any of that go
away. But, there's a big shakedown of the architecture going on anyways,
now is honestly a perfect time to merge projects, and hopefully get lots
of cool features from either side. This is not a contest of "my version
is better than your version". This is simply people trying to create
something that's cool. <grin> At least, as far as I can tell.
For me, personally, I need something that can be used as generically as
possible. I'm using it more as an extended version of chroot, and I tend
to use the chbind and chcontext commands directly. So, for me, the
kernel work and the low level tools are the most important, and the
userspace tools are secondary. But, I know there's tonnes of people who
are using it as a little "server inside a server" environment too. What
I like is something that's generic enough at the low level that it's
useful in many different ways. What I'm sure a lot of other people like
is the ability to use vservers with very little prior setup and
knowledge (i.e. it Just Works(tm)). For me, I like to roll my own... I
find that what "just works" for people tends to almost do what I want,
but not quite. Ahh, the curse of open source... so many people, so many
wants, so many needs, so few people who actually contribute code <grin>.
Cheers,
Liam
On Fri, 2004-01-30 at 11:52, Igor Seletskiy wrote:
> Sorry about the slip up :). I meant that there will be no licensing
> issues. We don't make money on FreeVPS, it is just a side product to
> H-Sphere. It is GPL - because Linux kernel is GPL. All our patches are
> are available online. If you like any of them - you can take them, parts
> of them, adopt them to linux-vserver or what ever. We might build a
> consulting business around it at some moment, yet GPL is GPL - and thats
> the beauty of it :)
>
> Anyway, it is up to you, I had interest to merge, yet if there is not
> enough interest from linux-vserver maintainers - I am fine with it as
> well. Lets our projects co-exists in a warm friendly atmosphere, as two
> separate projects. We can swap patches from time to time :)
>
> Best Regards,
> Igor Seletskiy
>
> Herbert Poetzl wrote:
> > On Thu, Jan 29, 2004 at 07:07:31PM -0500, Igor Seletskiy wrote:
> >
> >>Hello Everyone,
> >>
> >>I will follow up and add some more info. Alexey Lyashkov was hired by
> >>Positive Software in 2002 to add enhancements and speed up development
> >>of vserver project (it was vserver back then). Several more developers
> >>where added at later stages. I was mostly interested in creating virtual
> >>server environment for hosting companies. As vserver development
> >>stopped, we decided to create our own branch (freeVPS).
> >>As the name says - it is free. As part of linux kernel - it is GPL (I
> >>don't think it is legal to produce any kind of patches to linux kernel
> >>under any different license). Also, with tools it is more complex - most
> >>of the tools are GPL as well. Only those tools that are unique to
> >>h-sphere to provision freeVPS are covered by commercial license.
> >>So, from the licensing standpoint - there should be any issues.
> >
> >
> > hmm, a freudian slip? well let's for now assume
> > that there are no license issues involved and you
> > provide a list (maybe on the web) of all sources
> > covered by GPL and they are all which is required
> > for FreeVPS to use it.
> >
> >
> >>The reason redhat kernel was select - due to some back ports from 2.6 -
> >>like O(1) scheduler - that made it very convenient & easy to improve
> >>virtualization without sacrificing too much of the performance. Also,
> >>the fact that patches are for redhat kernel - doesn't reduce its ability
> >>to work on any other linux distro - it is still linux kernel.
> >
> >
> > sure, but I doubt that a RH 7.3 kernel (2.4.18.x.y)
> > will be the first (or even second) choice of a debian,
> > gentoo, suse or even mandrake person, so a vanilla
> > kernel might be acceptable to some degree, but the
> > ultimate goal should be a distro agnostic version.
> >
> > I have to admit, I didn't spend much time with freeVPS
> > lately, so I don't know it's current status, and what
> > the tool are capable of, and what not, maybe you could
> > elaborate on that for a start ...
> >
> >
> >>That is also why I think merge between linux-vserver & freeVPS makes
> >>sense. In 2.6 - we are going to go with standard kernel (as all the
> >>necessary pieces already there).
> >
> >
> > well, that is something we both have in common, and
> > I don't see a problem if you base your development
> > on the experimental releases linux-vserver does for
> > 2.6.x as long as the software stays free ;)
> >
> >
> >>Regarding how intrusive are changes - they probably are. We tried to
> >>create very good, highly isolated, high performance virtual environment
> >>that would sustain hosting environment. So we had to assume that inside
> >>each virtual server - there were "hostile" root users. I understand that
> >>it can break bunch of additional patches against vanilla kernel - yet,
> >>for us virtualization was more imported.
> >
> >
> > I would like to split this into three categories
> > a) security features
> > b) stealth features
> > c) nice to have features
> >
> > although I prefer lightweight and non intrusive
> > patches, I would not hesitate to do some intrusive
> > modification to satisfy a) but not for b) and c)
> > where they can still be supported as addons
> >
> > I also try to separate logic blocks and provide
> > patches for each one, which actually allows easy
> > portation and adaptation, and even removal of
> > some components (was done for the iunlink part)
> >
> >
> >>Regarding "patches are welcome" - it is not that easy. I cannot have my
> >>guys working on two projects. Thats why I want to be sure that
> >>a) There are enough interest in merging
> >> (aka finding compromises when necessary)
> >
> >
> > well, obviously there _is_ enough interest on your
> > side, and as I pointed out several time, there is
> > always interest on working together on my side,
> > and I already made some compromises with Alex, we
> > had quite some discussions regarding the interface
> > on the irc channel, I don't know if he adhered that
> > interface but for my part I tried where possible.
> >
> >
> >>b) FreeVPS design strategies are ok for linux-vserver developers
> >
> >
> > hum, hum, that is something I can only reject.
> > I'm not doing this project to follow some strategies
> > figured out by some management of yours, to promote
> > or sell your product more efficiently, and as I can't
> > speak for the other developers, I would not commit
> > myself to following some 'design strategies' at all
> >
> > so I would say, as long as your 'strategies' are okay
> > for linux-vserver and linux-vserver strategies are
> > okay for you, we can work together, if at some point
> > that isn't true anymore, we part and everybody is fine
> >
> >
> >>c) We can come up with a set of common goals, tasks and with a way to
> >>work together.
> >
> >
> > I'm all ears ...
> >
> > my suggestions for working together would be
> >
> > - have some discussions about the goals on ml or irc
> > - separate and document the codebase (featurewise)
> > - let the community decide about the strategy
> >
> > best,
> > Herbert
> >
> >
> >>Regards,
> >>Igor Seletskiy
> >>
> >>
> >>Herbert Poetzl wrote:
> >>
> >>>n Thu, Jan 29, 2004 at 04:34:00PM -0500, Igor Seletskiy wrote:
> >>>
> >>>
> >>>>Hi Herbert,
> >>>>
> >>>>My name is Igor Seletskiy. I own psoft (maker of freeVPS). I wander what
> >>>>are your thoughts about merging linux-vserver & freeVPS?
> >>>>I believe at some points freeVPS is more advanced then linux-vserver
> >>>>(like our new memory accounting module, new network routing, also, &
> >>>>mount tables), on the other hand - I am pretty sure that there are bunch
> >>>>of places where linux-vserver is more advanced.
> >>>>I spun off freeVPS when Jacques virtually stopped releasing anything.
> >>>>Yet, seeing how linux-vserver took off - I wander what your feelings are
> >>>>about merging projects & working together.
> >>>
> >>>
> >>>I always tried to keep contact to Alexey Lyashkov, who,
> >>>if I'm not mistaken, started and maintains the vserver
> >>>branch, now known as freeVPS (I wonder if that information
> >>>is incomplete?)
> >>>
> >>>I'm forwarding this to the mailing list, because I think
> >>>it is of interest for the community, and I hope you do not
> >>>take this as a personal offense (which isn't intended).
> >>>
> >>>some facts (as I see them):
> >>>
> >>>- freeVPS has some features the current linux-vserver
> >>> implementation lacks (memory, networking, ...)
> >>>
> >>>- freeVPS is limited to a certain kernel (RH 2.4.18)
> >>> and distribution (RedHat 7.3) and I assume arch
> >>> (i386) too
> >>>
> >>>- the License of tools and kernel patches is not
> >>> obvious to me, although kernel patches basically
> >>> default to GPL
> >>>
> >>>- the changes freeVPS made to the RH kernel are very
> >>> intrusive and might introduce various issues which
> >>> need some reviewing and a lot of testing
> >>>
> >>>my opinion:
> >>>
> >>>I'm convinced that 'working together' in a well defined
> >>>way, and even 'merging' various parts, provided that they
> >>>are covered by an open and free license, could be very
> >>>beneficial for both projects, but I currently do not see
> >>>a simple way to do that (ideas welcome ;) ...
> >>>
> >>>That said, I'm not convinced that it can't be done, it
> >>>just needs some work on both sides and especially some
> >>>official statements from your side, what how and why
> >>>psoft is/will be involved in this (well there is a
> >>>commercial product H-Sphere, right?)
> >>>
> >>>btw, linux-vserver development is free, and as I said
> >>>many times, patches are always welcome, so if your aim
> >>>is to 'improve' the quality of a free linux-vserver
> >>>implementation, publishing patches agains recent dev.
> >>>versions would be a great way to do that ...
> >>>
> >>>Now here is the point, where I would like to ask the
> >>>community for their opinion on that issue, because I
> >>>might be the current project leader, but the project
> >>>itself has evolved and become a community project.
> >>>
> >>>best,
> >>>Herbert
> >>>
> >>>
> >>>
> >>>>Best Regards,
> >>>>Igor Seletskiy
> >>>
> >>>
> >>>
> >>>
> >>>
> >>_______________________________________________
> >>Vserver mailing list
> >>Vserver_at_list.linux-vserver.org
> >>http://list.linux-vserver.org/mailman/listinfo/vserver
> >
> > _______________________________________________
> > Vserver mailing list
> > Vserver_at_list.linux-vserver.org
> > http://list.linux-vserver.org/mailman/listinfo/vserver
> >
> >
> _______________________________________________
> Vserver mailing list
> Vserver_at_list.linux-vserver.org
> http://list.linux-vserver.org/mailman/listinfo/vserver
>
_______________________________________________
Vserver mailing list
Vserver_at_list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver