Yes, well I did also say that I agree on the kernel part, right? :)
Originally Posted by Pallidus
It might have hardware compatibility issues, but still would not be common.
I wouldn't say the best DE yet, but they have a lot of potential, and their window manager shows promise too(no sluggish but smooth effects, even though no wayland yet).I'd like to inform you that their PPAs are available for Ubuntu 12.10 already. :)
They're in alpha stage now and say they're very close to beta. I trust they'll release it this year. :D
After first FINISHED version is out, adoption is very likely to grow. And just imagine Ubuntu with it as default. :D
Well, it does have a couple bugs, although most if not all are actually fglrx bugs in my case , in some cases manifesting in a more apparent way(youtube videos with hardware accelerated rendering only show black on fullscreen. Under any circumstances though, anything hardware accelerated and fullscreen on fglrx, seems to show bugs/glitchiness, heck, even with openbox :D ).
Or mint, though that's probably more unlikely than Ubuntu. It's one I believe has potential in becoming mainstream. Only one feature missing .. WOBBLY WINDOWS!! And burning windows when you close them maybe .. :roll eyes:
And actually, I believe that the system working well and being easy to work with, is bait more important to many than being updated. But more updated would be cool. I'm certain they'll at least have PPAs for every newer version, I mean they do have PPAs for 12.10(not officially released yet) some time now. The theme was a lil bit buggy with the new gtk etc though ... :D
I wish those guys good luck, their approach on some thing is very good in my opinion, and "release when ready" is also very good. In the end, adding the updated kernel shouldn't be too hard though. Maybe they can do it for newer ISOs or something, so none is forced to upgrade and cripple closed drivers, in case they use them.
Hope it comes to Fedora soon as well. :D
On the other hand, you can upgrade to a new release as painless as a regular update on Debian/Ubuntu. And at least Ubuntu comes with nice little utilities that make sure your drivers still work after you update the kernel. And makes it easy to install proprietary stuff. In contrast, in fedora after I run the flash installer, it tells me it was installed ok; yet FF still tells me I have no flash installed. So you see, it's not the tool that matters the most, it's what you do with it.
Originally Posted by disi
no not really I can except from a major distro that it supports all hardware where working opensource drivers are there... if ubuntu can do that why should fedora not be able to and a dist-upgrade funktionality should also be there, I dont need a grafical thing console based is ok but thats not really there too. Thats stuff which is not a personal thing.
Originally Posted by disi
there is aptitude too btw... which at least makes apt-cache obsolete but thats no show stoppers thats a convinient stuff. 99% of the time apt-get update; apt-get dist-upgrade is the only thing you need.
Originally Posted by disi
ok I go with that, to a certain point, as a major desktop linux you should then not break such stuff and if you do (sound thing) you should at least react fast if such a bug lands on your tracker.
Originally Posted by disi
Primary I did say that, because someone said, that he finds it good that fedora delays this release because it would become more stable than made it look like ubuntus fixed release shedule would lead to buggier versions, when I think the opposite is true. Of course not the delay is the cause of bugs, but they have bigger problems, maybe to less developers maybe wrong release policies that lead to a not mass-desktop-ready linux desktop than their feature-based instead of timebased release cycles.
nice to hear that, shure in ubuntu is also not all perfekt, I never said that, but they are at some points better, working drivers/modules/kernels, better reaction of bug-reports. I would not be pissed if fedora would not give big support for closed source drivers or programms like flash I dont use them, but the hardware I talked is opensource supportet.
Originally Posted by disi
its a chicken-egg problem I guess, they seem to have less users, because of reasons I telled... then there is nothing comparable like ubuntusers.de, so they then get less bug reports so less users come to them... in this case its very very important to give good support to the few bug reports you get. I would have loved bug reports for some projets I did in the past, but because nobody seemed to be interessted in that software at least not many people I nearly got no response so at some point they died more or less (canta game). So I cannot understand how you can tread like that your users. If you are not willing to give support through a bugtracker its bad itself but if so at least shut down the site so that users dont waste their time talking to a wall.
the website of fedora looks very corperative, very company-biased. that frightens away normal private users. And thats the other point having 2 different distributions for business and community is also stupid. that costs much time to basicly support a fork, why not go the ubuntu way and make ONE Distribution and make some long-time-support versions. so yes thats maybe a good thing for making money, but it does not work well for the community testing versions that are only there to make the real distribution behind it.
I dont like to flame about fedora, I wish it would be better. Because for me the alternatives go out. if you want a high package count there is not that big of a choice. like I said debian is too old, gentoo is dieing kind of, arch sounds reasonable but tried it and the tools are not that good and even gentoo is more userfriendly you have not to do all stuff manuelly there are etc-config tools and such stuff... and the aur packages are often completly broken. I agree that it has potential but we will see. opensuse could be an alternative but in the few days old version there is gnome-shell 3.4 installed so also very old-school but at least you can onclick 3.6 or something like that. but then again whats the big point of going away from ubuntu where I have at least 3.6 gnome and with a ppa the not upgraded packages. its also not really a gnome-distro. And kind of noobish^^
Mint maybe but it was a pain in the ass to get the gnome-shell to a vanilla look.
So staying on ubuntu till something changes I guess.
Well, uh, I don't think that's all necessarily true at all.
We don't get 'few' bug reports for Fedora. 193 bugs were filed against Fedora on 2012-10-15. 113 on 2012-10-14. 120 on 2012-10-13. I get bored of changing my query, but we get at least 100 bug reports a day, it appears.
Launchpad doesn't appear to be able to use 'date of bug creation' as a search field, so it's harder to be precise, but scrolling through https://bugs.launchpad.net/ubuntu/+b...mo=75&start=75 , clicking on bugs and looking at the time of creation, it looks like Ubuntu gets about the same number of bug reports in a day - a little over 100.
So Fedora in fact has at least as many bug reports to deal with as Ubuntu.
In general, in my experience, no project as large as a Linux distribution will ever be able to respond satisfactorily to all bug reports. I used to work for Mandriva, and MDV didn't. I have a little experience of poking through Ubuntu's bug reports, and Ubuntu doesn't. As a comedy aside, Android is fucking _terrible_ at it, trying to get a response to an Android bug from Google is a Sisyphean task. And Fedora doesn't, either. My rule of thumb is that maybe 50% of bug reports get a decent response, in a Linux distribution.
It is certainly not the case that Fedora bug reports don't get responses. Most do. Some don't, but as I said, there are some bug reports for every distribution that don't get satisfactory responses, this is effectively a fact of life. It won't change.
Let's be realistic here: 'my sound card stopped working' is not a showstopper bug. Not in practice. Not for Fedora, not for Ubuntu. Want proof on the Ubuntu front?
was reported in March 2012. Ubuntu didn't manage to fix it; one dev got some way in investigating it, but it certainly wasn't considered any kind of high priority showstopper. The bug was not actually fixed until I reported it upstream to the ALSA developers and provided needed debugging info. They put a fix in upstream kernel, which will eventually work its way downstream to Ubuntu (AFAICT it's still actually broken in Ubuntu; you have to compile ALSA from upstream to fix it, for Ubuntu). So if you're going to ding Fedora, ding Ubuntu too. :)
I don't think anyone's done a really reliable study on whether any distribution is actually significantly better at handling bug reports than any other. It'd be interesting data to see if someone did. But I think I'm on solid ground in asserting, in general, that no distribution handles all its bug reports well. And also that no distribution considers single-system hardware bugs as major showstoppers.
"no not really I can except from a major distro that it supports all hardware where working opensource drivers are there... if ubuntu can do that why should fedora not be able to"
this is not remotely as clear-cut as you suggest. The above indicates a case where Fedora's support is currently superior to Ubuntu's (that sound card works in current Fedora 17). There are literally billions of possible hardware combinations in the world. In practice, any two distros which do not use the precise same kernel source will have _differing_ hardware support. Each one will support some bits of hardware that the other doesn't. I don't believe any Linux distribution has ever been released which worked on all extant PC hardware. I doubt even that any distribution has ever been released which supported all extant hardware for which support is _theoretically possible_. Not Ubuntu, not Fedora, not Debian, not Mandriva, not anyone. The problem space is simply too large and no distributor - hell, no PC OS vendor period - can possibly test their OS on all available hardware.
"the website of fedora looks very corperative, very company-biased"
I really don't see how you can say that at all. What about https://fedoraproject.org/ is corporate or company-biased?
"On the other hand, you can upgrade to a new release as painless as a regular update on Debian/Ubuntu."
This is certainly not true. https://wiki.ubuntu.com/PrecisePango...ure-1.Upgrades lists three known issues with upgrading to Pangolin. I would be very surprised if there are not more than that.
http://ubuntuforums.org/showthread.php?t=1973408 is not a painless upgrade. http://ubuntuforums.org/showthread.php?t=1969817 is not a painless upgrade. http://ubuntuforums.org/showthread.php?t=2043559 is not a painless upgrade. http://ubuntuforums.org/showthread.php?t=1976791 is not a painless upgrade. I could go on, but you take my point. That's just from a casual Google for '12.04 upgrade site:ubuntuforums.org'; all those results are on the first page.
The fact is that an OS upgrade is a psychotically complex operation with an effectively infinite number of variables, it's as bad as or worse than the problem space for hardware support. I'd state that it's literally impossible for a general-purpose OS to guarantee trouble-free upgrades from one major version to the next. Ubuntu does not guarantee it in theory or in practice. Fedora does not. RHEL does not. Windows does not. OS X does not. Nobody does. It is not possible to do so.
Now you could develop an argument that Ubuntu does this better than Fedora, if you had enough solid data, but anecdotal data certainly is not enough, since we've already established that both Ubuntu and Fedora have troubles with upgrades in some cases. If we agree on that, then a single data point of 'had trouble with Fedora, didn't have trouble with Ubuntu' doesn't tell us anything we didn't know already. You'd need a much more systematic study of upgrades across hundreds or thousands of configurations in order to be certain.
"And thats the other point having 2 different distributions for business and community is also stupid. that costs much time to basicly support a fork, why not go the ubuntu way and make ONE Distribution and make some long-time-support versions. so yes thats maybe a good thing for making money, but it does not work well for the community testing versions that are only there to make the real distribution behind it."
This is a common misunderstanding of the relationship between Fedora and RHEL. It's much more complex than that. Fedora does serve partly as a testing ground for RHEL, but it's much more than that. There are many people who work on or with Fedora and never use RHEL; Fedora has its own identity and purpose. This is easy enough to understand if you think about it briefly. RHEL contains massively fewer packages than Fedora. If Fedora were just a testing ground for RHEL it would contain the exact same package base as RHEL does.
In general Fedora is a more bleeding-edge and less polished distro than Ubuntu, and this is by policy. It certainly makes sense for some people to use a distro like Ubuntu rather than a distro like Fedora. But the situation is far more complex than you paint it, I'd say.
Ok, it's more painful in some cases (it has worked for over 5 years, with every configuration I had). But even so, the worst case scenario requires an installation from scratch. Which is what every RPM-based distro mandates anyway.
Originally Posted by AdamW
I'm not saying it's a breeze or that everyone should do what Debian/Ubuntu does. I'm just saying Ubuntu has been less painful for me. I usually have Ubuntu (Kubuntu actually) at home and Fedora at work.
"But even so, the worst case scenario requires an installation from scratch. Which is what every RPM-based distro mandates anyway."
Er, I'm not sure where you get that idea; it isn't true. All RPM-based distros I'm aware of offer upgrade functionality. Fedora does, Mandriva does, SUSE does.
Are you talking about the mechanism Ubuntu offers for triggering an upgrade from within a running session, rather than the user triggering an upgrade by booting an install medium and picking an 'upgrade' option? That's very different from 'mandating an installation from scratch' - just because an upgrade is run through the system installer doesn't mean it's an installation from scratch. It's not. It's upgrading the installed system and preserving configuration, user data, package set etc.
Even if so, Fedora has a mechanism for triggering an upgrade from the running system; the current one is preupgrade - https://fedoraproject.org/wiki/How_to_use_PreUpgrade - and for F18 there's a new one being written (see earlier in this thread). MDV and SUSE may have similar systems these days, I'm not sure. You can also do a live upgrade of a running Fedora system using yum (https://fedoraproject.org/wiki/Upgra...dora_using_yum ), a running Mandriva system using urpmi, or a running SUSE system using whatever SUSE uses (zypper?). These methods usually aren't officially recommended, but in practice they work - I've upgraded this system from F15 to F18 using yum only.
Yes, openSUSE uses zypper for upgrades while the system is running, and has an upgrade option when installing from a DVD. I don't think there are any plans to add any more options, as these cover pretty much all the use cases.
Originally Posted by AdamW
Basically a full upgrade from release X to Y is not always painless. Especially when you have got packageing changes or a complete new gui like when you go from KDE 3 to 4 then every 2nd package has got a new name. For beginners i usually suggest using a /home partition and a clean install. Next thing that could be really problematic is when there is a multiarch transistion. Right now you see that with wheezy, every 3d driver is now multiarch, wine as well (also pulseaudio was tricky for 32 bit apps). In the main wheezy/sid repo there are still some missing updates that you could not even install em (i have those missing packages in Kanotix). I would not blame Fedora/Ubuntu or whatever when it breaks going from one release to the next via apt-get/yum. Also when you look at nvidia's current 310 driver you have to uninstall that one for Geforce 6/7 hardware now, that's also tricky. For fglrx this is even more fun, there DX10 cards are already dropped from current driver (GF 6/7 was DX9 hardware)... Ok, Fedora usually does not support binary drivers in their own repo, but you should not forget that.
Yes, that's what I was talking about. Right now I'm on F16 and nobody tells me there's a new release out there. But in this case, it's for the better because I ouldn't upgrade if I wanted to (businees requirements). Regardless, I think such an option make a distro way friendlier in the eyes of newcomers.
Originally Posted by AdamW
@Kano: Yes, I also use the separate /home partition "trick". That way I can break anything and not give a rat's behind.
Originally Posted by AdamW
thats my bug.
1. fedoras bug is a bit older ok not much but at least there were 2 stable releases since this time so it matters.
2. 1. month later a response form a paid ubuntu dev (after the conformation of the 2nd bugreport)
3. 2 months later he posted a solution that made the card work again, shurly no distro-bug but at least anybody who search this bug, is able to fix the sound
4. the bug is basicly fixed and the dev waits for the inclusion in upstream of this bug.
5. it seems that its fixed upstream but that its not on fixed stand is because the alsa devs did not answer his last question to make sure it works:
so its basicly fixed 1month later you had a workaround and 6 months later its fixed in ubuntu next it should work.
So way way extremely better support than what I got here:
so your example in fact does prove how much better ubuntu support is.
To the preupgrade thing I tried that, it wasnt painless, but if you dont recommend it its poor. And to upgrade from a usb-stick or something like that, is not very userfriendly.
why can debian do that since 10 years without a usbstick boot and fedora not? or is it since 20 years? ^^
And if you say in 18 there is a new one, thats basicly then because the old way did suck, or why would you fix something thats not broken.