"I've seen members of hit bands looking for odds jobs because their back catalog doesn't sell"
Not gonna cry too much over that. I go to work every day and do a good job; I don't expect to then be able to retire a year later and live off the profits of that good day's work forever more...
Frankly, we rather feel grub2 is something of a downgrade too. Or at least an unnecessary pain in the ass. Fedora isn't going to grub2 because we think it's way better than grub - we don't. Fedora's going to grub2 because it's what upstream supports, and we're tired of having an entire person who does nothing but keep grub-legacy working now upstream doesn't care about it any more.
"Is this extra "BIOS Boot Partition" partition really necessary on non-UEFI machines?"
Yes.
"Why cant we use/boot for that?"
BIOS boot partition replaces the empty space behind the MBR on MS-DOS labelled partitions, where bootloaders used to expand themselves. You can't use/boot because the BIOS boot partition exists *for the convenience of the bootloader* - i.e. it's part of the bootloader, really, not part of the installed OS. You only need one no matter how many OSes (and/boot partitions) you have.
Well...we actually don't use grub2 for EFI, because grub2-efi tested out to be really buggy. if you do an EFI install of F16 you get grub-legacy.
(In hindsight that was a bad call because it made all manner of things way more complex than they should be, but hey, hindsight is 20/20, right?)
we'll go grub2 for EFI whenever it stops sucking so much. probably F17 or F18.
Re:ever try it, or you just post what you THINK wo
on
Fedora 16 Released
·
· Score: 1
most developers don't read forums, as they're incredibly inefficient; just keeping up with Bugzilla is enough work. so if you want a dev to see your issue, file it as a bug, not a forum post.
Modern graphics cards don't even have 2D support any more. They fake it up. It makes precisely zero sense to target a card S3 made in 1998 when you're writing an entirely new Shell. Zero. Sense. The _only_ sane way to do it is via GL.
llvmpipe is slow when Phoronix is benchmarking Quake 3, sure. So what? Shell is a _desktop_, it does not feature rocket launchers or complex lighting. The performance of Shell / llvmpipe is reasonable running on an emulated Cirrus adapter in a KVM, for pity's sake, with absolutely no performance tuning done yet. You really don't need much power to render Shell perfectly well. All that was needed was *feature* support in llvmpipe, for even quite modest hardware to be able to render Shell reasonably without hardware 3D.
"Or you can make the audio card run in the sampling rate of the audio file..."
PA actually does this now - if the card is capable of it (many aren't, these days, and can only output 48KHz, so any time you're playing a CD-sourced audio file, it's going to need resampling), and if you're only playing one stream or multiple streams all at the same sampling rate.
"And resampling still does not justify the CPU usage (unless who did the resampling algorithm used a naive algorithm, which may be very well possible), especially with SIMD instructions."
Resampling is a rather more complex operation than you might think, at least to do it well. You can do an okay job very quickly, and that's what 'simple' does. The speex methods are more complex but give better results. You can't rely on SIMD instructions always being available; PA could ship some SIMD-dependent resampler as an option, I guess, but that would be something of a tweak and no-one would notice it anyway. I'm sure if someone contributed a resampler which used advanced instructions and the logic for PA to use it on CPUs that support advanced instructions and fall back to another resampler otherwise then that would be accepted, but in a way it's kind of a waste, because the modern CPUs which support advanced instruction sets are probably powerful enough to run the less efficient resamplers without a noticeable performance impact anyway, it's the older CPUs that struggle - the ones with less advanced instruction sets...
Someone's already posted, up-list, one of the many tools out there that exist solely to implement USB boot for legacy systems: it's just a small bootloader you can write to a CD which will then boot any bootable USB stick you plug in. Cost: 1 CD, let's you boot any USB stick.
"So what is wrong with giving folks choice, isn't that is what FOSS is supposed to be out, choice? Why not have a 2 CD set AND a DVD with everything but the kitchen sink, why not that?"
So here's the deal: because it's really fucking hard to fit everything in 650MB (or 700MB). This is not new. We were struggling with it at Mandrake in 2005, for pity's sake. We had this crazy-ass system where we produced four different versions of every live CD we produced, with different sets of languages on each, just to free up a bit more space for packages. You know something is crazy when it takes hours just to think up a cogent naming scheme (okay, so 'Mandrake 10' - that's the version. 'KDE Live' - that's the...image, build, spin, whatever. 'English / French / German' - that's the...version? No wait, we used that word already. Flavor? Well, that sounds fucking dumb. Er...)
Any distributor at all will tell you that trying to fit a functional desktop with an office suite - and if you try and take out the office suite, people kick and scream like anything - in 650MB is an exercise in pain, and all distributions have to compromise on something to achieve it. It's not a new situation. It's not as if Ubuntu magically bloated up lately. It's just that we're maybe, finally, reaching the point where USB sticks and DVDs are prevalent enough to ditch the CD size images, by default.
"So what is wrong with giving folks choice"
It's very simple: it makes QA and support a nightmare. One of the major reason why distros are perceived to have so many bugs is they try and support too much stupid user choice. It sounds all fine and dandy to say 'well just provide two images then' until you realize that doubles absolutely every QA / support cost *all the way down the line*. Take your release validation test suite and double it, and then see if you can achieve the same release quality without somehow finding twice the QA resources out of your ass. Take the burden on the poor schmucks who run your support forum and double it.
This is the point Mark was making in the recent Ubuntu bug about the Unity launcher location, and much as folks hated it, he's absolutely right. It sounds fine and dandy and all to say 'well, everyone should have the choice of where to put the Unity launcher!' except that what you're essentially doing is saying 'I want to quadruple the burden on the Unity developers and the UI QA system for no really good reason'. You want Unity to be robust and to have _really useful and interesting_ new features added quickly? Then accept that just locking the location of the damn launcher is going to help them achieve that.
The GNOME devs came to the exact same conclusion with Shell. Apple came to the exact same conclusion long ago; they maybe took it a mite too far, but if you ever wonder why OS X is considered so 'polished' and 'reliable' a major, major factor is that it isn't stuffed with messy, fragile code to implement pointless 'user choice' features, which promptly breaks all the damn time and makes QA a nightmare because _every additional choice_ doubles the QA team's problem space, and that kind of logarithmic growth is a bitch.
It's an issue I've seen come up _in the last week_ with the Fedora installer team. Getting Fedora 16 released has proved to be a hell of an operation, and this exact problem is a large part of the reason why. We're switching to grub2 with this release, and GPT disk labels; in doing so it became rapidly and painfully obvious that the huge rat's nest of 'user choice' options we've built up in the installer over the years is a giant hostage to fortune. It sounds fine and dandy to give everyone the option to choose exactly where to install the bootloader, install to a RAIDed LVM if they feel like it, and write the installer to a DVD or a CD or a USB stick, the latter in three different ways, and upgrade with any one of three rather different methods - but when you realize you have to ensure the bootloader upgrade (and everything else, of course,
In 'the west' I've found writeable CDs now cost more than DVDs in most stores. The equation does change a bit if you consider places where older technology is still in use, though.
"Like what? Using more CPU for audio than for playing a video? (yes, I did this test)"
I highly doubt that unless you're using something like VDPAU, in which case it's hardly a fair test as the CPU isn't _doing_ any video decoding.
However, it's true that PA uses more CPU time than ALSA by default; know why? Because it does higher quality resampling. Given that low quality resampling can introduce audible artifacts into your sound stream, I'm all in favour, thanks. But if you want to change PA to use the same resampling algorithm ALSA does, and hence gain 'performance' at the cost of audio quality, edit/etc/pulseaudio/daemon.conf and change resample-method from 'speex-float-3' to 'trivial'.
but the OP asked "How is this different from an ISP offering (for example) 1Mbps and 10Mbps connections at different prices?", and this entire sub-thread is a discussion of that OP's example. So *you're* the one who's off-topic, bub.
Most of the people who wrote teary-eyed Jobs obits and held candlelit vigils at Apple stores and proposed that there be a Steve Jobs day probably "thought that the iPod and beyond was all that mattered?". I'm guessing most of them weren't NeXT fans.
counting numbers of security advisories issued for a product is an entirely useless metric when it's up to the creator of the product under what circumstances to issue an advisory. Red Hat could stop issuing security advisories for anything tomorrow, and by your metric, it would then be the Most Secure Thing Ever.
By counting advisories and then ranking on the basis that more advisories = less security you're essentially punishing good behaviour. It's not a _good_ thing to encourage companies to stop telling you about security issues.
It's not really Ubuntu specific; I suspect they use Ubuntu as the example just because it's the one most organizations are actually likely to want to mention.
The FSF's list of free Linux distros - https://www.gnu.org/distros/free-distros.html - is pretty short and, well, not comprised of the distros that first spring to your mind, probably.
FSF does have a well-maintained and reasonably phrased listing of why they don't consider most major distros free:
man. I've only ever seen one episode of Seinfeld, but the first thing I thought when I saw that comment was "oh, I bet that's a Seinfeld quote". Then I saw how angry the replies to it were, and figured it couldn't possibly be a quote or they'd have realized.
Once again I fail to correctly estimate the idiocy of internet commenters!
so if I worked at Apple I'd've built an extra parking space with 'RESERVED FOR CEO' marked on it in big white letters.
If Jobs refused to use it and kept parking in the handicap spot, I'd call a meeting for all handicapped people on staff and tell 'em they can park in the CEO spot...
"and a stupid one as well. It shows a fundamental lack of understanding Apple and Android.
Android is an OS. Different compnais put it on different phones. Thnis means different capabilities and corporate plansd
Apple is the entire chain."
Well, yes, and if you read the entire article, he explicitly calls this out as a reason why Apple is better at keeping their phones up to date.
But...so what? The fact that there's some kind of reason why Android phones are so bad at this does not mean they're not bad. They're still bad, and it's still a practical problem for people who buy them.
Except for the dozens of security holes lying around in old versions of Android, that is.
Android is a full computer operating system, which means it *inevitably* has hundreds of security holes. Which means companies that sell Android hardware should be strapping themselves in for the security update responsibility that all other companies who sell computer operating systems correctly expect to assume. Except somehow they don't, and their customers don't crucify them for it.
The OP might be rather Apple-biased but it's highlighting an entirely valid point. Maybe people don't really need the new features of new Android releases, but they damn well deserve security updates, and they're not getting them.
Slashdot Mirror
...America has officially jumped the shark. It was a nice ride, folks, we'll catch you on the flip side.
"Hey, a notification icon might be a neat idea" is a valid patent in your universe? Really?
but that's my secret recipe!
"I've seen members of hit bands looking for odds jobs because their back catalog doesn't sell"
Not gonna cry too much over that. I go to work every day and do a good job; I don't expect to then be able to retire a year later and live off the profits of that good day's work forever more...
That's https://bugzilla.redhat.com/show_bug.cgi?id=737508 .
Frankly, we rather feel grub2 is something of a downgrade too. Or at least an unnecessary pain in the ass. Fedora isn't going to grub2 because we think it's way better than grub - we don't. Fedora's going to grub2 because it's what upstream supports, and we're tired of having an entire person who does nothing but keep grub-legacy working now upstream doesn't care about it any more.
"Is this extra "BIOS Boot Partition" partition really necessary on non-UEFI machines?"
Yes.
"Why cant we use /boot for that?"
BIOS boot partition replaces the empty space behind the MBR on MS-DOS labelled partitions, where bootloaders used to expand themselves. You can't use /boot because the BIOS boot partition exists *for the convenience of the bootloader* - i.e. it's part of the bootloader, really, not part of the installed OS. You only need one no matter how many OSes (and /boot partitions) you have.
Well...we actually don't use grub2 for EFI, because grub2-efi tested out to be really buggy. if you do an EFI install of F16 you get grub-legacy.
(In hindsight that was a bad call because it made all manner of things way more complex than they should be, but hey, hindsight is 20/20, right?)
we'll go grub2 for EFI whenever it stops sucking so much. probably F17 or F18.
most developers don't read forums, as they're incredibly inefficient; just keeping up with Bugzilla is enough work. so if you want a dev to see your issue, file it as a bug, not a forum post.
Modern graphics cards don't even have 2D support any more. They fake it up. It makes precisely zero sense to target a card S3 made in 1998 when you're writing an entirely new Shell. Zero. Sense. The _only_ sane way to do it is via GL.
llvmpipe is slow when Phoronix is benchmarking Quake 3, sure. So what? Shell is a _desktop_, it does not feature rocket launchers or complex lighting. The performance of Shell / llvmpipe is reasonable running on an emulated Cirrus adapter in a KVM, for pity's sake, with absolutely no performance tuning done yet. You really don't need much power to render Shell perfectly well. All that was needed was *feature* support in llvmpipe, for even quite modest hardware to be able to render Shell reasonably without hardware 3D.
"Or you can make the audio card run in the sampling rate of the audio file..."
PA actually does this now - if the card is capable of it (many aren't, these days, and can only output 48KHz, so any time you're playing a CD-sourced audio file, it's going to need resampling), and if you're only playing one stream or multiple streams all at the same sampling rate.
"And resampling still does not justify the CPU usage (unless who did the resampling algorithm used a naive algorithm, which may be very well possible), especially with SIMD instructions."
Resampling is a rather more complex operation than you might think, at least to do it well. You can do an okay job very quickly, and that's what 'simple' does. The speex methods are more complex but give better results. You can't rely on SIMD instructions always being available; PA could ship some SIMD-dependent resampler as an option, I guess, but that would be something of a tweak and no-one would notice it anyway. I'm sure if someone contributed a resampler which used advanced instructions and the logic for PA to use it on CPUs that support advanced instructions and fall back to another resampler otherwise then that would be accepted, but in a way it's kind of a waste, because the modern CPUs which support advanced instruction sets are probably powerful enough to run the less efficient resamplers without a noticeable performance impact anyway, it's the older CPUs that struggle - the ones with less advanced instruction sets...
Someone's already posted, up-list, one of the many tools out there that exist solely to implement USB boot for legacy systems: it's just a small bootloader you can write to a CD which will then boot any bootable USB stick you plug in. Cost: 1 CD, let's you boot any USB stick.
Er, mine does. Are you sure you're doing it right?
"So what is wrong with giving folks choice, isn't that is what FOSS is supposed to be out, choice? Why not have a 2 CD set AND a DVD with everything but the kitchen sink, why not that?"
So here's the deal: because it's really fucking hard to fit everything in 650MB (or 700MB). This is not new. We were struggling with it at Mandrake in 2005, for pity's sake. We had this crazy-ass system where we produced four different versions of every live CD we produced, with different sets of languages on each, just to free up a bit more space for packages. You know something is crazy when it takes hours just to think up a cogent naming scheme (okay, so 'Mandrake 10' - that's the version. 'KDE Live' - that's the...image, build, spin, whatever. 'English / French / German' - that's the...version? No wait, we used that word already. Flavor? Well, that sounds fucking dumb. Er...)
Any distributor at all will tell you that trying to fit a functional desktop with an office suite - and if you try and take out the office suite, people kick and scream like anything - in 650MB is an exercise in pain, and all distributions have to compromise on something to achieve it. It's not a new situation. It's not as if Ubuntu magically bloated up lately. It's just that we're maybe, finally, reaching the point where USB sticks and DVDs are prevalent enough to ditch the CD size images, by default.
"So what is wrong with giving folks choice"
It's very simple: it makes QA and support a nightmare. One of the major reason why distros are perceived to have so many bugs is they try and support too much stupid user choice. It sounds all fine and dandy to say 'well just provide two images then' until you realize that doubles absolutely every QA / support cost *all the way down the line*. Take your release validation test suite and double it, and then see if you can achieve the same release quality without somehow finding twice the QA resources out of your ass. Take the burden on the poor schmucks who run your support forum and double it.
This is the point Mark was making in the recent Ubuntu bug about the Unity launcher location, and much as folks hated it, he's absolutely right. It sounds fine and dandy and all to say 'well, everyone should have the choice of where to put the Unity launcher!' except that what you're essentially doing is saying 'I want to quadruple the burden on the Unity developers and the UI QA system for no really good reason'. You want Unity to be robust and to have _really useful and interesting_ new features added quickly? Then accept that just locking the location of the damn launcher is going to help them achieve that.
The GNOME devs came to the exact same conclusion with Shell. Apple came to the exact same conclusion long ago; they maybe took it a mite too far, but if you ever wonder why OS X is considered so 'polished' and 'reliable' a major, major factor is that it isn't stuffed with messy, fragile code to implement pointless 'user choice' features, which promptly breaks all the damn time and makes QA a nightmare because _every additional choice_ doubles the QA team's problem space, and that kind of logarithmic growth is a bitch.
It's an issue I've seen come up _in the last week_ with the Fedora installer team. Getting Fedora 16 released has proved to be a hell of an operation, and this exact problem is a large part of the reason why. We're switching to grub2 with this release, and GPT disk labels; in doing so it became rapidly and painfully obvious that the huge rat's nest of 'user choice' options we've built up in the installer over the years is a giant hostage to fortune. It sounds fine and dandy to give everyone the option to choose exactly where to install the bootloader, install to a RAIDed LVM if they feel like it, and write the installer to a DVD or a CD or a USB stick, the latter in three different ways, and upgrade with any one of three rather different methods - but when you realize you have to ensure the bootloader upgrade (and everything else, of course,
It may be doing a checksum on the burned disc to ensure it burned correctly.
In 'the west' I've found writeable CDs now cost more than DVDs in most stores. The equation does change a bit if you consider places where older technology is still in use, though.
"Like what? Using more CPU for audio than for playing a video? (yes, I did this test)"
I highly doubt that unless you're using something like VDPAU, in which case it's hardly a fair test as the CPU isn't _doing_ any video decoding.
However, it's true that PA uses more CPU time than ALSA by default; know why? Because it does higher quality resampling. Given that low quality resampling can introduce audible artifacts into your sound stream, I'm all in favour, thanks. But if you want to change PA to use the same resampling algorithm ALSA does, and hence gain 'performance' at the cost of audio quality, edit /etc/pulseaudio/daemon.conf and change resample-method from 'speex-float-3' to 'trivial'.
but the OP asked "How is this different from an ISP offering (for example) 1Mbps and 10Mbps connections at different prices?", and this entire sub-thread is a discussion of that OP's example. So *you're* the one who's off-topic, bub.
Most of the people who wrote teary-eyed Jobs obits and held candlelit vigils at Apple stores and proposed that there be a Steve Jobs day probably "thought that the iPod and beyond was all that mattered?". I'm guessing most of them weren't NeXT fans.
Just a very short refutation:
counting numbers of security advisories issued for a product is an entirely useless metric when it's up to the creator of the product under what circumstances to issue an advisory. Red Hat could stop issuing security advisories for anything tomorrow, and by your metric, it would then be the Most Secure Thing Ever.
By counting advisories and then ranking on the basis that more advisories = less security you're essentially punishing good behaviour. It's not a _good_ thing to encourage companies to stop telling you about security issues.
It's not really Ubuntu specific; I suspect they use Ubuntu as the example just because it's the one most organizations are actually likely to want to mention.
The FSF's list of free Linux distros - https://www.gnu.org/distros/free-distros.html - is pretty short and, well, not comprised of the distros that first spring to your mind, probably.
FSF does have a well-maintained and reasonably phrased listing of why they don't consider most major distros free:
https://www.gnu.org/distros/common-distros.html
man. I've only ever seen one episode of Seinfeld, but the first thing I thought when I saw that comment was "oh, I bet that's a Seinfeld quote". Then I saw how angry the replies to it were, and figured it couldn't possibly be a quote or they'd have realized.
Once again I fail to correctly estimate the idiocy of internet commenters!
so if I worked at Apple I'd've built an extra parking space with 'RESERVED FOR CEO' marked on it in big white letters.
If Jobs refused to use it and kept parking in the handicap spot, I'd call a meeting for all handicapped people on staff and tell 'em they can park in the CEO spot...
"and a stupid one as well. It shows a fundamental lack of understanding Apple and Android.
Android is an OS. Different compnais put it on different phones. Thnis means different capabilities and corporate plansd
Apple is the entire chain."
Well, yes, and if you read the entire article, he explicitly calls this out as a reason why Apple is better at keeping their phones up to date.
But...so what? The fact that there's some kind of reason why Android phones are so bad at this does not mean they're not bad. They're still bad, and it's still a practical problem for people who buy them.
"OS updates only matter to tech savvy users"
Except for the dozens of security holes lying around in old versions of Android, that is.
Android is a full computer operating system, which means it *inevitably* has hundreds of security holes. Which means companies that sell Android hardware should be strapping themselves in for the security update responsibility that all other companies who sell computer operating systems correctly expect to assume. Except somehow they don't, and their customers don't crucify them for it.
The OP might be rather Apple-biased but it's highlighting an entirely valid point. Maybe people don't really need the new features of new Android releases, but they damn well deserve security updates, and they're not getting them.
"Yellow for ten months (would have gone green this month, but 4.0 was released)"
No, it wasn't; it was announced. You can't actually buy it.
This is the standard he used for the graph: he counts an OS as 'released' when you can actually go out and buy a device that runs it.