Actually, the term DLL hell does not come from where the DLLs are placed on the hard disk, but wacky versioning scheme used by COM to identify which DLL to use.
For example, you define an interface, IFoo with a method public int getFoo(), in the bar.dll. When you build the DLL, it will be assigned version 1. You then go about writing your application that uses bar.dll and IFoo. It gets built and deployed to use bar.dll version 1. As you continue to develop, you determine that IFoo needs a doFoodles method so you update the interface and rebuild bar.dll and it gets assigned version 2. Now, you application is looking for version 1, but you want version 2. Furthermore, both versions of bar.dll are in the registery. You have now arrived in DLL hell.
Imagine the fun when you aren't developing but instead trying to distribute a version your applications. Your users have bar.dll registered on their system, but your application doesn't work. Oh, now you have to determine if they have the right version of bar.dll. Of course, we move into double prize money when they inadvertantly install the new bar.dll, but not the new version of your application.
This versioning scheme is so braindead that even Microsoft gave up on it. These days, when they need to change an interface such as IFoo, they change the name to IFoo2, IFoo3, etc.
In summary, DLL hell has nothing to do with where DLLs are placed on the file system, but instead, the braindead versioning notion used by COM and the registry.
IBM is urging Sun to create an open-source implementation of Java, not necessarily open source its current implementation. Sun's current Java implementation is loaded with tweaks and advanced features (generational garbage collection, HotSpot, etc) that would not be available in such a scenario. The open-source community developing this new implementation would have to develop these features on their own or hope that Sun will donate some or all of their work out the goodness of their heart.
As such, this move by IBM doesn't seem to have any short-term beneift. Furthermore, IBM isn't pushing this new open-source implementation to be the implementation of choice. Instead, they are saying that like the J2EE specs, there should be a free and open-source implementation of the J2SE specs. Whoopie.
The point of my reply is that he not acting responsibly as an officer of his company. It is fine for him to make those statements verbally to candidates or to require high fluency in English. Making broad, stereotypical statements about any ethnic group publically can draw a complaint that will be get investigated by the Department of Labor. All it takes is one Indian applicant to Fog Creek who didn't get hired to complain, and Mr. Spolsky will find his company dragged into a bureaucratic muck that will be expensive and time consuming to escape. Corporate officers and owners should never discuss their hiring practices publically -- amongst other corporate goings-on that should never aired in public.
It doesn't matter if the DoL cares. They don't investigate unless someone complains. All it takes for Fog Creek Software to have a run-in with the Department of Labor is to have a person of Indian decent file a complaint. While Fog Creek would probably prevail, it would be expensive, and completely avoidable by having their CEO/Owner not mouth off in his blog.
While I can emphatize with Mr. Spolsky's travails when filtering candidate resumes, he needs to consider the well-being of his company when ranting on his personal website. Spouting racists remarks about Indians and stating that he shreds resumes without any consderation are two perfectly good ways to get a not-so-nice visit from the Department of Labor. Especially when linked from slashdot -- allowing an even wider audience.
Bottom line, his resume advice is good, but his business acumen is quite lacking. CEOs and company owners do not make these kinds of remarks publically. End of discussion.
In addition to dubious selection of apps for the test, it should be noted the G5 will be noticably faster for Panther due to the fact that it will be built with a compiler to optimize for the new processor.
Wes Phillips ain't a kid, and is one of the snobbiest of the snobbiest audiophiles. He knows (and has auditioned) more boutique/high-end components than you could imagine. The actual article in Stereophile provided some wonderful, quantifiable insight into the performance of the iPod in the form of various lab measurements. Suffice it to say, the results were quite surprising.
Obviously, you don't what the word audiophile means or anything about the audiophile community if you state that columnists for Stereophile magazine have no idea what they are talking about.
Microsoft is all about embrace and extend. They see.NET as a way _out_ of the operating system game which is quickly becoming a high-cost, low profit venture. Fewer people are buying new PCs and they face serious challenges in the server front. If the trend continues, the Windows cash cow will turn into a anchor within 10 years and they see it coming. Microsoft also believes they loose billions a year on the piracy Office and Windows (hence the Activation crap) -- the cash cow that will keep giving and giving for the forseeable future..NET provides them with a path to become the worlds largest ASP. They want to saturate the world with.NET -- the PC XBox, TiVO, PocketPC, wherever. The wider the adoption of.NET, the wider the potential market of customers to rent Office, Money, and their cadre of low-cost, high-profit products. It also neatly solves their problem of piracy. Since their would be no local copies of software, it would become far more difficult to steal, and much easier to track down those would do. Why else would they go to ECMA to get it standardized? They want to people to be able to easily implement the runtime.
As such, I am sure that within the privacy of their offices, the Microsofties loves to Mono. They see the hope of being able to lease you and I Office without ever having to spend a dime. Of course,.NET has a long way to go before it will be able to support this model and Microsoft has a lot of porting to do, but hey, it is a ten year plan.
The ScrollPoint mouse uses a TrackPoint stick rather than a roll which allows for horizontal and vertical scrolling as well as continuous scrolling with having to constantly re-roll the mouse wheel. I have had a ScrollPoint for at least 2 and half years, maybe longer...
P.S. I have the older a ball-based version, but the link points to the newer optical version.
...extended warranties are bad. I don't know specifically about AppleCare.
Consider that they wouldn't sell it if they couldn't make money on it. For the cost of an extended warranty, you're paying cost of repair + profit to Apple + commission to salesman. Oh, and opportunity cost for your money as well.
To calculate what they charge for extended warranty, the company uses probability to determine the most likely cost of a repair over X years. It's simple probability math:.05 probability of Y breaking in 1 year,.10 of Z breaking in 2 years, etc. They figure out what the cost is and then tack on profit and commission and offer it to you.
In nearly all cases, it's better to be self-insured. Your mileage may vary, of course...and unfortunately, Apple won't give you the probability formulas they use to make the numbers;)
In general, I agree with afabbro on the issue of extended except in two cases -- cars and laptops. In the case of cars, if you intend to drive a car into the ground, you will get you monies worth out of the warrenty in one of the big repairs that will occur near the end of the warrenty period. In the case of laptops, no matter how well they are built, they will break. Laptops get abused, jostled, tossed, dropped, etc. I guarentee you will have many problems from small to large that the warrenty will quickly, easily, and cheaply repair. I have a Thinkpad, and as much of a tank as it is, I have a variety of odd occurances and problems that the 3 year (standard) warrenty quickly fixed. My warrenty is up in a year, and I am debating whether or not to just go ahead and buy a new Thinkpad just to ensure that I always have well-oiled, functioning machine...
The snippet also completely misses the point. The purpose of the OpenBSD hackathon is not to berak into OpenBSD, but to hack out new code and quash bugs.
Congratulations to the author for figuring something out has been in C++ (using the RTTI), Java (using reflection), and, I believe, SmallTalk for years. Java does provide a security facility that allows you to protect users from accessing and/or writing to "private" data, but if it is not enabled by default. I believe that.NET has a similiar security framework as well.
How do you think that Eclipse and Netbeans can show you the the definition of private/protected attributes and methods of compiled classes in their browsers?
While I am not a Microsoft fan, it demonstrates how this fanactical hatred of Microsoft harbored by so many narrows their perspective. The author of this e-books is clearly attempting to discredit the design and viability of.NET without understanding that this "hole" is widely implemented in platforms/languages.
Yeah, Opera's also A LOT better than Mozilla. (Less buggy, more advanced e-mail filtering, less crash prone, you cango back and forward by just using the "z" & "x" keys instead of giving yourself carpal tunnel from using a mouse etc etc.
FYI, Netscape, Mozilla, and IE support going backwards and fowards by using Alt+Left Arrow to go backwards and Alt+Right Arrow to go forwards. Works wonderfully, and doesn't require a mouse.
Actually, the bulk of Python is written in Python. The language is extensible through C (as well as Java and C++), and portion of the core interpriter is C, but alas you miss the point of my comment. OO languages have proven themselves in the large (i.e. Enterprise) system space as a good/great solution. Python demonstrates thtat OO can be very efficent in the small and mid-size spaces as well. Does it really matter what language the Python interpriter is built upon? No. Finally, I didn't say the OO could solve all problems. No language or approach can (otherwise, we wouldn't have so many), but many discount OO approaches as viable only large, complex systems, which is a fallacy.
P.S. -- Sorry for leaving out a word. I meant to say, "It is all about the paradigms that make the most sense to the designers and programmers. To imply the OO is not a good, general approach to solving both small and large problems sound take a peek at Python [python.org]."
P.P.S -- Bear in mind that BeOS was written entirely in C++ using a very nice OO design. So, yes, OO can be used in the systems programming space.
Let me default this comment by saying that I am big OO proponent.
The experience referenced in this message has nothing to do with the fact that an OO program was used, it had to do with NIH (Not Invented Here) syndrome. NIH predates OO, and exists in all programming paradigms. The failure of this consultant was in his understanding of OO, but in basic software engineering principles such as using libraries.
There are plenty of well-documented instances of oevrly complex/decomposed object models, but the exampled cited here does not qualify.
Finally, I contend, as troll fodder, that a well-written/designed OO implementation is just as compact and efficent as its procedural equivalent. It all about the paradigms that makes the most sense to the designer and programmers, and to imply the OO is not a good, general approach to solving both samll and large problems sound take a peek at Python.
Undoubtedly, JBoss will fix the areas where they are not compliant. But by the time they do, a new J2EE spec will probably be out, and they won't be able to pass again. Keep in mind that all the major app server vendors define the specs via JCP... so JBoss is necessarily going to always be playing catch up.
Two things. First, JBoss is part of the JCP defining a variety of specs including those that form J2EE. You too can become a member for free so long as you sign an NDA or two. The folks at the JBoss Group are writing the next version of the JMX spec for the JCP as an example.
Second, Sun is only talking about allowing them a to purchase a license for the J2EE 1.4 compatibity tests, not the current version, 1.3. Therefore, JBoss will be unable to certify itself on the current standard, and since most of the specs composing 1.4 are still in spec, they would probably fail any available tests.
One last point of note around Sun offering up the opporunity to buy the 1.4 tests is that Marc Fleury and many of the other JBoss developers have openly stated their displeasure with the Web Services angle of J2EE 1.4. They have stated that they may not implement all of 1.4 due to the little value they see in it, and their overall displike of "Web Smervices". So, Sun might be granting this opportunity knowing full well that JBoss has little or no intention of being fully compliant with J2EE 1.4
Slashdot Mirror
Actually, the term DLL hell does not come from where the DLLs are placed on the hard disk, but wacky versioning scheme used by COM to identify which DLL to use. For example, you define an interface, IFoo with a method public int getFoo(), in the bar.dll. When you build the DLL, it will be assigned version 1. You then go about writing your application that uses bar.dll and IFoo. It gets built and deployed to use bar.dll version 1. As you continue to develop, you determine that IFoo needs a doFoodles method so you update the interface and rebuild bar.dll and it gets assigned version 2. Now, you application is looking for version 1, but you want version 2. Furthermore, both versions of bar.dll are in the registery. You have now arrived in DLL hell. Imagine the fun when you aren't developing but instead trying to distribute a version your applications. Your users have bar.dll registered on their system, but your application doesn't work. Oh, now you have to determine if they have the right version of bar.dll. Of course, we move into double prize money when they inadvertantly install the new bar.dll, but not the new version of your application. This versioning scheme is so braindead that even Microsoft gave up on it. These days, when they need to change an interface such as IFoo, they change the name to IFoo2, IFoo3, etc. In summary, DLL hell has nothing to do with where DLLs are placed on the file system, but instead, the braindead versioning notion used by COM and the registry.
IBM is urging Sun to create an open-source implementation of Java, not necessarily open source its current implementation. Sun's current Java implementation is loaded with tweaks and advanced features (generational garbage collection, HotSpot, etc) that would not be available in such a scenario. The open-source community developing this new implementation would have to develop these features on their own or hope that Sun will donate some or all of their work out the goodness of their heart.
As such, this move by IBM doesn't seem to have any short-term beneift. Furthermore, IBM isn't pushing this new open-source implementation to be the implementation of choice. Instead, they are saying that like the J2EE specs, there should be a free and open-source implementation of the J2SE specs. Whoopie.
The point of my reply is that he not acting responsibly as an officer of his company. It is fine for him to make those statements verbally to candidates or to require high fluency in English. Making broad, stereotypical statements about any ethnic group publically can draw a complaint that will be get investigated by the Department of Labor. All it takes is one Indian applicant to Fog Creek who didn't get hired to complain, and Mr. Spolsky will find his company dragged into a bureaucratic muck that will be expensive and time consuming to escape. Corporate officers and owners should never discuss their hiring practices publically -- amongst other corporate goings-on that should never aired in public.
It doesn't matter if the DoL cares. They don't investigate unless someone complains. All it takes for Fog Creek Software to have a run-in with the Department of Labor is to have a person of Indian decent file a complaint. While Fog Creek would probably prevail, it would be expensive, and completely avoidable by having their CEO/Owner not mouth off in his blog.
While I can emphatize with Mr. Spolsky's travails when filtering candidate resumes, he needs to consider the well-being of his company when ranting on his personal website. Spouting racists remarks about Indians and stating that he shreds resumes without any consderation are two perfectly good ways to get a not-so-nice visit from the Department of Labor. Especially when linked from slashdot -- allowing an even wider audience.
Bottom line, his resume advice is good, but his business acumen is quite lacking. CEOs and company owners do not make these kinds of remarks publically. End of discussion.
... shooting down heliocopters and executing simulaneous attacks demonstrate the desperation of pro-Saddam forces in Iraq.
In addition to dubious selection of apps for the test, it should be noted the G5 will be noticably faster for Panther due to the fact that it will be built with a compiler to optimize for the new processor.
Wes Phillips ain't a kid, and is one of the snobbiest of the snobbiest audiophiles. He knows (and has auditioned) more boutique/high-end components than you could imagine. The actual article in Stereophile provided some wonderful, quantifiable insight into the performance of the iPod in the form of various lab measurements. Suffice it to say, the results were quite surprising.
Obviously, you don't what the word audiophile means or anything about the audiophile community if you state that columnists for Stereophile magazine have no idea what they are talking about.
Microsoft is all about embrace and extend. They see .NET as a way _out_ of the operating system game which is quickly becoming a high-cost, low profit venture. Fewer people are buying new PCs and they face serious challenges in the server front. If the trend continues, the Windows cash cow will turn into a anchor within 10 years and they see it coming. Microsoft also believes they loose billions a year on the piracy Office and Windows (hence the Activation crap) -- the cash cow that will keep giving and giving for the forseeable future. .NET provides them with a path to become the worlds largest ASP. They want to saturate the world with .NET -- the PC XBox, TiVO, PocketPC, wherever. The wider the adoption of .NET, the wider the potential market of customers to rent Office, Money, and their cadre of low-cost, high-profit products. It also neatly solves their problem of piracy. Since their would be no local copies of software, it would become far more difficult to steal, and much easier to track down those would do. Why else would they go to ECMA to get it standardized? They want to people to be able to easily implement the runtime.
.NET has a long way to go before it will be able to support this model and Microsoft has a lot of porting to do, but hey, it is a ten year plan.
As such, I am sure that within the privacy of their offices, the Microsofties loves to Mono. They see the hope of being able to lease you and I Office without ever having to spend a dime. Of course,
Sure hope he ain't singin' soprano with a cell phone exploding so close to the family blueprints.
Does anyone know if there will be an unlocked GSM version? Also, does anyone know the ETA on the crop of 802.11b SD cards?
The ScrollPoint mouse uses a TrackPoint stick rather than a roll which allows for horizontal and vertical scrolling as well as continuous scrolling with having to constantly re-roll the mouse wheel. I have had a ScrollPoint for at least 2 and half years, maybe longer ...
P.S. I have the older a ball-based version, but the link points to the newer optical version.
...extended warranties are bad. I don't know specifically about AppleCare. Consider that they wouldn't sell it if they couldn't make money on it. For the cost of an extended warranty, you're paying cost of repair + profit to Apple + commission to salesman. Oh, and opportunity cost for your money as well.
To calculate what they charge for extended warranty, the company uses probability to determine the most likely cost of a repair over X years. It's simple probability math: .05 probability of Y breaking in 1 year, .10 of Z breaking in 2 years, etc. They figure out what the cost is and then tack on profit and commission and offer it to you.
In nearly all cases, it's better to be self-insured. Your mileage may vary, of course...and unfortunately, Apple won't give you the probability formulas they use to make the numbers ;)
In general, I agree with afabbro on the issue of extended except in two cases -- cars and laptops. In the case of cars, if you intend to drive a car into the ground, you will get you monies worth out of the warrenty in one of the big repairs that will occur near the end of the warrenty period. In the case of laptops, no matter how well they are built, they will break. Laptops get abused, jostled, tossed, dropped, etc. I guarentee you will have many problems from small to large that the warrenty will quickly, easily, and cheaply repair. I have a Thinkpad, and as much of a tank as it is, I have a variety of odd occurances and problems that the 3 year (standard) warrenty quickly fixed. My warrenty is up in a year, and I am debating whether or not to just go ahead and buy a new Thinkpad just to ensure that I always have well-oiled, functioning machine ...
The snippet also completely misses the point. The purpose of the OpenBSD hackathon is not to berak into OpenBSD, but to hack out new code and quash bugs.
Congratulations to the author for figuring something out has been in C++ (using the RTTI), Java (using reflection), and, I believe, SmallTalk for years. Java does provide a security facility that allows you to protect users from accessing and/or writing to "private" data, but if it is not enabled by default. I believe that .NET has a similiar security framework as well.
How do you think that Eclipse and Netbeans can show you the the definition of private/protected attributes and methods of compiled classes in their browsers?
While I am not a Microsoft fan, it demonstrates how this fanactical hatred of Microsoft harbored by so many narrows their perspective. The author of this e-books is clearly attempting to discredit the design and viability of .NET without understanding that this "hole" is widely implemented in platforms/languages.
Yeah, Opera's also A LOT better than Mozilla. (Less buggy, more advanced e-mail filtering, less crash prone, you cango back and forward by just using the "z" & "x" keys instead of giving yourself carpal tunnel from using a mouse etc etc.
FYI, Netscape, Mozilla, and IE support going backwards and fowards by using Alt+Left Arrow to go backwards and Alt+Right Arrow to go forwards. Works wonderfully, and doesn't require a mouse.
Gee, sounds a lot like Osama's, "The day of reckoning will come upon the infidels." Wonderful role model for SCO ...
Actually, the bulk of Python is written in Python. The language is extensible through C (as well as Java and C++), and portion of the core interpriter is C, but alas you miss the point of my comment. OO languages have proven themselves in the large (i.e. Enterprise) system space as a good/great solution. Python demonstrates thtat OO can be very efficent in the small and mid-size spaces as well. Does it really matter what language the Python interpriter is built upon? No. Finally, I didn't say the OO could solve all problems. No language or approach can (otherwise, we wouldn't have so many), but many discount OO approaches as viable only large, complex systems, which is a fallacy. P.S. -- Sorry for leaving out a word. I meant to say, "It is all about the paradigms that make the most sense to the designers and programmers. To imply the OO is not a good, general approach to solving both small and large problems sound take a peek at Python [python.org]." P.P.S -- Bear in mind that BeOS was written entirely in C++ using a very nice OO design. So, yes, OO can be used in the systems programming space.
Let me default this comment by saying that I am big OO proponent.
The experience referenced in this message has nothing to do with the fact that an OO program was used, it had to do with NIH (Not Invented Here) syndrome. NIH predates OO, and exists in all programming paradigms. The failure of this consultant was in his understanding of OO, but in basic software engineering principles such as using libraries.
There are plenty of well-documented instances of oevrly complex/decomposed object models, but the exampled cited here does not qualify.
Finally, I contend, as troll fodder, that a well-written/designed OO implementation is just as compact and efficent as its procedural equivalent. It all about the paradigms that makes the most sense to the designer and programmers, and to imply the OO is not a good, general approach to solving both samll and large problems sound take a peek at Python.
Undoubtedly, JBoss will fix the areas where they are not compliant. But by the time they do, a new J2EE spec will probably be out, and they won't be able to pass again. Keep in mind that all the major app server vendors define the specs via JCP... so JBoss is necessarily going to always be playing catch up.
Two things. First, JBoss is part of the JCP defining a variety of specs including those that form J2EE. You too can become a member for free so long as you sign an NDA or two. The folks at the JBoss Group are writing the next version of the JMX spec for the JCP as an example.
Second, Sun is only talking about allowing them a to purchase a license for the J2EE 1.4 compatibity tests, not the current version, 1.3. Therefore, JBoss will be unable to certify itself on the current standard, and since most of the specs composing 1.4 are still in spec, they would probably fail any available tests.
One last point of note around Sun offering up the opporunity to buy the 1.4 tests is that Marc Fleury and many of the other JBoss developers have openly stated their displeasure with the Web Services angle of J2EE 1.4. They have stated that they may not implement all of 1.4 due to the little value they see in it, and their overall displike of "Web Smervices". So, Sun might be granting this opportunity knowing full well that JBoss has little or no intention of being fully compliant with J2EE 1.4