Google could also see it as investing in getting an open format available. The fact of the matter is that if they had not put all those resources into creating WebM, MPEG may well have taken up this issue in the first place. If they see it as such, they will welcome a competing open standard that could be superior,and would offer royalty free use of their acquired patents in this new standard.
Either reaction is possible, but your suggestion does seem slightly more likely.
I did not mean to imply that low end devices could encode Web M, but they can certainly play it. I did mean to imply that MPEG-LA would not be particularly thrilled about a royalty free codec of better than MPEG 2 quality that could be encoded on such a device, much like the very concept of the story.
I was merely pointing out to the eating utensil with a PHD, that MPEG is not necessarily doing the MPEG-L any favors by developing such a standard.
I did not say a crippling amount of royalties, merely a substantial amount. It is currently the codec of choice for many applications in a whole bunch of different industries that would be uninterested in the new royalty free codec. But companies are known for spending more money to irrationally protect a source of revenue than they actually receive from it, so some of those players may object and object loudly.
If as you imply the loss of smartphones and internet usage would barely touch the revenue and as a result the licensors would not really care, keep in mind that that would also apply just as much to Web M. They could not even see lawsuit as a real source of income, because it would be easy to show minimal loss of revenue which is a major component of determining any award in a lawsuit.
Agreed. You cannot warrant against damage caused by the non-standard software. I mean it is not your fault that the software executed a Killer poke or a modern equivalent thereof. The problem is that many companies refuse to warrant against hardware issues not caused by the non-standard software. In some cases it is quite obvious that the software was not responsible, such as structural defects in the case that caused it crack and those should still be covered. The nasty case is when the problem is a type that could have been caused by software, or may have been a hardware issue, and there is no no easy way to tell them apart. In that case, not covering the issue under the warranty may be entirely reasonable.
Any phone that allows substantial screwing with the the RF output of the phone is using a poorly designed cellular modem chip (baseband). Short of altering the baseband firmware, the worst that a phone should be able to do is a limited denial of service attack (such as mass producing SMS messages or rapidly starting a phone or data connection, and then droping it before it is fully established, and repeating).
That said I will admit that there are some rather poor baseband chips out there, which let the main processor specify important RF parameters.
Not necessarily. They could decide to adopt Theora as the basis of the new standard, and see if they can get royalty free patent licenses for possible improvements.
Keep in mind that MPEG has little issue with standardizing something that already exists, like how the MOV container format was standardized as the MP4 container format, how they standardized Adobe and Microsoft's OpenType as MPEG4 Part 22: Open Font Format, or how they standarized a slight modification to ASPEC as MPEG-1 Layer 3 Audio.
MPEG wants to merely merely standardize things, ending the problem of searching for a royalty free codec. Mozilla and Google both simply want a royalty free standard that is Good enough. VP8 seems like one possibility, but if something even slightly better than VP8 is standardized, both should be quite willing to implement it.
MPEG LA on the other hand actively does not want any codec better than say Microsoft Video 1 (the format most classic AVI files used) available on royalty free terms. They would lose out on a substantial amount of royalties if devices like phones or low end Digital Cameras used such a format rather than one of their formats. This is why they so actively fear projects like WebM. They make a substantial portion of their royalties from Cell phones, low end cameras, and similar devices.
This is not an attack on VP8. It might moot the WebM project, but neither Google nor Mozilla should have much of an issue with implementing such a standard, since automatic royalty free patent licenses don't cause any issues with Free or Open Source software. Indeed, they are even compatible with the GPLv3.
Please don't confuse MPEG with the MPEG LA. The latter is a a corporation with no formal relationship to MPEG. If anything MPEG doing this is intentionally snubbing the MPEG LA.
Proper use of Strong Named assemblies, and the Global Assembly Cache do prevent a variety of attacks, from infecting dlls, to simply placing fake versions in locations where a program is likely to accidentally pick them up.
The problem though is by default a reference to "log4net, Version=1.2.10.0, Culture=neutral, PublicKeyToken=1b44e1d426115821" does not allow "log4net, Version=1.2.10.1, Culture=neutral, PublicKeyToken=1b44e1d426115821" to be loaded, despite being signed with the same public key.
A publisher can create a publisher policy to redirect to the latest bugfix version, but Microsoft has not made this sufficiently clear to many developers, and has not provided any means of automatically creating on each compile a new policy assembly that redirects all the 1.2.10.x series names to the version of the newly built 1.2.10.55 assembly.
The core developers of the.Net framework don't see this issue much, since Microsoft does not change the versions of the core assemblies. For example, mscorlib.dll from.Net Framework 2.0, and mscorlib.dll from from.Net Framework 2.0 SP2 (which shipped with.Net Framework 3.5) are both "mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089".
Regular developers cannot do that, since the GAC cannot distinguish between two assemblies with exactly the same name, so you would fall back into DLL Hell where your bugfixes would be overridden by the next application that is installed that uses your library.
(On a slightly related note, I've always found it interesting that programs can also export symbols and therefore be shared libraries (native or CLR) themselves. The.Net Framework/CLR makes that a little more discoverable, as the assembly naming scheme intentionally does not distinguish between applications and shared libraries. Indeed,.Net reflector's API is to add the exe as an assembly reference to your project.)
True, but not nearly to the same extent that router makes do it. Other consumer electronics manufacturers tend to only make smaller changes without actually changing the model number. For changes similar to what router makers make, while the advertised portion of the model number (if any) may remain the same, the last few letters of the full model number are normally changed by a fair amount, and not just incrementing the revision number.
Creating a fake optical drive requires hardware support. However, it is true that nothing prevents a virus from replacing the U3 drive's ISO with malware, which would then autorun. For some crazy reason, on most U3 drives the ISO is stored in flash and is updatable, although they don't make it particularly easy to discover how to write a new image.
The exact set of changes being offered here were a part of Windows 7 from day one. Windows 7 completely ignores the "Open=" entires in any autorun.inf file except for those loaded in devices that claim to be optical media. (So CDs and DVDs will still show the autorun option in the autoplay menu, as will U3 style flash drives, etc)
This is just a patch to older systems to include the same behavior.
True, but by default on the NT familly all files have the execute permission. I mean I find the output of "ls --color" to be quite disturbing on Windows (executed via cygwin) because everything is marked executable.
It is also worth pointing out that Windows almost never tries to run anything that does not have an executable suffix. While It is possible, it is very rarely seen. I believe the path search system completely ignores files without an executable suffix, so the full path of such a file needs to be specified.
The exact terms are "provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty". An appropriate notice for a derived work would inherently include the copyright notice of the original. Of course considering the BSD license to be a copyright statement that must be preserved is still questionable.
Under this sort of analysis the endorsement term is considered to not really be a condition of the 3-clause BSD license (despite the text clearly claiming it is a condition), but rather an explanation that you are not getting the right to use the names for endorsements or promotions, and since by default you don't have that right, you cannot use the names for endorsements or promotions.
I fully agree that that one is more or less patently absurd, but that does appear to be the logic. I'll point out that courts have devised even more absurd legal fictions in the past in order to reach the desired conclusion.
My home has internet but really poor mobile phone coverage. It'd be nice to be able to buy a small cheap mobile phone "tower" that I could connect to my router, giving me and my neighbours better mobile phone coverage. I'd accept that it would be locked to some mobile phone provider or other, but I'm sure the provider wouldn't mind as I would be paying with my own money to extend their network coverage to fill in mobile phone shadow pockets that are too small for them to consider.
I really really hope that was deadpan sarcasm, but if not, you just described what have been variously callled microcells, picocells, or femtocells.
For consumer usage, the search phrase would be femtocell, and they are available for purchasing many locations, but not australia.
That is because Telstra feels that femtocells are normally used to overcome weak indor signals, but the frequency they use on their network (850 MHz) des nt have that problem nearly as badly. Virgin Mobile Australia and Vodafone Australia are (or have been) planning femtocells, but both have been slowed by the fact that neither are actually Australian owned, and deployments in other countries are taking priority,
Quite true, with the odd menu button (that lives on its own line, except when maximized, when it shares with tabs), down to having one little icon at the far end of the tab strip (albeit with very different functionality).
The biggest difference is that Opera still has a status bar on my machine (but It may have been off by default. I would turn that back on right away).
Of course Opera's current design was largely inspired by Chrome, but Firefox is definitely more Opera-like than chrome-like right in terms of UI right now.
There is no Windows Mobile 7 platform. There is a platform named "Windows Phone 7", but one could reasonably argue that the quotes are nessisary around that title, since it is not a Mobile Windows platform. Windows Mobile development did not differ much from developing directly for Windows CE, which is a full fledged member of the Windows OS Family. "WP7" is built on top of the Windows CE platform, but unlike the actual Windows Mobile series no version of the Windows API is exposed to programmers. Instead, all programs must be targeted at one of two.NET Framework-based APIs, namely: an incomplete implementation of the XNA framework, or an incomplete implementation of the Silverlight Framework.
X-Box Phone would have been slightly more appropriate a name than "Windows Phone", since developing for it is much more like developing for the X-Box than developing for any version of Windows. Oddly though the advertising for "WP7" is indirectly downplaying games for the platform by focusing on the "get in, get out quick". While for casual games that ability is quite desirable, it is presented as "spend as few seconds looking at the phone as possible", which is very anti-game.
It is generally true that the GNU tools have more functionality. I'm not sure why I said that the BSD userland is more complete, I can't remember typing that let alone why I did. But, and I know it is highly subjective, I think this extra functionality is not always as well polished and/or thought out.
I'll buy that. The newer stuff does tend to take a more expansive view of the "one thing" an appication should do, and arguably that thing is not always as "done well" as the traditional unix utilities are.
Can't quite put a finger on it, though, it may well be just 'feeling uncomfortable'. The BSD tools 'feel' more orthogonal, does that make sense? Maybe I'm just used to it and not as flexible as I once was...:-)
They are definitely less orthogonal than the original Unix tools, which is sometimes convenient, but does make it easier to end up using the wrong tool for the job.
The usual handwave for BSD is to claim that the BSD licenses qualify as part of the copyright notice, which the GPL mandates must be retained. I would fully agree that is stretching things a bit.
The GPLv3 does definitely make things less ambiguous.
Correct. The sentance "Debian GNU/kFreeBSD will port both a 32- and 64-bit PC version of the FreeBSD kernel into the Debian userspace" is very poorly worded.
Debian GNU/kFreeBSD is the kernel of FreeBSD but the same userspace as in all Debian ports.
With the exception of code under the old 4 clause BSD license, all BSD licensed code is fully compatible with the GPL, so I'm having trouble picturing any problems, especially since even the FSF (who generally interprets the concept of derivative works very widely) agrees that a kernel's licensing in no way affects the userland.
I find GNU Make generally superior to legacy Make implementations, especially if I am avoiding the autotools.For example, I can set up completely automated header detection and tracking, not needing "make dep" runs or the equivalent.
The GNU project's 'less' is my preferred pager, despite the fact that I don't use most of it's advanced features.
And then generally I prefer to have the GNU userland because mst of the utilities have extended features, that various scripts may be taking advantage of (the whole reason why having a 'gawk' application, or 'gsed' application is still relatively common on BSD systems). If I'm going to install GNU awk as 'gawk', and GNU make as 'gmake' anyway, why not just install them as 'awk' and 'make' and be done with it?
The documentation for GNU is generally just fine, as long as you reference documentation with 'info' rather than 'man', (info will display the TexInfo manual if present, and falls back on the man page automatically).
Of course I'd also be very interested to know about what you find incomplete about the GNU userland. (If nothing else it tells me to look for versions of those utilities in my distro. It is surprising hard to find any information trying to directly compare BSD and GNU userlands.
I will agree with that. The current method of creating each year's vaccine does not provide overall herd immunity, even if 100% of the population received it. I'm just arguing that this is due to how we make the vaccine, rather than anything special about Influenza itself.
Bad batches of vaccines not only fail to cause immunity, but in vaccines based on the actual organism have the risk of giving you the very disease you are trying to prevent! For example, some vaccines are based on killed copies of the virus in question. If somebody screwed up, and one batch was not killed, then you are injecting the live virus into people.
Thankfully in practice bad batches usually do not involve such issues but rather involve things like insufficient vaccination material included in the suspension, or the live organism used had mutated slightly resulting in the antibodies generated by the vaccine not being as effective against the wild organism as they should have been.
It could be largely possible for influenza if we vaccinated for all known strains. Unfortunately there are far, far t many known strains fr that to be viable.
Instead we vaccinate with strains similar to (but usually not identical to) the strains we expect to see in great numbers the wild that season. Any vaccine that is not an exact match has higher likelihood of failing to prevent catching the strain in the wild (relative to an exact match), because of the randomized process used to create antibodies. Furthermore we don't always guess what strains will be in the wild correctly, and in those years with respect to those strains not guessed the people with the vaccine don't have much advantage over the people without without.
Slashdot Mirror
Google could also see it as investing in getting an open format available. The fact of the matter is that if they had not put all those resources into creating WebM, MPEG may well have taken up this issue in the first place. If they see it as such, they will welcome a competing open standard that could be superior,and would offer royalty free use of their acquired patents in this new standard.
Either reaction is possible, but your suggestion does seem slightly more likely.
I did not mean to imply that low end devices could encode Web M, but they can certainly play it. I did mean to imply that MPEG-LA would not be particularly thrilled about a royalty free codec of better than MPEG 2 quality that could be encoded on such a device, much like the very concept of the story.
I was merely pointing out to the eating utensil with a PHD, that MPEG is not necessarily doing the MPEG-L any favors by developing such a standard.
I did not say a crippling amount of royalties, merely a substantial amount. It is currently the codec of choice for many applications in a whole bunch of different industries that would be uninterested in the new royalty free codec. But companies are known for spending more money to irrationally protect a source of revenue than they actually receive from it, so some of those players may object and object loudly.
If as you imply the loss of smartphones and internet usage would barely touch the revenue and as a result the licensors would not really care, keep in mind that that would also apply just as much to Web M. They could not even see lawsuit as a real source of income, because it would be easy to show minimal loss of revenue which is a major component of determining any award in a lawsuit.
Agreed. You cannot warrant against damage caused by the non-standard software. I mean it is not your fault that the software executed a Killer poke or a modern equivalent thereof. The problem is that many companies refuse to warrant against hardware issues not caused by the non-standard software. In some cases it is quite obvious that the software was not responsible, such as structural defects in the case that caused it crack and those should still be covered. The nasty case is when the problem is a type that could have been caused by software, or may have been a hardware issue, and there is no no easy way to tell them apart. In that case, not covering the issue under the warranty may be entirely reasonable.
Any phone that allows substantial screwing with the the RF output of the phone is using a poorly designed cellular modem chip (baseband). Short of altering the baseband firmware, the worst that a phone should be able to do is a limited denial of service attack (such as mass producing SMS messages or rapidly starting a phone or data connection, and then droping it before it is fully established, and repeating).
That said I will admit that there are some rather poor baseband chips out there, which let the main processor specify important RF parameters.
Not necessarily. They could decide to adopt Theora as the basis of the new standard, and see if they can get royalty free patent licenses for possible improvements.
Keep in mind that MPEG has little issue with standardizing something that already exists, like how the MOV container format was standardized as the MP4 container format, how they standardized Adobe and Microsoft's OpenType as MPEG4 Part 22: Open Font Format, or how they standarized a slight modification to ASPEC as MPEG-1 Layer 3 Audio.
MPEG wants to merely merely standardize things, ending the problem of searching for a royalty free codec. Mozilla and Google both simply want a royalty free standard that is Good enough. VP8 seems like one possibility, but if something even slightly better than VP8 is standardized, both should be quite willing to implement it.
MPEG LA on the other hand actively does not want any codec better than say Microsoft Video 1 (the format most classic AVI files used) available on royalty free terms. They would lose out on a substantial amount of royalties if devices like phones or low end Digital Cameras used such a format rather than one of their formats. This is why they so actively fear projects like WebM. They make a substantial portion of their royalties from Cell phones, low end cameras, and similar devices.
This is not an attack on VP8. It might moot the WebM project, but neither Google nor Mozilla should have much of an issue with implementing such a standard, since automatic royalty free patent licenses don't cause any issues with Free or Open Source software. Indeed, they are even compatible with the GPLv3.
Please don't confuse MPEG with the MPEG LA. The latter is a a corporation with no formal relationship to MPEG. If anything MPEG doing this is intentionally snubbing the MPEG LA.
Proper use of Strong Named assemblies, and the Global Assembly Cache do prevent a variety of attacks, from infecting dlls, to simply placing fake versions in locations where a program is likely to accidentally pick them up.
The problem though is by default a reference to "log4net, Version=1.2.10.0, Culture=neutral, PublicKeyToken=1b44e1d426115821" does not allow "log4net, Version=1.2.10.1, Culture=neutral, PublicKeyToken=1b44e1d426115821" to be loaded, despite being signed with the same public key.
A publisher can create a publisher policy to redirect to the latest bugfix version, but Microsoft has not made this sufficiently clear to many developers, and has not provided any means of automatically creating on each compile a new policy assembly that redirects all the 1.2.10.x series names to the version of the newly built 1.2.10.55 assembly.
The core developers of the .Net framework don't see this issue much, since Microsoft does not change the versions of the core assemblies. .Net Framework 2.0, and mscorlib.dll from from .Net Framework 2.0 SP2 (which shipped with .Net Framework 3.5) are both "mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089".
For example, mscorlib.dll from
Regular developers cannot do that, since the GAC cannot distinguish between two assemblies with exactly the same name, so you would fall back into DLL Hell where your bugfixes would be overridden by the next application that is installed that uses your library.
(On a slightly related note, I've always found it interesting that programs can also export symbols and therefore be shared libraries (native or CLR) themselves. The .Net Framework/CLR makes that a little more discoverable, as the assembly naming scheme intentionally does not distinguish between applications and shared libraries. Indeed, .Net reflector's API is to add the exe as an assembly reference to your project.)
True, but not nearly to the same extent that router makes do it. Other consumer electronics manufacturers tend to only make smaller changes without actually changing the model number. For changes similar to what router makers make, while the advertised portion of the model number (if any) may remain the same, the last few letters of the full model number are normally changed by a fair amount, and not just incrementing the revision number.
Creating a fake optical drive requires hardware support. However, it is true that nothing prevents a virus from replacing the U3 drive's ISO with malware, which would then autorun. For some crazy reason, on most U3 drives the ISO is stored in flash and is updatable, although they don't make it particularly easy to discover how to write a new image.
The exact set of changes being offered here were a part of Windows 7 from day one. Windows 7 completely ignores the "Open=" entires in any autorun.inf file except for those loaded in devices that claim to be optical media. (So CDs and DVDs will still show the autorun option in the autoplay menu, as will U3 style flash drives, etc)
This is just a patch to older systems to include the same behavior.
True, but by default on the NT familly all files have the execute permission. I mean I find the output of "ls --color" to be quite disturbing on Windows (executed via cygwin) because everything is marked executable.
It is also worth pointing out that Windows almost never tries to run anything that does not have an executable suffix. While It is possible, it is very rarely seen. I believe the path search system completely ignores files without an executable suffix, so the full path of such a file needs to be specified.
The exact terms are "provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty". An appropriate notice for a derived work would inherently include the copyright notice of the original. Of course considering the BSD license to be a copyright statement that must be preserved is still questionable.
Under this sort of analysis the endorsement term is considered to not really be a condition of the 3-clause BSD license (despite the text clearly claiming it is a condition), but rather an explanation that you are not getting the right to use the names for endorsements or promotions, and since by default you don't have that right, you cannot use the names for endorsements or promotions.
I fully agree that that one is more or less patently absurd, but that does appear to be the logic. I'll point out that courts have devised even more absurd legal fictions in the past in order to reach the desired conclusion.
My home has internet but really poor mobile phone coverage. It'd be nice to be able to buy a small cheap mobile phone "tower" that I could connect to my router, giving me and my neighbours better mobile phone coverage. I'd accept that it would be locked to some mobile phone provider or other, but I'm sure the provider wouldn't mind as I would be paying with my own money to extend their network coverage to fill in mobile phone shadow pockets that are too small for them to consider.
I really really hope that was deadpan sarcasm, but if not, you just described what have been variously callled microcells, picocells, or femtocells.
For consumer usage, the search phrase would be femtocell, and they are available for purchasing many locations, but not australia.
That is because Telstra feels that femtocells are normally used to overcome weak indor signals, but the frequency they use on their network (850 MHz) des nt have that problem nearly as badly. Virgin Mobile Australia and Vodafone Australia are (or have been) planning femtocells, but both have been slowed by the fact that neither are actually Australian owned, and deployments in other countries are taking priority,
Quite true, with the odd menu button (that lives on its own line, except when maximized, when it shares with tabs), down to having one little icon at the far end of the tab strip (albeit with very different functionality).
The biggest difference is that Opera still has a status bar on my machine (but It may have been off by default. I would turn that back on right away).
Of course Opera's current design was largely inspired by Chrome, but Firefox is definitely more Opera-like than chrome-like right in terms of UI right now.
Windows Mobile 7 phones
There is no Windows Mobile 7 platform. There is a platform named "Windows Phone 7", but one could reasonably argue that the quotes are nessisary around that title, since it is not a Mobile Windows platform. Windows Mobile development did not differ much from developing directly for Windows CE, which is a full fledged member of the Windows OS Family. "WP7" is built on top of the Windows CE platform, but unlike the actual Windows Mobile series no version of the Windows API is exposed to programmers. Instead, all programs must be targeted at one of two .NET Framework-based APIs, namely: an incomplete implementation of the XNA framework, or an incomplete implementation of the Silverlight Framework.
X-Box Phone would have been slightly more appropriate a name than "Windows Phone", since developing for it is much more like developing for the X-Box than developing for any version of Windows. Oddly though the advertising for "WP7" is indirectly downplaying games for the platform by focusing on the "get in, get out quick". While for casual games that ability is quite desirable, it is presented as "spend as few seconds looking at the phone as possible", which is very anti-game.
It is generally true that the GNU tools have more functionality. I'm not sure why I said that the BSD userland is more complete, I can't remember typing that let alone why I did. But, and I know it is highly subjective, I think this extra functionality is not always as well polished and/or thought out.
I'll buy that. The newer stuff does tend to take a more expansive view of the "one thing" an appication should do, and arguably that thing is not always as "done well" as the traditional unix utilities are.
Can't quite put a finger on it, though, it may well be just 'feeling uncomfortable'. The BSD tools 'feel' more orthogonal, does that make sense? Maybe I'm just used to it and not as flexible as I once was... :-)
They are definitely less orthogonal than the original Unix tools, which is sometimes convenient, but does make it easier to end up using the wrong tool for the job.
The usual handwave for BSD is to claim that the BSD licenses qualify as part of the copyright notice, which the GPL mandates must be retained. I would fully agree that is stretching things a bit.
The GPLv3 does definitely make things less ambiguous.
Correct. The sentance "Debian GNU/kFreeBSD will port both a 32- and 64-bit PC version of the FreeBSD kernel into the Debian userspace" is very poorly worded.
Debian GNU/kFreeBSD is the kernel of FreeBSD but the same userspace as in all Debian ports.
With the exception of code under the old 4 clause BSD license, all BSD licensed code is fully compatible with the GPL, so I'm having trouble picturing any problems, especially since even the FSF (who generally interprets the concept of derivative works very widely) agrees that a kernel's licensing in no way affects the userland.
I find GNU Make generally superior to legacy Make implementations, especially if I am avoiding the autotools.For example, I can set up completely automated header detection and tracking, not needing "make dep" runs or the equivalent.
The GNU project's 'less' is my preferred pager, despite the fact that I don't use most of it's advanced features.
And then generally I prefer to have the GNU userland because mst of the utilities have extended features, that various scripts may be taking advantage of (the whole reason why having a 'gawk' application, or 'gsed' application is still relatively common on BSD systems). If I'm going to install GNU awk as 'gawk', and GNU make as 'gmake' anyway, why not just install them as 'awk' and 'make' and be done with it?
The documentation for GNU is generally just fine, as long as you reference documentation with 'info' rather than 'man', (info will display the TexInfo manual if present, and falls back on the man page automatically).
Of course I'd also be very interested to know about what you find incomplete about the GNU userland. (If nothing else it tells me to look for versions of those utilities in my distro. It is surprising hard to find any information trying to directly compare BSD and GNU userlands.
I will agree with that. The current method of creating each year's vaccine does not provide overall herd immunity, even if 100% of the population received it. I'm just arguing that this is due to how we make the vaccine, rather than anything special about Influenza itself.
Bad batches of vaccines not only fail to cause immunity, but in vaccines based on the actual organism have the risk of giving you the very disease you are trying to prevent! For example, some vaccines are based on killed copies of the virus in question. If somebody screwed up, and one batch was not killed, then you are injecting the live virus into people.
Thankfully in practice bad batches usually do not involve such issues but rather involve things like insufficient vaccination material included in the suspension, or the live organism used had mutated slightly resulting in the antibodies generated by the vaccine not being as effective against the wild organism as they should have been.
It could be largely possible for influenza if we vaccinated for all known strains. Unfortunately there are far, far t many known strains fr that to be viable.
Instead we vaccinate with strains similar to (but usually not identical to) the strains we expect to see in great numbers the wild that season. Any vaccine that is not an exact match has higher likelihood of failing to prevent catching the strain in the wild (relative to an exact match), because of the randomized process used to create antibodies. Furthermore we don't always guess what strains will be in the wild correctly, and in those years with respect to those strains not guessed the people with the vaccine don't have much advantage over the people without without.