MV on Ubuntu

#31

dawn wrote:

Quote:

I forget what thread it was in, likely the one about someone
dumping lots of TigerLogic stock, in which case it is best to start
a new thread anyway. Glen was mentioning wanting to use other
flavors of unix than RedHat for his MV server environment. I don't
know what other versions of MV run on various linux distros, but I
was just reading a Cache ng thread where people said they were
successfully running Cache' on Ubuntu, but that it was not a
supported platform. Like most companies who run on any flavor of
linux, I'm pretty sure they are researching that possibility.

Just FYI. --dawn

For Ubuntu as a server platform I'd stick closely to the LTS (long
term support) releases which are intended to have an 18 month life
cycle. The desktop release schedule is IMO far too likely to produce
unstable server platforms, but the LTS releases are very stable. So
one would run a stable server on 6.10 then 8.04 then 9.10, etc.
--
Cheers, SDM -- a 21st Century Schizoid Man
Systems Theory internet music project: <www.systemstheory.net>
on MySpace: <www.myspace.com/systemstheory>
on Last FM: <www.last.fm/music/Systems+Theory>
get "Codetalkers" *free* at <www.mikedickson.org.uk/codetalkers>
NP: nothing

#32

dawn wrote:

Quote:

I forget what thread it was in, likely the one about someone
dumping lots of TigerLogic stock, in which case it is best to start
a new thread anyway. Glen was mentioning wanting to use other
flavors of unix than RedHat for his MV server environment. I don't
know what other versions of MV run on various linux distros, but I
was just reading a Cache ng thread where people said they were
successfully running Cache' on Ubuntu, but that it was not a
supported platform. Like most companies who run on any flavor of
linux, I'm pretty sure they are researching that possibility.

Just FYI. --dawn

For Ubuntu as a server platform I'd stick closely to the LTS (long
term support) releases which are intended to have an 18 month life
cycle. The desktop release schedule is IMO far too likely to produce
unstable server platforms, but the LTS releases are very stable. So
one would run a stable server on 6.10 then 8.04 then 9.10, etc.
--
Cheers, SDM -- a 21st Century Schizoid Man
Systems Theory internet music project: <www.systemstheory.net>
on MySpace: <www.myspace.com/systemstheory>
on Last FM: <www.last.fm/music/Systems+Theory>
get "Codetalkers" *free* at <www.mikedickson.org.uk/codetalkers>
NP: nothing

#33

dawn wrote:

Quote:

I forget what thread it was in, likely the one about someone
dumping lots of TigerLogic stock, in which case it is best to start
a new thread anyway. Glen was mentioning wanting to use other
flavors of unix than RedHat for his MV server environment. I don't
know what other versions of MV run on various linux distros, but I
was just reading a Cache ng thread where people said they were
successfully running Cache' on Ubuntu, but that it was not a
supported platform. Like most companies who run on any flavor of
linux, I'm pretty sure they are researching that possibility.

Just FYI. --dawn

For Ubuntu as a server platform I'd stick closely to the LTS (long
term support) releases which are intended to have an 18 month life
cycle. The desktop release schedule is IMO far too likely to produce
unstable server platforms, but the LTS releases are very stable. So
one would run a stable server on 6.10 then 8.04 then 9.10, etc.
--
Cheers, SDM -- a 21st Century Schizoid Man
Systems Theory internet music project: <www.systemstheory.net>
on MySpace: <www.myspace.com/systemstheory>
on Last FM: <www.last.fm/music/Systems+Theory>
get "Codetalkers" *free* at <www.mikedickson.org.uk/codetalkers>
NP: nothing

#34

Anthony.Youngman wrote:

Quote:

I've been active on the LSB, which is SUPPOSED to solve your problems
for you.

LSB is getting there, doing a great job, not quite there yet. Thanks
for any effort in that area.

Quote:

Thing is, if you create a package for any distro, you SHOULD be able
to put a load of "depends on" stuff in your package, and it won't
install unless they are there (indeed, it should install them for
you).

