By that same note, it wouldn't hurt to have IE support other vendor's specific prefixes that have stabilized, such as -moz/webkit-border-radius. I think it just hurts MS' pride to do so... updating software takes time and money... it's MS' turn to follow in the wild issues like other browsers had to for close to a decade.
I could have nearly as easily used office 365, or skydrive as its' communications channel... this pretty much only says they trust google to not crumble under the load, or randomly go offline more than they do ms/azure.
And how is this any different from any other system that allows user generated content to be shared online? The document in question is one you open locally in MS-Word... it uses gdocs as its' communication system.. so if you block outbound non-web ports, it still works... beyond this, it could just as easily used any of the many thousands of web forums and blog comment systems for this chatter. The difference being that gdocs is probably more reliable for the load that might be generated by said virus/malware.
Unless you're applying "enterprise" patterns and libraries that don't add more value than a few static methods could give you. Though, those aren't really corners, but spikes grafted onto a given project, sometimes entwined so deeply it takes 5x the time to troubleshot a problem across all the given layers of indirection and abstraction.
I find that a lot of younger (and formally educated) developers tend to apply patterns everywhere. Even some experienced developers do the same because "that's the way we always do it, and it works"... I recently replaced a solution spread across 5 Visual Studio projects (in said solution) with a single moderately complex SQL stored procedure, and a simple script in a timed event to run said stored procedure. The solution used ent-lib and applied several layers of abstraction and indirection to accomplish what is admittedly a somewhat complex task. The issue is it was made even more complex by the implementation. The more experience I get, the more I lean towards the simplest solution that will get the job done. And when I come across areas that are complex, I try to abstract only those parts out into something that is simpler to use.
I cringe whenever I see recently developed code that uses string concatenation for SQL. *sigh*... I will say this much, I don't think that there will ever be much less need for software developers of any experience level for a long period... I think the.com bust in the early 2000's was as bad as it will get. There is so much poor quality code in production environments in this country, and even more being developed.. there is lots of room. Not to mention the fact that displacing broken systems takes far more effort and experience than even writing the original.
As someone else pushing 40, I took a director level position early last year.. it was such a mind numbing experience I couldn't even keep it up long enough to get my end of year bonus. Knowing that there is pretty much a salary ceiling for a paid developer everywhere, I simply looked for the least stressful environment I could find that would pay at that ceiling.
I still keep up with new technology trends, and after a few one-offs a lot of that is now coming into use for newer development after some time in pushing for certain direction. I'm in a pretty small company, and very experienced. I find that I, and my opinions are valued. There is something to be said for that even if it means I won't be making much more in 5 years. I will probably move on in a couple years for something new though. I tend to get bored as a product's life cycle approaches maturity, and new development wains. This keeps me looking at new techniques and technology... but doesn't lead to a lifelong desire to stay with any company.
As much as I *HATE* to say it.. Oracle is probably the best choice to buy AMD... of course, it would have to be a paradigm shift for the "oracle way" of things... AMD chips tend to scale wide better than Intel, and could be a better mesh with the needs of Oracle's larger clients. Though I think the old Sun would have been a better option.
I really hope AMD sticks around.. their IGP solutions tend to be far better than Intels, and the all around value tends to be better at the low end, or when you need more parallel loads.
So, I don't think it's correct to say that "deployed near a strong radiation source" is necessary to see flaky behavior from a modern system, even with perfect hardware.
Just worth pointing out that this is only going to become more common as manufacturing processes are becoming much smaller and less resistant to outside influences (cosmic rays). There's some interesting notes in an article in the latest Maximum PC that mentions this, regarding a CPU that actually has ECC in even the in-cpu memory systems to ensure resistance to such events.
Grr.. just posted this in reply to the wrong thread above... here it is again, where I meant to reply...
The more I think about it.. the more I think... Software * with Apprentice, Journeyman, Mentor, Master, Master Trainer might be more appropriate... With those with a degree being able to skip to Journeyman.. but not really moving past until you are mentoring others. I've also thought a more formal guild system would be beneficial.. where advancement was based not only on experience, but peer acknowledgement.. where a number of level peers, or a few higher up put a stake of their own collective reputation on your "level"
The more I think about it.. the more I think... Software * with Apprentice, Journeyman, Mentor, Master, Master Trainer might be more appropriate... With those with a degree being able to skip to Journeyman.. but not really moving past until you are mentoring others. I've also thought a more formal guild system would be beneficial.. where advancement was based not only on experience, but peer acknowledgement.. where a number of level peers, or a few higher up put a stake of their own collective reputation on your "level"
In my own experience, someone with a CS, or similar degree who enters the workplace usually has knowledge of the tools in a "lab" level environment, not necessarily the real world or partially created software, or interfacing with systems in less than ideal conditions. In general, I find the biggest difference in varying levels of degrees vs. post-educational experience, is it tends to take longer for the arrogance to be rounded off. This isn't always the case, but just seems to be the trend. In general, the best developers I've worked with are either really green, and eager to learn... or have more than 5 years of real world experience.. and that the in-between seems to be a negative correlation to the amount of formal education they have.
This is only my own bias and experience here, not a hard fast fact. That said, and I've said it many times in this thread... Software creation/expansion is rarely a matter of engineering, and even "architecture" is usually a poor analogy. Software creation is usually a craft that is influenced by a need for domain knowledge, and implementation based on the environment, the direction of the mentors in that environment and one's own experience.
I think the biggest difference is in the design and planning phases... In practice, an engineer doesn't typically also build the car.. as an architect doesn't build the structure. Software, in general the further you get away from large up front designs is much more of a craft than an engineering discipline.
I don't like the term Software Engineer so long as you are not writing code that interfaces with physical devices, and even then not always. When you are designing for interacting with physical hardware, not abstract constructs, you are much more likely to be practicing engineering, not construction/crafting. This isn't a hard rule, as I believe that other areas of software creation are absolutely engineering disciplines... the fact is that most simply are not.
In practice, if you are codifying business rules as a computer construct.. you are not engineering. This is simply how I feel on the matter.. and I consider myself a software craftsman, not an engineer for the most part in my work. That isn't to say I don't understand the more thoughtful exercises, or that they aren't necessary, it's just that the great vast majority of software development is not engineering.
The problem is simply that creation of software has much more in common to a craft than any other engineering discipline. Very rarely does software creation involve a lot of engineering... and that is *usually* when interacting with real world objects. I would say a lot of database (dbms software) design is closer to an engineering discipline at its core than what most development is (codifying loosely defined business rules into a computer construct with what often turns out to be a poor interface).
I personally dislike the use of the term engineer with regards to *most* software development... unless said development is interacting with real world objects, it is more often a matter of craft as a discipline not engineering. This isn't always the case, and hasn't always been the case.. in early computing when you had to really think long and hard about how to put things together, with days or months of rework on the line for the smallest mistake, it was much more like an engineering discipline. Today, with relatively fast turn around, and very little thought into form and structure (relatively speaking) software creation is much more of a craft of development than an engineering construct. It's much more akin to say architecture even, where there are some points of engineering knowledge and "rules".. though in software most rules are meant to be broken in a number of cases... This simply isn't true in engineering... In software you can and should often trade absolute ACID compliance for performance improvements and scaleability. It's a mater of weighted decisions often with no absolutely right answer, and problems that can be worked through in nearly infinite ways, as opposed to only a handful of options in most cases.
Any software relying on kernel level integration that changed won't work.. IIRC this includes some of the network stack this time around, as well as some of the filesystem interfaces. There's very little that won't work... the less advanced the software the more likely it works from all the way back in early win32 days (3.x)... that said, a lot of that old software needs to install in an unprotected directory to work, not program files.
I think even that depends.. if you've worked in a number of different types of environments and have shown you can acquire domain knowledge quickly, there's less if a hindrance.
But you can run a number of smaller virtual environments in the larger x86 (64-bit) CPUs that wind up scaling very well in comparison to a small cluster of ARM systems... When I've priced out the ARM server systems currently available, x86 usually winds up being a better value, when you consider having a host + 1VM per compute unit, which still out-paces the ARM systems. That said, I think that some standardization of ARM based general computing systems could bring significant reduction in pricing which could lead in ARMs favor. I think if AMD and Samsung came together on a BIOS/UEFI common interface system for components, that general purpose ARM computing can really take off.
That was my thought... it would be fairly easy to set up a cluster of arm CPU based servers as proxy servers, file servers, and even distributed database servers... Anywhere the main bottlenecks are IO, and you need to scale wide anyhow. I personally think the likes of non-relational database servers (NoSQL) as well as Node.js and similar asynchronous platforms cry out to be used by ARM systems. If your bottleneck is storage I/O throwing more CPU at the problem will not help. Right now this is roughly half of where the problem space lay.
That said, It would be nice to see a production ARM system platform that doesn't wind up being more expensive than the x64 equivalent. Virtualized servers on x64 each connected to distinct drives by the host currently work out better in terms of cost than the wide scale systems that the current ARM server systems are starting to offer. Raspberry Pi shows that it can be done economically, but the biggest limitation there is simply the amount of memory... if you could get something similar to an R-Pi with 2-4GB of memory, and even a single SATA port, you could create clusters of systems that could scale wide very economically.
No.. "friendly" would be... "This application is not signed, enter your password below to continue." or something to that effect. But hey, I guess that kind of friendliness is what should be expected from the people that brought the walled iGarden.
Slashdot Mirror
By that same note, it wouldn't hurt to have IE support other vendor's specific prefixes that have stabilized, such as -moz/webkit-border-radius. I think it just hurts MS' pride to do so... updating software takes time and money... it's MS' turn to follow in the wild issues like other browsers had to for close to a decade.
Add to that that MS has its' own proprietary extensions (grid system in ie10 for example).
I could have nearly as easily used office 365, or skydrive as its' communications channel... this pretty much only says they trust google to not crumble under the load, or randomly go offline more than they do ms/azure.
And how is this any different from any other system that allows user generated content to be shared online? The document in question is one you open locally in MS-Word... it uses gdocs as its' communication system.. so if you block outbound non-web ports, it still works... beyond this, it could just as easily used any of the many thousands of web forums and blog comment systems for this chatter. The difference being that gdocs is probably more reliable for the load that might be generated by said virus/malware.
Unless you're applying "enterprise" patterns and libraries that don't add more value than a few static methods could give you. Though, those aren't really corners, but spikes grafted onto a given project, sometimes entwined so deeply it takes 5x the time to troubleshot a problem across all the given layers of indirection and abstraction.
I find that a lot of younger (and formally educated) developers tend to apply patterns everywhere. Even some experienced developers do the same because "that's the way we always do it, and it works" ... I recently replaced a solution spread across 5 Visual Studio projects (in said solution) with a single moderately complex SQL stored procedure, and a simple script in a timed event to run said stored procedure. The solution used ent-lib and applied several layers of abstraction and indirection to accomplish what is admittedly a somewhat complex task. The issue is it was made even more complex by the implementation. The more experience I get, the more I lean towards the simplest solution that will get the job done. And when I come across areas that are complex, I try to abstract only those parts out into something that is simpler to use.
I cringe whenever I see recently developed code that uses string concatenation for SQL. *sigh* ... I will say this much, I don't think that there will ever be much less need for software developers of any experience level for a long period... I think the .com bust in the early 2000's was as bad as it will get. There is so much poor quality code in production environments in this country, and even more being developed.. there is lots of room. Not to mention the fact that displacing broken systems takes far more effort and experience than even writing the original.
As someone else pushing 40, I took a director level position early last year.. it was such a mind numbing experience I couldn't even keep it up long enough to get my end of year bonus. Knowing that there is pretty much a salary ceiling for a paid developer everywhere, I simply looked for the least stressful environment I could find that would pay at that ceiling.
I still keep up with new technology trends, and after a few one-offs a lot of that is now coming into use for newer development after some time in pushing for certain direction. I'm in a pretty small company, and very experienced. I find that I, and my opinions are valued. There is something to be said for that even if it means I won't be making much more in 5 years. I will probably move on in a couple years for something new though. I tend to get bored as a product's life cycle approaches maturity, and new development wains. This keeps me looking at new techniques and technology... but doesn't lead to a lifelong desire to stay with any company.
Going down hill since 1834...
As much as I *HATE* to say it.. Oracle is probably the best choice to buy AMD... of course, it would have to be a paradigm shift for the "oracle way" of things... AMD chips tend to scale wide better than Intel, and could be a better mesh with the needs of Oracle's larger clients. Though I think the old Sun would have been a better option.
I really hope AMD sticks around.. their IGP solutions tend to be far better than Intels, and the all around value tends to be better at the low end, or when you need more parallel loads.
So, I don't think it's correct to say that "deployed near a strong radiation source" is necessary to see flaky behavior from a modern system, even with perfect hardware.
Just worth pointing out that this is only going to become more common as manufacturing processes are becoming much smaller and less resistant to outside influences (cosmic rays). There's some interesting notes in an article in the latest Maximum PC that mentions this, regarding a CPU that actually has ECC in even the in-cpu memory systems to ensure resistance to such events.
Grr.. just posted this in reply to the wrong thread above... here it is again, where I meant to reply...
The more I think about it.. the more I think... Software * with Apprentice, Journeyman, Mentor, Master, Master Trainer might be more appropriate... With those with a degree being able to skip to Journeyman.. but not really moving past until you are mentoring others. I've also thought a more formal guild system would be beneficial.. where advancement was based not only on experience, but peer acknowledgement.. where a number of level peers, or a few higher up put a stake of their own collective reputation on your "level"
The more I think about it.. the more I think... Software * with Apprentice, Journeyman, Mentor, Master, Master Trainer might be more appropriate... With those with a degree being able to skip to Journeyman.. but not really moving past until you are mentoring others. I've also thought a more formal guild system would be beneficial.. where advancement was based not only on experience, but peer acknowledgement.. where a number of level peers, or a few higher up put a stake of their own collective reputation on your "level"
In my own experience, someone with a CS, or similar degree who enters the workplace usually has knowledge of the tools in a "lab" level environment, not necessarily the real world or partially created software, or interfacing with systems in less than ideal conditions. In general, I find the biggest difference in varying levels of degrees vs. post-educational experience, is it tends to take longer for the arrogance to be rounded off. This isn't always the case, but just seems to be the trend. In general, the best developers I've worked with are either really green, and eager to learn... or have more than 5 years of real world experience.. and that the in-between seems to be a negative correlation to the amount of formal education they have.
This is only my own bias and experience here, not a hard fast fact. That said, and I've said it many times in this thread... Software creation/expansion is rarely a matter of engineering, and even "architecture" is usually a poor analogy. Software creation is usually a craft that is influenced by a need for domain knowledge, and implementation based on the environment, the direction of the mentors in that environment and one's own experience.
This is very simple.. software creation is usually a craft, not an engineering discipline.
I think the biggest difference is in the design and planning phases... In practice, an engineer doesn't typically also build the car.. as an architect doesn't build the structure. Software, in general the further you get away from large up front designs is much more of a craft than an engineering discipline.
I don't like the term Software Engineer so long as you are not writing code that interfaces with physical devices, and even then not always. When you are designing for interacting with physical hardware, not abstract constructs, you are much more likely to be practicing engineering, not construction/crafting. This isn't a hard rule, as I believe that other areas of software creation are absolutely engineering disciplines... the fact is that most simply are not.
In practice, if you are codifying business rules as a computer construct.. you are not engineering. This is simply how I feel on the matter.. and I consider myself a software craftsman, not an engineer for the most part in my work. That isn't to say I don't understand the more thoughtful exercises, or that they aren't necessary, it's just that the great vast majority of software development is not engineering.
The problem is simply that creation of software has much more in common to a craft than any other engineering discipline. Very rarely does software creation involve a lot of engineering... and that is *usually* when interacting with real world objects. I would say a lot of database (dbms software) design is closer to an engineering discipline at its core than what most development is (codifying loosely defined business rules into a computer construct with what often turns out to be a poor interface).
I personally dislike the use of the term engineer with regards to *most* software development... unless said development is interacting with real world objects, it is more often a matter of craft as a discipline not engineering. This isn't always the case, and hasn't always been the case.. in early computing when you had to really think long and hard about how to put things together, with days or months of rework on the line for the smallest mistake, it was much more like an engineering discipline. Today, with relatively fast turn around, and very little thought into form and structure (relatively speaking) software creation is much more of a craft of development than an engineering construct. It's much more akin to say architecture even, where there are some points of engineering knowledge and "rules" .. though in software most rules are meant to be broken in a number of cases... This simply isn't true in engineering... In software you can and should often trade absolute ACID compliance for performance improvements and scaleability. It's a mater of weighted decisions often with no absolutely right answer, and problems that can be worked through in nearly infinite ways, as opposed to only a handful of options in most cases.
Any software relying on kernel level integration that changed won't work.. IIRC this includes some of the network stack this time around, as well as some of the filesystem interfaces. There's very little that won't work... the less advanced the software the more likely it works from all the way back in early win32 days (3.x) ... that said, a lot of that old software needs to install in an unprotected directory to work, not program files.
Isn't IBM one of the single biggest recipients of new patents every year?
I think you mean the second iPod.. the first version really wasn't all that great.
I think even that depends.. if you've worked in a number of different types of environments and have shown you can acquire domain knowledge quickly, there's less if a hindrance.
But you can run a number of smaller virtual environments in the larger x86 (64-bit) CPUs that wind up scaling very well in comparison to a small cluster of ARM systems... When I've priced out the ARM server systems currently available, x86 usually winds up being a better value, when you consider having a host + 1VM per compute unit, which still out-paces the ARM systems. That said, I think that some standardization of ARM based general computing systems could bring significant reduction in pricing which could lead in ARMs favor. I think if AMD and Samsung came together on a BIOS/UEFI common interface system for components, that general purpose ARM computing can really take off.
That was my thought... it would be fairly easy to set up a cluster of arm CPU based servers as proxy servers, file servers, and even distributed database servers... Anywhere the main bottlenecks are IO, and you need to scale wide anyhow. I personally think the likes of non-relational database servers (NoSQL) as well as Node.js and similar asynchronous platforms cry out to be used by ARM systems. If your bottleneck is storage I/O throwing more CPU at the problem will not help. Right now this is roughly half of where the problem space lay.
That said, It would be nice to see a production ARM system platform that doesn't wind up being more expensive than the x64 equivalent. Virtualized servers on x64 each connected to distinct drives by the host currently work out better in terms of cost than the wide scale systems that the current ARM server systems are starting to offer. Raspberry Pi shows that it can be done economically, but the biggest limitation there is simply the amount of memory... if you could get something similar to an R-Pi with 2-4GB of memory, and even a single SATA port, you could create clusters of systems that could scale wide very economically.
No.. "friendly" would be... "This application is not signed, enter your password below to continue." or something to that effect. But hey, I guess that kind of friendliness is what should be expected from the people that brought the walled iGarden.