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.
I'm Shocked, shocked I tell you that a distro based on, and dependent upon, Debian packages would choose to focus on some kind of abstract "usability" or "stability" issue over fast and frequent updates!
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.
They don't include mp3 and dvd stuff because they don't want to get sued. DVD playing stuff with decss is on sketchy legal ground, and mp3 decoders are covered by vaiours patents. They would include them if they could- but they don't have the money to fight a losing court case.
Yes, there's an automated installer called Automatix [ubuntuforums.org]. It's only for Ubuntu Breezy, but there should be a new one when Dapper is final.
Don't use automatix. It uses --force-yes to force package installations which will downgrade packages and override any pinned packages, without prompting the user about unsigned repos. Just google automatix problems for more detail.
Windows licenses CSS. Some Linux distros do as well -- IIRC, Linspire is an example. So it depends upon the distro you're using. If a distro doesn't license CSS (and Ubuntu does not), then you have to use a hack to get around it, said hack being illegal in the U.S.
So tell them the truth: the technology exists, but U.S. law makes it risky to distribute it.
Fluendo has released a licensed MP3 plugin [fluendo.com] for the GStreamer framework. It's already in Debian unstable, and I'd say Ubuntu probably will include it.
Maybe smaller distros can get away with providing it, but that's just because they are flying under the radar. Larger distros would get caught. As far as I know, none of the larger distros include dvd or mp3 by default.
That's because Mandriva licenses the mp3 codecs, then offers the distro for free. It's actually something that should be better publicized about the distro.
What does Ubuntu offer that Debian doesn't? 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.
I used to use Debian on my laptop, but later switched to Ubuntu. Why?
It supports more hardware out-of-the-box, and it has newer GNOME packages than Debian. Things that I had to install in Debian (the touchpad, etc) were already installed.
I wouldn't use Ubuntu on a server though, everything I can do in Ubuntu I can do in Debian. Installing a Debian desktop is just more hassle than installing Ubuntu.
As a Gentoo user, I tried out Ubuntu on an old Toshiba laptop about a month or three ago when the current version came out. I liked what a I saw, but I ran into to huge problems. One, Ubuntu completely screwed up the monitor settings for the laptop, and the sound was completely futzed. I found the solution to fixing the monitor settings on an Ubuntu user forum (involved hand editing X.org's conf file) and the sound, well, I managed to get it to play somewhat but GNOME still never detected it properly.
If Ubuntu wants to be "Linux for human beings" it needs all the polish it can get after that experience.
More anecdotes... I tried Ubuntu on my laptop (Dell Inspiron 6000 w/ ATI) and it installed cleanly, and handled all suspend modes perfectly, right out of the box! Sound worked, the wireless (Intel) worked, and the display was quite nice (albeit with no 3D acceleration).
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).
The necessity of hand-editing xorg.conf or frankly any.conf file keeps Ubuntu and Linux in general out of the mainstream. Joe Sixpack isn't going to do it. Fundamental things such as video, keyboard, and mouse should work immediately, with sane and functional fallbacks.
Well, one one hand, this didn't stop Windows 3.x or Windows 95 from becoming ubiquitous (autoexec.bat and config.sys anyone?). But in fairness, that was 10-15 years ago.
windows 95 and 98 don't need config.sys or autoexec.bat unless you are running some strange hardware than needs real mode drivers indeed i fixed computers before by deleting/renaming them. I've never admind an ME box but i belived they removed the option for them altogether.
config.sys and autoexec.bat really belong to dos and in the dos days there wasn't exactly a lot of choice on what you ran on your IBM compatible PC.
Actually the Linux kernel does these things pretty well. And modern distros that use udev, hal and dbus can detect hardware configurations on-the-fly. I was half-shocked when I plugged in my digital camera and it was detected and mounted automagically. The problem is X has it's own hardware subsystems for the sake of portability (BSD kernel does not Linux-like subsystems) and are not as good. It would be great if X just would let the Linux kernel do its thing. There is some work [x.org] being done along these lines and hopefully will improve the situation.
On the other hand, I've installed Suse, RedHat Enterprise, Fedora & Debian on dozens of boxes. Ubuntu is the only one who autodetected all of my video settings correctly.
I actually think this much to do with the good work done by the x.org folks, as well as work done by
For example, Debian "stable" still uses Xfree86, and Xfree86 couldn't detect it's left nut without editing the Xfree86 conf file.
Fedora at this time used an experimental version of X.org , wheras Ubuntu had a polished & more stable version.
RedHat used a stable version of X.org (maybe it was still Xfree86), but the config tools screwed up the config so badly taht X wouldn't start.
Suse had some propietary tools which mucked up the display.
A 6 week delay doesn't sound earth shattering to me... I fail to see the problem here, to be honest. Especially if it's about improving usability, an area critical for Linux adoption, which is one of the main purposes for this particular distro.
To me, this feels basically like delaying an extra security heavy distro 6 weeks to implement verify a new security protocol implementation works correctly.
Considering that they want this to be the first Ubuntu release that's supported for a long time and that can compete with things like SuSE's or RedHat's enterprise distributions, I'd say six weeks are perfectly acceptable.
To be honest, Dapper is very stable and polished already. There's mixed reactions over the new Clearlooks scheme they've implemented but overall, it's turning out very well. I can't speak for the localisation issues, but a stable release is much better than a rushed release. If you want to try Dapper, Flight 5 should be just fine.
There are certain things that simply do not work on Dapper at the moment. Most important for me, I haven't found a single Lisp compiler that works. CLisp, CMUCL, and SBCL all worked fine on breezy; as soon as I upgraded to dapper, they started segfaulting on startup... I know very little about the internals of Linux, but I think its something to do with changes in the memory model that are messing with the garbage collectors.
One of the reasons, imho, that Blizzard's games are always so good, is that they are not afraid to delay them. They test and test and tweak and tweak and when they game comes out, it is of the highest quality. Blizzard is admirable because they respect that programming is an art that can't be rushed. Most companies rush their products so they can start generating revenue.
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.
If it wasn't for the fact that Ubuntu is synchronized with Gnome releases I wouldn't mind the delay. But now they would have to either rush the next release, be late with it or completly skip Gnome 2.16. I hope they'll find some good solution because many users are preferring Ubuntu to other distros because of fairly nice bleeding-edgeness. With this step they could lose major selling point to causal Linux geeks.
The recent theme changes are not a step in good direction too. It looks abysymal and burns my eyes. Even tough I didn't like brown theme the new one made me miss it.
I think that almost everybody would agree that a little more time spent making a product better is a good thing.
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.:) Any steps, no matter how small, to appeal to the Chinese/Korean/Japanese markets will probably pay off well.
Not that it all matters to me, though... I use SUSE.:)
This is the Ubuntu that will be competing with Windows Vista. It needs to be polished.
There is going to be a reasonably large number of desktop users willing to "try Linux out" just before they "upgrade" to Vista. The distribution they're most likely to try is currently Ubuntu, and if it is good enough, they might switch to Linux rather than Vista.
By the way: does anyone know if dapper will ship a kernel that's been compiled with the version of gcc that's included on the distribution CD's? If badger had one fundamental flaw, it would be a kernel compiled with gcc3.4 and gcc 4.? included on the CD. People who need to compile e.g. their wireless driver because it's not included in the standard kernel, are fucked, because they may not have network access with the distribution files and need to download either gcc 3.4 or kernel sources...
The biggest issue is that not everyone will work on polish and bug fixing. Some will be working on development of new features. A good version control system should allow this state of affairs, but what will happen when someone working on the development branch gets a major new feature developed in the long six week time frame that others are working on the polish?
One faction will say, "Don't commit any new features until the next major release after this one!" while another faction will say "This is too important to wait through endless patch releases and another major release cycle!" The temptation will be to "just risk a few bugs" for this "major new feature" by those who don't really see the value of the polish right now. The offense will be that "any new feature" will require more polish, patches, or in essence de-values the work the polish team has been doing. Great amounts of spite and venom will be launched at each side.
Set a firm, clear policy about what the polish window will be and about the firm exclusion of new functionality that's independent of any particular technology before this starts and make sure everyone knows what that policy is. Not setting a policy is bound to cause chaos. Setting and then breaking a policy is bound to drive off any future desire to work on future "polish" release work.
I remember keeping track of the Breezy Badger planning wiki before that version was released, and it seemed to me that the team deferred many of their major goals... on the other hand, it looks like most improvements planned for Dapper have been implemented already, as Shuttleworth notes in his message:
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.
After the Asia business tour I realised that we need to improve our
support for Chinese, Japanese, Korean and other Asian fonts,
translations, input methods and supporting tools.
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.
I'm listing the specs for Ubuntu, and I'm glad to read that many things I had complained about in Hoary [slashdot.org] seem to be fixed, like network availability for installation and upgrading.
Some example specs (copied / pasted) :
The current i386/amd64 CD boot loader (isolinux) and configuration are not very user-friendly. Prompts can only be displayed in one language, and responses must be typed in by the user.
We should evaluate available options for replacements, and ways to simplify the process for the user, including:
- Displaying a countdown and automatically continuing after a timeout
- Allowing language selection from the boot loader
- Localized help
---
Upgrading from one Ubuntu release to the next is currently a power-user operation, involving editing of configuration files, careful attention to the decisions made by the packaging tools, and manual cleanup of obsolete or unwanted packages. This process should be wrapped in a tool (perhaps as extensions to update-manager), suitable for backporting to breezy-updates, which simplifies it for users, incorporating:
Automatic detection of the availability of a new release, offering an upgrade to the user
Preservation of user package selection (e.g., via metapackages)
Removal of obsolete packages (e.g., openoffice.org, python2.3)
Warnings about unsupported packages?
Do something sane with old kernel(s)
Upgrade packaging tools (including itself) first?
This is what all linux distros should do, start listening to the users instead of relying on the old "RTFM n00b" cliché.
I'm sure that if Ubuntu keeps doing all of these user-friendliness checks in a couple of years, Ubuntu will match the usability and installation-friendliness of WinXP, yay!:D
Friendly suggestion for the next time you happen to ask for help in a user forum:
Don't let your anger show. Frustration is understandable, but showing it makes you harder to communicate with. If you want people to help, don't make snide remarks.
You toss control back to whatever would otherwise load when it fails.
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.
What can we do to minimize this negative consequence?
As many others have pointed out, in 446 bytes, we can't do anything. All the Microsoft boot loader have historically done when it barfs is print something like "NT Loader not Found", and then left you "locked out of your system", just as GRUB did.
BTW, you're not really locked out. You can create a GRUB boot floppy and manually boot into your OS installation. You can also use the Windows CD to set the MBR back to its original state. Or you could use most Linux distros' rescue CDs to fix the problem.
IANAE but I think that the vast majority of your printers rely on patented Adobe technology, and as such, each manufacturer is on different versions and licenses.
I am, on the other hand, an expert on a technology called SVG, and I know that there are alot of guys at Canon working with the w3c on something called SVGPrint, which they are looking to use as an Open/Free mechanism to transmit data to all their printers. (In place of postscript?).
There is alot of work going on in these fields, but it will take a little bit longer until some of the newer open technologies hit the market.
by Anonymous Coward
on Saturday March 11 2006, @07:12PM (#14900238)
> spits control back to whatever would load in the absence of GRUB having been installed.
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,/boot/grub/stage2. GRUB needs to do this because it is bigger than 512 bytes, so stage 2 contains all of the GRUB code that doesn't fit in the first 512. GRUB needs to be this larger than 512 bytes because it's a really advanced boot loader, it even understands file systems, which allows it to load configuration files, initrds, kernels, and modules by reading the file system, instead of having hard coded locations of those files location (by disk geometry) rammed into it. (this really helps when you update, replace, or change those files!)
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/boot/grub/stage2, a location which is hard coded with the disk geometry location of this file. (stage 1 doesn't understand file systems).
As/boot/grub/stage2, the parition table, and the boot sector of your windows partition are completely differnt locations on the drive, it is entirely posible that GRUB stage 1 could have a problem, while the Microsoft MBR could not.
What could be different about these different locations on the drive?
If there was an error on the drive where/boot/grub/stage2 is located, but not in the partition table or boot sector of the Windows partition, one could fail where the other succeds.
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/boot/grub/stage2) is loadable, but a bug in the implementation means it only works for block_number=(location of partition table) or block_number=(location of boot sector). Who wants to bet that there are BIOS out there that only get tested by the manufacturer on MBRs that only load play with the partition table and boot sectors of partiti
Yeah, thats a common misconception. Ubuntu is not a snapshot of Debian Unstable. Multiverse is a snapshot of packages in Debian Unstable that are not in Universe, Main, or Restricted. Universe contains packages supported by the community, which is encouraged to work closely with Debian. Main and Restricted are both modules that are directly supported by Canonical. These packages are worked on heavily by employees of Canonical and while there is significant collaboration(some would like to see more, but thats a seperate debate) these packages are not just stabalized snapshots. Canonical puts a lot of time into Main and Restricted and you will often see versions of packages(and packages) that are in Ubuntu before they hit Debian. You can see that by the fact that Ubuntu Dapper currently has the prerelease gnome 2.13 while Debian still has 2.12. Please stop spreading this misinformation.
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
Re:Delay in Debian Derived Distro?? (Score:4, Informative)
Parent
Well, looking at Vista (Score:4, Insightful)
Re:Well, looking at Vista (Score:5, Funny)
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, Informative)
EasyUbuntu is better and much more in keeping with the Ubuntu way http://easyubuntu.freecontrib.org/ [freecontrib.org]
Parent
Re:Question? Answer. (Score:4, Informative)
See the FAQ: http://www.dvdcca.org/faq.html [dvdcca.org]
Michael
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:4, Interesting)
Fluendo has released a licensed MP3 plugin [fluendo.com] for the GStreamer framework. It's already in Debian unstable, and I'd say Ubuntu probably will include it.
Parent
Re:Question? Answer. (Score:5, Interesting)
Parent
Re:Question? Answer. (Score:4, Informative)
Parent
What does Ubuntu offer that Debian doesn't? (Score:3, Interesting)
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:What does Ubuntu offer that Debian doesn't? (Score:5, Interesting)
I used to use Debian on my laptop, but later switched to Ubuntu. Why?
It supports more hardware out-of-the-box, and it has newer GNOME packages than Debian. Things that I had to install in Debian (the touchpad, etc) were already installed.
I wouldn't use Ubuntu on a server though, everything I can do in Ubuntu I can do in Debian. Installing a Debian desktop is just more hassle than installing Ubuntu.
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
Re:"Linux for human beings" (Score:4, Informative)
config.sys and autoexec.bat really belong to dos and in the dos days there wasn't exactly a lot of choice on what you ran on your IBM compatible PC.
Parent
Blame X (Score:4, Informative)
Parent
Re:"Linux for human beings" (Score:4, Informative)
I actually think this much to do with the good work done by the x.org folks, as well as work done by
For example, Debian "stable" still uses Xfree86, and Xfree86 couldn't detect it's left nut without editing the Xfree86 conf file.
Fedora at this time used an experimental version of X.org , wheras Ubuntu had a polished & more stable version.
RedHat used a stable version of X.org (maybe it was still Xfree86), but the config tools screwed up the config so badly taht X wouldn't start.
Suse had some propietary tools which mucked up the display.
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)
Ubuntu is Debian, Debian is Ubuntu... (Score:3, Funny)
Really... (Score:5, Insightful)
Re:Really... (Score:4, Interesting)
Parent
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.
Out of sync (Score:4, Insightful)
The recent theme changes are not a step in good direction too. It looks abysymal and burns my eyes. Even tough I didn't like brown theme the new one made me miss it.
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
Re:Not just polish... (Score:4, Funny)
Parent
It's worth delaying (Score:4, Insightful)
There is going to be a reasonably large number of desktop users willing to "try Linux out" just before they "upgrade" to Vista. The distribution they're most likely to try is currently Ubuntu, and if it is good enough, they might switch to Linux rather than Vista.
Compile kernel modules for dapper (Score:4, Insightful)
Value of Polish vs. New Features (Score:4, Insightful)
One faction will say, "Don't commit any new features until the next major release after this one!" while another faction will say "This is too important to wait through endless patch releases and another major release cycle!" The temptation will be to "just risk a few bugs" for this "major new feature" by those who don't really see the value of the polish right now. The offense will be that "any new feature" will require more polish, patches, or in essence de-values the work the polish team has been doing. Great amounts of spite and venom will be launched at each side.
Set a firm, clear policy about what the polish window will be and about the firm exclusion of new functionality that's independent of any particular technology before this starts and make sure everyone knows what that policy is. Not setting a policy is bound to cause chaos. Setting and then breaking a policy is bound to drive off any future desire to work on future "polish" release work.
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.
Wow. (Score:4, Informative)
Some example specs (copied / pasted) :
This is what all linux distros should do, start listening to the users instead of relying on the old "RTFM n00b" cliché.
I'm sure that if Ubuntu keeps doing all of these user-friendliness checks in a couple of years, Ubuntu will match the usability and installation-friendliness of WinXP, yay!
Re:User friendly? (Score:4, Insightful)
Don't let your anger show. Frustration is understandable, but showing it makes you harder to communicate with. If you want people to help, don't make snide remarks.
Parent
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:4, Informative)
As many others have pointed out, in 446 bytes, we can't do anything. All the Microsoft boot loader have historically done when it barfs is print something like "NT Loader not Found", and then left you "locked out of your system", just as GRUB did.
BTW, you're not really locked out. You can create a GRUB boot floppy and manually boot into your OS installation. You can also use the Windows CD to set the MBR back to its original state. Or you could use most Linux distros' rescue CDs to fix the problem.
Parent
Re:User friendly? (Score:4, Informative)
I am, on the other hand, an expert on a technology called SVG, and I know that there are alot of guys at Canon working with the w3c on something called SVGPrint, which they are looking to use as an Open/Free mechanism to transmit data to all their printers. (In place of postscript?).
There is alot of work going on in these fields, but it will take a little bit longer until some of the newer open technologies hit the market.
Parent
Re:User friendly? (Score:4, Funny)
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:Ubuntu release philosophy: A fatal flaw (Score:5, Informative)
Parent
Re:worth delaying for WPA support alone (Score:4, Informative)
Parent