that's what differentiates a useful user base from a dumb customer base, which is exactly the distinction I was trying to draw.
the page I linked is an alternative method which turns the fonts into a package and installs it system wide. It's somewhat more elegant. But creating a ~/.fonts folder and throwing TTF files at it certainly works, too. You pick your poison.
Re:Ubuntu influence on marketing materials
on
Fedora 12 Released
·
· Score: 2, Informative
EPEL is pretty good in the RHEL/CentOS/Fedora world, but nowhere near as large and well-maintained as Universe, IMHO.
You're conflating things you shouldn't conflate. RHEL has an intentionally restricted package set; it's restricted to what Red Hat can commit to offer very detailed support for (not a problem Canonical has with Universe or Multiverse). Fedora's package set is entirely different from RHEL's, and EPEL has no relevance to Fedora, you would not use an EPEL repository on a Fedora system.
Fedora is never going to have any market share, because we're not selling anything. There isn't a market. This isn't a glib point, it's an important one. No-one's playing for a share of a dumb customer base, here. That's not what Fedora is about.
Installing microsoft fonts was a real PITA, there might be an easier way to do it but in fedora11 i needed to do it urgently and ended up having to compile, that's not acceptable!
Duh...huh? Compile *what*? You can't 'compile' the Microsoft core fonts, they're only available as a bundle of TTF files. Which you could 'install' by just sticking them in ~/.fonts .
Re:gparted and ntfs-3g on live cd?
on
Fedora 12 Released
·
· Score: 2, Informative
the installer has a partitioning tool (which is actually based on libparted, as it happens). why would you need ntfs-3g to do partitioning? you only need it if you actually want to mount the partition and write to it.
there's cutting edge, and then there's cutting edge. the original example scenario was 'backporting features from 2.6.32 to 2.6.31'. so you would advise we somehow shipped fedora 12 with a kernel version - 2.6.32 - which barely even existed at the final version freeze date?
That depends on whether you're taking a long view or a short view, and whether your goal is in fact simply to 'attract new users' no matter what the cost. For Fedora, it isn't.
Kernels in Fedora and RHEL *are* parallel installable and always have been. Installing a new kernel does not remove the old one, and they're both available for selection from the bootloader.
Re:it didn't detect my usb mouse so i can't instal
on
Fedora 12 Released
·
· Score: 1
thanks for the info. Well, that sucks:/ you _should_ be able to complete an install - even a graphical one - using only the keyboard (usual tab / space / enter stuff), though I'm not sure if you want to:). The bug I was thinking of is https://bugzilla.redhat.com/show_bug.cgi?id=524808 , you could try the kernel parameter 'intel_iommu=off' or 'iommu=soft' . But I really doubt it's that issue if you're on final, it seemed pretty certain that it was fixed.
As far as Fedora is concerned, this is not a 'problem'. The problem is rather in distributions which rely to too great an extent on closed source drivers to provide hardware support. For instance, many Ubuntu users upgrading to 9.10 are finding they can no longer use the proprietary ATI/AMD driver for their video card and are using the free driver. Which, it seems, Ubuntu does not pay too much attention to maintaining, as many of them have problems. By contrast, Fedora considers it better that users are encouraged to use the free drivers rather than the proprietary ones, and focuses on the development of the free drivers (Red Hat pays two full time developers to work on the radeon driver). In the long run, this is better for both Fedora users and all Linux users.
I find Fedora does a lot less, and doesn't do it as well. The primary example of this is yum, which is a third rate program by comparision to apt. In fact, my personal opinion is that the success of Ubuntu has been down to properly maintained and comprehensive apt-repositories. When I left Fedora, yum had nothing in the same league as these, and dependency hell was very much still with the platform.
So, you mean, you have no direct experience with any recent Fedora, yet wish to criticise it anyway? Glad we got that cleared up. You're also conflating three different things in the above. The package management program has very little to do with what packages are available to it; the comparative quality or otherwise of apt-get and yum has zip all to do with what packages are available in the Fedora or Debian (or Ubuntu) repositories. 'Dependency hell', apart from being so vague these days as to be practically meaningless, is a separate issue again, as it rarely has anything to do with the package manager itself, but is to do with the quality of the packages. Again, given that you don't give any details on your actual current experience with Fedora or the date at which you 'left Fedora', it's hard to place much value in your experiences.
Fedora is a distro for admins who want ease of use, but not so much ease of use that they lose their jobs. They want the odd error or config mismatch so they need to directly intervene on occasion. So they won't go for debian or especially Ubuntu.
Here, I think you dropped this - it's your tin foil hat. Don't answer that door, it's the FBI!
Well, what alternative do you suggest for introducing desired new features into older kernel versions? It's not really the case that upstream 'didn't want to' backport things from 2.6.32 to 2.6.31, it's just not what upstream does. Upstream kernel maintainers do not maintain kernel version X once it's released, they go on to work on kernel version Y, pretty much. That doesn't mean it's somehow wrong for a distribution to do it, often it's the right thing to do, and Fedora is not the only distribution that does this (Ubuntu does it too, in some cases).
Again, for RHEL, what's the alternative? The whole point of RHEL is to provide long-term stable releases, but customers also want support for newer hardware. When RH has several thousand large customers all screaming for support for their shiny new SAN hardware that they just spent several zillion dollars on, saying 'well, we're not going to backport that driver to kernel 2.6.18' isn't really an option, and updating them all wholesale to a new kernel release probably wouldn't be the best idea in the world either. What would you suggest RH does instead?
Re:it didn't detect my usb mouse so i can't instal
on
Fedora 12 Released
·
· Score: 1
when you say 'it', what do you mean exactly? did you get f12 final already and try it? if you were testing a pre-release, there was a known bug up till very late which caused USB not to work on some systems, this is fixed in the final release.
Yes. http://fedoraproject.org/wiki/Statistics - we have seen over 2.4 million installations of Fedora 11 so far, a 20% increase on Fedora 10. Methodology is extensively discussed on the linked page.
On a side note. It would be nice if the Ubuntu installer by default created a seperate/home partition. (or maybe they have in the last version or so, I haven't installed from scratch).
Uh, why? For most people, that's just a pain in the ass... suddenly you have to guess how much space you'll want in / and/home, and if you underestimate, you find yourself having to resize filesystems. And for those who care (such as yourself), you can easily set things up that way during the initial install.
Going from experience, many of those who care only realize they care when it's too late. i.e. after they've installed Linux, decided they like it, and hit their first upgrade point, whereupon someone says 'of course, if you have a separate/home, you can just...'
I don't know what Ubuntu did to it, but we've been using ext4 by default on Fedora throughout the 11 and 12 cycles and haven't had any reports of this bug that I can find.
"Correct! Also why have OSes gotten so large they required DVDs! I remember being able to install 3.11 for workgroups off a series of floppies, why can't we go back to that?!"
"I can barely run xubuntu on a machine with 256megs or ram let alone full ubuntu."
Xfce's almost as much of a resource hog as GNOME or KDE these days. On a 256MB system I'd recommend LXDE for something vaguely familiar which really doesn't eat tons of RAM. Of course, then you need low-resource apps as well. Dillo's a good basic browser, Midori if you need more than Dillo can provide. I'm partial to nedit for a very low-resource text editor. And so on...
That's not an 'assload of CLI', it's a *configuration file*.
If you want to admin anything without encountering a configuration file...well, good luck. And no, just because something consists of text rather than pictures, that does not mean it's bad.
in terms of what it actually installs, wampserver isn't exactly 'self contained' either. It installs a bunch of separate bits which depend on each other, just as you get by installing a collection of packages on Red Hat. All you'd have needed to duplicate wampserver functionality on RH is a trivial script - or just a saved rpm command line - which installs the appropriate package set from the discs.
Yeah, there is an actual issue here in that RH's dependency-resolving package management tools do not work by default on the disc media. In some distros, e.g. Mandriva, they do. In an ideal world, RH's would too. In practice, just about every real-world RH deployment has access to a package server; even if it's on a secure network, you'd usually have a private repository available on the network for the servers to use, so you can do proper package management and tracking. So that's why this just isn't seen as a real big problem for RH.
You can hack it up relatively easily, if you need to - copy all the packages off the disc(s) into a directory somewhere, run 'createrepo.' on the directory, and add the directory as a yum repository in/etc/yum.repos.d/ . Yeah, it's a bit of a trick that takes some knowledge to figure out, but let's face it, that's what sysadmin work _is_, no matter what OS or software you run. I don't think anyone's yet met the syadmin whose job consisted exclusively of reading the manual and clicking the handy desktop icons. You used exactly the same kind of knowledge-based shortcut in using wampserver on Windows, as pointed out before.
Basically, we're not disputing that, given the situation you're in, it happened to be easier for you to install on a Windows box than a Linux one. We're just pointing out this is, to a large extent, because of your particular situation and skill set. It's not something you can generalize out, or legitimately argue means there's some kind of significant problem for Linux. It's just one of those things.
Um. It's not, really, given that AMD has only started providing useful specifications relatively recently, and writing 3D drivers ain't exactly a walk in the park. Compare that NVIDIA is, what, 11 years old and we don't have usable open source 3D support for any of those chips yet (nouveau is getting there, though). _You_ try reverse engineering a 3D graphics card and see how far you get.
r700 and r800 are very similar to r600 as far as writing driver support goes, and AMD have provided those specs much faster, so r700 and r800 (and future generation) support should come fairly soon.
There is an easy way out of that, though it may not be totally obvious: don't use your existing/boot partition for F12, just wipe it out and leave it as empty space, make sure the bootloader gets installed to the / partition. F12 doesn't need a separate/boot partition if / is ext4 any more, as F12's grub supports booting from ext4 (F11's didn't, which is why you needed the separate/boot).
That is a good point, though. I don't think we'd actually noticed that particular unfortunate consequence chain until you pointed it out. I'm not entirely sure there's much we can _do_ about it at this point, though. I'm sorry about that.
Nice selective quoting. What was the point of that? You make me look like I say something I didn't say, shorn of all context, and make...no useful point whatsoever.
well. um. it does. yum takes care of the dependencies for you. all you have to do is tell it what you want to install.
try as I might, I _really_ can't see any qualitative difference between the two. You seem to be assuming that it's blindingly obvious that you should use this 'wampserver' thing to install the stack on Windows, but I've no idea why. I'd never heard of it until I came across this thread. How did you magically know that the right tool to use to install the stack on Windows was 'wampserver'? I'm betting you didn't; you either did research yourself and found this tool, or you were given the benefit of this knowledge by someone else who had. How is that any different from doing a couple of minutes of research yourself to learn about yum, or being told about it by other people in this thread?
also, you didn't answer the question about updates, which is rather important. Does this 'wampserver' thing take care of keeping the whole stack up to date with security updates for you?
It's worth noting that we tweaked the Fedora 12 release cycle somewhat, and this 'Beta' release is equivalent to the 'Preview' release from previous cycles. It's more akin to what the rest of the world considers a Beta - i.e. it's feature complete and changes from here on in will only be for bug fixes - than our previous 'Beta' releases were.
Slashdot Mirror
that's what differentiates a useful user base from a dumb customer base, which is exactly the distinction I was trying to draw.
the page I linked is an alternative method which turns the fonts into a package and installs it system wide. It's somewhat more elegant. But creating a ~/.fonts folder and throwing TTF files at it certainly works, too. You pick your poison.
EPEL is pretty good in the RHEL/CentOS/Fedora world, but nowhere near as large and well-maintained as Universe, IMHO.
You're conflating things you shouldn't conflate. RHEL has an intentionally restricted package set; it's restricted to what Red Hat can commit to offer very detailed support for (not a problem Canonical has with Universe or Multiverse). Fedora's package set is entirely different from RHEL's, and EPEL has no relevance to Fedora, you would not use an EPEL repository on a Fedora system.
Fedora is never going to have any market share, because we're not selling anything. There isn't a market. This isn't a glib point, it's an important one. No-one's playing for a share of a dumb customer base, here. That's not what Fedora is about.
Second Google result for 'fedora "microsoft fonts"': http://miltonpaiva.wordpress.com/2009/07/10/fedora-11-x64-%E2%80%93-microsoft-fonts/
Installing microsoft fonts was a real PITA, there might be an easier way to do it but in fedora11 i needed to do it urgently and ended up having to compile, that's not acceptable!
Duh...huh? Compile *what*? You can't 'compile' the Microsoft core fonts, they're only available as a bundle of TTF files. Which you could 'install' by just sticking them in ~/.fonts .
the installer has a partitioning tool (which is actually based on libparted, as it happens). why would you need ntfs-3g to do partitioning? you only need it if you actually want to mount the partition and write to it.
there's cutting edge, and then there's cutting edge. the original example scenario was 'backporting features from 2.6.32 to 2.6.31'. so you would advise we somehow shipped fedora 12 with a kernel version - 2.6.32 - which barely even existed at the final version freeze date?
That depends on whether you're taking a long view or a short view, and whether your goal is in fact simply to 'attract new users' no matter what the cost. For Fedora, it isn't.
Kernels in Fedora and RHEL *are* parallel installable and always have been. Installing a new kernel does not remove the old one, and they're both available for selection from the bootloader.
thanks for the info. Well, that sucks :/ you _should_ be able to complete an install - even a graphical one - using only the keyboard (usual tab / space / enter stuff), though I'm not sure if you want to :). The bug I was thinking of is https://bugzilla.redhat.com/show_bug.cgi?id=524808 , you could try the kernel parameter 'intel_iommu=off' or 'iommu=soft' . But I really doubt it's that issue if you're on final, it seemed pretty certain that it was fixed.
As far as Fedora is concerned, this is not a 'problem'. The problem is rather in distributions which rely to too great an extent on closed source drivers to provide hardware support. For instance, many Ubuntu users upgrading to 9.10 are finding they can no longer use the proprietary ATI/AMD driver for their video card and are using the free driver. Which, it seems, Ubuntu does not pay too much attention to maintaining, as many of them have problems. By contrast, Fedora considers it better that users are encouraged to use the free drivers rather than the proprietary ones, and focuses on the development of the free drivers (Red Hat pays two full time developers to work on the radeon driver). In the long run, this is better for both Fedora users and all Linux users.
I find Fedora does a lot less, and doesn't do it as well. The primary example of this is yum, which is a third rate program by comparision to apt. In fact, my personal opinion is that the success of Ubuntu has been down to properly maintained and comprehensive apt-repositories. When I left Fedora, yum had nothing in the same league as these, and dependency hell was very much still with the platform.
So, you mean, you have no direct experience with any recent Fedora, yet wish to criticise it anyway? Glad we got that cleared up. You're also conflating three different things in the above. The package management program has very little to do with what packages are available to it; the comparative quality or otherwise of apt-get and yum has zip all to do with what packages are available in the Fedora or Debian (or Ubuntu) repositories. 'Dependency hell', apart from being so vague these days as to be practically meaningless, is a separate issue again, as it rarely has anything to do with the package manager itself, but is to do with the quality of the packages. Again, given that you don't give any details on your actual current experience with Fedora or the date at which you 'left Fedora', it's hard to place much value in your experiences.
Fedora is a distro for admins who want ease of use, but not so much ease of use that they lose their jobs. They want the odd error or config mismatch so they need to directly intervene on occasion. So they won't go for debian or especially Ubuntu.
Here, I think you dropped this - it's your tin foil hat. Don't answer that door, it's the FBI!
Well, what alternative do you suggest for introducing desired new features into older kernel versions? It's not really the case that upstream 'didn't want to' backport things from 2.6.32 to 2.6.31, it's just not what upstream does. Upstream kernel maintainers do not maintain kernel version X once it's released, they go on to work on kernel version Y, pretty much. That doesn't mean it's somehow wrong for a distribution to do it, often it's the right thing to do, and Fedora is not the only distribution that does this (Ubuntu does it too, in some cases).
Again, for RHEL, what's the alternative? The whole point of RHEL is to provide long-term stable releases, but customers also want support for newer hardware. When RH has several thousand large customers all screaming for support for their shiny new SAN hardware that they just spent several zillion dollars on, saying 'well, we're not going to backport that driver to kernel 2.6.18' isn't really an option, and updating them all wholesale to a new kernel release probably wouldn't be the best idea in the world either. What would you suggest RH does instead?
when you say 'it', what do you mean exactly? did you get f12 final already and try it? if you were testing a pre-release, there was a known bug up till very late which caused USB not to work on some systems, this is fixed in the final release.
Yes. http://fedoraproject.org/wiki/Statistics - we have seen over 2.4 million installations of Fedora 11 so far, a 20% increase on Fedora 10. Methodology is extensively discussed on the linked page.
On a side note. It would be nice if the Ubuntu installer by default created a seperate /home partition. (or maybe they have in the last version or so, I haven't installed from scratch).
Uh, why? For most people, that's just a pain in the ass... suddenly you have to guess how much space you'll want in / and /home, and if you underestimate, you find yourself having to resize filesystems. And for those who care (such as yourself), you can easily set things up that way during the initial install.
Going from experience, many of those who care only realize they care when it's too late. i.e. after they've installed Linux, decided they like it, and hit their first upgrade point, whereupon someone says 'of course, if you have a separate /home, you can just...'
I don't know what Ubuntu did to it, but we've been using ext4 by default on Fedora throughout the 11 and 12 cycles and haven't had any reports of this bug that I can find.
"Correct! Also why have OSes gotten so large they required DVDs! I remember being able to install 3.11 for workgroups off a series of floppies, why can't we go back to that?!"
Because...then we'd be running Windows 3.11?
*shudders*
"I can barely run xubuntu on a machine with 256megs or ram let alone full ubuntu."
Xfce's almost as much of a resource hog as GNOME or KDE these days. On a 256MB system I'd recommend LXDE for something vaguely familiar which really doesn't eat tons of RAM. Of course, then you need low-resource apps as well. Dillo's a good basic browser, Midori if you need more than Dillo can provide. I'm partial to nedit for a very low-resource text editor. And so on...
That's not an 'assload of CLI', it's a *configuration file*.
If you want to admin anything without encountering a configuration file...well, good luck. And no, just because something consists of text rather than pictures, that does not mean it's bad.
in terms of what it actually installs, wampserver isn't exactly 'self contained' either. It installs a bunch of separate bits which depend on each other, just as you get by installing a collection of packages on Red Hat. All you'd have needed to duplicate wampserver functionality on RH is a trivial script - or just a saved rpm command line - which installs the appropriate package set from the discs.
Yeah, there is an actual issue here in that RH's dependency-resolving package management tools do not work by default on the disc media. In some distros, e.g. Mandriva, they do. In an ideal world, RH's would too. In practice, just about every real-world RH deployment has access to a package server; even if it's on a secure network, you'd usually have a private repository available on the network for the servers to use, so you can do proper package management and tracking. So that's why this just isn't seen as a real big problem for RH.
You can hack it up relatively easily, if you need to - copy all the packages off the disc(s) into a directory somewhere, run 'createrepo .' on the directory, and add the directory as a yum repository in /etc/yum.repos.d/ . Yeah, it's a bit of a trick that takes some knowledge to figure out, but let's face it, that's what sysadmin work _is_, no matter what OS or software you run. I don't think anyone's yet met the syadmin whose job consisted exclusively of reading the manual and clicking the handy desktop icons. You used exactly the same kind of knowledge-based shortcut in using wampserver on Windows, as pointed out before.
Basically, we're not disputing that, given the situation you're in, it happened to be easier for you to install on a Windows box than a Linux one. We're just pointing out this is, to a large extent, because of your particular situation and skill set. It's not something you can generalize out, or legitimately argue means there's some kind of significant problem for Linux. It's just one of those things.
Um. It's not, really, given that AMD has only started providing useful specifications relatively recently, and writing 3D drivers ain't exactly a walk in the park. Compare that NVIDIA is, what, 11 years old and we don't have usable open source 3D support for any of those chips yet (nouveau is getting there, though). _You_ try reverse engineering a 3D graphics card and see how far you get.
r700 and r800 are very similar to r600 as far as writing driver support goes, and AMD have provided those specs much faster, so r700 and r800 (and future generation) support should come fairly soon.
There is an easy way out of that, though it may not be totally obvious: don't use your existing /boot partition for F12, just wipe it out and leave it as empty space, make sure the bootloader gets installed to the / partition. F12 doesn't need a separate /boot partition if / is ext4 any more, as F12's grub supports booting from ext4 (F11's didn't, which is why you needed the separate /boot).
That is a good point, though. I don't think we'd actually noticed that particular unfortunate consequence chain until you pointed it out. I'm not entirely sure there's much we can _do_ about it at this point, though. I'm sorry about that.
Nice selective quoting. What was the point of that? You make me look like I say something I didn't say, shorn of all context, and make...no useful point whatsoever.
well. um. it does. yum takes care of the dependencies for you. all you have to do is tell it what you want to install.
try as I might, I _really_ can't see any qualitative difference between the two. You seem to be assuming that it's blindingly obvious that you should use this 'wampserver' thing to install the stack on Windows, but I've no idea why. I'd never heard of it until I came across this thread. How did you magically know that the right tool to use to install the stack on Windows was 'wampserver'? I'm betting you didn't; you either did research yourself and found this tool, or you were given the benefit of this knowledge by someone else who had. How is that any different from doing a couple of minutes of research yourself to learn about yum, or being told about it by other people in this thread?
also, you didn't answer the question about updates, which is rather important. Does this 'wampserver' thing take care of keeping the whole stack up to date with security updates for you?
It's worth noting that we tweaked the Fedora 12 release cycle somewhat, and this 'Beta' release is equivalent to the 'Preview' release from previous cycles. It's more akin to what the rest of the world considers a Beta - i.e. it's feature complete and changes from here on in will only be for bug fixes - than our previous 'Beta' releases were.