Yes because as developer I love bugfixing and regression testing way more than implementing cool new features.
Not the most fun activity, but at the same time, serious Software Engineers usually take pride in what they do and are embarrassed about handing off defective software. The quarterly time pressures in a corporation are typically what gets them to compromise on quality.
Care to explain why OSS projects frequently have long lists of unpatched bugs if your point was even remotely close to accurate?
Likely because they're doing it in their spare time, so the project moves much more slowly. My point was that with open source projects, you see them starting at very low version numbers and it'll take them a very long time to reach 1.0. By the time they reach 1.0, the quality might be something like a 1.4.7 release of a commercial product.
In a company run by Software Engineers, bugs would be fixed before new features are added and we'd see life cycles similar to open source projects that produce typically stable and largely bug free 1.0 releases.
The reality of Corporate America, however, is based on quarterly results. Getting that next release out the door and being able to sell is everything. That means that all clean-up work (bugs, exploits, refactoring) will be prioritized along with new features and unless it's really critical will likely not get done for a long time, because they are lower priority since they bring no customer sales.
Unless and until those bugs affect the bottom-line, the company won't do a thing about them. A good recent example would be Sony's rootkit problem, which it turns out was pointed out to them before the public release on sysinternal's blog.
The plan I'm using is BYOD-Lite which costs me only $6 a month and there was no activation fee, since I had my own VOIP equipment in the form of an Asterisk PBX installed on Linux. From what I can tell, they are one of the few providers who allow the use of customer supplied VoIP hardware/software, in my case Asterisk.
Something you'll have to research is what technology you want to use for hooking up individual phones to Asterisk. One possibility would be to use hardware from Digium: http://www.digium.com/index.php?menu=product_categ ory&category=hardware or any other Analog Telephone Adapter (ATA), or you could use Softphones installed on employee PCs such as X-Lite (free), or similar.
I've heard fellow programmers suggest this before, but the way I see it, you are hurting yourself and here's why: when you become an absolute specialist in one area (in this case your particular implementation), you will be pigeon-holed into this role with no chance for growth.
A much better approach to job security is to adapt to the needs inside the company and make sure your skills are needed. This will also lead to more opportunities for pay increases and general healthiness of your psyche.
In the end, what makes you interesting as a developer should be your ability for problem solving and not your ability to obfuscate your work, unless, of course, your intention is not to work;)
Actually, the document you point out kind of describes the flaw in the MS scheduler. The MS scheduler only optimizes HT behavior when you have several physical HT enabled CPUs. So let's say you have 2 P4s with HT. Windows will see 4 CPUs. The article describes how Windows will try to schedule on a logical CPU that's part of a physical CPU which currently has nothing scheduled.
So the support described by Microsoft completely fails to address single physical CPU scenarios, or multi-CPU scenarios under high thread load.
What the scheduler needs to do in a single physical HT CPU scenario is only allow threads to execute on the second logical CPU that share resources with the thread executing on the first logical CPU in order to minimize resource contention.
This is not a challenge unique to Microsoft, of course.
Any hardware manufacturer has to properly plan lead times and coordinate parts supplies. At the same time, parts obsolescence is a big challenge to any manufacturer. Every one of those thousands of parts needs to be tracked and if obsolescence is pending, a suitable replacement needs to be identified and validated.
So the article simply points out the obvious: the more complex a piece of hardware, the more can go wrong with the supply line.
-- http://www.gloryhoundz.com/
It's amazing that the mainstream media don't cover the coming era of DRM more. A true failure of the press in my opinion. Their responsibility would be to cover this topic in laymen's terms to make it understandable to the masses. This should make the nightly news instead of a review of your latest and greatest toothpaste. As it is, the public doesn't know about this and lawmakers don't understand it, so the content companies have a relatively easy time pushing their legislative agendas.
Personally, I can't wait for DRM to become widely used so that consumers are faced with a limitation of their rights.
Content companies need to learn that people like to consume. DRM is a barrier to consumption and thus doesn't make business sense. A great early example of this was Circuit City's Divx system which flopped very quickly.
Once consumers realize what's happening, DRM as we know it today will hopefully go the way of the Dodo.
-- http://www.gloryhoundz.com/
Unfortunately Windows looks at an HT CPU as if it had multiple cores (true SMP). If Microsoft would change the Windows Scheduler to properly treat an HT CPU by adjusting the way it distributes threads and processes to the two virtual CPUs, then there should be a performance gain and no penalty.
In this context, P2P is really meaningless, since it offers no advantage to me, the consumer. The only advantage it offers is for content providers, because they can serve more costumers because customers bear part of the bandwidth cost.
So since I'm providing bandwidth, do I get a download credit? If I keep files in my share long enough, I should be able to download more files without cost to me, since I'm providing a service to the content providers and they should be compensating me for it.
That might prove more difficult, since torture is a fine line and requires not just literal interpretation of the verbage but actually human-like understanding of the interaction (social understanding).
It could lighten the mood, though, with the occasional glitch that inserts some hilarity.
Unfortunately, DRM in general is an industry trend that'll be very difficult to stop. The vast majority of people buying DRM protected Software, Audio, Games don't even know about it, until they find they can't do something. Amazingly, even people working in the software industry have no clue about DRM.
Generally, the best way to combat silliness such as DRM is with your wallet, but because DRM is well hidden and only a small percentage of the population knows about it, voting with your wallet is difficult to do in this case.
Things such as the broadcast flag might perhaps get the public to notice DRM and hate it, once TV here in the US goes all digital.
Slashdot Mirror
Yes because as developer I love bugfixing and regression testing way more than implementing cool new features.
Not the most fun activity, but at the same time, serious Software Engineers usually take pride in what they do and are embarrassed about handing off defective software. The quarterly time pressures in a corporation are typically what gets them to compromise on quality.
Care to explain why OSS projects frequently have long lists of unpatched bugs if your point was even remotely close to accurate?
Likely because they're doing it in their spare time, so the project moves much more slowly. My point was that with open source projects, you see them starting at very low version numbers and it'll take them a very long time to reach 1.0. By the time they reach 1.0, the quality might be something like a 1.4.7 release of a commercial product.
http://www.gloryhoundz.com/
In a company run by Software Engineers, bugs would be fixed before new features are added and we'd see life cycles similar to open source projects that produce typically stable and largely bug free 1.0 releases.
The reality of Corporate America, however, is based on quarterly results. Getting that next release out the door and being able to sell is everything. That means that all clean-up work (bugs, exploits, refactoring) will be prioritized along with new features and unless it's really critical will likely not get done for a long time, because they are lower priority since they bring no customer sales.
Unless and until those bugs affect the bottom-line, the company won't do a thing about them. A good recent example would be Sony's rootkit problem, which it turns out was pointed out to them before the public release on sysinternal's blog.
http://www.gloryhoundz.com/
I've switched to using http://asterisk.org/ along with http://www.broadvoice.com/rates_compare.html. I think you'll find this Wiki to be a very useful resource: http://voip-info.org/
g ory&category=hardware or any other Analog Telephone Adapter (ATA), or you could use Softphones installed on employee PCs such as X-Lite (free), or similar.
The plan I'm using is BYOD-Lite which costs me only $6 a month and there was no activation fee, since I had my own VOIP equipment in the form of an Asterisk PBX installed on Linux. From what I can tell, they are one of the few providers who allow the use of customer supplied VoIP hardware/software, in my case Asterisk.
Something you'll have to research is what technology you want to use for hooking up individual phones to Asterisk. One possibility would be to use hardware from Digium: http://www.digium.com/index.php?menu=product_cate
Good Luck!
http://www.gloryhoundz.com/
I've heard fellow programmers suggest this before, but the way I see it, you are hurting yourself and here's why: when you become an absolute specialist in one area (in this case your particular implementation), you will be pigeon-holed into this role with no chance for growth.
;)
A much better approach to job security is to adapt to the needs inside the company and make sure your skills are needed. This will also lead to more opportunities for pay increases and general healthiness of your psyche.
In the end, what makes you interesting as a developer should be your ability for problem solving and not your ability to obfuscate your work, unless, of course, your intention is not to work
Actually, the document you point out kind of describes the flaw in the MS scheduler. The MS scheduler only optimizes HT behavior when you have several physical HT enabled CPUs. So let's say you have 2 P4s with HT. Windows will see 4 CPUs. The article describes how Windows will try to schedule on a logical CPU that's part of a physical CPU which currently has nothing scheduled.
So the support described by Microsoft completely fails to address single physical CPU scenarios, or multi-CPU scenarios under high thread load.
What the scheduler needs to do in a single physical HT CPU scenario is only allow threads to execute on the second logical CPU that share resources with the thread executing on the first logical CPU in order to minimize resource contention.
This is not a challenge unique to Microsoft, of course.
Any hardware manufacturer has to properly plan lead times and coordinate parts supplies. At the same time, parts obsolescence is a big challenge to any manufacturer. Every one of those thousands of parts needs to be tracked and if obsolescence is pending, a suitable replacement needs to be identified and validated.
So the article simply points out the obvious: the more complex a piece of hardware, the more can go wrong with the supply line.
--
http://www.gloryhoundz.com/
It's amazing that the mainstream media don't cover the coming era of DRM more. A true failure of the press in my opinion. Their responsibility would be to cover this topic in laymen's terms to make it understandable to the masses. This should make the nightly news instead of a review of your latest and greatest toothpaste. As it is, the public doesn't know about this and lawmakers don't understand it, so the content companies have a relatively easy time pushing their legislative agendas.
Personally, I can't wait for DRM to become widely used so that consumers are faced with a limitation of their rights.
Content companies need to learn that people like to consume. DRM is a barrier to consumption and thus doesn't make business sense. A great early example of this was Circuit City's Divx system which flopped very quickly.
Once consumers realize what's happening, DRM as we know it today will hopefully go the way of the Dodo.
--
http://www.gloryhoundz.com/
Unfortunately Windows looks at an HT CPU as if it had multiple cores (true SMP). If Microsoft would change the Windows Scheduler to properly treat an HT CPU by adjusting the way it distributes threads and processes to the two virtual CPUs, then there should be a performance gain and no penalty.
--
http://www.gloryhoundz.com/
In this context, P2P is really meaningless, since it offers no advantage to me, the consumer. The only advantage it offers is for content providers, because they can serve more costumers because customers bear part of the bandwidth cost.
So since I'm providing bandwidth, do I get a download credit? If I keep files in my share long enough, I should be able to download more files without cost to me, since I'm providing a service to the content providers and they should be compensating me for it.
--
Innovation at play: http://www.gloryhoundz.com/
That might prove more difficult, since torture is a fine line and requires not just literal interpretation of the verbage but actually human-like understanding of the interaction (social understanding). It could lighten the mood, though, with the occasional glitch that inserts some hilarity.
Unfortunately, DRM in general is an industry trend that'll be very difficult to stop. The vast majority of people buying DRM protected Software, Audio, Games don't even know about it, until they find they can't do something. Amazingly, even people working in the software industry have no clue about DRM.
Generally, the best way to combat silliness such as DRM is with your wallet, but because DRM is well hidden and only a small percentage of the population knows about it, voting with your wallet is difficult to do in this case.
Things such as the broadcast flag might perhaps get the public to notice DRM and hate it, once TV here in the US goes all digital.