I believe France has the worst legislation ever. As an end-user you are not allowed to make copies even of your own media if it involves circumventing DRM, and you still pay a tax on removable media (CD, DVD, hard drives, flash memory) and players (MP3, video, mobile phones) to cover for losses due to this. You are not allowed to download copyrighted stuff off the net (three strikes) but the government is preparing a new tax on all Internet users to cover for losses due to this. Of course copyright holders retain the right to sue your ass into oblivion even after being cut off the net, up to 300,000 euros fine and 3 years in jail.
Not really efficient. In every French company and administration (including ministries) I have worked with you find at least one multi-TB server with more recent movies, music, software and books you could ever find time for in your whole life.
This "fluidity" as you say, is the bread and butter of all companies who need to put software on a Linux server for more than a year. Everywhere I can see, RedHat is used as the default OS for servers because it has been declared Oracle-compatible, and Fedora is only a testbed for RedHat. It is really a sad thing that people use the same distro for desktop as a testbed for server-based software, since they have completely different requirements. I do not blame RedHat, they do not have infinite resources. I blame companies for picking RedHat for anything server-based.
Being able to to install an old Linux media and (perhaps) successfully upgrade to a current state isn't really a selling point
My point was: the distribution is continuous, as opposed to RPM-based distributions that have born-from-scratch versions every 6 months. This allows you to pin some applications in a given state (version number) and let others evolve as you see fit. This is extremely useful if you are managing servers that are meant to last several years 24x7. Your own software may depend on some fixed-version of a given set of libraries and you do not want (or cannot) re-test it with every new release of external libraries you do not control.
This continuity takes all Debian packages as a whole, where dependencies are finely described for each package. When I say that package X depends on packages Y and Z (with fine-grained version numbers) I say this forever in the sense that somebody somewhere might have to get stuck with this version for several years and wants to know the dependencies it causes. You usually run a Debian instance with packages taken from various stages (stable/unstable/testing). You may want to keep a given version of the kernel or the C++ libs for compatibility reasons but run the latest Gnome on top. You end up with a system that is not purely 'stable', 'unstable' or 'testing' but has the actual parts in the way you want. For long-term servers this removes quite a lot of headaches.
It sounds like making packages for deb-repos is much more time consuming than making rpm-packages for a specific Fedora release
In a sense yes: the total amount of work needed to build a Debian repository is much greater than what is needed for a Fedora release, because Debian contributors outnumber Fedora by 100 to 1. But for every individual package maintainer the work is quite simple. Most often this job is done by package authors themselves anyway.
RPM is probably a better packaging mechanism than deb. No doubt yum has more or less the same intelligence as apt when it comes to upgrading a machine.
The real difference comes from the repositories. RPM-based repositories are strictly bound to a unique binary distribution (RedHat 8 or 9 or SuSE 10 or 11), so they gravitate around the same set of basic packages and have trivial dependency descriptions, e.g. you want gnome, you get evolution. APT-based repositories are not bound to any single version of Debian, you can fetch a 2-year old Debian installation CD and run an upgrade to the latest and brightest using a reliable connection. This implies having much more detailed dependency descriptions for each package, like: this package requires a mail user agent, a database client, library X version 1.2 or higher, and library Y version 2.2 (strict).
To build such a repository requires a huge amount of manpower, which Debian draws from the mass of its contributors (thousands). Each package maintainer takes greatest care of maintaining correct and usable dependency descriptions, abusive or incomplete dependencies are treated as bugs. RedHat cannot fight these numbers: how many people are working on maintaining their repository stability and consistency?
If RedHat wants to improve their repositories and get closer to Debian quality, they have to destroy the boundaries between successive distributions and make the transition continuous. This implies in turn having much more fine-grained dependency descriptions between packages. Repositories get more reliable, the RPM upgrade nightmare disappears and yum looks just as smart as apt.
Re:reason for, reason not for
on
Blank Keyboard
·
· Score: 1
You do not realize how much good this brings until you work with foreign keyboards, believe me. I used to work for a multinational institute where all developpers would have US keyboards, but administrative people could choose whatever they wanted. Say you want to type an e-mail on the secretary's Mac and you end up on a german, french, sometimes hebrew or even russian keyboard. You confidently type away your lines and it takes a couple of secondes before you realize what you see is definitely not what you typed.
The real issue then is to find whatever icon/menu should be activated to bring the machine back (temporarily) to a standard US keyboard. And voila! You fingers start flying again on some keyboard showing key symbols you have never seen before. Beats mute keyboards, doesn't it?
Actually I am typing this on a french keyboard configured as US. Finding anything else but a french keyboard in France is an impossible task.
This whole "study" is bullshit. The figures are
made up from wind. To give an example: you might be interested in knowing that open-source software is counted as pirated (since it was not purchased).
A more complete analysis can be found on:
http://chosechu.blogspot.com/
Slashdot Mirror
I believe France has the worst legislation ever. As an end-user you are not allowed to make copies even of your own media if it involves circumventing DRM, and you still pay a tax on removable media (CD, DVD, hard drives, flash memory) and players (MP3, video, mobile phones) to cover for losses due to this. You are not allowed to download copyrighted stuff off the net (three strikes) but the government is preparing a new tax on all Internet users to cover for losses due to this. Of course copyright holders retain the right to sue your ass into oblivion even after being cut off the net, up to 300,000 euros fine and 3 years in jail. Not really efficient. In every French company and administration (including ministries) I have worked with you find at least one multi-TB server with more recent movies, music, software and books you could ever find time for in your whole life.
This "fluidity" as you say, is the bread and butter of all companies who need to put software on a Linux server for more than a year. Everywhere I can see, RedHat is used as the default OS for servers because it has been declared Oracle-compatible, and Fedora is only a testbed for RedHat. It is really a sad thing that people use the same distro for desktop as a testbed for server-based software, since they have completely different requirements. I do not blame RedHat, they do not have infinite resources. I blame companies for picking RedHat for anything server-based.
Being able to to install an old Linux media and (perhaps) successfully upgrade to a current state isn't really a selling point
My point was: the distribution is continuous, as opposed to RPM-based distributions that have born-from-scratch versions every 6 months. This allows you to pin some applications in a given state (version number) and let others evolve as you see fit. This is extremely useful if you are managing servers that are meant to last several years 24x7. Your own software may depend on some fixed-version of a given set of libraries and you do not want (or cannot) re-test it with every new release of external libraries you do not control.
This continuity takes all Debian packages as a whole, where dependencies are finely described for each package. When I say that package X depends on packages Y and Z (with fine-grained version numbers) I say this forever in the sense that somebody somewhere might have to get stuck with this version for several years and wants to know the dependencies it causes. You usually run a Debian instance with packages taken from various stages (stable/unstable/testing). You may want to keep a given version of the kernel or the C++ libs for compatibility reasons but run the latest Gnome on top. You end up with a system that is not purely 'stable', 'unstable' or 'testing' but has the actual parts in the way you want. For long-term servers this removes quite a lot of headaches.
It sounds like making packages for deb-repos is much more time consuming than making rpm-packages for a specific Fedora release
In a sense yes: the total amount of work needed to build a Debian repository is much greater than what is needed for a Fedora release, because Debian contributors outnumber Fedora by 100 to 1. But for every individual package maintainer the work is quite simple. Most often this job is done by package authors themselves anyway.
RPM is probably a better packaging mechanism than deb.
No doubt yum has more or less the same intelligence as apt when it comes to upgrading a machine.
The real difference comes from the repositories. RPM-based repositories are strictly bound to a unique binary distribution (RedHat 8 or 9 or SuSE 10 or 11), so they gravitate around the same set of basic packages and have trivial dependency descriptions, e.g. you want gnome, you get evolution. APT-based repositories are not bound to any single version of Debian, you can fetch a 2-year old Debian installation CD and run an upgrade to the latest and brightest using a reliable connection. This implies having much more detailed dependency descriptions for each package, like: this package requires a mail user agent, a database client, library X version 1.2 or higher, and library Y version 2.2 (strict).
To build such a repository requires a huge amount of manpower, which Debian draws from the mass of its contributors (thousands). Each package maintainer takes greatest care of maintaining correct and usable dependency descriptions, abusive or incomplete dependencies are treated as bugs. RedHat cannot fight these numbers: how many people are working on maintaining their repository stability and consistency?
If RedHat wants to improve their repositories and get closer to Debian quality, they have to destroy the boundaries between successive distributions and make the transition continuous. This implies in turn having much more fine-grained dependency descriptions between packages. Repositories get more reliable, the RPM upgrade nightmare disappears and yum looks just as smart as apt.
You do not realize how much good this brings until you work with foreign keyboards, believe me. I used to work for a multinational institute where all developpers would have US keyboards, but administrative people could choose whatever they wanted. Say you want to type an e-mail on the secretary's Mac and you end up on a german, french, sometimes hebrew or even russian keyboard. You confidently type away your lines and it takes a couple of secondes before you realize what you see is definitely not what you typed. The real issue then is to find whatever icon/menu should be activated to bring the machine back (temporarily) to a standard US keyboard. And voila! You fingers start flying again on some keyboard showing key symbols you have never seen before. Beats mute keyboards, doesn't it? Actually I am typing this on a french keyboard configured as US. Finding anything else but a french keyboard in France is an impossible task.
This whole "study" is bullshit. The figures are made up from wind. To give an example: you might be interested in knowing that open-source software is counted as pirated (since it was not purchased). A more complete analysis can be found on: http://chosechu.blogspot.com/