Mark Shuttleworth Proposes Delaying next Ubuntu
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.
He proposes a town hall for March 14, not April.
505 users in favor of the delay, 50 against at last count.
http://ubuntuforums.org/showthread.php?t=142536
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.
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.
Keep up the good work guys.
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.
The problem is that, with a broken bootloader, you can't really 'bypass it'. The bootloader, by definition, is the first thing that runs. If it's broken, there's nowhere to put the logic to do anything else. Maybe if the PC had a more usable firmware than the BIOS we're stuck with, you might have some recovery route, but the way the platform is set up, you have no alternatives.
my sig's at the bottom of the page.
How is it then that other distributions (pclinux being the best at it) provide all the goodies right out of the box year after year without having problems? Afterall, if it was such a contentious issue, they'd be shut down faster than you could say "uck, not turd brown again!".
Karma: Neutered
You toss control back to whatever would otherwise load when it fails.
...
Back to whatever would otherwise load? That would be nothing (Well, not nothing, but it's impossible to determine what that something would be). The BIOS loads the first 512 bytes of the disk (the MBR) into ram at location 07c0:0000, that MBR then loads the 512 bytes at the start of the partition marked "active" in the MBR at address 07c0:0000. Now, keep in mind that there are 512 bytes in the MBR for data, and code, also remember that the MBR just loaded the partition bootloader over itself in RAM, it's not there any more at all. Next, the partition bootloader (grub in this case) has 512 bytes at location 0x7c0:0000 to load the rest of itself into memory, including error conditions. Now, the read fails, and you get code like this:
if(read failed)
print ("read error")
goto fail
fail:
clear interrupts
halt cpu
because there isn't any other option. You can't just jump back to code that was overwritten when you came into ram. There is no option but to crash in this case. It's like if your interrupt handling code page faults. Your OS WILL crash.
God save our Queen, and Heaven bless The Maple Leaf Forever!
Except, I don't believe, that's on the cards
Considering that Dapper is going to be a major release, oriented towards gaining the business market, not supporting WPA is a big mistake!
I hope I'm wrong
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.
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.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
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.
"We Don't Need No Truthless Heros!" - Project 86
get it here: http://www.ubuntu.com/testing/flight5 Live CD and .torrents available
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 being done along these lines and hopefully will improve the situation.
The best education consists in immunizing people against systematic attempts at education. - Paul Feyerabend
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.
Ahem... Mandriva does.
Yes, there's an automated installer called Automatix. It's only for Ubuntu Breezy, but there should be a new one when Dapper is final.
You want ubuntu unstable? Well that is dapper at the moment isn't?
p yGroundhog ?
Though when dapper is released you have to do a dist-upgrade to the next development release.
If you really want bleeding edge ubuntu, then perhaps this version is better: https://wiki.ubuntu.com/UbuntuDownUnder/BOFs/Grum
Anyway, if you want just more than security updates, then the backports repositories is enough for me.
My other Sig is very funny.
Install XP on one disk, install Linux on another. Write GRUB on Linux disk and set the BIOS to boot from that. Now if GRUB boots ok, you can choose between linux and xp. If GRUB errors, then change the BIOS setting and boot from the NTFS disk. Your xp installation will boot without a problem. If your most important installation is xp, the wise thing to do is install Ubuntu in a new disk and not repartition the old one
> spits control back to whatever would load in the absence of GRUB having been installed.
/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!)
/boot/grub/stage2, a location which is hard coded with the disk geometry location of this file. (stage 1 doesn't understand file systems).
/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.
/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.
/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
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
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.
Big ones, small ones, some as big as yer 'ead!
Give 'em a twist, a flick o' the wrist...
It is.
They just don't publicize it enough. Probably so they don't get sued for that, too.
I think you're trolling. As an engineer, you should be able to understand "that's just the way it has to be." I'll try to explain further, but for some reason, I don't think you'll get it:
PCs have exactly one master boot record. That master boot record points to exactly one bootloader. When you install GRUB, the single entry in the master boot record is changed to load GRUB instead of the Windows bootloader. There is no "whatever would have loaded." PCs just aren't designed that way. Don't like it? Call IBM and ask them to go back in time and fix it. But until then, that's just the way it is.
As for Ubuntu's install instructions not being correct, I find it highly unlikely. The fact that tens of thousands of people have managed to install it just fine by following those same instructions would seem to indicate that it does work the vast majority of the time. The logical conclusion when a set of instructions work fine for thousands of people but don't work for you, would seem to be that you did something wrong. Believe it or not, even an "engineer" can fuck up sometimes. Did you try the install again paying closer attention to the instructions? Did you make sure your partitions were correct? Did you try using LILO instead? Or did you just get pissed and start trolling?
Oh, and by the way, I like how you state that you're not a software engineer and that you have no idea how PCs boot, and then make suggestions about how GRUB and the boot process should work. Do you have software engineers telling you how helicopters should work? How often are their good ideas thrown out because they don't know how anything works?
Maybe not
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.
A bootstrap loader sits in the Master Boot Record -- the first 512 bytes on the disc. The BIOS knows how to position the reading heads at any cylinder and sector on the disc's surface and select the signal from any head. It knows precious little else. What it does when first switched on is go to head 0, cylinder 0, sector 0 {which is the only sector you can be absolutely cast-iron certain will definitely always exist, no matter what size drive it is}; read that sector, which is 512 bytes big, into memory; and begin executing it as instructions.
/mbr
Within the space of those 512 bytes, you have to have a program which loads the operating system proper. It can use BIOS calls to find any place on the disc {or just within the first 1024 cylinders, if it's a really ancient BIOS} in order to do this. Once the operating system itself has loaded, it no longer needs to rely on the BIOS's own methods of accessing the disk; it can talk to devices directly.
Windows has a bootstrap loader of its own, which goes in the MBR. Grub also goes in the MBR. Even Lilo, the original bootstrap loader which had nothing wrong with it in the first place before Grub became all trendy, goes in the MBR. When you installed Grub, you overwrote Windows' own bootstrap loader. It is now lost for all time.
The solution is to replace the MBR. Either boot up with a Windows CD and do
C:\> fdisk
to install the MBR from Windows; or boot up with the kernel from a Linux boot CD, using a cheatcode to specify your usual root file system:
boot: linux root=/dev/hda1
{or whatever partition it's on}, and then re-configure Grub. Or preferably just install Lilo instead.
I hope this explains why you can't have a fallback when the bootstrap loader fails. In the Olden Days, with no bootstrap loader you would have been given a simple memory editor which would allow you to display the contents of memory, enter instructions and data in hexadecimal, and begin executing instructions from memory. Things like this would be useful to programmers {you could type in a bootstrap loader by hand if you needed to}, but they stopped being popular about the time more non-programmers started buying computers. More sophisticated display devices began needing more sophisticated BIOSes, and the hex editor {which most users would not know how to use anyway} was squozen out to make room.
Je fume. Tu fumes. Nous fûmes!
If you live in the EU or the UK, and certain other countries, a software MP3 player licence costs nothing; the patents in question are not valid in those countries.
Je fume. Tu fumes. Nous fûmes!
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!
I think the next release of Ubuntu has some really bleeding edge new features and testing is probably not going well. XGL alone is a bit of a gamble(though I cannot wait to have it running soon after a full install) and I think he's looking at some of the QA for some of these features and flinching. I don't blame him but the community will be there for it, so let it delay 6 weeks if they think that's enough time to make some significant resolution to the quality of the distribution, otherwise let it fly and see if it stabilizes with the increased interest.
Because the DVD program you installed on Windows is using a licensed copy of the MPEG codec - not a hacked codec based on DeCSS.
I guess your meant Windows.
But that's not true either. The windows boot loader is fully capable of loading another OS.
Take a look at
Garry Williams
He was just being sarcastic dude...
We all know what to do, but we don't know how to get re-elected once we have done it
See the FAQ: http://www.dvdcca.org/faq.html
Michael
"No live organism can continue for long to exist sanely under conditions of absolute reality;..."
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.
"I think it would be a good idea!"
Gandhi, about Internet Security
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.
EasyUbuntu is better and much more in keeping with the Ubuntu way http://easyubuntu.freecontrib.org/
Well, the Ubuntu "unstable" releases tend to be a lot less stable than Debian unstable. It's because they tweak so much stuff and are preparing for a stable release and expect a consistent environment for the upcoming release. Nothing wrong with that but the pre-releases don't tend to work that great until the beta is released.
The ratio of people to cake is too big