Slashdot Log In
Mark Shuttleworth Proposes Delaying next Ubuntu
Posted by
Zonk
on Sat Mar 11, 2006 05:41 PM
from the waiting-on-the-duck dept.
from the waiting-on-the-duck dept.
Beuno writes "Mark Shuttleworth has proposed on the ubuntu-art mailing list to postpone the 'Dapper Drake' release by 6 weeks. He lays out the reasons pretty clearly: the delay should make the release a more user-friendly distro. He has also called up a community meeting in April 14th on IRC for community input. Is it really worth delaying the release for more then a month just to polish it out a little bit?" Commentary on this also available from the Tectonic site.
Related Stories
[+]
IT: Dapper Drake Hits Ubuntu Servers 259 comments
linuxbeta writes "Ubuntu 6.04 (Dapper Drake) daily builds have hit the Ubuntu servers. Dapper's goals: Substantial polish and integration, software discovery and installation, make network-wide enterprise updates easy to manage, consider LSB and related certification standards and support for deployment of Dapper on mission-critical servers. Screenshots have already surfaced."
[+]
Shuttleworth on Open Source Development 162 comments
An anonymous reader writes "Mark Shuttleworth (retired cosmonaut and Ubuntu daddy) has written an informative blog entry about the problems associated with open source development. He found that paying geeks to code without assigning them managers lead to "shiny geek toys", rather than the product he was actually paying for. Shuttleworth says that left-field thinking is required when it comes to managing open source teams. See also Andrew Orlowski's analysis of why AOL eventually killed the Netscape project from a few years ago, where he describes Mozilla developers as "wandering off into Lotus-eating land"."
[+]
Previewing Dapper And Edgy 144 comments
Frank Clarkson writes to mention a ZDNet article about the upcoming release of 'Dapper Drake', Ubuntu Linux. They also give a mini-preview of Eft. From the article: "'I'm promising to impose (almost ;-) ) zero from-the-top requirements for Edgy, this release is entirely up the to development team to envision and implement,' he wrote. 'Almost everything that lands in Edgy will be driven from the development team, who get to play with whatever new technologies they fancy along the way. So that should give us a nice big bump in infrastructure and bling.'"
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Error (Score:5, Informative)
Delay in Debian Derived Distro?? (Score:5, Funny)
Where's the bleeding edge code? Where's the "It compiled this morning let's push it out" mentality that's so common with Debian based Distros??
I'm astounded and saddened. Microsoft has updates coming out weekly. It can't be good for Ubuntu if it loses the "update war" with Microsoft. If you lose the update war, everything else is down hill from there.
Parent
Question? Answer. (Score:5, Insightful)
Absolutely.
Re:Question? Answer. (Score:5, Informative)
Parent
Re:Question? Answer. (Score:5, Informative)
Parent
Re:Question? Answer. (Score:5, Insightful)
So tell them the truth: the technology exists, but U.S. law makes it risky to distribute it.
Parent
Re:Question? Answer. (Score:5, Interesting)
Parent
The testers seem to agree (Score:5, Informative)
http://ubuntuforums.org/showthread.php?t=142536 [ubuntuforums.org]
Dapper is coming along nicely, but there are a number of bugs that might not get the attention they deserve if Dapper is released on schedule.
Their Flight 5 CD is out. It should be quite stable for normal use.
"Linux for human beings" (Score:5, Informative)
If Ubuntu wants to be "Linux for human beings" it needs all the polish it can get after that experience.
Keep up the good work guys.
Re:"Linux for human beings" (Score:5, Informative)
The only real issue was the 5.10 didn't handle ALPS Touchpads well at all. It was almost unusable as a result.
Fortunately, the Dapper betas have fixed that, and Ubuntu really is the most usable easy distribution for this box. OpenSuSe and Fedora both had significantly greater issues (either with suspend or the touchpad, or both).
Parent
Re:"Linux for human beings" (Score:5, Interesting)
Parent
Re:"Linux for human beings" (Score:5, Interesting)
Parent
Well... (Score:5, Insightful)
To me, this feels basically like delaying an extra security heavy distro 6 weeks to implement verify a new security protocol implementation works correctly.
Support/enterprise (Score:5, Insightful)
Really... (Score:5, Insightful)
d'uh. (Score:5, Insightful)
there are hundreds of distros already, and the only thing they all lack is polish, so yes.
what's the hurry?
YES! (Score:5, Insightful)
Patience is a virtue. Ubuntu has no need to generate revenue, and if it takes six more weeks to make the release more usable for human beings, that can only be a good thing.
Not just polish... (Score:5, Insightful)
It's not just about polish, though. TFA lays out a number of points where improvements are needed:
1. Testing
2. Certification
3. Localisation
4. (last but not least) Polish
Improvements to Asian localisation should help a ton of people - we're not all English speakers.
Not that it all matters to me, though... I use SUSE.
BaltikaTroika
Give them more time; they've earned it (Score:5, Interesting)
https://launchpad.net/distros/ubuntu/dapper/+spec
I'll refrain from Debian comparisons, as they're not needed to communicate what stellar work the team has done here. Point is, Ubuntu users and admins ought to support this delay, for the same reason I support Ubuntu... the Ubuntu team simply has its shit together, moreso than that of any other freely available distribution.
Let Shuttleworth strategize to take on Red Hat, SuSE, and Vista--because Ubuntu actually has a fighting chance. That prospect ought to excite Ubuntu partisans (like me) and fence-sitters alike.
I'm all for the delay if the goals are met (Score:5, Informative)
Amen to that! I tried installing Ubuntu on my girlfriend's laptop, and in the end I just gave up getting Chinese input working properly (she's Taiwanese and sends a lot of mail in Chinese to her friends back home.) After a couple of long nights spent fiddling with it, I could get it to sort of work with some apps, but this is one area where Windows beats Linux hands down -- after I gave up and installed Windows on her machine, enabling Chinese input took me all of about 30 seconds to do, and it works flawlessly in every app she uses.
Re:User friendly? (Score:5, Informative)
The fact that you're not a software engineer shows.
Want to know what would have otherwise loaded? The Windows Bootloader, which would have been within the exact same 512b sector that Grub now occupies. Boot loaders on PCs are extremely restricted in what they can do -- their code can be no larger than 446b in size, they run in real mode, and basically must rely directly on BIOS for all of their I/O routines.
In effect, this is 1980's technology, and flexability is virtually nil. The primary boot loader can't just pass its duties off to another boot loader, as there aren't really sufficient instructions available to do this, and the two boot loaders cannot occupy the same space on the drive.
If you're looking for something to blame for this situation, it's the fact that the architecture of the PC BIOS hasn't changed significantly in more than 20 years. It's still firmly rooted in the days of 160KB floppy booting, where the idea of a second-stage boot loader for choosing what OS you want to boot would never have occurred (want to boot a different OS on a diskette-only system? Use a different boot disk). BIOS should have died a long time ago.
Boot loaders like GRUB do the best they can with what little resources and possibilities they are given. I'm sorry that the GRUB developers don't have access to your screwy system to test and debug on. Here I've run GRUB on a variety of systems, and the only machine I ever found which had problems with it is one with a built-in nVidia chipset, back in the Fedora Core 2 days, which was easily solved by switching to a different boot loader.
Yaz.
Parent
Re:User friendly? (Score:5, Informative)
The BIOS knows you want to boot from your hard drive, it does one simple thing to facilitate this, it loads the first 512 bytes from the drive into memory, and it tells the CPU "start executing here". Should the code in those 512 bytes fail, the bios has nothing further it can do, it only knows how to do one thing, grab the 512 bytes and let them execute.
You installed Stage 1 of GRUB in the MBR (first 512 bytes of the drive). When you installed it, you installed it over top of the 512 bytes that were Microsoft's MBR. This is what was there before GRUB was installed, and now it is gone, completely written over, and neither GRUB nor the bios can do anything about it.
I think you would probably like it if the grub installer put a backup copy of the Microsoft MBR somewhere else on the drive, and you would like stage 1 of GRUB to load and execute those if there is any problem. But, if there is an error loading those 512 bytes, absolutely nothing can be done.
There is a perfectly valid explanation for why stage 1 might fail and why the microsoft MBR doesn't.
Stage 1 of GRUB (installed in the mbr) has 1 job, load a file from your Ubuntu partition,
The Microsoft MBR also has a simple job. It looks, at the partition table for partitions marked as bootable, takes the first one, loads the boot sector of that partition into memory, and executes it.
So stage 1 of GRUB and the Microsoft MBR really have a lot in common, as they are both 512 bytes they really do shit all, they just attempt to load more boot code off the drive and let it rip. The crucial difference here is WHERE on the drive they play with. Microsoft MBR reads the partition table and the boot sector of the partition marked bootable. GRUB stage 1 reads the location of
As
What could be different about these different locations on the drive?
If there was an error on the drive where
Or, maybe the hard drive is fine in all locations, but the mechanism used by these two MBRs to access it is not behaving as it should. What is this mechanism? Our frequenly buggy friend, the BIOS. The BIOS implements a interface that the MBR can use to get its job done. Something like
load_sector_from_ide_drive( ide_channel, master_or_slave, block_number )
Assume neither MBR has any bugs in calling this interface, what if there is a problem with the implementation itself? What if the interface promises that a block_number=(location of
Parent
Re:What does Ubuntu offer that Debian doesn't? (Score:5, Informative)
a reasonablly predictable release schedule (a bit too fast for my liking in fact) and a bit of polish for some desktop related stuff.
as such it fills the gap between debian stable (slow unpredictable release process) and debian testing (constant upgrade treadmill with little in the way of security support)
What can be done with Ubuntu that I can't do with Debian?
if you feel like supporting debian testing/unstable then nothing. And with sarge for a while probablly not much.
However in the couple of years prior to the sarge release running woody was becoming more and more untenable as recent software simply wasn't getting tested with stuff that old. Sarge is ok for the moment but unless debian can get thier house in order and come up with a release every few years at least then we are going to run into this issue again.
Parent
Re:What does Ubuntu offer that Debian doesn't? (Score:5, Funny)
Parent
Re:Ubuntu release philosophy: A fatal flaw (Score:5, Informative)
Parent