Originally posted by AdamW
View Post
Announcement
Collapse
No announcement yet.
Alan Cox Calls Fedora 18 "The Worst Red Hat Distro"
Collapse
X
-
-
Originally posted by LinuxID10T View PostFluxbox and Blackbox.
I do not know how you cannot access to Fluxbox while I successful got there without a fuss.
Leave a comment:
-
Originally posted by Alan CoxDear Slashdot, switching one system that run Ubuntu in a VM to Fedora into running Ubuntu does not constitute 'switching to Ubuntu'. I've been running Unbuntu for some jobs (like building Android images) for ages 8). In fact I run several distros (Fedora still included)
And for that matter my goldfish boot/stress test image is a hacked Debian fs image...
Originally posted by Alan CoxI'm leaving the Linux world and Intel for a bit for family reasons. I'm aware that "family reasons" is usually management speak for "I think the boss is an asshole" but I'd like to assure everyone that while I frequently think Linus is an asshole (and therefore very good as kernel dictator) I am departing quite genuinely for family reasons and not because I've fallen out with Linus or Intel or anyone else. Far from it I've had great fun working there.
Most of the people who should know more do, I know I've missed a few.
I may be back at some point in the future - who knows. In the mean time if you'd like my job (or indeed one of a range of others) we're hiring 8)
Leave a comment:
-
"You basically just say 'it sucks'. This is not useful feedback for anyone."
Anaconda is broken and it has been broken since day one and it needs a big overhaul.
At first it was just me saying that... now there are plenty of others, are we all wrong?
Common sense would dictate that the cheer ammount of changes, and the heavy nature of, you were about to make in fedora WOULD REQUIRE much more than the time you had in the development window.
so a sane person would either continue to postpone the release or simply skip 18 and deliver a functioning and stable f19.
I mentioned the problems I had in f18's live sessions as they would simply crash firefox and kill the system, someone said they could be due to memory management, strange as f17 never did that and 4gigs were always enough to test f17 beta and it never crashed once.
I was about to install the beta but since I couldn't connect to a hidden wi fi and had a bunch of other small issues I (luckily) backed out.
When the final release came I picked up a windows 7 laptop that had plenty of unpartioned space and installed by selecting 'boot device yes' (grub installed well) and I did let anaconda do everything automatically since it said it required no input (how hard could it be really, 1 partition with windows 7, 200g of unpartioned disk space).
Manually partitioning the disk is a clusterfuck, mount point 500mb ?? I even picked standard partition as I had no need for LVM.
During install I get a Kmod 04044 something error and then it boots into the fedora logo, the wi fi lights light up etc but blank screen... blank screen... blank screen.
ext4 partitions couldnt be mounted due to fs incompabilities etc etc...
I'm sorry but I had 0 problems, ZERO, with any linux distro thus far.
That comment about "getting your money back" is counterproductive, why does microsoft go around the college here giving copies of windows 8 to IT students?
The people that are using fedora today could be a rhel contract tomorrow, so you shouldn't dismiss them as cheap guinea pigs.
Leave a comment:
-
Originally posted by GreatEmerald View PostThat's... interesting. I don't know that much in this field, but it doesn't feel right. What changes does the installer need to reflect? New package versions? I don't think all the installers of all the distributions need as much maintenance. I suppose the old Anaconda could have been an exception, though.
Anyway, just an example. anaconda in general is built on top of rather a lot of other components of Fedora. It uses NetworkManager for network configuration, for instance. It uses yum's interfaces for package installation. It uses the packaged grub2 to set up the installed system's bootloader, it uses packaged libparted for a lot of partitioning stuff, etc etc. It's a part of Fedora like any other in some ways - it's not a static blob of code laid on top, it builds against or calls out to the current packaged version of all those bits. When you build a Fedora installer image, you're essentially building a small self-contained special-case Fedora environment: the build process pulls in the current packaged kernel, dracut, anaconda itself, libparted, NetworkManager, systemd (that's another one anaconda commonly has to react to changes in), etc etc etc etc etc and smooshes them together. Booting anaconda is really just booting a specific Fedora instance with a systemd config that runs anaconda.
The 'static blob of code' approach is possible, but it comes with its own problems - you're really just trading one set in for another. If you give your installer its own network config code, or just throw a static NM build in there, you solve the problem of having to potentially adjust your installer code for changes in NM, but you give yourself some other problems instead. If you write separate network code for the installer, well, now you have two piles of network code to maintain. You can leave the network code in the installer alone and it'll probably keep more or less working, but how do you support wifi installs, when wifi comes along? Well, you've got to write a bunch of wifi code into your installer at the same time you're writing a bunch of wifi code into NM. Seems stupid. If you throw a static NM build into your installer...when do you update it? Once a cycle? What if a fix for some important bug comes along and you get it in your actual distro but not in the installer? seems sub-optimal. What if your installer winds up writing out a configuration that the installed NM can't read properly because they're different versions? Again, not great. Anyhoo. Yeah. That's the issue. You _can_ write an installer that requires less maintenance than anaconda, that's true, but at the cost of not gaining the advantages of improvements in the underlying components.
Originally posted by GreatEmerald View PostOh come on, it's a well known fact that nobody ever reads manuals and licenses these days
Leave a comment:
-
Originally posted by picasticks View PostSomething so invisible needs to be killed. Gnome needs to stop hiding UI elements, it kills everyday usability. OS X has a few things absolutely right, like the app menu bar locked at the top of the screen (I can find the File menu of the current app with my eyes closed)
Originally posted by hoyt View PostI agree that Fedora goes too far with the minimalization concept, but that's because the design goal seems to be the corporate desktop. Just look at all the fiddling one must do to enable the extra repos and make the installation consumer friendly. It reminds me of tweaking a Windows 98 install.
Originally posted by kaczu View Posthttp://i826.photobucket.com/albums/zz188/kaczu_bucket/logout_zps55487f73.jpg
This really isn't THAT hard. You would think for those of us (not speaking to you directly) who compile programs, configure wine, or hell give me something (install RAID?). I don't know but this...
Originally posted by AdamW View PostPerhaps you could consider *gaining* some insight into a development process before criticising it? This is not a snark, it's a genuine suggestion. All the points you raised have been raised repeatedly, and explain repeatedly, in all sorts of venues - the Fedora mailing list, the forums, here on Phoronix - over the last few months. I'm getting pretty tired of explaining it _again_.
Originally posted by AdamW View PostThis is actually one of the major reasons we're doing newUI in the first place: a significant part of the work involved in maintaining any OS installer is simply in keeping it up to date with the rest of the system. You can't just take the installer from one release, shove it in the next, and call it good. It has to be maintained to account for changes in the rest of the system. oldUI in particular was getting to the point where maintaining it from release to release just so that it worked _the same_ - not noticeably better - was taking up a significant proportion of all the resources we had for installer development. That meant we couldn't really do a lot of work on making the installer better.
Originally posted by AdamW View PostAt this point we have the same product and it's just about massaging the messaging. That's something we already tried to do with the release announcement and other release documentation, and see how much slack that's bought us.
Leave a comment:
-
Originally posted by pingufunkybeat View PostNow Alan Cox has left the Linux developer community:
http://linux.slashdot.org/story/13/0...ux-development
See what you did Fedora? You drove him to Ubuntu, and he couldn't take it for very long! Now he's gone.
Leave a comment:
-
Originally posted by Vim_User View PostWhy was shipping F18 with the old installer not an option?
With hindsight there's a reasonable case to be made that it might have been better to wait for F19, but that's a very difficult call to make six months ahead of time. The practicalities described in the previous post mean it's not really viable to jump then jump back two months later, because then you have to retool and try to fix up oldUI for the new release, which is just as bad as trying to hack newUI into usable shape. It's pretty much a one-time call.
Leave a comment:
-
Originally posted by chithanh View PostStrawman. Of course Red Hat is not a charity which develops Fedora for the benefit of mankind.
Originally posted by chithanh View PostI agree that the criticism that some people have voiced on Fedora 18 is too harsh, and that lots of people worked very hard to improve the release in many areas. That makes it even more sad to see their work overshadowed by that turd of an installer. I have very little insight into the development process, but it appears to me that there was no proper backup plan in place so the only choice was to push out the release:- Fedora 17 had an installer that worked just fine. So you could have continued to use that, and optionally provide your new installer to those who want to test it.
- You could have recommended users to ditch the installer altogether and link to a document instead which describes manual partitioning + febootstrap as the preferred install method (Gentoo does it like this, and Arch has recently adopted this way too).
- You could have labeled Fedora 18 as "Forever Beta" and not make it an official release, just something for the interested.
Any of these steps would possibly have led to a lot fewer disappointed users than what we are seeing now.
"Fedora 17 had an installer that worked just fine. So you could have continued to use that, and optionally provide your new installer to those who want to test it."
That's not how things work in practice at all. You are by all means free to confirm this for yourself: take the Fedora 17 installer, plop it down in the Fedora 18 package set, and try to build an installer image. Ten to one it won't even compose, but on the offchance that it does, the composed image will _certainly_ be entirely busted. It won't work at all and will probably eat babies.
This is actually one of the major reasons we're doing newUI in the first place: a significant part of the work involved in maintaining any OS installer is simply in keeping it up to date with the rest of the system. You can't just take the installer from one release, shove it in the next, and call it good. It has to be maintained to account for changes in the rest of the system. oldUI in particular was getting to the point where maintaining it from release to release just so that it worked _the same_ - not noticeably better - was taking up a significant proportion of all the resources we had for installer development. That meant we couldn't really do a lot of work on making the installer better.
One of the major advantages of newUI is that it should require rather less running-to-stay-in-place maintenance work than oldUI did. However, as long as we do something like your plan - variations on which were suggested umpteen times by people who are not aware of the details - we were making the resource problem worse, not better: because we have to _both_ maintain oldUI _and_ work on newUI. newUI work did not start in the F18 cycle, it started back around the F15 cycle; so for three releases the anaconda team has been trying to work on newUI while simultaneously maintaining oldUI. This causes significant stress on them, slows the pace of newUI development, and probably means oldUI wasn't getting quite all the love it needed.
So any scenario in which we're continuing to work on both installers - let alone one where we actually offer and to some extent support both installers, which is pretty much the nightmare scenario - is a vary bad and unsustainable one.
This whole setup gives us a very strong reason to get newUI in as default as early as practical: now we have hit the point where newUI is in as default, we're in a much better place. We can kick oldUI to the curb, no-one has to work on it any more. Everyone is dedicated to making newUI better, and now we have a release out where newUI is the only option, we are getting lots of feedback on what bits of newUI need improving. The pace of newUI development will be far more rapid than it would have been had we tried some kind of do-both-at-once approach.
"You could have recommended users to ditch the installer altogether and link to a document instead which describes manual partitioning + febootstrap as the preferred install method (Gentoo does it like this, and Arch has recently adopted this way too)"
That's...interesting, but really not in line with how Fedora rolls, I don't think. It would have been just too drastic for a single release. newUI really isn't that terrible, you know; quite a few people have been saying 'it worked fine for me, I don't get the fuss'. It's at its most awkward when you're using custom partitioning with existing complex layouts, and I think that describes quite a few Phoronix users as this is one of the places for distro tweakers, but it doesn't describe everyone. If you're just doing a fresh install to a VM, for instance, it rolls fine. Even custom install to an empty disk works pretty nicely.
"You could have labeled Fedora 18 as "Forever Beta" and not make it an official release, just something for the interested."
That again would have been a valid approach, but I'm not sure it buys us a lot. At this point we have the same product and it's just about massaging the messaging. That's something we already tried to do with the release announcement and other release documentation, and see how much slack that's bought us.
Leave a comment:
-
Originally posted by Pallidus View Postthis is coming from someone that used and liked fedora 17:
fedora 18 is not only the worse fedora release to date, it's also a broken distro that should have never been released.
The writing was on the wall and when, month after month after month, they noticed how broke everything was THEY SHOULD HAVE SIMPLY DELAYED OR CANCELLED fedora 18
jump straight to 19 or release 18 in 19's date....
Alan Cox wasn't the only one jumping to ubuntu
hell even the alpha right now is 238912833 times more stable than fedora 18
We have a defined set of release criteria for Fedora and a process that ensures it reaches those criteria. The F18 release was delayed because we were going through that process: once we hit the criteria, it got released. The criteria do not say 'it must be perfect', and it's entirely the case that some releases exceed the criteria while some may only hit them. This is a thing that happens in software development. Given the nature of Fedora and the development cycle we're working on, we are never going to hit a perfect release every time, especially when that release involves rewriting the entire installer.
Leave a comment:
Leave a comment: