Oh? this (and this follow up post) seem to indicate that it's not so clearcut. Looks like x264 beat MainConcept in most tests, and the major tests it lost in were rather unrealistic.
But in the interest of full disclosure, Dark Shikari is one of the main developers on x264, so he's got an obvious bias. Doesn't necessarily make him wrong though.
Maybe the ones they release here are crap (I don't know, never used one), but I've got no complaints with the Kyocera A5521K I had in Japan a couple years back.
The inclusion of a real web browser isn't really that important in the Japanese market. In Japan, probably more people browse the web on their cellphone than on a computer. This means that my and large, Japanese websites are made with the limited browsers in mind in the first place, though many sites will check the user agent of similar to allow separate versions for computers and cellphones. Because there was demand for it, the mobile web already worked rather well in Japan, and throwing Safari onto a cellphone there doesn't really change things much.
Obviously, you can only cut the price so far because you need to make some profit per unit
That doesn't really apply to most videogames. The actual cost per unit is the cost of the disk and packaging, so almost nothing. All the development, production, testing, etc are fixed costs no matter how many units you sell, so theit "cost per unit" is really a very fuzzy concept, depending on many different factors. Valve's little experiment here is a perfect example of how lowering the price can even lower the cost per unit.
There are plenty of games out there that I don't feel are worth the price they're asking. Maybe some are, but many aren't. Valve's experiment is still perfectly applicable to many games.
This has been debunked on reddit and probably other places.
1) Bush's robots.txt began very similarly to Obama's, it grew later. Obama's robots.txt file starting small proves nothing. Look again in a year and see what it looks like then. 2) The pages disallowed by Bush's robots.txt file were (almost?) all printer-friendly versions of pages which were not excluded. The information was still there and accessible to spiders.
I'm no Bush fan, but let's limit the bashing to things that are actually true and meaningful, shall we?
Use Flash Lite. It runs on ARM. It's also currently a couple major versions behind the normal Flash plugin, but I believe Adobe's said they're making it a priority to bring it up to date with the rise of netbooks and such.
I guess we've just had different experiences then. I use QuickMark for QR/Datamatrix codes and the MS tag scanner for MS Tags (obv.) -- on my phone I was getting mixed results with some QR codes (like the ones I pointed out), but much better results with MS tags. The hardware is common in this case.
I used the software that came preloaded on my Kyocera A5521K, which wasn't a particularly high end Japanese cellhpone when I got it in late 2006. It claims to be "MEDIASEEK/KDDI Barcode Reader & Maker 1.2.1"
I could probably be accused of being anti-MS, paranoid about privacy concerns, or a number of other things, but NIH is not really one of them in this case. I'm proposing using the already existing technologies instead of needlessly inventing new alternatives that I don't see as adding anything significant.
Why is it ok to have QRs + Datamatrix + others, but not ok to have the same mix + MS tags then? That's the reason I was talking about reverse NIH -- it's not that I think you're being particularly anti-MS or anything -- its just that one yardstick of redundancy applied to all existing formats, but when MS's format enters the game (and it's the only one that brings anything different to the table, IMHO), it's "needlessly inventing new alternatives"?
I do think it's suboptimal having all these separate formats. I would prefer it if they consolidated on one common, open format, and I have a slight prefrence for QR Code there simply because it's the format with which I have the most experience. If I'd been aware of the proliferation of formats when those other formats were introduced, I'd likely have been arguing them as well, but as it is, it's a little late. Right or not, it's easier to argue against a new format than against one that's already somewhat entrenched.
I'll take your word that MS Tags have been more reliable for you. But with as little trouble as I've had, I don't believe that the QR Code format makes it inherently unreliable.
Maybe. Or maybe it has better decoding software. I don't know. I just know that in my experience, the technology is there and it works pretty well. And by the time something like this ever takes off in the US (it's been talked about for a long time, but hasn't really gone anywhere - if anything, this is the advantage of MS pushing it, they'll get publicity), the average cellphone camera will be even better, and so there should be even fewer problems, almost regardless of the particular barcode standard in use.
From Wikipedia (emphasis added):
Not Invented Here (NIH) is a term used to describe persistent sociological, corporate or institutional culture that avoids using or buying already existing products, research or knowledge because of its different origins.
I could probably be accused of being anti-MS, paranoid about privacy concerns, or a number of other things, but NIH is not really one of them in this case. I'm proposing using the already existing technologies instead of needlessly inventing new alternatives that I don't see as adding anything significant.
Those both worked flawlessly on my Japanese cellphone from a few years ago.
Being artificially limited to one vendor is more or less the definition of vendor lock-in.
Right -- but you're not limited to one vendor. There's no reason we can't have QR codes, Datamatrix codes, MS Tags, and more co-existing peacefully. There's no reason scanning apps can't recognize multiple tag formats and know what to do with them. Most already recognize all key formats, and will probably add MS tags if they catch on. MS's own apps only recognize MS tags right now, but they've stated that they're adding formats..
There's also no real good reason for the creation of new formats when existing formats do work well beyond NIH syndrom.
For the hundreds of examples of easy to scan QR codes you can give me, I can give you hundreds of examples of QR codes that won't scan.
Got a link to one? I don't recall having any problems with a real-world QR Code. Contrived examples like the one on the wikipedia page on QR Codes are problematic, but I don't think I've ever seen someone really try cramming so much data in practice that it wouldn't scan.
And again, URLs encoded in QR Codes still handle the case where there is a large amount of data.
There's no lock-in just because tag data gets resolved through MS's service.
You can't use the tag format without it going through Microsoft, and getting them to agree to store whatever data goes with your tag. Being artificially limited to one vendor is more or less the definition of vendor lock-in.
On the other hand, if I go to Delta's website to see my flight information, only Delta really knows I did so
Actually your gateway and every hop along the way knows you were on Delta's site. If your traffic wasn't SSL-encrypted, they have the ability to even reconstruct the pages as you saw them. Somebody on your LAN with a packet sniffer could also do that. Your ISP essentially knows just about everything you do.
So? That's because there's a practical need in order to get the traffic where it's going. That doesn't mean Microsoft has any reason to know where you go as well.
I can't think of a reason that a protocol couldn't be developed that scanning apps would implement
I can't either. But who will operate the service for free? Even a consortium would have to make money in some way to keep the service up. Or if the government runs it, then the tax payers pay for it. In the current model, the guys that showed initiative (by creating the service and the apps) reap the reward (profit), the businesses/individuals who can gain from the service will pay for it directly, and eventually consumers will pay for it (indirectly) in the cost of goods (same as any other form of advertising). The enterpreneur made money, business got done, consumers got a service. That's as it should be. If consumers don't use the service, businesses won't see the value, and MS won't get paid. That's also as it should be.
I fail to see what this model offers over QR Codes as used in Japan. QR Codes can contain a fair amount of data encoded in the barcode itself - enough for small images, or plenty of text. Those barcodes cost nothing to maintain once they're out there. If needed, the barcode can contain a URL, where more data can be provided. Most organization which would want to distribute these barcodes in the first place have their own webspace available, where they could easily host the content without having to pay extra to a third party. For those without, there's no technical reason a third party which did nothing but store data for these URL barcodes couldn't exist. Or multiple third parties, and let the free market determine pricing, rather than grant Microsoft the monopoly on it because they decided to reinvent what's already been done perfectly well in other parts of the world.
Essentially; what is Microsoft's role in this? Is it a critical role (you *need* the centralized server for some reason), or are they creating a false market segment?
They appear to have solved a problem that nobody seems to have solved adequately so far. All existing solutions either fail to associate rich content with the tag, or score poorly on the pattern recognition front, and fail miserably in adverse conditions. This solution still has the drawback of requiring net access -- but if you have that, it's the best solution by far. So Microsoft's role has been to do the research into creating the tag format, developing and testing the scanning apps, getting OEMs and partners to adopt the technology, providing the service. They have not done this out of the goodness of their heart -- they're in the technology business, and they see this as a business opportunity. It's not a false market or a real market or anything in between. MS wants your business, and they're working to earn it -- same as any other business.
As above, this adds nothing over what could already be done with existing technology. Having lived in Japan for a year, I can tell you that reading QR Codes on a cellphone is even simpler than point-and-click. You just point, and before you would have even pressed the button to tell it to read, it's already recognized the barcode and read the data. Works perfectly in all sorts of lighting conditions.
I mentioned a couple of uses such as printing a tag on your business card that work contacts
You can fit a surprising amount in a QR Code. But even suppose you wanted to put something in there that wouldn't fit - you still have the option of doing the same as MS is doing. Just encode a URL that then directs the user to the actual data. IMHO, it's much better to have the option to encode the data directly when feasible, and use the URL as a fallback for when it's not, than to force everyone through MS's servers.
What happens if MS starts charging for the service (either barcode reading or barcode generation - since generation apparently requires use of MS's database and servers), or starts dropping old data (or discontinues the service altogether)? Or if their servers go down? And then you have the people worried about the privacy implications. None of these are problems if the data is encoded in the barcode itself.
But you're missing the point. The point is that if Google takes someone else's ideas and makes a fortune on them then that is just wrong.
How?
If Google steals an idea and makes a fortune on it, then sure, it's wrong. But if they use an idea that was freely given to them through this service, where the stated goal is to possibly be used in Google's products.... what's the problem? The submitter knew what Google was going to do with the idea, and submitted it anyway.
If you're concerned about your IMs being displayed as a notification, there's a reason there's an option to turn those off. They default to off in Pidgin, last I checked too.
I disagree about not being able to interact with notifications. It's one feature I use all the time with Pidgin. It pops up a notification when a contact signs on, and the notification includes a button to open a conversation with them. Perfect for those times that the notification reminds me that I had wanted to talk to this person for some reason. The button it completely relevant to the message, and avoids a fair amount of work in figuring out where I put the buddy list window and digging through a lot of contacts to find the one that just happened to sign on.
What could be done, and I believe Linux can do, is write the pages out to swap space, but as long as there's no reason not to, keep the copies in RAM as well.
If you need the RAM for disk cache, the RAM copy can be dropped since it already exists on disk. If the program needs to access memory, it's already there and doesn't need swapped back in.
If the claim that windows swapped out everything when the computer was left idle overnight is correct, then it is indeed a suboptimal paging algorithm. An idle computer has no reason to remove things from RAM, as there's nothing it needs the space for.
libavcodec does indeed have its own FLAC decoder, which is not dependent on libFLAC. It may have (optionally) supported using libFLAC at some point in the past, but my subversion checkout from a couple weeks ago doesn't even seem to support that anymore, instead preferring their own FLAC implementation.
The eEye Security advisory doesn't mention libavcodec at all. That seems to have been (incorrectly) added by heise security.
But that argument only works for traffic that has to go over the internet infrastructure itself. If I've got a cable connection, and want to transfer to someone else down the street, or even across the same city who's on the same provider, that traffic never has to leave the cable company. And no matter how limited the cable company's connection to their provider may be, or how limited the infrastructure out there may be because of being spread too thin, the cable company can definitely handle the traffic within their own network.
Plus, I don't buy the argument about the problem being the infrastructure in the US. The connections I got to sites in the US from Japan was faster than I get from my ISP here in the US. If the problem was infrastructure, that'd never happen. No, this is simply a case of the ISPs charging more and offering less service than other countries.
WINE isn't virtualization. It's merely an implementation of the Win32 API. The program itself is still happily running with as much access to the machine as any other process.
Now, I do believe Qemu is capable of something closer to this, where it emulates for one process, and passes the syscalls on to the native kernel.
Sample (If you're using IE, your browser will close! You have been warned!)
It seems IE6 or programs using IE6 components will definitely crash! I haven't checked IE7 though!
It seems to be when you have and input or select or such just below a table or tr or such, and you use the css wildcard * to set everything to position:relative.
By the way, if the input has its style directly set to relative, it doesn't crash. What's up with that? I don't really get it, but it sure is interesting...!
Anyone out there who loves Firefox or Opera should go spread this all over and decrease IE's market share!!!
Slashdot Mirror
Main Concept being the best overall.
Oh? this (and this follow up post) seem to indicate that it's not so clearcut. Looks like x264 beat MainConcept in most tests, and the major tests it lost in were rather unrealistic.
But in the interest of full disclosure, Dark Shikari is one of the main developers on x264, so he's got an obvious bias. Doesn't necessarily make him wrong though.
Maybe the ones they release here are crap (I don't know, never used one), but I've got no complaints with the Kyocera A5521K I had in Japan a couple years back.
The inclusion of a real web browser isn't really that important in the Japanese market. In Japan, probably more people browse the web on their cellphone than on a computer. This means that my and large, Japanese websites are made with the limited browsers in mind in the first place, though many sites will check the user agent of similar to allow separate versions for computers and cellphones. Because there was demand for it, the mobile web already worked rather well in Japan, and throwing Safari onto a cellphone there doesn't really change things much.
Obviously, you can only cut the price so far because you need to make some profit per unit
That doesn't really apply to most videogames. The actual cost per unit is the cost of the disk and packaging, so almost nothing. All the development, production, testing, etc are fixed costs no matter how many units you sell, so theit "cost per unit" is really a very fuzzy concept, depending on many different factors. Valve's little experiment here is a perfect example of how lowering the price can even lower the cost per unit.
There are plenty of games out there that I don't feel are worth the price they're asking. Maybe some are, but many aren't. Valve's experiment is still perfectly applicable to many games.
This has been debunked on reddit and probably other places.
1) Bush's robots.txt began very similarly to Obama's, it grew later. Obama's robots.txt file starting small proves nothing. Look again in a year and see what it looks like then.
2) The pages disallowed by Bush's robots.txt file were (almost?) all printer-friendly versions of pages which were not excluded. The information was still there and accessible to spiders.
I'm no Bush fan, but let's limit the bashing to things that are actually true and meaningful, shall we?
Use Flash Lite. It runs on ARM. It's also currently a couple major versions behind the normal Flash plugin, but I believe Adobe's said they're making it a priority to bring it up to date with the rise of netbooks and such.
I guess we've just had different experiences then. I use QuickMark for QR/Datamatrix codes and the MS tag scanner for MS Tags (obv.) -- on my phone I was getting mixed results with some QR codes (like the ones I pointed out), but much better results with MS tags. The hardware is common in this case.
I used the software that came preloaded on my Kyocera A5521K, which wasn't a particularly high end Japanese cellhpone when I got it in late 2006. It claims to be "MEDIASEEK/KDDI Barcode Reader & Maker 1.2.1"
I could probably be accused of being anti-MS, paranoid about privacy concerns, or a number of other things, but NIH is not really one of them in this case. I'm proposing using the already existing technologies instead of needlessly inventing new alternatives that I don't see as adding anything significant.
Why is it ok to have QRs + Datamatrix + others, but not ok to have the same mix + MS tags then? That's the reason I was talking about reverse NIH -- it's not that I think you're being particularly anti-MS or anything -- its just that one yardstick of redundancy applied to all existing formats, but when MS's format enters the game (and it's the only one that brings anything different to the table, IMHO), it's "needlessly inventing new alternatives"?
I do think it's suboptimal having all these separate formats. I would prefer it if they consolidated on one common, open format, and I have a slight prefrence for QR Code there simply because it's the format with which I have the most experience. If I'd been aware of the proliferation of formats when those other formats were introduced, I'd likely have been arguing them as well, but as it is, it's a little late. Right or not, it's easier to argue against a new format than against one that's already somewhat entrenched.
I'll take your word that MS Tags have been more reliable for you. But with as little trouble as I've had, I don't believe that the QR Code format makes it inherently unreliable.
Perhaps your phone has a better camera.
Maybe. Or maybe it has better decoding software. I don't know. I just know that in my experience, the technology is there and it works pretty well. And by the time something like this ever takes off in the US (it's been talked about for a long time, but hasn't really gone anywhere - if anything, this is the advantage of MS pushing it, they'll get publicity), the average cellphone camera will be even better, and so there should be even fewer problems, almost regardless of the particular barcode standard in use.
From Wikipedia (emphasis added):
Not Invented Here (NIH) is a term used to describe persistent sociological, corporate or institutional culture that avoids using or buying already existing products, research or knowledge because of its different origins.
I could probably be accused of being anti-MS, paranoid about privacy concerns, or a number of other things, but NIH is not really one of them in this case. I'm proposing using the already existing technologies instead of needlessly inventing new alternatives that I don't see as adding anything significant.
Sure, here are a couple of problematic examples:
http://mobile-tagging.blogspot.com/2008/11/code-entdeckt-7-firmendbde.html
http://mobile-tagging.blogspot.com/2008/10/qr-code-webimage-analyse.html
Those both worked flawlessly on my Japanese cellphone from a few years ago.
Being artificially limited to one vendor is more or less the definition of vendor lock-in.
Right -- but you're not limited to one vendor. There's no reason we can't have QR codes, Datamatrix codes, MS Tags, and more co-existing peacefully. There's no reason scanning apps can't recognize multiple tag formats and know what to do with them. Most already recognize all key formats, and will probably add MS tags if they catch on. MS's own apps only recognize MS tags right now, but they've stated that they're adding formats..
There's also no real good reason for the creation of new formats when existing formats do work well beyond NIH syndrom.
For the hundreds of examples of easy to scan QR codes you can give me, I can give you hundreds of examples of QR codes that won't scan.
Got a link to one? I don't recall having any problems with a real-world QR Code. Contrived examples like the one on the wikipedia page on QR Codes are problematic, but I don't think I've ever seen someone really try cramming so much data in practice that it wouldn't scan.
And again, URLs encoded in QR Codes still handle the case where there is a large amount of data.
There's no lock-in just because tag data gets resolved through MS's service.
You can't use the tag format without it going through Microsoft, and getting them to agree to store whatever data goes with your tag. Being artificially limited to one vendor is more or less the definition of vendor lock-in.
People have been storing URL in QR Codes for years. How is this any improvement?
On the other hand, if I go to Delta's website to see my flight information, only Delta really knows I did so
Actually your gateway and every hop along the way knows you were on Delta's site. If your traffic wasn't SSL-encrypted, they have the ability to even reconstruct the pages as you saw them. Somebody on your LAN with a packet sniffer could also do that. Your ISP essentially knows just about everything you do.
So? That's because there's a practical need in order to get the traffic where it's going. That doesn't mean Microsoft has any reason to know where you go as well.
I can't think of a reason that a protocol couldn't be developed that scanning apps would implement
I can't either. But who will operate the service for free? Even a consortium would have to make money in some way to keep the service up. Or if the government runs it, then the tax payers pay for it. In the current model, the guys that showed initiative (by creating the service and the apps) reap the reward (profit), the businesses/individuals who can gain from the service will pay for it directly, and eventually consumers will pay for it (indirectly) in the cost of goods (same as any other form of advertising). The enterpreneur made money, business got done, consumers got a service. That's as it should be. If consumers don't use the service, businesses won't see the value, and MS won't get paid. That's also as it should be.
I fail to see what this model offers over QR Codes as used in Japan. QR Codes can contain a fair amount of data encoded in the barcode itself - enough for small images, or plenty of text. Those barcodes cost nothing to maintain once they're out there. If needed, the barcode can contain a URL, where more data can be provided. Most organization which would want to distribute these barcodes in the first place have their own webspace available, where they could easily host the content without having to pay extra to a third party. For those without, there's no technical reason a third party which did nothing but store data for these URL barcodes couldn't exist. Or multiple third parties, and let the free market determine pricing, rather than grant Microsoft the monopoly on it because they decided to reinvent what's already been done perfectly well in other parts of the world.
Essentially; what is Microsoft's role in this? Is it a critical role (you *need* the centralized server for some reason), or are they creating a false market segment?
They appear to have solved a problem that nobody seems to have solved adequately so far. All existing solutions either fail to associate rich content with the tag, or score poorly on the pattern recognition front, and fail miserably in adverse conditions. This solution still has the drawback of requiring net access -- but if you have that, it's the best solution by far. So Microsoft's role has been to do the research into creating the tag format, developing and testing the scanning apps, getting OEMs and partners to adopt the technology, providing the service. They have not done this out of the goodness of their heart -- they're in the technology business, and they see this as a business opportunity. It's not a false market or a real market or anything in between. MS wants your business, and they're working to earn it -- same as any other business.
As above, this adds nothing over what could already be done with existing technology. Having lived in Japan for a year, I can tell you that reading QR Codes on a cellphone is even simpler than point-and-click. You just point, and before you would have even pressed the button to tell it to read, it's already recognized the barcode and read the data. Works perfectly in all sorts of lighting conditions.
I mentioned a couple of uses such as printing a tag on your business card that work contacts
You can fit a surprising amount in a QR Code. But even suppose you wanted to put something in there that wouldn't fit - you still have the option of doing the same as MS is doing. Just encode a URL that then directs the user to the actual data. IMHO, it's much better to have the option to encode the data directly when feasible, and use the URL as a fallback for when it's not, than to force everyone through MS's servers.
What happens if MS starts charging for the service (either barcode reading or barcode generation - since generation apparently requires use of MS's database and servers), or starts dropping old data (or discontinues the service altogether)? Or if their servers go down? And then you have the people worried about the privacy implications. None of these are problems if the data is encoded in the barcode itself.
But you're missing the point. The point is that if Google takes someone else's ideas and makes a fortune on them then that is just wrong.
How?
If Google steals an idea and makes a fortune on it, then sure, it's wrong. But if they use an idea that was freely given to them through this service, where the stated goal is to possibly be used in Google's products .... what's the problem? The submitter knew what Google was going to do with the idea, and submitted it anyway.
If you're concerned about your IMs being displayed as a notification, there's a reason there's an option to turn those off. They default to off in Pidgin, last I checked too.
I disagree about not being able to interact with notifications. It's one feature I use all the time with Pidgin. It pops up a notification when a contact signs on, and the notification includes a button to open a conversation with them. Perfect for those times that the notification reminds me that I had wanted to talk to this person for some reason. The button it completely relevant to the message, and avoids a fair amount of work in figuring out where I put the buddy list window and digging through a lot of contacts to find the one that just happened to sign on.
What could be done, and I believe Linux can do, is write the pages out to swap space, but as long as there's no reason not to, keep the copies in RAM as well.
If you need the RAM for disk cache, the RAM copy can be dropped since it already exists on disk. If the program needs to access memory, it's already there and doesn't need swapped back in.
If the claim that windows swapped out everything when the computer was left idle overnight is correct, then it is indeed a suboptimal paging algorithm. An idle computer has no reason to remove things from RAM, as there's nothing it needs the space for.
Why do we write free software? I would hope part of the goal is to make code that lots of people will use.
I write free software to fill some need that I have. If others find it useful as well, great, but that's not why I write it.
libavcodec does indeed have its own FLAC decoder, which is not dependent on libFLAC. It may have (optionally) supported using libFLAC at some point in the past, but my subversion checkout from a couple weeks ago doesn't even seem to support that anymore, instead preferring their own FLAC implementation.
The eEye Security advisory doesn't mention libavcodec at all. That seems to have been (incorrectly) added by heise security.
Even better would be Near Field Communication. Just touch the phones together, no cables or anything.
There are two stages to the competition with the prize money split evenly between them. Details for the second stage will be released later.
Actually, it's meant to be a flame. http://en.wikipedia.org/wiki/Asahi_Beer_Hall
But that argument only works for traffic that has to go over the internet infrastructure itself. If I've got a cable connection, and want to transfer to someone else down the street, or even across the same city who's on the same provider, that traffic never has to leave the cable company. And no matter how limited the cable company's connection to their provider may be, or how limited the infrastructure out there may be because of being spread too thin, the cable company can definitely handle the traffic within their own network.
Plus, I don't buy the argument about the problem being the infrastructure in the US. The connections I got to sites in the US from Japan was faster than I get from my ISP here in the US. If the problem was infrastructure, that'd never happen. No, this is simply a case of the ISPs charging more and offering less service than other countries.
WINE isn't virtualization. It's merely an implementation of the Win32 API. The program itself is still happily running with as much access to the machine as any other process. Now, I do believe Qemu is capable of something closer to this, where it emulates for one process, and passes the syscalls on to the native kernel.
Here's a quick translation I just did:
< /table>
Hello! Good afternoon!!!!!
I stumbled across a browser crash, so today I'll tell you about it!
Here it is!
<style>*{position:relative}</style><table><input>
Sample (If you're using IE, your browser will close! You have been warned!)
It seems IE6 or programs using IE6 components will definitely crash!
I haven't checked IE7 though!
It seems to be when you have and input or select or such just below a table or tr or such,
and you use the css wildcard * to set everything to position:relative.
By the way, if the input has its style directly set to relative, it doesn't crash. What's up with that?
I don't really get it, but it sure is interesting...!
Anyone out there who loves Firefox or Opera should go spread this all over and decrease IE's market share!!!