It seems to me that the console vendors are trying (with some success) to have thier cake and eat it. The major games are still sold through traditional retail channels (and are still resellable for the most part* which is what keeps the game shops in buisness) giving them wide exposure. BUT they are selling the extra bits (both dlc and standalone stuff) exclusively through thier own closed distribution systems (avoiding retail markup on them) and those extras cannot be resold.
* Sometimes they include a bit of dlc that can only be used by the inittial purchasor in the box but the core game can still be resold.
It's true that coders can and will fuck things up in any language. However there are things that language designers can do to influence both the number and the severity of fuckups.
In Java and similar languages if the coder forgets to check a boundry or forgets to actually allocate an array or similar you get an exception. While an unanticipated exception is not ideal it is a lot better than what would happen in an older language.
In C and similar languages where arrays aren't bounds checked and where the language will happily let you dereference an uninitialised pointer that kind of mistake leads to unrelated memory being overwritten. At best this means a crashed application butlikely it means either subtle corruption and/or an exploitable vulnerability.
In the specific case of C things are made even worse by a couple of factors.
1: the languages lack of a string type that manages the size of the string it contains. Programmers are therefore forced to do manually a lot of tedious and easy to fuck up string related bookkeeping that in more modern languages would be handled for them. Tedious manual processes are a recipe for mistakes. 2: standard library routines that do it wrong both makign it difficult to use them in a secure way and setting a bad example for coders. Look at gets and sprintf for examples.
There have been attempts to bolt extra checking onto C (google for fortify_source) but they are of limited effectiveness due to the language's design.
The core of a clock is a device that generates events at a predictable rate. We can then count those events to measure time.
You can quantify a clocks quality to some extent by comparing it to other clocks of the same type. The more consistent they are with each other the better the clocks. Ageing will need to be accounted for for in some way though (since all clocks of a type could age in the same way and therefore change time in a consistent manner).
Now what would be interesting is if two types of clock were both consistant with other clocks of the same type but diverged relative to each other by more than random chance and aging could account for since this could indicate that the laws of physics were changing...
Why is noone asking to examine the C programming language, to adapt it to modern programming processes and methods? C++ is basically* an extention of C and it evolved over the years from "C with classes" to a language with powerfull templates, operator overloading, automatic constructor/destructor calls etc.
The trouble with C++ though is things like operator overloading, templates etc are great in moderation but abusing them leads to hard to maintain code. Worse the standard IO libraries abuse operator overloading in the name of brevrity setting a REALLY bad example to programmers. The sheer complexity of the language also make it much harder to keep the ABI consistent than with plain C and made it much harder for other languages to import making it a poor choice for libraries.
*yes a few constructs that were valid (but bad practice) in C were made invalid in C++ but good C should generally be valid C++
You're not going to be using Java or the trendy Microsoft language of the day on an Atmel AVR with 1K of flash and 64 bytes of RAM that you want to clock at 1MHz. With only 64 bytes of ram you probably aren't going to be using C either. When every byte matters assembler tends to be the tool of choice.
But there is definitely a tier of microcontrollers where a higher level than assembler is desirable and C and assembler are the only options available.
I don't believe such a language exists. C++ may be a better option since you can use OOP constructs where they make sense while still doing the low level stuff.
In theory maybe, in practice writing "good" C code requires all of the following
1: programmers who understands the issues 2: programmers who are careful enough to keep the mistake count down. 3: a tough auditing process to catch programmers who slip up (even the best programmers make mistakes from time to time). 4: good design documents that are kept up to date to define what needs to be checked, what it should be checked against, when memory can be freed safely etc. Auditors can only do thier job if they know what to audit against. 5: an attitude among those in charge that writing correct secure code is more important than the current crunch.
Unfortunately history has shown that the combination of the above is very rare. If an app or library is popular, written in C and exposed to untrusted data it's almost inevitable it will suffer from this type of exploit sooner or later.
Portability isn't purely or even mostly a language issue.
The thing with java is it comes with a HUGE standard library that behaves in a pretty consistent way across platforms and is set up ready to use by the installation of the java runtime. I can easily write a networked GUI app in java and run it anywhere there is a usable j2se implementation. Other than file handling (which gets a bit messy whatever tool you use due to the fact that filesystem differences are hard to extract) it's easier to write portable java code than platform specific java code.
With C I can write a simple text based app that monitors one thing at a time and it will be extremely portable. Beyond that things get a lot more complex and you either have to use third party portability libraries or start writing platform specific code. I don't even think there is a standard way to wait for activity on either a network socket or standard input. The standard variable types vary in size both between operating systems and between different ports of the same OS.
Even when using those third party portability libraries (e.g. gtk/glib) getting the build process right for all platforms can still bean a PITA. I will also have to build and ship different binaries and most likely redo all my testing for each platform I want to support which is a lot of extra work to me.
That is the difference, java encourages portable code, C makes you go out of your way to make your (non-trivial) code portable.
What's interesting about all this is that the core x86 patents are likely to expire sooner or later and AMD have apparently said they will license AMD64 to anyone x64 isn't just plain 386 with AMD's extentions. It also includes stuff that intel added over the years between the release of the 386 and amd's introduction of x64 such as SSE2.
I'd also bet that while the patents on the basic 80386 have probably either expired or will expire soon Intel will have a lot of patents surrounding implementing the 386 instruction set in modern ways.
IMO anyone who wants to manufacture x86 chips in the next decade or so needs a patent warchest they can hit intel back with to get a cross licensing agreement out of them. Beyond that it depends whether software vendors start compiling their code to demand newer extensions.
Some arm's have no FPU at all and those that do had various incompatible designs.
The old debian arm port was compiled for an older FPU meaning it ended up using emulation (which performs even worse than softfloat) almost everywhere. The new debian armel port is softfloat (there was talk of compiling critical packages multiple times for different FPU types but I don't think anything came of it).
In other words don't expect decent FP performance on arm with a general purpose linux distro.
Calling windows XP professional x64 edition terrible is a bit of an exaggeration. I installed it on my office desktop (I needed access to more than 4GB of ram for hfss) and was pleasantly surprised to find all the hardware I had connected worked (surprisingly even the old HP scanner I recovered from a cupboard). Later I built a machine with 48GB of ram and again it runs XP professional x64 edition fine.
Thats not to say there aren't annoyances but most of them affect all x64 windows versions equally (the main exception I can think of right now is netware which has a client for 64-bit vista and win7 but not for 64-bit XP).
I never tried the itanium version so I can't comment on that.
The Wikimedia Foundation is absolved of any liability as they function more as an internet service provider with thee associated protections that come with it. The WMF does have DMCA take-down procedures that have and are being used when copyright violations are formally noticed as well Wikipedia may be able to avoid liability through the DMCA safe harbour but I doubt reusers would have that protection. Especially in the case of reusers that are compiling then selling copies of subsets of the wiki.
Also often the attribution information is available but buried. e.g. an edit summary may say something was moved from another article. Someone checking manually could folow the trail to the history of the other article and get the information but I don't see any real way to automate this.
They could try to figure out which one recently became richer (or has a friend who recently became richer), I'll bet the £10K is full retail value not criminal fence value. A few grand of cash can't be that difficult to hide and depending on how valuable each watch was i'm guessing the watches themselves weren't hard to hide either.
Maybe and you could probablly say the same for IBM but if they do that they set themselves up for lots of dubious lawsuits aiming for a quick buck.
OTOH if they build a reputation for crushing those who file dubious lawsuits against you hopefully the next one will decide it's not such a good idea after all.
I was under the impression that the music industry decided to allow their music to be sold online DRM free not because of consumer outcry but because they realised it was the only way to break the ipod/itunes dual product lockin. Also don't forget they had been offering drm free (or at least very weakly protected) CDs the whole time and that music has a HUGE analog hole (video has one too to some extent but there are things like macrovision to try and make it harder to exploit it).
I'm fairly certain that Valve has stated that if they were to bring Steam offline forever, they would provide a way of unlocking the games, and I don't really doubt this. The thing is afaict "promises" like that are not legally binding and even if they are contracts that would have been legally binding can sometimes be dissolved as part of a bankruptcy.
Companies fortunes ebb and flow and I would not be at all surprised if in ten years time the only way to play valves games is with legally dubious (or outright illegal) third party cracks.
The people running valve now probably won't want this but by the time the shit hits the fan (if it does) they are likely to no longer be in control.
True not that it makes much difference. Australia looks pretty isolated even before you put the country names on the map and once you do things look even worse.
I'm pretty sure (if anyone has any facts to contradict this please post them) that o and north american form the core of the internet* with lots of ISPs including most if not all the teir 1 ISPS having a strong presense, good interconnections between providers and a large portion of the internets servers.
Going round via the land route or a mixed land/sea route from australia through asia/africa into europe you are going to end up dealing with a lot of countries that are either unfriendly, pro censorship**, unstable, lacking in internet infrastructure or a combination of those attributes. Not exactly ideal places to get your internet connection through. So australians get thier internet connection through rather long undersea links to north America. Afaict there are relatively few of these and bandwidth is relatively expensive on them.
I've also heard that issues with the peering policies and pricing structures of big operators within australia make things even worse.
*yes europe and north america are quite far apart physically but during the dotcom boom insane ammounts of transatlantic fiber were laid so connections between them are reliable, high bandwith and relatively cheap).
**even countries that want to censor generally want it limited to thier OWN censorship
Well the world geometry and textures will be either in the client already or downloaded by the client during the game so those should be relatively easy to copy (assuming you've already reverse engineered the protocol).
What will most likely have to be redone from scratch is all the scripting but that is a lot less work than creating the game from scratch.
They'll either learn their lesson or go out of business from lack of sales. Unless they extend this to consoles I doubt it will have that much impact on their buisness. Afaict PC gamers are a pretty small part of the gaming market.
Attribution—You must attribute the work in the manner specified by the author or licensor (but not in any way that suggests that they endorse you or your use of the work.) Which is actually somewhat hard to do for wiki articles. You really need to go through the history pretty carefully to find not only the authors who contributed directly but also the authors whose work was copied and pasted around with only a vauge reference to the source in the edit history to put together a proper atribution for a wiki article.
Either the owner keeps paying the loan on the sized car or they default and their credit record is ruined and the bailiffs are sent in.
A bigger problem with the "seize the car" system is that people at risk of their car being sized would just take to driving bangers which have little to no value in the first place.
For survivability you don't want "sturdyness", you want the car to be crumply. Afaict you want BOTH in different parts of the car.
The section that does not contain the passengers should be crumply to absorb the impact. The section behind it that does contain the passengers should be sturdy to prevent the passengers being squashed.
For video sites afacit it's pretty cheap to offer HTML5 video with H.264* as well as flash with H.264 because they can use the same processing chain for both. They have to do two versions of the player scripting of course but for at least the larger video sites I doubt that is a big deal.
*Unfortunately adding HTML5 video with theora is potentially a lot more expensive as it means duplicating the video processing chain.
pdf is the standard format for electronic documents in "as printed" form. There are lots of cases where it is nessacery to read documents from sources that are not perfectly trusted. If a pdf can't handle that securely then it's not fit for purpose.
Also at least acrobat (and I think other pdf readers too) installs browser plugins as standard so there is NO WARNING when a web page opens a pdf. This means that acrobat like flash has exposed itself to any website the user visits and therefore needs to be held to the same standards as the web browser itself.
Slashdot Mirror
It seems to me that the console vendors are trying (with some success) to have thier cake and eat it. The major games are still sold through traditional retail channels (and are still resellable for the most part* which is what keeps the game shops in buisness) giving them wide exposure. BUT they are selling the extra bits (both dlc and standalone stuff) exclusively through thier own closed distribution systems (avoiding retail markup on them) and those extras cannot be resold.
* Sometimes they include a bit of dlc that can only be used by the inittial purchasor in the box but the core game can still be resold.
It's true that coders can and will fuck things up in any language. However there are things that language designers can do to influence both the number and the severity of fuckups.
In Java and similar languages if the coder forgets to check a boundry or forgets to actually allocate an array or similar you get an exception. While an unanticipated exception is not ideal it is a lot better than what would happen in an older language.
In C and similar languages where arrays aren't bounds checked and where the language will happily let you dereference an uninitialised pointer that kind of mistake leads to unrelated memory being overwritten. At best this means a crashed application butlikely it means either subtle corruption and/or an exploitable vulnerability.
In the specific case of C things are made even worse by a couple of factors.
1: the languages lack of a string type that manages the size of the string it contains. Programmers are therefore forced to do manually a lot of tedious and easy to fuck up string related bookkeeping that in more modern languages would be handled for them. Tedious manual processes are a recipe for mistakes.
2: standard library routines that do it wrong both makign it difficult to use them in a secure way and setting a bad example for coders. Look at gets and sprintf for examples.
There have been attempts to bolt extra checking onto C (google for fortify_source) but they are of limited effectiveness due to the language's design.
The core of a clock is a device that generates events at a predictable rate. We can then count those events to measure time.
You can quantify a clocks quality to some extent by comparing it to other clocks of the same type. The more consistent they are with each other the better the clocks. Ageing will need to be accounted for for in some way though (since all clocks of a type could age in the same way and therefore change time in a consistent manner).
Now what would be interesting is if two types of clock were both consistant with other clocks of the same type but diverged relative to each other by more than random chance and aging could account for since this could indicate that the laws of physics were changing...
Why is noone asking to examine the C programming language, to adapt it to modern programming processes and methods?
C++ is basically* an extention of C and it evolved over the years from "C with classes" to a language with powerfull templates, operator overloading, automatic constructor/destructor calls etc.
The trouble with C++ though is things like operator overloading, templates etc are great in moderation but abusing them leads to hard to maintain code. Worse the standard IO libraries abuse operator overloading in the name of brevrity setting a REALLY bad example to programmers. The sheer complexity of the language also make it much harder to keep the ABI consistent than with plain C and made it much harder for other languages to import making it a poor choice for libraries.
*yes a few constructs that were valid (but bad practice) in C were made invalid in C++ but good C should generally be valid C++
You're not going to be using Java or the trendy Microsoft language of the day on an Atmel AVR with 1K of flash and 64 bytes of RAM that you want to clock at 1MHz.
With only 64 bytes of ram you probably aren't going to be using C either. When every byte matters assembler tends to be the tool of choice.
But there is definitely a tier of microcontrollers where a higher level than assembler is desirable and C and assembler are the only options available.
I don't believe such a language exists.
C++ may be a better option since you can use OOP constructs where they make sense while still doing the low level stuff.
In theory maybe, in practice writing "good" C code requires all of the following
1: programmers who understands the issues
2: programmers who are careful enough to keep the mistake count down.
3: a tough auditing process to catch programmers who slip up (even the best programmers make mistakes from time to time).
4: good design documents that are kept up to date to define what needs to be checked, what it should be checked against, when memory can be freed safely etc. Auditors can only do thier job if they know what to audit against.
5: an attitude among those in charge that writing correct secure code is more important than the current crunch.
Unfortunately history has shown that the combination of the above is very rare. If an app or library is popular, written in C and exposed to untrusted data it's almost inevitable it will suffer from this type of exploit sooner or later.
Portability isn't purely or even mostly a language issue.
The thing with java is it comes with a HUGE standard library that behaves in a pretty consistent way across platforms and is set up ready to use by the installation of the java runtime. I can easily write a networked GUI app in java and run it anywhere there is a usable j2se implementation. Other than file handling (which gets a bit messy whatever tool you use due to the fact that filesystem differences are hard to extract) it's easier to write portable java code than platform specific java code.
With C I can write a simple text based app that monitors one thing at a time and it will be extremely portable. Beyond that things get a lot more complex and you either have to use third party portability libraries or start writing platform specific code. I don't even think there is a standard way to wait for activity on either a network socket or standard input. The standard variable types vary in size both between operating systems and between different ports of the same OS.
Even when using those third party portability libraries (e.g. gtk/glib) getting the build process right for all platforms can still bean a PITA. I will also have to build and ship different binaries and most likely redo all my testing for each platform I want to support which is a lot of extra work to me.
That is the difference, java encourages portable code, C makes you go out of your way to make your (non-trivial) code portable.
Indeed, more details at
http://lists.debian.org/debian-devel-announce/2009/10/msg00000.html
http://lists.debian.org/debian-alpha/2009/07/msg00015.html
http://lists.debian.org/debian-alpha/2009/08/msg00005.html
http://lists.debian.org/debian-alpha/2009/10/msg00003.html
http://lists.debian.org/debian-alpha/2009/10/msg00004.html
http://lists.debian.org/debian-alpha/2009/10/msg00011.html
What's interesting about all this is that the core x86 patents are likely to expire sooner or later and AMD have apparently said they will license AMD64 to anyone
x64 isn't just plain 386 with AMD's extentions. It also includes stuff that intel added over the years between the release of the 386 and amd's introduction of x64 such as SSE2.
I'd also bet that while the patents on the basic 80386 have probably either expired or will expire soon Intel will have a lot of patents surrounding implementing the 386 instruction set in modern ways.
IMO anyone who wants to manufacture x86 chips in the next decade or so needs a patent warchest they can hit intel back with to get a cross licensing agreement out of them. Beyond that it depends whether software vendors start compiling their code to demand newer extensions.
ARM already has a sane FPU design. ;)
Which one?
Some arm's have no FPU at all and those that do had various incompatible designs.
The old debian arm port was compiled for an older FPU meaning it ended up using emulation (which performs even worse than softfloat) almost everywhere. The new debian armel port is softfloat (there was talk of compiling critical packages multiple times for different FPU types but I don't think anything came of it).
In other words don't expect decent FP performance on arm with a general purpose linux distro.
Calling windows XP professional x64 edition terrible is a bit of an exaggeration. I installed it on my office desktop (I needed access to more than 4GB of ram for hfss) and was pleasantly surprised to find all the hardware I had connected worked (surprisingly even the old HP scanner I recovered from a cupboard). Later I built a machine with 48GB of ram and again it runs XP professional x64 edition fine.
Thats not to say there aren't annoyances but most of them affect all x64 windows versions equally (the main exception I can think of right now is netware which has a client for 64-bit vista and win7 but not for 64-bit XP).
I never tried the itanium version so I can't comment on that.
The Wikimedia Foundation is absolved of any liability as they function more as an internet service provider with thee associated protections that come with it. The WMF does have DMCA take-down procedures that have and are being used when copyright violations are formally noticed as well
Wikipedia may be able to avoid liability through the DMCA safe harbour but I doubt reusers would have that protection. Especially in the case of reusers that are compiling then selling copies of subsets of the wiki.
Also often the attribution information is available but buried. e.g. an edit summary may say something was moved from another article. Someone checking manually could folow the trail to the history of the other article and get the information but I don't see any real way to automate this.
They could try to figure out which one recently became richer (or has a friend who recently became richer),
I'll bet the £10K is full retail value not criminal fence value. A few grand of cash can't be that difficult to hide and depending on how valuable each watch was i'm guessing the watches themselves weren't hard to hide either.
Maybe and you could probablly say the same for IBM but if they do that they set themselves up for lots of dubious lawsuits aiming for a quick buck.
OTOH if they build a reputation for crushing those who file dubious lawsuits against you hopefully the next one will decide it's not such a good idea after all.
I was under the impression that the music industry decided to allow their music to be sold online DRM free not because of consumer outcry but because they realised it was the only way to break the ipod/itunes dual product lockin. Also don't forget they had been offering drm free (or at least very weakly protected) CDs the whole time and that music has a HUGE analog hole (video has one too to some extent but there are things like macrovision to try and make it harder to exploit it).
I'm fairly certain that Valve has stated that if they were to bring Steam offline forever, they would provide a way of unlocking the games, and I don't really doubt this.
The thing is afaict "promises" like that are not legally binding and even if they are contracts that would have been legally binding can sometimes be dissolved as part of a bankruptcy.
Companies fortunes ebb and flow and I would not be at all surprised if in ten years time the only way to play valves games is with legally dubious (or outright illegal) third party cracks.
The people running valve now probably won't want this but by the time the shit hits the fan (if it does) they are likely to no longer be in control.
True not that it makes much difference. Australia looks pretty isolated even before you put the country names on the map and once you do things look even worse.
I'm pretty sure (if anyone has any facts to contradict this please post them) that o and north american form the core of the internet* with lots of ISPs including most if not all the teir 1 ISPS having a strong presense, good interconnections between providers and a large portion of the internets servers.
Going round via the land route or a mixed land/sea route from australia through asia/africa into europe you are going to end up dealing with a lot of countries that are either unfriendly, pro censorship**, unstable, lacking in internet infrastructure or a combination of those attributes. Not exactly ideal places to get your internet connection through. So australians get thier internet connection through rather long undersea links to north America. Afaict there are relatively few of these and bandwidth is relatively expensive on them.
I've also heard that issues with the peering policies and pricing structures of big operators within australia make things even worse.
*yes europe and north america are quite far apart physically but during the dotcom boom insane ammounts of transatlantic fiber were laid so connections between them are reliable, high bandwith and relatively cheap).
**even countries that want to censor generally want it limited to thier OWN censorship
Well the world geometry and textures will be either in the client already or downloaded by the client during the game so those should be relatively easy to copy (assuming you've already reverse engineered the protocol).
What will most likely have to be redone from scratch is all the scripting but that is a lot less work than creating the game from scratch.
They'll either learn their lesson or go out of business from lack of sales.
Unless they extend this to consoles I doubt it will have that much impact on their buisness. Afaict PC gamers are a pretty small part of the gaming market.
Attribution—You must attribute the work in the manner specified by the author or licensor (but not in any way that suggests that they endorse you or your use of the work.)
Which is actually somewhat hard to do for wiki articles. You really need to go through the history pretty carefully to find not only the authors who contributed directly but also the authors whose work was copied and pasted around with only a vauge reference to the source in the edit history to put together a proper atribution for a wiki article.
You still own a car if you bought it on a loan
Either the owner keeps paying the loan on the sized car or they default and their credit record is ruined and the bailiffs are sent in.
A bigger problem with the "seize the car" system is that people at risk of their car being sized would just take to driving bangers which have little to no value in the first place.
For survivability you don't want "sturdyness", you want the car to be crumply.
Afaict you want BOTH in different parts of the car.
The section that does not contain the passengers should be crumply to absorb the impact. The section behind it that does contain the passengers should be sturdy to prevent the passengers being squashed.
For video sites afacit it's pretty cheap to offer HTML5 video with H.264* as well as flash with H.264 because they can use the same processing chain for both. They have to do two versions of the player scripting of course but for at least the larger video sites I doubt that is a big deal.
*Unfortunately adding HTML5 video with theora is potentially a lot more expensive as it means duplicating the video processing chain.
pdf is the standard format for electronic documents in "as printed" form. There are lots of cases where it is nessacery to read documents from sources that are not perfectly trusted. If a pdf can't handle that securely then it's not fit for purpose.
Also at least acrobat (and I think other pdf readers too) installs browser plugins as standard so there is NO WARNING when a web page opens a pdf. This means that acrobat like flash has exposed itself to any website the user visits and therefore needs to be held to the same standards as the web browser itself.