So if you need a specific version of gcc, or glibc2, or whatever, just
put that in your package as a "depends on", and your install should
work across pretty much all recent versions of that distro. That's
actually where Debian scores over RedHat, because pretty much any .deb
will install on pretty much any Debian-based distro (including
Ubuntu), while rpm stuff can be very temperamental about distros (we
have SuSE to thank for that :-(

It's this key point that confounds me with Linux. It's mired in the
same DLL Hell scenario that prompted the evolution of the .NET
Framework where assemblies of different releases can coexist. In
Linux:
- I can load package X that depends on package B v1.0, and another
package Y that also depends on package B v1.0.
- Then I upgrade package X to a new release (intentionally or
unknowingly) which now requires package B v1.1.
- I upgrade B to v1.1 and package X is now functional, but package Y
is broken.
- We now need to wait for the author of package Y to break up with his
girlfriend, get over a bad cold, or otherwise find time to upgrade the
software to work with package B v1.1.
- Assuming package Y gets upgraded we later find that something we
really needed, package Z, no longer works because it relied on the
prior release of package Y.
- For whatever reason we can't get changes for package Z. Upgrading
package Y auto-upgraded some other packages, and in order to get back
to a functional state we need to completely reinstall the system.

Yeah, been there, done that.

Ahh, but it's Open Source! Well, that's all very nice but as Martin
and a million others will tell ya, Open Source is only as good as the
people who contribute, not the people who download and rave about how
good it is. So unless you have free time, and skills, to maintain
your free software, Dependency Hell can kill ya with Linux (and
Windows COM).

The point here is not some all-encompassing statement that Linux is
bad - that's not my view in the least - but that a stable distros can
be problematic even on minor auto upgrades via yum, apt, etc, and
volatile distros like Fedora and Ubuntu can be really problematic for
production servers that require consistent stability.

If some Linux distro has no problem supporting multiple versions of
package B so that X and Y can coexist in harmony, please let me in on
the secret.

T

#35

Anthony.Youngman wrote:

Quote:

I've been active on the LSB, which is SUPPOSED to solve your problems
for you.

LSB is getting there, doing a great job, not quite there yet. Thanks
for any effort in that area.

Quote:

Thing is, if you create a package for any distro, you SHOULD be able
to put a load of "depends on" stuff in your package, and it won't
install unless they are there (indeed, it should install them for
you).

So if you need a specific version of gcc, or glibc2, or whatever, just
put that in your package as a "depends on", and your install should
work across pretty much all recent versions of that distro. That's
actually where Debian scores over RedHat, because pretty much any .deb
will install on pretty much any Debian-based distro (including
Ubuntu), while rpm stuff can be very temperamental about distros (we
have SuSE to thank for that :-(

It's this key point that confounds me with Linux. It's mired in the
same DLL Hell scenario that prompted the evolution of the .NET
Framework where assemblies of different releases can coexist. In
Linux:
- I can load package X that depends on package B v1.0, and another
package Y that also depends on package B v1.0.
- Then I upgrade package X to a new release (intentionally or
unknowingly) which now requires package B v1.1.
- I upgrade B to v1.1 and package X is now functional, but package Y
is broken.
- We now need to wait for the author of package Y to break up with his
girlfriend, get over a bad cold, or otherwise find time to upgrade the
software to work with package B v1.1.
- Assuming package Y gets upgraded we later find that something we
really needed, package Z, no longer works because it relied on the
prior release of package Y.
- For whatever reason we can't get changes for package Z. Upgrading
package Y auto-upgraded some other packages, and in order to get back
to a functional state we need to completely reinstall the system.

Yeah, been there, done that.

Ahh, but it's Open Source! Well, that's all very nice but as Martin
and a million others will tell ya, Open Source is only as good as the
people who contribute, not the people who download and rave about how
good it is. So unless you have free time, and skills, to maintain
your free software, Dependency Hell can kill ya with Linux (and
Windows COM).

The point here is not some all-encompassing statement that Linux is
bad - that's not my view in the least - but that a stable distros can
be problematic even on minor auto upgrades via yum, apt, etc, and
volatile distros like Fedora and Ubuntu can be really problematic for
production servers that require consistent stability.

If some Linux distro has no problem supporting multiple versions of
package B so that X and Y can coexist in harmony, please let me in on
the secret.

T

#36

Anthony.Youngman wrote:

Quote:

I've been active on the LSB, which is SUPPOSED to solve your problems
for you.

LSB is getting there, doing a great job, not quite there yet. Thanks
for any effort in that area.

Quote:

Thing is, if you create a package for any distro, you SHOULD be able
to put a load of "depends on" stuff in your package, and it won't
install unless they are there (indeed, it should install them for
you).

So if you need a specific version of gcc, or glibc2, or whatever, just
put that in your package as a "depends on", and your install should
work across pretty much all recent versions of that distro. That's
actually where Debian scores over RedHat, because pretty much any .deb
will install on pretty much any Debian-based distro (including
Ubuntu), while rpm stuff can be very temperamental about distros (we
have SuSE to thank for that :-(

It's this key point that confounds me with Linux. It's mired in the
same DLL Hell scenario that prompted the evolution of the .NET
Framework where assemblies of different releases can coexist. In
Linux:
- I can load package X that depends on package B v1.0, and another
package Y that also depends on package B v1.0.
- Then I upgrade package X to a new release (intentionally or
unknowingly) which now requires package B v1.1.
- I upgrade B to v1.1 and package X is now functional, but package Y
is broken.
- We now need to wait for the author of package Y to break up with his
girlfriend, get over a bad cold, or otherwise find time to upgrade the
software to work with package B v1.1.
- Assuming package Y gets upgraded we later find that something we
really needed, package Z, no longer works because it relied on the
prior release of package Y.
- For whatever reason we can't get changes for package Z. Upgrading
package Y auto-upgraded some other packages, and in order to get back
to a functional state we need to completely reinstall the system.

Yeah, been there, done that.

Ahh, but it's Open Source! Well, that's all very nice but as Martin
and a million others will tell ya, Open Source is only as good as the
people who contribute, not the people who download and rave about how
good it is. So unless you have free time, and skills, to maintain
your free software, Dependency Hell can kill ya with Linux (and
Windows COM).

The point here is not some all-encompassing statement that Linux is
bad - that's not my view in the least - but that a stable distros can
be problematic even on minor auto upgrades via yum, apt, etc, and
volatile distros like Fedora and Ubuntu can be really problematic for
production servers that require consistent stability.

If some Linux distro has no problem supporting multiple versions of
package B so that X and Y can coexist in harmony, please let me in on
the secret.

T

#37

Anthony.Youngman wrote:

Quote:

I've been active on the LSB, which is SUPPOSED to solve your problems
for you.

LSB is getting there, doing a great job, not quite there yet. Thanks
for any effort in that area.

Quote:

Thing is, if you create a package for any distro, you SHOULD be able
to put a load of "depends on" stuff in your package, and it won't
install unless they are there (indeed, it should install them for
you).

So if you need a specific version of gcc, or glibc2, or whatever, just
put that in your package as a "depends on", and your install should
work across pretty much all recent versions of that distro. That's
actually where Debian scores over RedHat, because pretty much any .deb
will install on pretty much any Debian-based distro (including
Ubuntu), while rpm stuff can be very temperamental about distros (we
have SuSE to thank for that :-(

It's this key point that confounds me with Linux. It's mired in the
same DLL Hell scenario that prompted the evolution of the .NET
Framework where assemblies of different releases can coexist. In
Linux:
- I can load package X that depends on package B v1.0, and another
package Y that also depends on package B v1.0.
- Then I upgrade package X to a new release (intentionally or
unknowingly) which now requires package B v1.1.
- I upgrade B to v1.1 and package X is now functional, but package Y
is broken.
- We now need to wait for the author of package Y to break up with his
girlfriend, get over a bad cold, or otherwise find time to upgrade the
software to work with package B v1.1.
- Assuming package Y gets upgraded we later find that something we
really needed, package Z, no longer works because it relied on the
prior release of package Y.
- For whatever reason we can't get changes for package Z. Upgrading
package Y auto-upgraded some other packages, and in order to get back
to a functional state we need to completely reinstall the system.

Yeah, been there, done that.

Ahh, but it's Open Source! Well, that's all very nice but as Martin
and a million others will tell ya, Open Source is only as good as the
people who contribute, not the people who download and rave about how
good it is. So unless you have free time, and skills, to maintain
your free software, Dependency Hell can kill ya with Linux (and
Windows COM).

The point here is not some all-encompassing statement that Linux is
bad - that's not my view in the least - but that a stable distros can
be problematic even on minor auto upgrades via yum, apt, etc, and
volatile distros like Fedora and Ubuntu can be really problematic for
production servers that require consistent stability.

If some Linux distro has no problem supporting multiple versions of
package B so that X and Y can coexist in harmony, please let me in on
the secret.

T

#38

Anthony.Youngman wrote:

Quote:

I've been active on the LSB, which is SUPPOSED to solve your problems
for you.

LSB is getting there, doing a great job, not quite there yet. Thanks
for any effort in that area.

Quote:

Thing is, if you create a package for any distro, you SHOULD be able
to put a load of "depends on" stuff in your package, and it won't
install unless they are there (indeed, it should install them for
you).

So if you need a specific version of gcc, or glibc2, or whatever, just
put that in your package as a "depends on", and your install should
work across pretty much all recent versions of that distro. That's
actually where Debian scores over RedHat, because pretty much any .deb
will install on pretty much any Debian-based distro (including
Ubuntu), while rpm stuff can be very temperamental about distros (we
have SuSE to thank for that :-(

It's this key point that confounds me with Linux. It's mired in the
same DLL Hell scenario that prompted the evolution of the .NET
Framework where assemblies of different releases can coexist. In
Linux:
- I can load package X that depends on package B v1.0, and another
package Y that also depends on package B v1.0.
- Then I upgrade package X to a new release (intentionally or
unknowingly) which now requires package B v1.1.
- I upgrade B to v1.1 and package X is now functional, but package Y
is broken.
- We now need to wait for the author of package Y to break up with his
girlfriend, get over a bad cold, or otherwise find time to upgrade the
software to work with package B v1.1.
- Assuming package Y gets upgraded we later find that something we
really needed, package Z, no longer works because it relied on the
prior release of package Y.
- For whatever reason we can't get changes for package Z. Upgrading
package Y auto-upgraded some other packages, and in order to get back
to a functional state we need to completely reinstall the system.

Yeah, been there, done that.

Ahh, but it's Open Source! Well, that's all very nice but as Martin
and a million others will tell ya, Open Source is only as good as the
people who contribute, not the people who download and rave about how
good it is. So unless you have free time, and skills, to maintain
your free software, Dependency Hell can kill ya with Linux (and
Windows COM).

The point here is not some all-encompassing statement that Linux is
bad - that's not my view in the least - but that a stable distros can
be problematic even on minor auto upgrades via yum, apt, etc, and
volatile distros like Fedora and Ubuntu can be really problematic for
production servers that require consistent stability.

If some Linux distro has no problem supporting multiple versions of
package B so that X and Y can coexist in harmony, please let me in on
the secret.

T

#39

Anthony.Youngman wrote:

Quote:

I've been active on the LSB, which is SUPPOSED to solve your problems
for you.

LSB is getting there, doing a great job, not quite there yet. Thanks
for any effort in that area.

Quote:

Thing is, if you create a package for any distro, you SHOULD be able
to put a load of "depends on" stuff in your package, and it won't
install unless they are there (indeed, it should install them for
you).

So if you need a specific version of gcc, or glibc2, or whatever, just
put that in your package as a "depends on", and your install should
work across pretty much all recent versions of that distro. That's
actually where Debian scores over RedHat, because pretty much any .deb
will install on pretty much any Debian-based distro (including
Ubuntu), while rpm stuff can be very temperamental about distros (we
have SuSE to thank for that :-(

It's this key point that confounds me with Linux. It's mired in the
same DLL Hell scenario that prompted the evolution of the .NET
Framework where assemblies of different releases can coexist. In
Linux:
- I can load package X that depends on package B v1.0, and another
package Y that also depends on package B v1.0.
- Then I upgrade package X to a new release (intentionally or
unknowingly) which now requires package B v1.1.
- I upgrade B to v1.1 and package X is now functional, but package Y
is broken.
- We now need to wait for the author of package Y to break up with his
girlfriend, get over a bad cold, or otherwise find time to upgrade the
software to work with package B v1.1.
- Assuming package Y gets upgraded we later find that something we
really needed, package Z, no longer works because it relied on the
prior release of package Y.
- For whatever reason we can't get changes for package Z. Upgrading
package Y auto-upgraded some other packages, and in order to get back
to a functional state we need to completely reinstall the system.

Yeah, been there, done that.

Ahh, but it's Open Source! Well, that's all very nice but as Martin
and a million others will tell ya, Open Source is only as good as the
people who contribute, not the people who download and rave about how
good it is. So unless you have free time, and skills, to maintain
your free software, Dependency Hell can kill ya with Linux (and
Windows COM).

The point here is not some all-encompassing statement that Linux is
bad - that's not my view in the least - but that a stable distros can
be problematic even on minor auto upgrades via yum, apt, etc, and
volatile distros like Fedora and Ubuntu can be really problematic for
production servers that require consistent stability.

If some Linux distro has no problem supporting multiple versions of
package B so that X and Y can coexist in harmony, please let me in on
the secret.

T

#40

Anthony.Youngman wrote:

Quote:

I've been active on the LSB, which is SUPPOSED to solve your problems
for you.

LSB is getting there, doing a great job, not quite there yet. Thanks
for any effort in that area.

Quote:

Thing is, if you create a package for any distro, you SHOULD be able
to put a load of "depends on" stuff in your package, and it won't
install unless they are there (indeed, it should install them for
you).

So if you need a specific version of gcc, or glibc2, or whatever, just
put that in your package as a "depends on", and your install should
work across pretty much all recent versions of that distro. That's
actually where Debian scores over RedHat, because pretty much any .deb
will install on pretty much any Debian-based distro (including
Ubuntu), while rpm stuff can be very temperamental about distros (we
have SuSE to thank for that :-(

It's this key point that confounds me with Linux. It's mired in the
same DLL Hell scenario that prompted the evolution of the .NET
Framework where assemblies of different releases can coexist. In
Linux:
- I can load package X that depends on package B v1.0, and another
package Y that also depends on package B v1.0.
- Then I upgrade package X to a new release (intentionally or
unknowingly) which now requires package B v1.1.
- I upgrade B to v1.1 and package X is now functional, but package Y
is broken.
- We now need to wait for the author of package Y to break up with his
girlfriend, get over a bad cold, or otherwise find time to upgrade the
software to work with package B v1.1.
- Assuming package Y gets upgraded we later find that something we
really needed, package Z, no longer works because it relied on the
prior release of package Y.
- For whatever reason we can't get changes for package Z. Upgrading
package Y auto-upgraded some other packages, and in order to get back
to a functional state we need to completely reinstall the system.

Yeah, been there, done that.

Ahh, but it's Open Source! Well, that's all very nice but as Martin
and a million others will tell ya, Open Source is only as good as the
people who contribute, not the people who download and rave about how
good it is. So unless you have free time, and skills, to maintain
your free software, Dependency Hell can kill ya with Linux (and
Windows COM).

The point here is not some all-encompassing statement that Linux is
bad - that's not my view in the least - but that a stable distros can
be problematic even on minor auto upgrades via yum, apt, etc, and
volatile distros like Fedora and Ubuntu can be really problematic for
production servers that require consistent stability.

If some Linux distro has no problem supporting multiple versions of
package B so that X and Y can coexist in harmony, please let me in on
the secret.

T