Well Apple has seemed to change direction in allowing Opera
Perhaps you should educate yourself on what Opera Mini is and is not before commenting. It is not a web browser. The web browsers that enable Opera Mini are running on Opera servers, not on the iPhone, and have heavily reduced functionality (no javascript, svg, etc..) because of it.
Opera Mini is to a Web Browser in the same way that a Picture of a Ferrari is to an Actual Car.
Because those things aren't the web, those are browsers which are tools used to access the web. Get the difference?
Safari is not standards compliant. Other browsers comply with some of the standards that safari does not comply with.
Yeah.. I get the difference.. you love Apple and dont give a fuck that they arent offering their own standards compliant browser while simultaneously they are preventing anyone else from making such an offering.
Hmm, I didn't know until last week that iPhone developers could only use C, ObjectiveC, or JavaScript.
In fact, all those developers that werent using those, also only found out last week.
You can take your "like you didn't know" argument, and shove it right up your ass. Its willfully ignorant of the fucking fact that Apple has changed the deal more than a few times already.
If I take a can of coke out of a shop and later come back in to pay for it, it doesn't undo the fact that my original walk-out was theft.
This is not a valid analogy. He did not shoplift the iPhone. He found it in a bar.
Let's start with the point that a device was found that belonged to a person. There was originally nothing to suggest it wasn't his own phone, so returning it to Apple raises question number 1: why? Why wasn't it left under care of the bar staff, as that would be logically the place where the guy who lost it would go looking?
Asking the question "why?" isn't a valid argument. Maybe the guy behind the bar is a well known scumbag.
Why not turn it over to people that will CONTACT APPLE, AND THEN TURN IT OVER TO APPLE?
Oh fuck.. thats what he did.
Question 2: why Gizmodo? It has emerged that a number of parties were contacted, offering access to the device. Back to basics: the person selling access or generating money in any way, shape or form off the device had no right to do so as it was not their device
You have just agreed that he did not sell the device, but only charged for access to it. If he did not sell the device, he could not have "sold stolen goods."
Someone made $5000 which he would not have made without having the device in his possession
Making money is not a crime.
Note that it's not Apple's problem at this point, this is state law.
Please..
State law does not contend that a person must give the property to SOMEONE THAT DOES NOT OWN IT (which was your first claim.)
State law does not contend that a person cannot SELL A STORY to a media company.
State law does not contend that a person cannot seek an intermediary in order to return the property (you actually contend that a different intermediary is required.)
Please cite the law preventing a private party who finds lost goods from charging an intermediary for their desire to document the good, contact the owner, and return it themselves.
Dont make up laws. Cite the one you think applies.
The biggest part that is the problem of releasing the data right away is because you don't know if the data is crap without a lot of vetting. Once and a while, it doesn't get caught until a fresh pair of eyes (reviewers) take a look at it and pick up on something maybe your team hasn't thought of.
umm... releasing the data generates "fresh pairs of eyes", pretty much the ultimate in "vetting."
So this is not a reason not to release the data.
The other problem is then you would create a whole industry of research snipers who would poach papers from researchers, thus eliminating the benefits of gathering huge, difficult to collect data sets. There would be no incentive to spend 10 years gathering data, only to have your research sniped as you are writing up your papers.
The benefits of gathering huge "difficult to collect" data sets with PUBLIC MONEY, is that PUBLIC MONEY pays your salary. Period.
Umm, no - Apple had nothing to do with the felony that was committed
What felony? Facts not in evidence. The people possessing the device contacted Apple, and then gave it back to them. Thats not a felony.
Now you are going to argue that the original "unauthorized" person to have it didnt return it to Apple, and thats a felony.. ..but he in fact gave it to people that WOULD contact Apple and WOULD return it to Apple (facts that ARE in evidence, they DID contact Apple and they DID return the device.) So thats not a felony either.
The exchange of money between these two parties is a red herring.
They had not reported anything stolen prior to being informed that the device was in anothers possession, BY THOSE POSESSING IT. When they asked for the device back, THOSE POSSESSING IT GAVE IT TO THEM.
The only thing lost here is the integrity of the local justice system, which sold its ethics to Apple.
ID and LENGTH is not a "container" by any definition that I have ever heard of or used in practice.
What you are describing is a common ordinary linked list.
None of the containers that I am aware of require you to understand the video data in order to play the audio data, so what the heck are you actually getting on about? That "containers" should be ordinary linked lists?
In reality, thats not fit for purpose. That media file contains at least two stream, and while each stream can be treatable as independent, they can also be treatable as semi-dependent. There exists information that is shared between streams. For example, metadata.
If I am not required to decode the video stream, then you can't put the shared metadata in the video stream. If I am not required to decode the audio stream, then you can't put the shared metadata in the audio stream. So what then?
And thus, the media container is born. Linked lists just don't cut it. These formats are more than linked lists for a real (and I gave only one of them) reason.
As far as I'm concerned, a container format should provide enough information to determine two things:
Basically, what you just wrote is "there shouldn't be containers."
Is that really your position? I certainly can understand it. It has that quality to it that any hack can go ahead and start coding to handle it immediately, which is great. But checking with reality, we seem to have so many container formats because ID/LEN is just not enough for purposes.
If you increase the use of solar energy, wouldn't you expect that the Sun's energy that is converted to electricity would lessen the heat generated by sun light entering our atmosphere and heating the objects it strikes?
The laws of thermodynamics would like to have a word with you.
Those solar panels trap energy.
House analogy. If you want to cool your house, do you trap the energy inside of it, or do you systematically pump it out with an air conditioner?
Why do warmers never understand the laws of thermodynamics?
Again, releasing data is fine. I am all for it. I think data should absolutely be released once the lab that generated is finished with it, and that that should be shortly after the initial batch of papers is published.
Oh come on.. rationalize this time frame ("shortly after we publish") for us.
Are you honestly claiming that its not reasonable to have the data ready, prior to publishing? Also, how can the peer review process work if the data isnt available until after publishing?
Apparently there isnt any review of the data after all, right?
I'm calling bullshit. You just want to be able to publish before releasing because you think that you have more rights over the data than the people that paid for it.
It seems the only person making a big deal about this is you. Users can set the DPI if they want to. Deal. If the user wants to "lie" and say that the dpi is 200 when it's really 87 then who cares?
If I am the only one making a big deal of it, then why was I modded +5 insightful for pointing out the problem.
Its because programmers care. I've got an OS thats fucking with my rendering, unless I flag as "DPI AWARE", all the while its impossible for the program to actually be aware of the DPI of the display device.
Okay, now you are making little to no sense whatsoever. The DPI handling in windows works the way it should work.
So it reports the displays DPI? Didn't think so. It *should* report the DPI because its called DPI. It is not called ScalingFactor
What you are describing is how a ScalingFactor should work, and I already pointed out before you said ANYTHING on this subject THAT THERE SHOULD BE ONE.
Thus, my program could be DPI aware, as well as account for the users desire to scale things. As it is now, some poeple use DPI to report the actual DPI, while others use DPI to define a scaling factor. YOU think that this is how it SHOULD be? REALLY? Moron.
Do you really think that you are getting a discount?
You just gave a for-profit corporation the ability to control how much of their product you buy. If it is in their financial interests to lower your draw, they will. But the converse is also true, that they will increase your draw if that is in their financial interests.
OS caching is a little different, but by its nature sequential data will typically be evicted quicker
So what you are thinking is that the OS cache intentionally purges high frequency data in favor of low frequency data, for a reason that arbitrary hurts performance.
Got it. You have no idea what you are talking about.
"Even though I am fielding requests for that big block of data all the god damned time.. like every five seconds and shit... I'm going to go ahead and dump most of it as soon as the system asks for that random burst of rarely used data that is only read once per session at most"
Leave the cache algorithm discussions for the programmers, OK? Running a SAN does not make you informed about cache algorithms, and SAN's arent even fucking typical.
This is a lie. It's called resolution independence and numerous widget sets will do it if you use them correctly. As you might note, NeXTStep, the OS upon which OSX is based, is resolution-independent.
,br>
umm... hello? NeXTStep used vector-based icons, yet still failed at scaling raster-based stuff.
Almost 100% of the digital images in the world are raster-based. Period. End of story. Game over.
Yes, again this is how it should be. There's a couple scenarios here. First, what are you expected to do if your monitor incorrectly reports it's dpi, or fails to report it at all?
Look in the small database of physical display dimensions indexed by PnP ID, allow user to input their own values if they want to, and off you go.
Seriously. You are making a big problem of this, when it isnt a big problem at all. Windows XP had no clue what my LCD monitor was, but Windows 7 knows exactly what it is, because its in its small database of PnP ID's, which even includes its native resolution.
Secondly, if you *are* using it as a "global scaling factor" people with bad eyesight (or people that simply want larger-yet-crisp imagery) can be accommodated while still displaying at the native resolution.
umm... hello? DPI and scaling are not the same thing. DPI stands for DOTS PER INCH.
So here the user is, with his "DPI" set to some random value X because some random developers application Y (which he frequently uses) looks good at that resolution..
..but that developer is actually an idiot that likes over-sized buttons and text, but only in his own applications..
..so this users DPI setting is influenced by a developer that isnt actually playing a rational game..
So what does "DPI AWARE" mean in the windows world right now? It means the programmer demands that the OS render verbatim exactly what he wants.. pixel perfect.. and in most cases, it is used because the program is actually intentionally oblivious of the DPI setting.. because if they use that damn value, then they are letting some other random developer effect the users experience with their program.
The CERT Advistory history shows us that when the majority of systems on the internet were *nix, there were lots of exploits for *nix systems...
...and that over time, as more and more home users started populating the net with Windows system, the exploits for Windows grew in number...
...and towards the end of the history, when Windows systems vastly outnumbered everything else on the internet, the great majority of exploits were for Windows systems.
Well, it doesn't cache files because that would be silly. It caches blocks. The _result_ is the same as what the OP is after, which is that frequently accessed _data_ is cached on the higher-speed device.
NO! You dont seem to get it.
Only the first few sectors of frequently accessed sequential data benefit from being cached here.
But that's not really important, because if throughput is a limiting factor then you're looking at long, sequential reads or writes - which typically aren't cached by most caching algorithms anyway.
Oh yes they are. Don't make things up.
The typical cache algorithm doesnt know anything about the sequentialness of the operations, the latency of the device, the throughput of the device, nor the overall size of the read request. Its level of operation is below that, and for good reason. The cache memory is superior in every way to what its caching. That is, specifically, that cache memory has better latency AND better throughput. In that typical cache algorithm that you are misinformed about, the two things it considers in its caching policy are frequency and age. Everything else is meaninglessly static in favor of cache memory.
It is pretty much only with readyboost that the back end is not uniformly worse, that the flash drive is better than the HD in some ways but not others. It considers size, sequentialness, frequency, latency, throughput, and age.
Yes, that's because that's where the biggest benefits are derived - small accesses where seek time dominates.
It does it even on large sequential accesses, but only for up-to the first 512KB (yes, since I posted last I read the damn specifics. The white paper is available.)
The 512KB limit was derived from the amount of data that can be ready from the top performing thumb drives (around 20MB/sec) within the seek time of the slowest HD's (around 24ms)
The trick to making this happen is NOT to have the OS do it, because quite frankly, it can't. As you have noted, icons and so forth cannot be scaled satisfactorily in a generic manner.
The key is to give programmers the information they need to do it themselves and then get the fuck out of the way and let them do it. Over time, the RAD GUI builders would all do it automatically for the programmer.
In the current state of affairs, the OS is doing some DPI-scaling things but not others, which actually constrains the programmer and makes it a complicated mess. If all my rendering needs to be "DPI Aware" then its actually not so difficult. But instead of that, I not only have to be DPI-aware, I also need to be OS-intervention-aware... and that of course is different across OS versions (most notably the break between XP and VISTA)
Slashdot Mirror
Well Apple has seemed to change direction in allowing Opera
Perhaps you should educate yourself on what Opera Mini is and is not before commenting. It is not a web browser. The web browsers that enable Opera Mini are running on Opera servers, not on the iPhone, and have heavily reduced functionality (no javascript, svg, etc..) because of it.
Opera Mini is to a Web Browser in the same way that a Picture of a Ferrari is to an Actual Car.
Because those things aren't the web, those are browsers which are tools used to access the web. Get the difference?
Safari is not standards compliant. Other browsers comply with some of the standards that safari does not comply with.
Yeah.. I get the difference.. you love Apple and dont give a fuck that they arent offering their own standards compliant browser while simultaneously they are preventing anyone else from making such an offering.
Hmm, I didn't know until last week that iPhone developers could only use C, ObjectiveC, or JavaScript.
In fact, all those developers that werent using those, also only found out last week.
You can take your "like you didn't know" argument, and shove it right up your ass. Its willfully ignorant of the fucking fact that Apple has changed the deal more than a few times already.
If I take a can of coke out of a shop and later come back in to pay for it, it doesn't undo the fact that my original walk-out was theft.
This is not a valid analogy. He did not shoplift the iPhone. He found it in a bar.
Let's start with the point that a device was found that belonged to a person. There was originally nothing to suggest it wasn't his own phone, so returning it to Apple raises question number 1: why? Why wasn't it left under care of the bar staff, as that would be logically the place where the guy who lost it would go looking?
Asking the question "why?" isn't a valid argument. Maybe the guy behind the bar is a well known scumbag.
Why not turn it over to people that will CONTACT APPLE, AND THEN TURN IT OVER TO APPLE?
Oh fuck.. thats what he did.
Question 2: why Gizmodo? It has emerged that a number of parties were contacted, offering access to the device. Back to basics: the person selling access or generating money in any way, shape or form off the device had no right to do so as it was not their device
You have just agreed that he did not sell the device, but only charged for access to it. If he did not sell the device, he could not have "sold stolen goods."
Someone made $5000 which he would not have made without having the device in his possession
Making money is not a crime.
Note that it's not Apple's problem at this point, this is state law.
Please..
State law does not contend that a person must give the property to SOMEONE THAT DOES NOT OWN IT (which was your first claim.)
State law does not contend that a person cannot SELL A STORY to a media company.
State law does not contend that a person cannot seek an intermediary in order to return the property (you actually contend that a different intermediary is required.)
Please cite the law preventing a private party who finds lost goods from charging an intermediary for their desire to document the good, contact the owner, and return it themselves.
Dont make up laws. Cite the one you think applies.
The biggest part that is the problem of releasing the data right away is because you don't know if the data is crap without a lot of vetting. Once and a while, it doesn't get caught until a fresh pair of eyes (reviewers) take a look at it and pick up on something maybe your team hasn't thought of.
umm... releasing the data generates "fresh pairs of eyes", pretty much the ultimate in "vetting."
So this is not a reason not to release the data.
The other problem is then you would create a whole industry of research snipers who would poach papers from researchers, thus eliminating the benefits of gathering huge, difficult to collect data sets. There would be no incentive to spend 10 years gathering data, only to have your research sniped as you are writing up your papers.
The benefits of gathering huge "difficult to collect" data sets with PUBLIC MONEY, is that PUBLIC MONEY pays your salary. Period.
Umm, no - Apple had nothing to do with the felony that was committed
What felony? Facts not in evidence. The people possessing the device contacted Apple, and then gave it back to them. Thats not a felony.
..but he in fact gave it to people that WOULD contact Apple and WOULD return it to Apple (facts that ARE in evidence, they DID contact Apple and they DID return the device.) So thats not a felony either.
Now you are going to argue that the original "unauthorized" person to have it didnt return it to Apple, and thats a felony..
The exchange of money between these two parties is a red herring.
I have to call bullshit.
They had not reported anything stolen prior to being informed that the device was in anothers possession, BY THOSE POSESSING IT. When they asked for the device back, THOSE POSSESSING IT GAVE IT TO THEM.
The only thing lost here is the integrity of the local justice system, which sold its ethics to Apple.
ID and LENGTH is not a "container" by any definition that I have ever heard of or used in practice.
What you are describing is a common ordinary linked list.
None of the containers that I am aware of require you to understand the video data in order to play the audio data, so what the heck are you actually getting on about? That "containers" should be ordinary linked lists?
In reality, thats not fit for purpose. That media file contains at least two stream, and while each stream can be treatable as independent, they can also be treatable as semi-dependent. There exists information that is shared between streams. For example, metadata.
If I am not required to decode the video stream, then you can't put the shared metadata in the video stream. If I am not required to decode the audio stream, then you can't put the shared metadata in the audio stream. So what then?
And thus, the media container is born. Linked lists just don't cut it. These formats are more than linked lists for a real (and I gave only one of them) reason.
As far as I'm concerned, a container format should provide enough information to determine two things:
Basically, what you just wrote is "there shouldn't be containers."
Is that really your position? I certainly can understand it. It has that quality to it that any hack can go ahead and start coding to handle it immediately, which is great. But checking with reality, we seem to have so many container formats because ID/LEN is just not enough for purposes.
If you increase the use of solar energy, wouldn't you expect that the Sun's energy that is converted to electricity would lessen the heat generated by sun light entering our atmosphere and heating the objects it strikes?
The laws of thermodynamics would like to have a word with you.
Those solar panels trap energy.
House analogy. If you want to cool your house, do you trap the energy inside of it, or do you systematically pump it out with an air conditioner?
Why do warmers never understand the laws of thermodynamics?
Again, releasing data is fine. I am all for it. I think data should absolutely be released once the lab that generated is finished with it, and that that should be shortly after the initial batch of papers is published.
Oh come on.. rationalize this time frame ("shortly after we publish") for us.
Are you honestly claiming that its not reasonable to have the data ready, prior to publishing? Also, how can the peer review process work if the data isnt available until after publishing?
Apparently there isnt any review of the data after all, right?
I'm calling bullshit. You just want to be able to publish before releasing because you think that you have more rights over the data than the people that paid for it.
Web browsers do not scale images based on OS "DPI" settings. Stop making things up.
False dichotomy.
Solar is not a cost efficient method of producing energy, so poor is the method that it isnt even competitive against price gougers.
Perhaps you need to learn a bit or two about what people have been doing to get Java programs onto devices without the JVM
What the *heck* are you talking about? If my app is dpi-aware how is "some other random developer" going to effect my UI at all??
His program is critical to the user, but renders shit very very small. Whats the end result, dipshit?
It seems the only person making a big deal about this is you. Users can set the DPI if they want to. Deal. If the user wants to "lie" and say that the dpi is 200 when it's really 87 then who cares?
If I am the only one making a big deal of it, then why was I modded +5 insightful for pointing out the problem.
Its because programmers care. I've got an OS thats fucking with my rendering, unless I flag as "DPI AWARE", all the while its impossible for the program to actually be aware of the DPI of the display device.
Okay, now you are making little to no sense whatsoever. The DPI handling in windows works the way it should work.
So it reports the displays DPI? Didn't think so. It *should* report the DPI because its called DPI. It is not called ScalingFactor
What you are describing is how a ScalingFactor should work, and I already pointed out before you said ANYTHING on this subject THAT THERE SHOULD BE ONE.
Thus, my program could be DPI aware, as well as account for the users desire to scale things. As it is now, some poeple use DPI to report the actual DPI, while others use DPI to define a scaling factor. YOU think that this is how it SHOULD be? REALLY? Moron.
We are talking about programs, not idealized GUI's.
Program do things like display IMAGES, such as the browser you are running right now.
So you are going to spend a lot of money on a system that probably will never pay for itself, with borrowed money you also have to pay interest on?
Do you really think that you are getting a discount?
You just gave a for-profit corporation the ability to control how much of their product you buy. If it is in their financial interests to lower your draw, they will. But the converse is also true, that they will increase your draw if that is in their financial interests.
OS caching is a little different, but by its nature sequential data will typically be evicted quicker
So what you are thinking is that the OS cache intentionally purges high frequency data in favor of low frequency data, for a reason that arbitrary hurts performance.
Got it. You have no idea what you are talking about.
"Even though I am fielding requests for that big block of data all the god damned time.. like every five seconds and shit... I'm going to go ahead and dump most of it as soon as the system asks for that random burst of rarely used data that is only read once per session at most"
Leave the cache algorithm discussions for the programmers, OK? Running a SAN does not make you informed about cache algorithms, and SAN's arent even fucking typical.
This is a lie. It's called resolution independence and numerous widget sets will do it if you use them correctly. As you might note, NeXTStep, the OS upon which OSX is based, is resolution-independent.
,br> umm... hello? NeXTStep used vector-based icons, yet still failed at scaling raster-based stuff.
Almost 100% of the digital images in the world are raster-based. Period. End of story. Game over.
Yes, again this is how it should be. There's a couple scenarios here. First, what are you expected to do if your monitor incorrectly reports it's dpi, or fails to report it at all?
Look in the small database of physical display dimensions indexed by PnP ID, allow user to input their own values if they want to, and off you go.
Seriously. You are making a big problem of this, when it isnt a big problem at all. Windows XP had no clue what my LCD monitor was, but Windows 7 knows exactly what it is, because its in its small database of PnP ID's, which even includes its native resolution.
Secondly, if you *are* using it as a "global scaling factor" people with bad eyesight (or people that simply want larger-yet-crisp imagery) can be accommodated while still displaying at the native resolution.
umm... hello? DPI and scaling are not the same thing. DPI stands for DOTS PER INCH.
..but that developer is actually an idiot that likes over-sized buttons and text, but only in his own applications..
..so this users DPI setting is influenced by a developer that isnt actually playing a rational game..
So here the user is, with his "DPI" set to some random value X because some random developers application Y (which he frequently uses) looks good at that resolution..
So what does "DPI AWARE" mean in the windows world right now? It means the programmer demands that the OS render verbatim exactly what he wants.. pixel perfect.. and in most cases, it is used because the program is actually intentionally oblivious of the DPI setting.. because if they use that damn value, then they are letting some other random developer effect the users experience with their program.
The CERT Advistory history shows us that when the majority of systems on the internet were *nix, there were lots of exploits for *nix systems...
...and that over time, as more and more home users started populating the net with Windows system, the exploits for Windows grew in number...
...and towards the end of the history, when Windows systems vastly outnumbered everything else on the internet, the great majority of exploits were for Windows systems.
Well, it doesn't cache files because that would be silly. It caches blocks. The _result_ is the same as what the OP is after, which is that frequently accessed _data_ is cached on the higher-speed device.
NO! You dont seem to get it.
Only the first few sectors of frequently accessed sequential data benefit from being cached here.
But that's not really important, because if throughput is a limiting factor then you're looking at long, sequential reads or writes - which typically aren't cached by most caching algorithms anyway.
Oh yes they are. Don't make things up.
The typical cache algorithm doesnt know anything about the sequentialness of the operations, the latency of the device, the throughput of the device, nor the overall size of the read request. Its level of operation is below that, and for good reason. The cache memory is superior in every way to what its caching. That is, specifically, that cache memory has better latency AND better throughput. In that typical cache algorithm that you are misinformed about, the two things it considers in its caching policy are frequency and age. Everything else is meaninglessly static in favor of cache memory.
It is pretty much only with readyboost that the back end is not uniformly worse, that the flash drive is better than the HD in some ways but not others. It considers size, sequentialness, frequency, latency, throughput, and age.
Yes, that's because that's where the biggest benefits are derived - small accesses where seek time dominates.
It does it even on large sequential accesses, but only for up-to the first 512KB (yes, since I posted last I read the damn specifics. The white paper is available.)
The 512KB limit was derived from the amount of data that can be ready from the top performing thumb drives (around 20MB/sec) within the seek time of the slowest HD's (around 24ms)
The trick to making this happen is NOT to have the OS do it, because quite frankly, it can't. As you have noted, icons and so forth cannot be scaled satisfactorily in a generic manner.
The key is to give programmers the information they need to do it themselves and then get the fuck out of the way and let them do it. Over time, the RAD GUI builders would all do it automatically for the programmer.
In the current state of affairs, the OS is doing some DPI-scaling things but not others, which actually constrains the programmer and makes it a complicated mess. If all my rendering needs to be "DPI Aware" then its actually not so difficult. But instead of that, I not only have to be DPI-aware, I also need to be OS-intervention-aware... and that of course is different across OS versions (most notably the break between XP and VISTA)