“It’s important to bear in mind that UnitedLinux is purely an enterprise play. While the new UnitedLinux distribution will be their in-common product targeted at you folks, the four companies will continue to maintain their own product lines for other markets. Since the Linux enterprise marketplace is dominated by Red Hat, you really have to wonder how big a ripple this will make in the pond.” Editorial at ZDNews.
UnitedLinux is Purely an Enterprise Play
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Yes, according to officials at Borland with whom I spoke. As the developers of Kylix–a RAD tool for Linux from the company that invented RAD tools–differences in distributions are a problem for Borland. Officially, they only support Red Hat 7.1, Mandrake 8.0, and SuSE 7.2. (end of article citation).
We all know Linux distributions suck!!
Linux distributions always compete with each other by changing directory layout without a valid reason except. They all create a problem to those wanting to use Linux as a viable platform for their particular application.
In graphics Linux could provide a good (and faster than WinNT) network rendering farm but the differences are so big that software is released for a fixed in time and a oarticular distribution. If you spend $2000 USD on software then you don’t like to be closed on a time box.
The same applies on development software, like Borland’s.
If they want to be profitable (at least to pay the salaries of the developers) they have to support 2/3 most known/used distributions. This really sucks for an enterprise approach.
The other option is to stay away from Linux like Adobe does. Distributions are stoping Linux and earning money with it. This will be the end of Linux, caused by Linux parasites (excluding on the Server side).
So something like UnitedLinux has the potential to make things markedly simpler for an ISV like Borland. (end of article citation:-).
If everyone just follows LSB; and have support for RPM (officially used by LSB); things would be much better. That’s the problem of having everything under a few umbrellas. For example, how many versions of FreeBSD is there with compatiblity problems?
Most follow the LSB but it doesn’t change much and it isn’t complete enough. Also RPM isn’t a standard, it’s a suggestion, just because everyone uses RPM somehow. It’s no problem to install a RPM on a Debian system but it’s a problem to install a deb on a RPM system. Debian can’t just switch to RPM though because RPM is missing features that are needed to make APT working as good as it does. So we will hopefully see a new packaging format soon that can be used by everyone. See this for example:
http://www.linuxbase.org/talks/pkg20001129.html
But I’m not sure if we will still see it this century. The funny thing is, that all those efforts (that are taking forever right now) wouldn’t be neccessary if someone (Linus and co) would have released an official GNU/Linux distribution.
I hope that GNU won’t make the same mistake with GNU/Hurd. But AFAIK their plan is to create a complete operating system, just like FreeBSD.
All that may be needed to get the ball rolling is someone who creates a new package format. A format 100% compatible with both RPM and DEB. Just make it happen and people might start using it.
You can’t make the packages RPM and DEB compatible because they are too different in structure. You have to create something new and that’s what they do. But obviously they are not very fast, maybe not even very interested. I mean, the incompatible RPM story works very well for RedHat in making sure they get “RedHat only” software… It’s probably not much different for SuSE. And Debian has no reason to be worried either, it works well for them. Debian doesn’t care much about proprietory software anyway. But those are the big players that have to accept the new packaging format, otherwise it has no chance to become a standard. Maybe they are already working their ass off and I just didn’t hear anything about it, who knows.
Why does anyone care about supporting debian, let the little 15 year old kids fend for them selves. Most of them are too leet to use package managers, they need to compile the source themselves.
….
…
Now I begin to wonder weither osnews readers are really the “world’s technological elite” or just the lowest kind of trollscum. If every discussion goes like this from now on, this place is worthless. *sad*
I hope that GNU won’t make the same mistake with GNU/Hurd. But AFAIK their plan is to create a complete operating system, just like FreeBSD.
One of the mistakes they won’t make is forcing everyone to call it GNU/Hurd; they would shorten it as GNU.
Why does anyone care about supporting debian, let the little 15 year old kids fend for them selves. Most of them are too leet to use package managers, they need to compile the source themselves.
And this proves that some humans evolved from slime.
Now I begin to wonder weither osnews readers are really the “world’s technological elite” or just the lowest kind of trollscum. If every discussion goes like this from now on, this place is worthless. *sad*
If “Beatiful Mind” is any indicator; geniuses DO loose some screws every so often.
“One of the mistakes they won’t make is forcing everyone to call it GNU/Hurd”
Mandatory short interruption: Of course nobody ever _forced_ anyone to call the other system GNU/Linux either.
Mandatory short interruption: Of course nobody ever _forced_ anyone to call the other system GNU/Linux either.
Forced? No. Have politically correct GNU hippies flooding your mail box demanding for a change? yes. Mentioning at every @$%#% free software conference that Linux is GNU/linux? Yes
You can’t make the packages RPM and DEB compatible because they are too different in structure.
I know Debian and Redhat have different structure and rules for where to put config files etc. But I can’t come to think of any differences so big that it can’t be solved by the package manager. Maybe I just don’t know enough of how RPMs and DEBs differ. Will you enlighten me on the problems please?
This trolling is getting on my nerves.
(not pointed to ealm)
ealm:
“know Debian and Redhat have different structure and rules for where to put config files etc. But I can’t come to think of any differences so big that it can’t be solved by the package manager. Maybe I just don’t know enough of how RPMs and DEBs differ. Will you enlighten me on the problems please?”
A big difference is that RPM also has file dependencies and uses those a lot, deb hasn’t. Deb on the other hand has not just “dependencies” but also “suggestions” and “recommendations”, while RPM hasn’t. I don’t know much about other differences but I know they are there
(like how those packages are build, the dependency syntax, etc). Maybe it would be possible to write something like a “wrapper” around them, but I could imagine that just creating a new package format is easier and especially the cleaner solution.
A big difference is that RPM also has file dependencies and uses those a lot, deb hasn’t.
Why not just change it to only look for files. If the package the deb used to rely on is there the files will be too – no conflict as long as the packages are clean.
Deb on the other hand has not just “dependencies” but also “suggestions” and “recommendations”, while RPM hasn’t.
..and what’s the problem with that? You don’t have to give suggestions or recommendations if you don’t want. It could be seen as an extra feature to the rpm users.
I don’t know much about other differences but I know they are there
(like how those packages are build, the dependency syntax, etc).
True, the build process would probably be new, but it wouldn’t have to break compability. I also know that some config files are put in different places on debian and redhat, but it wouldn’t be a biggie to implement a feature to have the packagemanager making use of PATHS. Ie through a simple PATH variable a package file could tell package manager to put file.cfg in *CONFIGDIR*. This could mean /etc on debian and /etc/foo on redhat, whatever the CONFIGDIR path is set to.
Maybe it would be possible to write something like a “wrapper” around them, but I could imagine that just creating a new package format is easier and especially the cleaner solution.
Problem is, package maintainers in the different camps wouldn’t care for a new package format. It would take too much effort to get everyone converted at once. While a new package format, compatible with the existing ones, would have an alot easier time getting accepted as those who wants could start using it at once.
Just an idea cause something need to happend. And btw, don’t answer, don’t even comment on the trolls – just ignore them.