Doesn't [Red Hat] use a tweaked version of the kernel. What do the tweaks entail?
Sure we do (but the source RPM including all patches we're using is publically available - if they depend on one of the patches, you can apply it everywhere.)
The patches are mostly driver updates and additions, better support for Pentium III processors and some feature additions (large file support for the Enterprise Edition and such).
Does [Red Hat] have extensions so that that product only will run on it?
No. That would be Microsoft strategy. A vendor saying they release something only for Red Hat Linux usually means they compile it on Red Hat Linux, so they'll require the library versions we're shipping (stuff like glibc 2.0 vs. glibc 2.1, libstdc++ 2.8 vs. 2.9 vs. 3.0). Installing a couple of compat libraries will usually permit you to run it on anything else (just don't count on getting support if you do that).
We're all for LSB support - we wouldn't play any tricks to create Red Hat Linux-only software even if we could. (And we can't - since we release everything we do under the GPL, someone could just "abuse" the code easily).
We will not ship anything in the main distribution if we can't ship the source. If they did that, they'd end up with their driver being available for download on redhat.com and its possible inclusion on the Linux Applications CD. (And offering something for download is something they can do themselves).
A [GPL]ed driver can't be just ported to BSD, because doing so would [GPL]-infect the BSD kernel
Take a look at the FreeBSD source code. Look for "softupdates" and "math emulation". They may not be in by default, but it clearly shows GPL code can be used in the BSD world.
Is it truly necessary to release open sourced drivers?
Yes. Binary only drivers are definitely better than nothing, BUT:
Many distributions have strict policies against including binary only programs/drivers. Making it binary only means it won't be included in (at least) the standard kernel, Red Hat, Debian and Mandrake.
If they're kernel modules (which a lot of drivers are), they'll need to be updated every time you want to use a different kernel. It'll be a lot of work for the company to keep track of all new kernels, even if they support only the kernels released by the major distributions.
Linux is not the only OS around. Open-sourced drivers can be ported to *BSD (even though it's painful; as similar as most userspace code is, kernel code is quite different between them) and others. The various BSDs don't have a market share that would drive an average company to develop drivers for any of them (yet).
A kernel driver can crash the entire system. If it's binary only, it can't be fixed by the community. Do we want a version of Linux that crashes as frequently as Windows as soon as a certain hardware is used? I don't think so.
Well, the best solution would obviously be open-sourcing the whole thing - but if they won't do it, why not do both simultaneously?
Put a limited open-sourced driver up so everyone can use it and it can be included in distributions (and developed from there, chances are it will outdo the closed-source version some day), and at the same time, release a closed-source driver for download so people who need the extra functionality right now and don't insist on having everything in source form can use that.
Try to download a distribution other than a very basic one, and the companies make it difficult to impossible [...] Redhat gives you only the standard distribution
Please get your facts right. You can download all of Powertools (thereby turning your standard distribution into something like deluxe). We can't do the same thing for the professional version because of some ugly legal issues (the professional version contains patented crypto code).
If you find something legally distributable on a Red Hat Linux CD that is not available for download on the ftp servers, you've found a bug. Let me know and I'll fix it.
What if you want to send a clueless user to download package xyz from ftp://ftp.xyz.fsf/, and their DNS isn't configured to resolve the.fsf TLD? (Some people can't even fix their DNS settings because they don't have root...)
Another problem is dealing with 2 people creating the same TLD - if A creates.fsf and B creates another.fsf, how do you decide which xyz.fsf someone wants? I don't like the idea of getting 2 completely different http://linux.fsf/s depending on what machine I'm using to access it.
Any (good and workable) suggestions on fixing these problems?
I'd think that's true of virtually all Linux distributions - some are even easy to configure for non-Unix guys.
BSD style init scripts
Why would you call that an advantage? SysV init scripts are much less of a pain when you need to add some service automatically...
No RPM locking dependancy
No distribution has that - you can just take Red Hat, Debian, or whatever and compile stuff from source. All you lose when doing that without doing it properly is dependency checking for other packages that depend on the stuff you installed from source.
Really about time. Now all we need is some more people with write access - giving everyone read access is a very good first step (especially because distributors can finally start including post-release fixes!) - but I don't know if the (few) people with write access can keep track of the numerous patches this will generate. (Not doubting their qualification of course, nobody can keep track of 200 patches/day!)
Argh! Now that someone noticed it, I can as well make it official... Resistance is futile. Slashdot will be assimilated. Oops, no, we're not Microsoft, forget that.
It's not the same, though in the long run merging them will probably make sense.
They're very similar, but not exactly the same. unmaintained.sourceforge.net wants to create a list (probably with the purpose of someone just taking the initiative and releasing a new version), UFO wants to keep the stuff alive while trying to look for new maintainers and requires the consent of the original maintainer. So far, it hasn't really started off (largely my fault; I started it, didn't have enough time to work a lot on it myself, and didn't manage to start a real community effort). Contributors are VERY welcome...
I can see that this page is going to be attract free software wannabees, who see the opportunity to take responsibility for an already partially complete codebase in order to try to get kudos as the project manager. In reality though, this is likely to be bad for the project. I doubt that these newcomers will see the project as little more than an ego boost and a nice addition to their curriculum vitae, and many of these new 'project managers' will lack the ability or dedication to put the project back on track.
I agree that this is a potential problem - At ufo.bero.org, I'm trying to solve it by requiring that a new maintainer sends in a couple of patches before taking it over officially.
There's quite some interesting stuff left - drivers that manage old hardware the original programmer doesn't have access to anymore and some niche software some people rely on, but that doesn't have a use for the general public. I'd say there are a number of umaintained packages out there that are being worked on in 1000 places (ported to new systems) because the original maintainer isn't around anymore. This sort of duplicated work can be avoided by finding a new maintainer...
They're very similar indeed, but not exactly the same. unmaintained.sourceforge.net wants to create a list (probably with the purpose of someone just taking the initiative and releasing a new version), UFO (which has moved on to ufo.bero.org) wants to keep the stuff alive while trying to look for new maintainers and requires the consent of the original maintainer. So far, it hasn't really started off (largely my fault; I started it, didn't have enough time to work a lot on it myself, and didn't manage to start a real community effort). Contributors are welcome...
I'd call that a security issue - but then, you don't need to use their implementation. I for one won't. The protocol specs are out in the open, so they can't hide anything evil in there.
2)Interaction between all devices is handled by a standard protocol and each device is seen as a member of the same IP address?
That's one of the reasons why we need IPv6 at some time - every device could get its own.
Besides, it's always your option not to connect the fridge to the outside world while still having it connected to your local network and selected trusted IPs (control the connections to the outside world with ipchains or something similar)...
Debian [...] is dedicted to having Open Source software, unlike commercial distros which have no fear of packaging non-free software.
Not entirely true. Red Hat has the strict policy not to put anything that is not free on the main CD, with the sole exception being Netscape because the free replacements aren't ready yet. (Mozilla and Konqueror are great, but at this time, they're even more unstable than Netscape or lacking some features that are needed). We'll replace it as as soon as the replacements are ready.
How do the "simple", "point-n-click" "easy-to-use" "interfaces" hurt you? If you don't like them, don't use them.
One of the niceties of Linux is that you can use text mode, vi and TeX as well as easy-to-use tools.
The "idiots should be using an idiot OS" line of (un)thought is not quite valid - not everyone who doesn't know how to handle vi is an idiot, and not everyone who uses a computer should be overly technical. Today, virtually all books are written using computers - would you like to see your favorite writer's current work destroyed by a bluescreen? Or would you want him to spend a year trying to figure out TeX before writing his book?
No? So, we need an easy-to-use tool for him on a reliable OS.
If you don't want to use it, don't. Nobody is forcing these tools on you.
It's not about yet another GUI, it's about an IDE (Integrated Development Environment). The nicety of it is that they're planning to generate (native) Linux applications from [Borland C++ and Delphi] source originally written to run on Windoze - we may see even more Linux ports.
Here's why I based BeroLinux on Red Hat Linux (quite far back, I know) even though I had tried pretty much every distribution that was available:
Red Hat was (and definitely still is) a nice distribution to start from
Unlike the other commercial distributions, it's freely usable.
While dpkg has some advantages, rpm is much more of a standard format (most packages that are not part of any distribution are packaged as rpms if they're available in packaged form at all), it's easier to program for, and it's easier and faster to build packagages for.
dpkg has a few features too many - it is hard to build a good distribution that is based on Debian but doesn't have Debian's post-install stuff, which is sometimes hard for a newbie to handle
I've probably had a few more reasons - but these are the most important ones.
Did you have a look at the recent KDE 2.0 beta or a recent KDE 2.0 CVS snapshot? [If you haven't, download from kde.org or get Red Hat Linux binaries here]
Anyone who looks at it anywhere near objectively will notice that anyone who has used Windows can deal with it - the interfaces are similar, and as far as differences are concerned, KDE 2.0 wins in usability.
Something similar can be said about GNOME 1.2, which just needs some more time to get all the functionality implemented.
Red Hat Linux 7.0 will (probably) have an autologin feature for people who don't want to get used to the login process, and other distributions will probably follow.
KOffice (obviously) integrates perfectly with KDE - even StarOffice adds itself to the KDE menus so even the most stupid user can find it. Both of them can read M$-Office files, so converting old documents shouldn't be much of a problem.
I doubt a stupid user could tell the difference between a Windows system and a KDE 2 system that has been configured to look like Windows.
I agree about the "Code it. Use it. Debug it." part though - we need to demonstrate that we are not just a viable alternative, but the better one - if people don't care about reliablity, efficiency and speed, it's not as easy on the desktop as on servers...
Slashdot Mirror
Doesn't [Red Hat] use a tweaked version of the kernel. What do the tweaks entail?
Sure we do (but the source RPM including all patches we're using is publically available - if they depend on one of the patches, you can apply it everywhere.)
The patches are mostly driver updates and additions, better support for Pentium III processors and some feature additions (large file support for the Enterprise Edition and such).
Does [Red Hat] have extensions so that that product only will run on it?
No. That would be Microsoft strategy. A vendor saying they release something only for Red Hat Linux usually means they compile it on Red Hat Linux, so they'll require the library versions we're shipping (stuff like glibc 2.0 vs. glibc 2.1, libstdc++ 2.8 vs. 2.9 vs. 3.0).
Installing a couple of compat libraries will usually permit you to run it on anything else (just don't count on getting support if you do that).
We're all for LSB support - we wouldn't play any tricks to create Red Hat Linux-only software even if we could. (And we can't - since we release everything we do under the GPL, someone could just "abuse" the code easily).
We will not ship anything in the main distribution if we can't ship the source. If they did that, they'd end up with their driver being available for download on redhat.com and its possible inclusion on the Linux Applications CD.
(And offering something for download is something they can do themselves).
A [GPL]ed driver can't be just ported to BSD, because doing so would [GPL]-infect the BSD kernel
Take a look at the FreeBSD source code. Look for "softupdates" and "math emulation".
They may not be in by default, but it clearly shows GPL code can be used in the BSD world.
Yes. Binary only drivers are definitely better than nothing, BUT:
Well, the best solution would obviously be open-sourcing the whole thing - but if they won't do it, why not do both simultaneously?
Put a limited open-sourced driver up so everyone can use it and it can be included in distributions (and developed from there, chances are it will outdo the closed-source version some day), and at the same time, release a closed-source driver for download so people who need the extra functionality right now and don't insist on having everything in source form can use that.
Actually we DO release it. ;)
We don't believe in proprietary software any more than Debian does.
The clustering tools are released under the terms of the GPL.
Try to download a distribution other than a very basic one, and the companies make it difficult to impossible [...] Redhat gives you only the standard distribution
Please get your facts right.
You can download all of Powertools (thereby turning your standard distribution into something like deluxe).
We can't do the same thing for the professional version because of some ugly legal issues (the professional version contains patented crypto code).
If you find something legally distributable on a Red Hat Linux CD that is not available for download on the ftp servers, you've found a bug. Let me know and I'll fix it.
What if you want to send a clueless user to download package xyz from ftp://ftp.xyz.fsf/, and their DNS isn't configured to resolve the .fsf TLD? (Some people can't even fix their DNS settings because they don't have root...)
.fsf and B creates another .fsf, how do you decide which xyz.fsf someone wants? I don't like the idea of getting 2 completely different http://linux.fsf/s depending on what machine I'm using to access it.
Another problem is dealing with 2 people creating the same TLD - if A creates
Any (good and workable) suggestions on fixing these problems?
- Stable out of the box
True - so are Red Hat, Debian and many others.
Easy to configure (for the average Unix guy)
I'd think that's true of virtually all Linux distributions - some are even easy to configure for non-Unix guys.
BSD style init scripts
Why would you call that an advantage? SysV init scripts are much less of a pain when you need to add some service automatically...
No RPM locking dependancy
No distribution has that - you can just take Red Hat, Debian, or whatever and compile stuff from source. All you lose when doing that without doing it properly is dependency checking for other packages that depend on the stuff you installed from source.
Really about time. Now all we need is some more people with write access - giving everyone read access is a very good first step (especially because distributors can finally start including post-release fixes!) - but I don't know if the (few) people with write access can keep track of the numerous patches this will generate.
(Not doubting their qualification of course, nobody can keep track of 200 patches/day!)
Argh! Now that someone noticed it, I can as well make it official...
Resistance is futile. Slashdot will be assimilated.
Oops, no, we're not Microsoft, forget that.
It's not the same, though in the long run merging them will probably make sense.
They're very similar, but not exactly the same.
unmaintained.sourceforge.net wants to create a list (probably with the purpose of someone just taking the initiative and releasing a new version), UFO wants to keep the stuff alive while trying to look for new maintainers and requires the consent of the original maintainer. So far, it hasn't really started off (largely my fault; I started it, didn't have enough time to work a lot on it myself, and didn't manage to start a real community effort). Contributors are VERY welcome...
I can see that this page is going to be attract
free software wannabees, who see the opportunity to take responsibility for an already partially complete codebase in order to try to get kudos as the project manager. In reality though, this is likely to be bad for the project. I doubt that these newcomers will see the project as little more than an ego boost and a nice addition to their curriculum vitae, and many of these new 'project managers' will lack the ability or dedication to put the project back on track.
I agree that this is a potential problem - At ufo.bero.org, I'm trying to solve it by requiring that a new maintainer sends in a couple of patches before taking it over officially.
There's quite some interesting stuff left - drivers that manage old hardware the original programmer doesn't have access to anymore and some niche software some people rely on, but that doesn't have a use for the general public.
I'd say there are a number of umaintained packages out there that are being worked on in 1000 places (ported to new systems) because the original maintainer isn't around anymore. This sort of duplicated work can be avoided by finding a new maintainer...
They're very similar indeed, but not exactly the same.
unmaintained.sourceforge.net wants to create a list (probably with the purpose of someone just taking the initiative and releasing a new version), UFO (which has moved on to ufo.bero.org) wants to keep the stuff alive while trying to look for new maintainers and requires the consent of the original maintainer. So far, it hasn't really started off (largely my fault; I started it, didn't have enough time to work a lot on it myself, and didn't manage to start a real community effort). Contributors are welcome...
Sure - it's running on Red Hat Linux after all. ;) ;)
Oh, and besides the line is so bad that even all the traffic it can stand won't kill the server.
No need, just --force installation. /opt/kde2, the only "conflicting" files are config stuff.
The beta packages go to
1) Microsoft is implementing it
I'd call that a security issue - but then, you don't need to use their implementation. I for one won't.
The protocol specs are out in the open, so they can't hide anything evil in there.
2)Interaction between all devices is handled by a standard protocol and each device is seen as a member of the same IP address?
That's one of the reasons why we need IPv6 at some time - every device could get its own.
Besides, it's always your option not to connect the fridge to the outside world while still having it connected to your local network and selected trusted IPs (control the connections to the outside world with ipchains or something similar)...
Red Hat Linux (tested on 6.2) packages for beta 2
for x86, alpha and sparc are now available at http://www.bero.org/kde/.
Debian [...] is dedicted to having Open Source software, unlike commercial distros which have no fear of packaging non-free software.
Not entirely true.
Red Hat has the strict policy not to put anything that is not free on the main CD, with the sole exception being Netscape because the free replacements aren't ready yet. (Mozilla and Konqueror are great, but at this time, they're even more unstable than Netscape or lacking some features that are needed). We'll replace it as as soon as the replacements are ready.
How do the "simple", "point-n-click" "easy-to-use" "interfaces" hurt you?
If you don't like them, don't use them.
One of the niceties of Linux is that you can use text mode, vi and TeX as well as easy-to-use tools.
The "idiots should be using an idiot OS" line of (un)thought is not quite valid - not everyone who doesn't know how to handle vi is an idiot, and not everyone who uses a computer should be overly technical.
Today, virtually all books are written using computers - would you like to see your favorite writer's current work destroyed by a bluescreen? Or would you want him to spend a year trying to figure out TeX before writing his book?
No? So, we need an easy-to-use tool for him on a reliable OS.
If you don't want to use it, don't. Nobody is forcing these tools on you.
It's not about yet another GUI, it's about an IDE (Integrated Development Environment).
The nicety of it is that they're planning to generate (native) Linux applications from [Borland C++ and Delphi] source originally written to run
on Windoze - we may see even more Linux ports.
I've probably had a few more reasons - but these are the most important ones.
Did you have a look at the recent KDE 2.0 beta or a recent KDE 2.0 CVS snapshot? [If you haven't, download from kde.org or get Red Hat Linux binaries here]
Anyone who looks at it anywhere near objectively will notice that anyone who has used Windows can deal with it - the interfaces are similar, and as far as differences are concerned, KDE 2.0 wins in usability.
Something similar can be said about GNOME 1.2, which just needs some more time to get all the functionality implemented.
Red Hat Linux 7.0 will (probably) have an autologin feature for people who don't want to get used to the login process, and other distributions will probably follow.
KOffice (obviously) integrates perfectly with KDE - even StarOffice adds itself to the KDE menus so even the most stupid user can find it. Both of them can read M$-Office files, so converting old documents shouldn't be much of a problem.
I doubt a stupid user could tell the difference between a Windows system and a KDE 2 system that has been configured to look like Windows.
I agree about the "Code it. Use it. Debug it." part though - we need to demonstrate that we are not just a viable alternative, but the better one - if people don't care about reliablity, efficiency and speed, it's not as easy on the desktop as on servers...