yes,m if they produce a console with one of those button-clad controllers they'll be just another me-too device. Put a wireless keyboard, mouse, funny controller and joystick as options that you plug in and you'll have a different beast.
If it plays media and streams netflix/iplayer et al, and records TV from youview/cable then you have a must-buy system.
It also needs an Android version of smartglass to access it too.
all in all, I'm highlighting that real-world usage of exceptions will be slow. I don't care why that is too much, nor whether it could theoretically be made better, my day-job says "make it fast" so I need to know how to achieve that.
Of course, I'd love to go back to C++ programming which would solve half my problems with the.NET bolloxs I have to use at the moment. Note that most people were told that exceptions were essentially free when used in a managed environment... so you do see a lot of kids thinking they can use them for program flow, but they're still not free even in C++ code.
nope, the idea is that you have an accident ( even a minor one at low speed) and they check everything to make sure you were not at fault in any way whatsoever - for example, I might drive from the parking lot ot the petrol station without my seatbelt (at 5mph) hit something on the road/kerb/hedge and they can refuse to pay out because I wasn't wearing a seatbelt - even at that low speed. You could be dong 35mph in a 30 zone (as everyone will do at some time) and get refused - as you were speeding.
That's moot though as its only speculation based on some insurer's practices (there are a lot of dodgy ones out there), bear in mind that insurers are putting black boxes in cars to track your driving performance, in return for reduced premiums, so when you have an accident they will be taking all that data into account - they reduced the premiums because you said you were a good driver, so you had better have been up until the accident - the co-op insurer (in the uk) even puts your driving performance data online for you to view. I wonder how officious they are when it comes to deciding what good driving is?
Its probably a good thing all round, but the nutters on the road - they don't have insurance anyway.
there are functions that successfully return 0 which indicates a failure. (Microsoft even defines the S_FALSE return code for COM).
eg, you want to look up an entry in a lookup table: you pass in the thing you want to get the associated data for, and there is no entry in the table - its a failure, but its not an unexpected failure (there might be cases where you are the first one to add to the table, this 'error' condition says you need to initialise the data).
So if you use exceptions for this case, you're going to be unhappy. If you use return codes, what do you return? success? Nothing failed per se, but it didn't succeed either as you don't have the data you requested and you have to take alternative action.
Here you go: the guy who wrote the.NET system explaining just why they are slow - in detail, lots of detail.
Performance in particular is detailed near the end, find "Performance and Trends" if you can't cope with the first half:
However, there is a serious long term performance problem with exceptions and this must be factored into your decision.
Consider some of the things that happen when you throw an exception:
Grab a stack trace by interpreting metadata emitted by the compiler to guide our stack unwind.
Run through a chain of handlers up the stack, calling each handler twice.
Compensate for mismatches between SEH, C++ and managed exceptions.
Allocate a managed Exception instance and run its constructor. Most likely, this involves looking up resources for the various error messages.
Probably take a trip through the OS kernel. Often take a hardware exception.
Notify any attached debuggers, profilers, vectored exception handlers and other interested parties.
This is light years away from returning a -1 from your function call. Exceptions are inherently non-local, and if there's an obvious and enduring trend for today's architectures, it's that you must remain local for good performance.
not really - often the exception contains little of use, except a stack trace and that would show you little in most cases too.
If you end up throwing an exception with some custom text saying what the problem was - then you could just as easily log that text there and then.
Exceptions are just a different way of returning the error information - that's all, nothing particularly special about them except you cannot totally ignore them, and they are slow.
yes you really do care. Once you've started using exceptions for normal things, then you quickly find your program will be throwing the buggers all the time. In many server applications you'll be getting 3 or 4 exceptions per request (I see this, even in the Microsoft code that you have no control over)
net result: really slow code, exceptions don't just run slowly, they also screw your CPU caches and other bits that we rely on to get data through the CPU as quickly as it can handle it - a CPU today, if it had to fetch instructions from main RAM every time, would run about as quickly as a old 8bit computer.
So using an exception to return the fact that you have no network connectivity (a condition you'd usually expect to be either exceptional - when the network goes down - or a non-performance issue - in that the user can't do anything). Using an exception to handle a missing entry in a data collection (eg so you can then take steps to populate it) will kill you. Too bad that I see exceptions used for this kind of behaviour:(
it does work in the defence's favour too - you can prove you hit the brakes, and the speed you were travelling at, so if you hit someone who jumped into the road in front of you, you'll be able to say you weren't running them down.
Collection of data for insurance purposes is another matter though, that's more a way for a corporate to wheedle out of their financial responsibilities than it is to keep the roads safe.
no, they *used* to have good developer relationships, but they appear to be blowing that away for the new stuff - you pay them to develop for the platform, and then you pay them for every sale you make, and you have to jump through hoops to get onto the platform in the first place - its no wonder they have little respect for developers anymore, we're not value-adding partners.. we're cows to be milked,
it is great and mindblowing (well, as things go on a phone)... I have the Great Little War Game and will upgrade when I get a better phone... it is shown in the "great apps" section of the Play Store, so I assume people who have Windows RT devices will know about it from that - or at least it'd get pushed to the front page, its not like Microsoft has anything better to promote.
this technology already exists in the form of virtualbox or vmware - the game can come complete with everything it needs to run in a fully tested, no-weird-upgrades-installed configuration and run, seamlessly at that.
there are loads of commemorative coins that are legal tender, but might not actually get accepted anywhere but a London bank or back at the Royal Mint.
I did mean ordinary coinage, not these exceptional ones - I don't see anyone accepting a coin weighing a kilogram for example.
coins are easier to fake, you generally need a metal that's roughly the same weight as the original and plate it to be the right colour, and then get stamping. The point of making coins in these denominations is that you don't care so much as they're not worth much and its tricky to forge enough to make it worth your while. Not to mention tricky to launder enough - no-one's going to go to a bank with a truck stuffed with $10m of coins!
This is why you never see $100 coins, but you do see 1c pennies.
All apps for Windows 8 (ie Metro) are built on WinRT (the runtime API), not.NET. There is no such thing as.NET anymore, its been superseded with WinRT. (you can still write apps in C#, but they no longer use the.NET runtime because there isn't one on Windows 8 Metro to use - unless you're writing desktop apps, but that's like writing Windows 7 legacy code).
All apps that can be written that use the new API will work on both x86 and ARM instructions, assuming you compile them appropriately.
You can write apps for WindowsRT in C# or Vb.net or C++. there are limitations, if you're writing a 3d game for example, you have to use C++.
Code compiled to work on ARM will not work on x86. You will have to recompile for x86 to make that happen. And vice versa.
Part of the problem here is that Microsoft decided that WinRT (the runtime) and Windows RT (the ARM-based device) were differnet enough that no-one would get confused. Its a lot like what they did when.NET was first coined - the term was used for practically every product.
you're right - and the best bit is you don't need to even like MS to like this product as it was purchased by MS (who could choose the best). It used to be Forefront (by Sybari) and it was "teh win" of AV products, and had a pricetag to match.
so, yes, I run it and I'm happy to do so - it ain't no shitty crap a Microsoft development team put together, it was developed by professionals:)
yeah - its especially good for your log files, after all, SSD is just like a big RAM drive.....
you're going to be better off forgetting SSDs and going with lots more RAM in most cases, if you have enough RAM to cache all your static files, then you have the best solution. If you're running a dynamic site that generates stuff from a DB and that DB is continually written to, then generally putting your DB on a SSD is going to kill its performance just as quickly as if you had put/var/log on it.
RAID drives are the fastest, stripe data across 2 drives basically doubles your access speed, so stripe across an array of 4! The disadvantage is 1 drive failure kills all data - so mirror the lot. 8 drives in a stripe+mirror (mirror each pair, then put the stripe across the pairs - not the other way round) will give you fabulous performance without worry that your SSD will start garbage collecting all the time when it starts to fill up.
there was a distributed "3g survey" mapping project that the BBC tried a while back and its still on-going using OpenSignalMaps which will no doubt come back into fashion as the 4G rollout starts up in earnest.
and it won't be as secure as a JVM-based solution that has many, many years of engineering updates and patches applied to it already. In fact, a JVM-based implementation would be so secure there's a new patch being developed for it right now.
With the single executable - you know you have no dependency issues but you do end up with security/update issues. Updating requires a new version that is rebuilt with every dependency again - which can be a major download, especially for things that never change.
But I agree with you generally. There is the case for security updates - if library x needs an update, too bad, you have to update all the programs that are built with it whereas a shared library system would let you update that library just once (of course, the library developer has to keep an eye on backwards compatibility which is a bit of a dead art by today's coders)
Even with huge executables, you can deploy them with patch updaters that only transfer diffs. Or you could deploy with a single directory full of shared libraries, which still makes it difficult to update every app that uses a particular library, but is easier than updating an equal number of single-exe programs.
Trouble is... imagine you have this single-directory deployment mechanism. You think "you know, I'll just store the list of libraries somewhere common so if one needs updating, there's a list of all the places it can be found", and you end up needing an installer and a registry and then you think "but why not store the library in a common place and avoid this overhead and just update it once" and you then have a global cache, and then you think "but what about when that library changes its interface and breaks dependencies" and then you have a side-by-side common directory, and then you realise that you need a new way of loading dlls so you can load 2 different versions of the same dll and you end up with the monstrosity that is probe path loading and then you have everything big and complicated and really messy.
So yeah, a single executable is a good thing. Shame there's so few xcopy-style deployments on Windows despite them saying they'd go with this when.net first came out. I guess the need for complexity is baked in to Windows architects now.
In fact, with.NET, I notice that the latest anti-pattern is embedding the installation code inside the executable itself, so you not only need an installer(installutil, comes with the.net framework) but you need to store the installer code inside the thing that is installing. Way to go - to take something that was reasonably sensible and twist it so that it is still just as complex but now less configurable and manageable!
not necessarily - whilst any business can stick with Office 2003 or 2007, Microsoft tries their hardest to keep you upgrading - for example, if you are on the SA licencing system (ie for bulk purchases) then you must upgrade to the latest version. No option to keep running old version.
Then, of course, most companies will upgrade anyway, like they upgrade from XP when, technically, they don't really need to. Of course they will upgrade to 7 eventually due to security support, but Office has just as many problems that requires security patches.
so - yes, I'm fine with the methodology of counting Office upgrades in this mix. I'm quite curious why its only â4m though - are they really counting all the Sharepoint, OneNote, Groovy, Lync and other Office bits or not.
the letter of the law is often just vague enough that one man's "pay tax based on your headquarters country" which was intended that companies with multiple locations pay tax on the country their main one was based becomes "headquarters is registered as a PO Box in a country with no tax", which *might* be perfectly legal according to the law, but that depends on the interpretation of what a headquarters is.
This is why some tax avoidance schemes are not completely legal, the way to figure them out after they have been written down by the legislature is to go to court so a judge can interpret them and give a more definitive (or clearer) answer.
Its rather like Apple patenting something, Samsung will take them to court to figure out if the patent is actually valid or not. You could say "but the patent was granted, therefore Samsung needs to pay up", or you could say "although its granted, a judge needs to review its validity". Not a perfect analogy, but you get the idea.
The latest legal difficulties to hit News Corporation could also potentially have ramifications on its 27 TV licences within the Fox network â" the real financial heart of the operation. Three of the licences are up for renewal, and in August the ethics watchdog Citizens for Responsibility and Ethics in Washington (Crew) filed a petition with the US broadcasting regulator, the Federal Communications Commission, that called for them to be denied on the grounds that the company did not have the requisite character to run a public service.
The FCC is being asked to deny renewal for 3 of the 27 Fox licences. Whatever regulates the sat/cable industry might be asked to consider if Fox is a reputable enough company to own a licence to broadcast - the UK has such requirements, and I can't really believe the US has a totally deregulated media industry (a corrupt one, maybe).
Sure, but you must be in the minority, my xbox 360 not only plays the greatest games but will connect to Office 365 so you can enjoy the latest in productivity applications when the kids aren't using it with their Kinect, and you can also get a great Windows Phone 8 and connect to it using Microsoft Smartglass for the latest in fully immersive entertainment control.
Why not Bing these to find out more?
(think I got the full set in there, where's my bonus?)
Slashdot Mirror
yes,m if they produce a console with one of those button-clad controllers they'll be just another me-too device. Put a wireless keyboard, mouse, funny controller and joystick as options that you plug in and you'll have a different beast.
If it plays media and streams netflix/iplayer et al, and records TV from youview/cable then you have a must-buy system.
It also needs an Android version of smartglass to access it too.
all in all, I'm highlighting that real-world usage of exceptions will be slow. I don't care why that is too much, nor whether it could theoretically be made better, my day-job says "make it fast" so I need to know how to achieve that.
Of course, I'd love to go back to C++ programming which would solve half my problems with the .NET bolloxs I have to use at the moment. Note that most people were told that exceptions were essentially free when used in a managed environment... so you do see a lot of kids thinking they can use them for program flow, but they're still not free even in C++ code.
nope, the idea is that you have an accident ( even a minor one at low speed) and they check everything to make sure you were not at fault in any way whatsoever - for example, I might drive from the parking lot ot the petrol station without my seatbelt (at 5mph) hit something on the road/kerb/hedge and they can refuse to pay out because I wasn't wearing a seatbelt - even at that low speed. You could be dong 35mph in a 30 zone (as everyone will do at some time) and get refused - as you were speeding.
That's moot though as its only speculation based on some insurer's practices (there are a lot of dodgy ones out there), bear in mind that insurers are putting black boxes in cars to track your driving performance, in return for reduced premiums, so when you have an accident they will be taking all that data into account - they reduced the premiums because you said you were a good driver, so you had better have been up until the accident - the co-op insurer (in the uk) even puts your driving performance data online for you to view. I wonder how officious they are when it comes to deciding what good driving is?
Its probably a good thing all round, but the nutters on the road - they don't have insurance anyway.
sorry, fail.
there are functions that successfully return 0 which indicates a failure. (Microsoft even defines the S_FALSE return code for COM).
eg, you want to look up an entry in a lookup table: you pass in the thing you want to get the associated data for, and there is no entry in the table - its a failure, but its not an unexpected failure (there might be cases where you are the first one to add to the table, this 'error' condition says you need to initialise the data).
So if you use exceptions for this case, you're going to be unhappy. If you use return codes, what do you return? success? Nothing failed per se, but it didn't succeed either as you don't have the data you requested and you have to take alternative action.
Here you go: the guy who wrote the .NET system explaining just why they are slow - in detail, lots of detail.
Performance in particular is detailed near the end, find "Performance and Trends" if you can't cope with the first half:
However, there is a serious long term performance problem with exceptions and this must be factored into your decision.
Consider some of the things that happen when you throw an exception:
Grab a stack trace by interpreting metadata emitted by the compiler to guide our stack unwind.
Run through a chain of handlers up the stack, calling each handler twice.
Compensate for mismatches between SEH, C++ and managed exceptions.
Allocate a managed Exception instance and run its constructor. Most likely, this involves looking up resources for the various error messages.
Probably take a trip through the OS kernel. Often take a hardware exception.
Notify any attached debuggers, profilers, vectored exception handlers and other interested parties.
This is light years away from returning a -1 from your function call. Exceptions are inherently non-local, and if there's an obvious and enduring trend for today's architectures, it's that you must remain local for good performance.
not really - often the exception contains little of use, except a stack trace and that would show you little in most cases too.
If you end up throwing an exception with some custom text saying what the problem was - then you could just as easily log that text there and then.
Exceptions are just a different way of returning the error information - that's all, nothing particularly special about them except you cannot totally ignore them, and they are slow.
yes you really do care. Once you've started using exceptions for normal things, then you quickly find your program will be throwing the buggers all the time. In many server applications you'll be getting 3 or 4 exceptions per request (I see this, even in the Microsoft code that you have no control over)
net result: really slow code, exceptions don't just run slowly, they also screw your CPU caches and other bits that we rely on to get data through the CPU as quickly as it can handle it - a CPU today, if it had to fetch instructions from main RAM every time, would run about as quickly as a old 8bit computer.
So using an exception to return the fact that you have no network connectivity (a condition you'd usually expect to be either exceptional - when the network goes down - or a non-performance issue - in that the user can't do anything). Using an exception to handle a missing entry in a data collection (eg so you can then take steps to populate it) will kill you. Too bad that I see exceptions used for this kind of behaviour :(
it does work in the defence's favour too - you can prove you hit the brakes, and the speed you were travelling at, so if you hit someone who jumped into the road in front of you, you'll be able to say you weren't running them down.
Collection of data for insurance purposes is another matter though, that's more a way for a corporate to wheedle out of their financial responsibilities than it is to keep the roads safe.
no, they *used* to have good developer relationships, but they appear to be blowing that away for the new stuff - you pay them to develop for the platform, and then you pay them for every sale you make, and you have to jump through hoops to get onto the platform in the first place - its no wonder they have little respect for developers anymore, we're not value-adding partners.. we're cows to be milked,
it is great and mindblowing (well, as things go on a phone)... I have the Great Little War Game and will upgrade when I get a better phone... it is shown in the "great apps" section of the Play Store, so I assume people who have Windows RT devices will know about it from that - or at least it'd get pushed to the front page, its not like Microsoft has anything better to promote.
this technology already exists in the form of virtualbox or vmware - the game can come complete with everything it needs to run in a fully tested, no-weird-upgrades-installed configuration and run, seamlessly at that.
It will be faster than Java too :)
there are loads of commemorative coins that are legal tender, but might not actually get accepted anywhere but a London bank or back at the Royal Mint.
I did mean ordinary coinage, not these exceptional ones - I don't see anyone accepting a coin weighing a kilogram for example.
coins are easier to fake, you generally need a metal that's roughly the same weight as the original and plate it to be the right colour, and then get stamping. The point of making coins in these denominations is that you don't care so much as they're not worth much and its tricky to forge enough to make it worth your while. Not to mention tricky to launder enough - no-one's going to go to a bank with a truck stuffed with $10m of coins!
This is why you never see $100 coins, but you do see 1c pennies.
All apps for Windows 8 (ie Metro) are built on WinRT (the runtime API), not .NET. There is no such thing as .NET anymore, its been superseded with WinRT. (you can still write apps in C#, but they no longer use the .NET runtime because there isn't one on Windows 8 Metro to use - unless you're writing desktop apps, but that's like writing Windows 7 legacy code).
All apps that can be written that use the new API will work on both x86 and ARM instructions, assuming you compile them appropriately.
You can write apps for WindowsRT in C# or Vb.net or C++. there are limitations, if you're writing a 3d game for example, you have to use C++.
Code compiled to work on ARM will not work on x86. You will have to recompile for x86 to make that happen. And vice versa.
Part of the problem here is that Microsoft decided that WinRT (the runtime) and Windows RT (the ARM-based device) were differnet enough that no-one would get confused. Its a lot like what they did when .NET was first coined - the term was used for practically every product.
Windows 8 overtakes all of Android web traffic in just 10 days
security updates are available already?!
you're right - and the best bit is you don't need to even like MS to like this product as it was purchased by MS (who could choose the best). It used to be Forefront (by Sybari) and it was "teh win" of AV products, and had a pricetag to match.
so, yes, I run it and I'm happy to do so - it ain't no shitty crap a Microsoft development team put together, it was developed by professionals :)
yeah - its especially good for your log files, after all, SSD is just like a big RAM drive.....
you're going to be better off forgetting SSDs and going with lots more RAM in most cases, if you have enough RAM to cache all your static files, then you have the best solution. If you're running a dynamic site that generates stuff from a DB and that DB is continually written to, then generally putting your DB on a SSD is going to kill its performance just as quickly as if you had put /var/log on it.
RAID drives are the fastest, stripe data across 2 drives basically doubles your access speed, so stripe across an array of 4! The disadvantage is 1 drive failure kills all data - so mirror the lot. 8 drives in a stripe+mirror (mirror each pair, then put the stripe across the pairs - not the other way round) will give you fabulous performance without worry that your SSD will start garbage collecting all the time when it starts to fill up.
there was a distributed "3g survey" mapping project that the BBC tried a while back and its still on-going using OpenSignalMaps which will no doubt come back into fashion as the 4G rollout starts up in earnest.
and it won't be as secure as a JVM-based solution that has many, many years of engineering updates and patches applied to it already. In fact, a JVM-based implementation would be so secure there's a new patch being developed for it right now.
With the single executable - you know you have no dependency issues but you do end up with security/update issues. Updating requires a new version that is rebuilt with every dependency again - which can be a major download, especially for things that never change.
But I agree with you generally. There is the case for security updates - if library x needs an update, too bad, you have to update all the programs that are built with it whereas a shared library system would let you update that library just once (of course, the library developer has to keep an eye on backwards compatibility which is a bit of a dead art by today's coders)
Even with huge executables, you can deploy them with patch updaters that only transfer diffs. Or you could deploy with a single directory full of shared libraries, which still makes it difficult to update every app that uses a particular library, but is easier than updating an equal number of single-exe programs.
Trouble is... imagine you have this single-directory deployment mechanism. You think "you know, I'll just store the list of libraries somewhere common so if one needs updating, there's a list of all the places it can be found", and you end up needing an installer and a registry and then you think "but why not store the library in a common place and avoid this overhead and just update it once" and you then have a global cache, and then you think "but what about when that library changes its interface and breaks dependencies" and then you have a side-by-side common directory, and then you realise that you need a new way of loading dlls so you can load 2 different versions of the same dll and you end up with the monstrosity that is probe path loading and then you have everything big and complicated and really messy.
So yeah, a single executable is a good thing. Shame there's so few xcopy-style deployments on Windows despite them saying they'd go with this when .net first came out. I guess the need for complexity is baked in to Windows architects now.
In fact, with .NET, I notice that the latest anti-pattern is embedding the installation code inside the executable itself, so you not only need an installer(installutil, comes with the .net framework) but you need to store the installer code inside the thing that is installing. Way to go - to take something that was reasonably sensible and twist it so that it is still just as complex but now less configurable and manageable!
not necessarily - whilst any business can stick with Office 2003 or 2007, Microsoft tries their hardest to keep you upgrading - for example, if you are on the SA licencing system (ie for bulk purchases) then you must upgrade to the latest version. No option to keep running old version.
Then, of course, most companies will upgrade anyway, like they upgrade from XP when, technically, they don't really need to. Of course they will upgrade to 7 eventually due to security support, but Office has just as many problems that requires security patches.
so - yes, I'm fine with the methodology of counting Office upgrades in this mix. I'm quite curious why its only â4m though - are they really counting all the Sharepoint, OneNote, Groovy, Lync and other Office bits or not.
the letter of the law is often just vague enough that one man's "pay tax based on your headquarters country" which was intended that companies with multiple locations pay tax on the country their main one was based becomes "headquarters is registered as a PO Box in a country with no tax", which *might* be perfectly legal according to the law, but that depends on the interpretation of what a headquarters is.
This is why some tax avoidance schemes are not completely legal, the way to figure them out after they have been written down by the legislature is to go to court so a judge can interpret them and give a more definitive (or clearer) answer.
Its rather like Apple patenting something, Samsung will take them to court to figure out if the patent is actually valid or not. You could say "but the patent was granted, therefore Samsung needs to pay up", or you could say "although its granted, a judge needs to review its validity". Not a perfect analogy, but you get the idea.
and to prove your point, just consider tax legislation, and how companies create subsidiaries to manage this.
yeah, you were misreading (or not reading) TFA:
The latest legal difficulties to hit News Corporation could also potentially have ramifications on its 27 TV licences within the Fox network â" the real financial heart of the operation. Three of the licences are up for renewal, and in August the ethics watchdog Citizens for Responsibility and Ethics in Washington (Crew) filed a petition with the US broadcasting regulator, the Federal Communications Commission, that called for them to be denied on the grounds that the company did not have the requisite character to run a public service.
The FCC is being asked to deny renewal for 3 of the 27 Fox licences. Whatever regulates the sat/cable industry might be asked to consider if Fox is a reputable enough company to own a licence to broadcast - the UK has such requirements, and I can't really believe the US has a totally deregulated media industry (a corrupt one, maybe).
Anyway, keep your eyes open, this time next week the Leveson Inquiry publishes its report into News Corp.
Sure, but you must be in the minority, my xbox 360 not only plays the greatest games but will connect to Office 365 so you can enjoy the latest in productivity applications when the kids aren't using it with their Kinect, and you can also get a great Windows Phone 8 and connect to it using Microsoft Smartglass for the latest in fully immersive entertainment control.
Why not Bing these to find out more?
(think I got the full set in there, where's my bonus?)