"I realize that every individual has their own set of priorities and concerns with their browser, but that's exactly what's great about extensions. Put the necessary stuff in and leave the optional stuff optional. Keep the footprint small and avoid both bloat and insecurity in the process."
This is exactly it. If I can be forgiven for using a cliche, "extensions are the new tabs". They're as much of a killer app as tabs were, IMO.
Not only do extensions make it possible to keep the base install simple and add features only a fraction of people want (eg mouse gestures, sessions) on an as-needed basis, they allow lawsuitbait features (eg BugMeNot integration) and features too narrow in scope to make it into an official release (eg enhancements for specific websites like Fark).
Naturally, some want a browser that works the way they want out of the box, and perhaps Firefox can't do that for everyone. I have no problem with that. I don't even have a problem with people using IE. What I like is that there's a powerful choice that works well for me, and the fact that IE's market share isn't high enough to let websites start requiring it again (it still happens but it was much more common a few years ago).
Also... now that the Mac version doesn't suck I can ditch Safari. It still has a slightly smaller memory footprint, but it's not significantly faster anymore and there are themes that help Firefox look native. With Firefox's feature lead, it's worth a small memory hit even on my older iBook, and with the ruthless efficiency of the AdBlock and Fliterset.G Updater extensions I even end up saving memory.
I said "one of the slowest desktop processors available". Chips that aren't available as desktop chips anymore don't count.
Pentium 4s might be slower at the same clock speed, but given the clock speed advantage they stay ahead pretty easily.
"which is up to 6x powerful per CPU-cycle than a P4 in most tests."
Of course, it's also dramatically slower in other tests and overall. Being able to find a niche where it's faster doesn't say a lot. For example, a C3 with its hardware encryption engine is fast at encryption, but not fast overall.
For the loads that actually get put on desktop chips,the only thing slower than a G4 is a C3, and those are a lot cheaper.
"But how competent do you have to be to make sure the program stops receiving data when the buffer is full?"
It may be difficult to grasp intuitively, but it's extremely easy to do by accident in languages like C++ (by far the most common for games programming). In fact, you will most likely be vulnerable if you don't go out of your way to prevent it.
For example, if the program expects something to be a certain size, it will often only provide enough memory for the expected size an never confirm that it actually is of that size. This happens a lot.
Other security problems can occur when a program takes things for granted, like that a number will be within a given range because a number outside of the range can't occur in normal conditions. For example, there was a security problem where IE didn't make sure one of the values in an image's header wasn't negative, and this allowed a malicious image to execute arbitrary code. It's common for games to make such assumptions.
"Why does the buffer's data structure even allow this?"
Buffers are typically on the stack, and the stack contains information such as return addresses for functions. Putting them elsewhere involves allocating your own memory which is more work, leads to other sorts of bugs, and incurs a performance hit. This is a weakness which other languages address, but they also suffer from disadvantages (mostly performance) that make them unappealing for games.
Preventing these issues is hard because basically you have to spend a lot of time making sure everything is within certain limits, and working out what those limits are. Even small slipups can result in security problems, so you have to be careful.
While that would be true in general, G4s have now fallen so far behind that even poor performance relative to other chips is an improvement over a G4. And these things have three of those cores.
A G5 system would probably be competitive as a desktop, but no one's selling those at a low enough price to be directly comparable.
I remain skeptical, but your argument is much more compelling than MisterEntropy's. In particular, he advocates a strategy for which no software currently exists.
"1. Start with an MP3 2. Decompress and burn 3. Rip and undecompress to reproduce the original MP3
As you can see, there is no lossy compression step in this sequence -- no information is discarded."
There exists no way to "undecompress" an MP3 or other lossy file in the way you describe. If you disagree you are invited to link to software that actually exists that can do it, or even a paper decribing how to do it.
Because the original file can't be reconstructed. Lossy compression is a process that discards information.
"undecompressing and compressing are different problems"
The only decompression that happens is when a bitstream is created that mimics the original. This is what happens when you play it, and the same codec is used when you burn a CD. The CD is not the same as the original uncompressed copy, and the original compressed copy cannot be reconstructed from it. It's not like a.zip file.
If you could reconstruct the original file from a copy that's been through lossy compression, it wouldn't be called "lossy" and there would be no need for lossless codecs.
"Ripping a track and compressing it to AAC or MP3 is lossy, but _decompressing_ it to burn onto CD is not. Decompression is essentially lossless and can be perfectly inverted."
The resulting CD will have the same quality as the original 128 kbps AAC (or whatever it is), and you can rip the CD to get a.wav or a.flac or whatever with the same quality as the original 128 kbps, but you can't get another file compressed with a lossy codec without generation loss. The quality of iTMS and most other (legal) online music stores is already marginal, so it's not an acceptable solution unless you're happy with giant.flac or.wav files.
"Nothing is stopping people from buying songs on iTunes, burning to CD, and then ripping to DRM free music. You can do this over and over and the price of blank cds are less than the cost of an album these days."
That still costs more than the album, and still leaves you with generation loss. It's a stupid solution.
Given that more than two cores has quickly diminishing returns unless you have rediculously CPU-bound multi-threaded code, I would be surprised if we didn't see some very large caches or even a portion of main memory on die. OSes are getting NUMA support for Opterons, on-die memory would be another case of that.
"He said something to the effect that he replaced multi CPU with singel CPU if he could. He wrote that in in the last year or so."
I couldn't find the quote, but if he's making the statement in general then he's simply wrong (since there's a demonstrable benefit more often than not), and if he's talking about the few cases where there's not a benefit and the overhead is a problem then it's not news because that's been known for a while. But I'd have to see the quote...
"It helps with responsiveness, not performance, in general. There are programs hogging the CPU, so there multi-core helps (I'm working on such a system daily as a developer). More precicely, we have two threads needing much CPU but part of the application needs more that their share (hello Sun Java) of resources."
a) Responsiveness is critical to a desktop system. You notice a few milliseconds of latency before you notice a batch job finishing a few seconds faster.
b) Raw performance does benefit pretty frequently, and when there's a detriment (at least with AMD CPUs) it's pretty small.
"A kernel compiled for a single CPU is faster than a kernel compiled for multipe CPU's, even when you only have one CPU. This is why OpenBSD has two kernels: 1) one cpu and 2) multpiple CPU's. The main developer of DragonBSD said that his preference is single CPU, performance wise (I'll leave that as a Google exercise)."
Dillon said he felt FreeBSD's focus on many CPUs to the exclusion of single-CPU performance was a mistake, not that single CPUs are preferable.
Also, most desktop workloads benefit from having two CPUs, it helps responsiveness quite a bit (even on OSes with good schedulers like Linux). There is overhead for the locking in the kernel, but the benefit almost always outweighs the cost.
"I know as soon as I hear they've started using a microkernel, I'll be taking a real close look at it."
Their plans don't include microkernels. They're using messaging because they think that is easier to maintain and will possibly perform better than the finely grained locking you see in FreeBSD, Linux, and most other OSes designed to use large numbers of processors. The kernel will still be in one address space.
Large companies like Sony don't have the freedom to opperate completely outside a country like that. They'll have a large portion of their assets in a country like the US.
"Also, unless "I've bought Apple computers in the past" refers to a past recent enough that they were running OS X when you bought them, they might as well have been in a different universe."
I currently have an iBook running 10.3.9.
"(sluggish Java? There's Java that isn't sluggish? That must be in an alternate reality as well)"
"The battery lawsuit was a bit nutty -- I have an 1G iPod from 2001 that still runs to this day with the original battery. Yes, it's down to about 2 hours capacity from 8, but claims about it only lasting 18 months were unfounded."
Much like the nano screens, experience varies from user to user. Some were dropping faster than that.
"As for the Nano, I have one, yes in my pocket, yes my screen is a bit scratched, but no more than my other iPods, and it's still very legible."
The number of reports is too large to discount, but plenty of people are saying there's no problem. It seems that some fraction of nanos are affected, but not all of them.
"So let me get this straight. Say I buy a razor. After using it in a benign manner as it was designed, it became dull, impairing a core function (shaving). Does this mean that the saw manufacturer was engaging in illegal business practices and I can sue them? I knew Gillette was crooked for selling me these damned $15/pack razor blades, but KNOWING they were going to get dull after normal usage, well that must be illegal;)"
Blades are dulled by use. Should a screen be dulled by use?
Apple lost a lawsuit where their wrong was much less clear with iPod batteries that fell below their advertised capacity over time.
"And on the other hand, someone like me (or, I would guess, your good self) who is capable of handling the limited choice of application software that results from picking free UNIX (whether Linux- or BSD- based) is also capable of handling the limited hardware availability that results from picking OSX. It's simply a matter of which limitation one is willing to put up with."
That's true, but I've bought Apple computers in the past when their offerings coincided with my needs, and I found that there's nothing uniquely available to the platform that I need. Indeed, there are some limitations that I find difficult to deal with (eg sluggish Java releases).
Slashdot Mirror
"I realize that every individual has their own set of priorities and concerns with their browser, but that's exactly what's great about extensions. Put the necessary stuff in and leave the optional stuff optional. Keep the footprint small and avoid both bloat and insecurity in the process."
This is exactly it. If I can be forgiven for using a cliche, "extensions are the new tabs". They're as much of a killer app as tabs were, IMO.
Not only do extensions make it possible to keep the base install simple and add features only a fraction of people want (eg mouse gestures, sessions) on an as-needed basis, they allow lawsuitbait features (eg BugMeNot integration) and features too narrow in scope to make it into an official release (eg enhancements for specific websites like Fark).
Naturally, some want a browser that works the way they want out of the box, and perhaps Firefox can't do that for everyone. I have no problem with that. I don't even have a problem with people using IE. What I like is that there's a powerful choice that works well for me, and the fact that IE's market share isn't high enough to let websites start requiring it again (it still happens but it was much more common a few years ago).
Also... now that the Mac version doesn't suck I can ditch Safari. It still has a slightly smaller memory footprint, but it's not significantly faster anymore and there are themes that help Firefox look native. With Firefox's feature lead, it's worth a small memory hit even on my older iBook, and with the ruthless efficiency of the AdBlock and Fliterset.G Updater extensions I even end up saving memory.
I said "one of the slowest desktop processors available". Chips that aren't available as desktop chips anymore don't count.
Pentium 4s might be slower at the same clock speed, but given the clock speed advantage they stay ahead pretty easily.
"which is up to 6x powerful per CPU-cycle than a P4 in most tests."
Of course, it's also dramatically slower in other tests and overall. Being able to find a niche where it's faster doesn't say a lot. For example, a C3 with its hardware encryption engine is fast at encryption, but not fast overall.
For the loads that actually get put on desktop chips,the only thing slower than a G4 is a C3, and those are a lot cheaper.
"But how competent do you have to be to make sure the program stops receiving data when the buffer is full?"
It may be difficult to grasp intuitively, but it's extremely easy to do by accident in languages like C++ (by far the most common for games programming). In fact, you will most likely be vulnerable if you don't go out of your way to prevent it.
For example, if the program expects something to be a certain size, it will often only provide enough memory for the expected size an never confirm that it actually is of that size. This happens a lot.
Other security problems can occur when a program takes things for granted, like that a number will be within a given range because a number outside of the range can't occur in normal conditions. For example, there was a security problem where IE didn't make sure one of the values in an image's header wasn't negative, and this allowed a malicious image to execute arbitrary code. It's common for games to make such assumptions.
"Why does the buffer's data structure even allow this?"
Buffers are typically on the stack, and the stack contains information such as return addresses for functions. Putting them elsewhere involves allocating your own memory which is more work, leads to other sorts of bugs, and incurs a performance hit. This is a weakness which other languages address, but they also suffer from disadvantages (mostly performance) that make them unappealing for games.
Preventing these issues is hard because basically you have to spend a lot of time making sure everything is within certain limits, and working out what those limits are. Even small slipups can result in security problems, so you have to be careful.
Games programming isn't my thing I'm afraid. For better or worse, I deal with stuff that has to be secure on a network...
While that would be true in general, G4s have now fallen so far behind that even poor performance relative to other chips is an improvement over a G4. And these things have three of those cores.
A G5 system would probably be competitive as a desktop, but no one's selling those at a low enough price to be directly comparable.
A G4 -- one of the slowest desktop processors available -- versus a three-core chip with an enhanced altivec and much higher clock speeds.
Why do you think?
As long as these things play games online the possibility exists of a buffer overflow there as well.
I know games programmers, and while many are competent, they rarely care/have time to audit their code for security bugs.
"Why would I spend $30 to get an album on a USB stick when I can get an album on CD for $16 or on Itunes for less than that?"
iTunes is DRMed. Also, according to TFA it has 29 songs plus extras (videos etc).
I remain skeptical, but your argument is much more compelling than MisterEntropy's. In particular, he advocates a strategy for which no software currently exists.
"As I said, no one has written the software yet, but it's not particularly difficult."
I see. Software that would be extremely useful and would be easy to write, but no one has gotten around to it yet.
"1. Start with an MP3
2. Decompress and burn
3. Rip and undecompress to reproduce the original MP3
As you can see, there is no lossy compression step in this sequence -- no information is discarded."
There exists no way to "undecompress" an MP3 or other lossy file in the way you describe. If you disagree you are invited to link to software that actually exists that can do it, or even a paper decribing how to do it.
"Sure you can. What makes you think otherwise?"
.zip file.
Because the original file can't be reconstructed. Lossy compression is a process that discards information.
"undecompressing and compressing are different problems"
The only decompression that happens is when a bitstream is created that mimics the original. This is what happens when you play it, and the same codec is used when you burn a CD. The CD is not the same as the original uncompressed copy, and the original compressed copy cannot be reconstructed from it. It's not like a
If you could reconstruct the original file from a copy that's been through lossy compression, it wouldn't be called "lossy" and there would be no need for lossless codecs.
"Ripping a track and compressing it to AAC or MP3 is lossy, but _decompressing_ it to burn onto CD is not. Decompression is essentially lossless and can be perfectly inverted."
.wav or a .flac or whatever with the same quality as the original 128 kbps, but you can't get another file compressed with a lossy codec without generation loss. The quality of iTMS and most other (legal) online music stores is already marginal, so it's not an acceptable solution unless you're happy with giant .flac or .wav files.
The resulting CD will have the same quality as the original 128 kbps AAC (or whatever it is), and you can rip the CD to get a
Easier to download 256 kbps MP3s online.
"AAC is not "closed" by any definition."
It's not well supported by non-Apple players.
MP3 is pretty much the only format that you can expect any player or computer to play.
"Nothing is stopping people from buying songs on iTunes, burning to CD, and then ripping to DRM free music. You can do this over and over and the price of blank cds are less than the cost of an album these days."
That still costs more than the album, and still leaves you with generation loss. It's a stupid solution.
Given that more than two cores has quickly diminishing returns unless you have rediculously CPU-bound multi-threaded code, I would be surprised if we didn't see some very large caches or even a portion of main memory on die. OSes are getting NUMA support for Opterons, on-die memory would be another case of that.
"He said something to the effect that he replaced multi CPU with singel CPU if he could. He wrote that in in the last year or so."
I couldn't find the quote, but if he's making the statement in general then he's simply wrong (since there's a demonstrable benefit more often than not), and if he's talking about the few cases where there's not a benefit and the overhead is a problem then it's not news because that's been known for a while. But I'd have to see the quote...
"It helps with responsiveness, not performance, in general. There are programs hogging the CPU, so there multi-core helps (I'm working on such a system daily as a developer). More precicely, we have two threads needing much CPU but part of the application needs more that their share (hello Sun Java) of resources."
a) Responsiveness is critical to a desktop system. You notice a few milliseconds of latency before you notice a batch job finishing a few seconds faster.
b) Raw performance does benefit pretty frequently, and when there's a detriment (at least with AMD CPUs) it's pretty small.
"A kernel compiled for a single CPU is faster than a kernel compiled for multipe CPU's, even when you only have one CPU. This is why OpenBSD has two kernels: 1) one cpu and 2) multpiple CPU's. The main developer of DragonBSD said that his preference is single CPU, performance wise (I'll leave that as a Google exercise)."
Dillon said he felt FreeBSD's focus on many CPUs to the exclusion of single-CPU performance was a mistake, not that single CPUs are preferable.
Also, most desktop workloads benefit from having two CPUs, it helps responsiveness quite a bit (even on OSes with good schedulers like Linux). There is overhead for the locking in the kernel, but the benefit almost always outweighs the cost.
"... and I am still back in good ol' 4.4 I think. I guess if it aint broke, dont upgrade till it does!"
Doesn't that have a bunch of security bugs? 4.11 is pretty nice.
"I know as soon as I hear they've started using a microkernel, I'll be taking a real close look at it."
Their plans don't include microkernels. They're using messaging because they think that is easier to maintain and will possibly perform better than the finely grained locking you see in FreeBSD, Linux, and most other OSes designed to use large numbers of processors. The kernel will still be in one address space.
Large companies like Sony don't have the freedom to opperate completely outside a country like that. They'll have a large portion of their assets in a country like the US.
"Also, unless "I've bought Apple computers in the past" refers to a past recent enough that they were running OS X when you bought them, they might as well have been in a different universe."
I currently have an iBook running 10.3.9.
"(sluggish Java? There's Java that isn't sluggish? That must be in an alternate reality as well)"
hehehe, touche
I mean releases that are 6-12 months after Sun's.
"The battery lawsuit was a bit nutty -- I have an 1G iPod from 2001 that still runs to this day with the original battery. Yes, it's down to about 2 hours capacity from 8, but claims about it only lasting 18 months were unfounded."
Much like the nano screens, experience varies from user to user. Some were dropping faster than that.
"As for the Nano, I have one, yes in my pocket, yes my screen is a bit scratched, but no more than my other iPods, and it's still very legible."
The number of reports is too large to discount, but plenty of people are saying there's no problem. It seems that some fraction of nanos are affected, but not all of them.
"So let me get this straight. Say I buy a razor. After using it in a benign manner as it was designed, it became dull, impairing a core function (shaving). Does this mean that the saw manufacturer was engaging in illegal business practices and I can sue them? I knew Gillette was crooked for selling me these damned $15/pack razor blades, but KNOWING they were going to get dull after normal usage, well that must be illegal ;)"
Blades are dulled by use. Should a screen be dulled by use?
Apple lost a lawsuit where their wrong was much less clear with iPod batteries that fell below their advertised capacity over time.
"And on the other hand, someone like me (or, I would guess, your good self) who is capable of handling the limited choice of application software that results from picking free UNIX (whether Linux- or BSD- based) is also capable of handling the limited hardware availability that results from picking OSX. It's simply a matter of which limitation one is willing to put up with."
That's true, but I've bought Apple computers in the past when their offerings coincided with my needs, and I found that there's nothing uniquely available to the platform that I need. Indeed, there are some limitations that I find difficult to deal with (eg sluggish Java releases).