Dude. I have the exact same problem with the same machine. I've already sent it in once to be completely rebuilt. The hinges on these things were NOT designed to handle these huge honking screens. Every tech I've talked to has said that these laptops are the most troublesome of all the models Dell has made. Get the thing repaired quickly though, 'cause if you don't the damage will just keep spreading.
Actually, many Smalltalk version control systems (such as Envy) are entirely tied to the programming language/dev environment. Take a look at Visual Age, as it's version control mechanisms are very Envy-ish.
Personally, I've found this to be less of an advantage than one might think. In general, it's good enough to work with files, and it's more flexible (particularly for cross-language development). If you have change sets, and if your language already supports some idea of seperation of components (for example Smalltalk allows you to seperate out the code for a method from the rest of the object), then you're fine.
Yeah, but the deal is the airwaves are owned by the public, and licensees of said airwaves should be serving the public good. If you take the radio stations out of the equation, then who the hell cares. However, they are very much part of the equation.
Umm... There are like a million things that impact a movies' success in the first few weeks. I think it's rather hasty to select reasons that suit one's own agenda, and then provide no research/evidence to back one's argument's up.
Spider-man opened on a hell of a lot more screens, for starters. Interestingly, the Spider-man brand is actually *older* than the Star Wars brand, so it is entirely possible that it's actually getting more older viewers than Star Wars, rather than Katz's statement that a new, younger generation has chosen Spider-man. Let's also not forget that Spider-man has got a decently acted romantic storyline, which makes it a better date film.
Really, there are just so many reasons, it is silly to draw conclusions without some research.
I think what IIS's game is is a matter of perspective. I think this reviewer defined it as running on Windows. No big deal really, but Apache did suck at this until recently.
As for this being a sucker job on Slashdot... if it had said, "IIS whumps Apache's A**", you can bet that they would have gotten at least as much traffic.
I can speak for the Outlook issue. I plugged my Zaurus into an XP machine, pressed the synch button, and voila.... I had sync. One small problem I *did* identify was that it was easy for the dialogs that the synch program pops up to be "hidden" by other windows that I clicked on after pressing sync.
For the most part, I hate it when reviews focus on problems setting something up on one particular machine. If you try 10 different machines with 10 different configurations, you can maybe make a reasonable estimate of the "plug-and-play" nature of a device, but if you give me ANY device out there, I can setup a machine for you which will not be able to easily use said device. Having a problem with one configuration doesn't really give you enough information to provide useful feedback for review.
That being said, I think most of his review is pretty decent. My main criticism is that he's writing it from a Palm user's perspective. While admittedly, more of his readers are likely to be Palm users than PocketPC users, I think it's important to recognize that the Zaurus doesn't really compete in the same market space as Palm. Sharp calls it a "Personal Mobile Tool" as opposed to PDA, and while that's partially just marketing spin, I think it's actually a valid point. As a PDA, the Zaurus sucks for basically all the reasons that he identified. As a competitor to PocketPC, I think it's much more interesting.
I wish when he described the "complexity" of the user interface, he specifically compared it to the Palm interface. I think it'd be hard to argue that the Zaurus interface is more complex than a PocketPC interface. He is right that the keyboard is a tad awkward because it's recessed, but frankly I have yet to see a better scheme. He also fails to mention that while the unit is bulky, if you actually want to use a CF card (say for a wireless interface), then it's much more compact than an iPAQ with sleeve. He probably has never used an iPAQ, or if he has, never wanted anything more than the basic functionality that comes with it, and for that reason, never discovered this issue with iPAQ sleeves.
His criticism about the lack of software is also quite valid, although he perhaps isn't aware of the large Linux and Qt code bases that can be leveraged to port software to the Zaurus, and the fact that Sharp has done a pretty good job of seeding the developer community to move things along. Certainly, when the first WinCE device came out (or for that matter the first Palm device), there wasn't exactly a ton of software out there. So, if you're thinking of buying one today and having a bevy of software out there, then this is certainly a problem, but if you are either waiting to buy until later, or willing to be optimistic, then there is good reason to believe that the software problem won't last for long.
The M-1 tank uses the Firebird database apparently. The military really liked the near-instant recovery from power failure (apparently the M-1 tank loses it's power every time it shoots it's main gun).
Do the following search and replace in this article:
s/C#/Java/
s/unsafe/native/
And it still is true. Java has it's own "native" methods, which have all the same problems that C#'s unsafe methods have. In C#'s case it's a bit easier to work with because you don't have to change languages, (Java native methods can't be written in Java).
For starters, I wasn't questioning your experience as a programmer, I was questioning your experience building these types of solutions. MMORPG's introduce a whole slew of design issues which most programmers have little or no exposure to. Honestly, I think from what you've said before, and what you're saying in this post, you haven't had much exposure to these problems.
The key part of what's being done here isn't about language features. Microsoft most definitely is not doing anything new with C#, but they are building a new VM, a new library, a new compiler, etc. There's a lot of places for bugs to creap in. But it's even more than that. C# has no infrastructure. That's why I was recommending J2EE rather than Java. J2EE allows you to easily and efficiently add machine's to the system.
Take a look at J2EE again. It's not nearly as clunky as you may think. For starers, the current state of the art CMP technology is actually significantly faster than what traditional O/R tools are capable of. If you're really concerned about persistance performance, look at various OODB-caching products that plug in to J2EE's persistence container (Gemstone and Versant come to mind). But really, the part of J2EE that seems most important to me is messaging. If you build this thing around a messaging model, you're in great shape.
Now, you could build your own, you could use a proprietary messaging product, you could find a proprietary application server, or you could leverage all the other aspects of a J2EE app-server that you're going to need as well (and if you think using BMP means you effectively don't get any benefit from J2EE, then I think this is one example of how you don't know that much about what's needed to build this kind of solution).
This same thing happened last year... Some guy wrote a piece claiming similar things, and making the same mistake: adding up all the bug entries against all the distributions, so that many bugs were counted several times over (and somehow not adding up Windows 9x bugs with Windows NT bugs..... ). When will people learn.
Really, writing something as sophisticated as this with a new language which neither you nor it's developers completely understand yet is a really, really bad idea. I wouldn't use C# for any major production project yet. It's not ready for it.
If you have no prior experience writing this kind of application, I'd recommend using somekind of a framework to provide you the basics. This will save you the roughly 1 billion design mistakes you are likely to make. If you were experienced with this kind of thing, I'd give you different advice. But for your first run it'd be a smart idea to learn a decent design that someone else has already done.
You could look at a few open source projects which are doing this thing. If you don't like any of them, the other thing I'd suggest is using a J2EE solution. What you're describing sounds like a good fit for a JMS-based solution, particularly using message-driven beans. The nice thing with a J2EE solution is you have a proven framework to work within that can provide you with the scalability, availability, and reliability that you need.
I'm not against reinventing the wheel, but it's best if you have some experience before you do that, otherwise you'll end up with a triangular shaped rock.;-)
Solaris x86 is, for the most part, Solaris Sparc + some device drivers and a microkernel that are x86 specific. So, releasing just the x86 components of Solaris might not achieve too much.
Sun seems to have a lot of credibility problems with the open source community. Moves like SCSL, Jini, and limited support for SparcLinux have all lead to a mixed view of Sun. In some ways, I think the reason for this is that Sun didn't drink the open source "Kool Aid".
So my questions are: do you encounter these credibility problems? Are they a problem for you? Are you (or Sun) doing anything to change these perceptions?
Tradtionally, UMA is a huge performance issue because all the components are accessing memory over the same, narrow bus. However, Xbox uses AMD's HyperTransport bus, which effectively provides a dedicated channel for each device on the bus (in the Xbox's case I believe just the CPU and GPU are on the bus).
Correct me if I'm wrong, but I believe the frequency band used by 802.11a is also unlicensed. The only difference is that there aren't a lot of devices out there using it, as compared to 2.4GHz.
The issue of keeping the network protocol consistent on multiple platforms is BS. That being said there are still lots of issues.
The truth of the matter is that no matter how rich your protocol, you still have only a small portion of your code, on both the client and the server, dedicated to the protocol. It is entirely possible to have this part of the code isolated from the rest of the code, and for it to be completely platform independant. It's also possible to allow for updates to the protocol code independant of the rest of the code.
Most well implemented protocols have built in support for handling multiple versions of the protocol simultaneously (typically implemented through some form of extension mechanism or flat out versioning). I've worked on projects using extremely complex binary protocols which make games like Sims Online seem pathetic. It can be done.
The real reality is that most game houses have not yet developed this expertise, nor are they likely to in the near future. Furthermore, even if they DID develop this expertise, heck even if it cost them ZERO $'s to develop on an additional platform, it still doesn't make economic sense. Why? Because no matter how hard you try, each new platform dramatically adds to the support costs for the product. You now have to support a whole new set of OS bugs, train your tech support people on how to support a new platform, etc.
As everyone in the open source world knows, support costs are the real costs of software development. Until your userbase grows large enough outweigh the support costs, well, you won't get a lot of commercial software. So be it.
Slashdot Mirror
Fuck, this is my problem, and my warrantee is wearing out. Ugh! Someone has got to go after them with some kind of a class action.
Dude. I have the exact same problem with the same machine. I've already sent it in once to be completely rebuilt. The hinges on these things were NOT designed to handle these huge honking screens. Every tech I've talked to has said that these laptops are the most troublesome of all the models Dell has made. Get the thing repaired quickly though, 'cause if you don't the damage will just keep spreading.
I thought it was possible to avoid significant problems with priority inversion by using a probabilistic scheduler... like BeOS?
Actually, many Smalltalk version control systems (such as Envy) are entirely tied to the programming language/dev environment. Take a look at Visual Age, as it's version control mechanisms are very Envy-ish.
Personally, I've found this to be less of an advantage than one might think. In general, it's good enough to work with files, and it's more flexible (particularly for cross-language development). If you have change sets, and if your language already supports some idea of seperation of components (for example Smalltalk allows you to seperate out the code for a method from the rest of the object), then you're fine.
Yeah, but the deal is the airwaves are owned by the public, and licensees of said airwaves should be serving the public good. If you take the radio stations out of the equation, then who the hell cares. However, they are very much part of the equation.
....is that there are so many to choose from. ;-)
Umm... There are like a million things that impact a movies' success in the first few weeks. I think it's rather hasty to select reasons that suit one's own agenda, and then provide no research/evidence to back one's argument's up.
Spider-man opened on a hell of a lot more screens, for starters. Interestingly, the Spider-man brand is actually *older* than the Star Wars brand, so it is entirely possible that it's actually getting more older viewers than Star Wars, rather than Katz's statement that a new, younger generation has chosen Spider-man. Let's also not forget that Spider-man has got a decently acted romantic storyline, which makes it a better date film.
Really, there are just so many reasons, it is silly to draw conclusions without some research.
See, now I read the title, and I thought the article would be a recycling program for Palm Pilots. ;-)
I think what IIS's game is is a matter of perspective. I think this reviewer defined it as running on Windows. No big deal really, but Apache did suck at this until recently.
As for this being a sucker job on Slashdot... if it had said, "IIS whumps Apache's A**", you can bet that they would have gotten at least as much traffic.
I can speak for the Outlook issue. I plugged my Zaurus into an XP machine, pressed the synch button, and voila.... I had sync. One small problem I *did* identify was that it was easy for the dialogs that the synch program pops up to be "hidden" by other windows that I clicked on after pressing sync.
For the most part, I hate it when reviews focus on problems setting something up on one particular machine. If you try 10 different machines with 10 different configurations, you can maybe make a reasonable estimate of the "plug-and-play" nature of a device, but if you give me ANY device out there, I can setup a machine for you which will not be able to easily use said device. Having a problem with one configuration doesn't really give you enough information to provide useful feedback for review.
That being said, I think most of his review is pretty decent. My main criticism is that he's writing it from a Palm user's perspective. While admittedly, more of his readers are likely to be Palm users than PocketPC users, I think it's important to recognize that the Zaurus doesn't really compete in the same market space as Palm. Sharp calls it a "Personal Mobile Tool" as opposed to PDA, and while that's partially just marketing spin, I think it's actually a valid point. As a PDA, the Zaurus sucks for basically all the reasons that he identified. As a competitor to PocketPC, I think it's much more interesting.
I wish when he described the "complexity" of the user interface, he specifically compared it to the Palm interface. I think it'd be hard to argue that the Zaurus interface is more complex than a PocketPC interface. He is right that the keyboard is a tad awkward because it's recessed, but frankly I have yet to see a better scheme. He also fails to mention that while the unit is bulky, if you actually want to use a CF card (say for a wireless interface), then it's much more compact than an iPAQ with sleeve. He probably has never used an iPAQ, or if he has, never wanted anything more than the basic functionality that comes with it, and for that reason, never discovered this issue with iPAQ sleeves.
His criticism about the lack of software is also quite valid, although he perhaps isn't aware of the large Linux and Qt code bases that can be leveraged to port software to the Zaurus, and the fact that Sharp has done a pretty good job of seeding the developer community to move things along. Certainly, when the first WinCE device came out (or for that matter the first Palm device), there wasn't exactly a ton of software out there. So, if you're thinking of buying one today and having a bevy of software out there, then this is certainly a problem, but if you are either waiting to buy until later, or willing to be optimistic, then there is good reason to believe that the software problem won't last for long.
Dammit.. I'm sorry bad linking. References to it's use can be found here and here.
Sigh. Unfortunately a simple Google keyword search doesn't prove much one way or another. Please read this link particlarly the bottom part.
The M-1 tank uses the Firebird database apparently. The military really liked the near-instant recovery from power failure (apparently the M-1 tank loses it's power every time it shoots it's main gun).
Actually Dan Kegel wrote up a very detailed commentary, and he is nothing close to a lawyer.
Do the following search and replace in this article:
s/C#/Java/
s/unsafe/native/
And it still is true. Java has it's own "native" methods, which have all the same problems that C#'s unsafe methods have. In C#'s case it's a bit easier to work with because you don't have to change languages, (Java native methods can't be written in Java).
Man, I hope someone calls Joy on his hypocracy.
For starters, I wasn't questioning your experience as a programmer, I was questioning your experience building these types of solutions. MMORPG's introduce a whole slew of design issues which most programmers have little or no exposure to. Honestly, I think from what you've said before, and what you're saying in this post, you haven't had much exposure to these problems.
The key part of what's being done here isn't about language features. Microsoft most definitely is not doing anything new with C#, but they are building a new VM, a new library, a new compiler, etc. There's a lot of places for bugs to creap in. But it's even more than that. C# has no infrastructure. That's why I was recommending J2EE rather than Java. J2EE allows you to easily and efficiently add machine's to the system.
Take a look at J2EE again. It's not nearly as clunky as you may think. For starers, the current state of the art CMP technology is actually significantly faster than what traditional O/R tools are capable of. If you're really concerned about persistance performance, look at various OODB-caching products that plug in to J2EE's persistence container (Gemstone and Versant come to mind). But really, the part of J2EE that seems most important to me is messaging. If you build this thing around a messaging model, you're in great shape.
Now, you could build your own, you could use a proprietary messaging product, you could find a proprietary application server, or you could leverage all the other aspects of a J2EE app-server that you're going to need as well (and if you think using BMP means you effectively don't get any benefit from J2EE, then I think this is one example of how you don't know that much about what's needed to build this kind of solution).
This same thing happened last year... Some guy wrote a piece claiming similar things, and making the same mistake: adding up all the bug entries against all the distributions, so that many bugs were counted several times over (and somehow not adding up Windows 9x bugs with Windows NT bugs..... ). When will people learn.
Really, writing something as sophisticated as this with a new language which neither you nor it's developers completely understand yet is a really, really bad idea. I wouldn't use C# for any major production project yet. It's not ready for it.
;-)
If you have no prior experience writing this kind of application, I'd recommend using somekind of a framework to provide you the basics. This will save you the roughly 1 billion design mistakes you are likely to make. If you were experienced with this kind of thing, I'd give you different advice. But for your first run it'd be a smart idea to learn a decent design that someone else has already done.
You could look at a few open source projects which are doing this thing. If you don't like any of them, the other thing I'd suggest is using a J2EE solution. What you're describing sounds like a good fit for a JMS-based solution, particularly using message-driven beans. The nice thing with a J2EE solution is you have a proven framework to work within that can provide you with the scalability, availability, and reliability that you need.
I'm not against reinventing the wheel, but it's best if you have some experience before you do that, otherwise you'll end up with a triangular shaped rock.
Solaris x86 is, for the most part, Solaris Sparc + some device drivers and a microkernel that are x86 specific. So, releasing just the x86 components of Solaris might not achieve too much.
Sun seems to have a lot of credibility problems with the open source community. Moves like SCSL, Jini, and limited support for SparcLinux have all lead to a mixed view of Sun. In some ways, I think the reason for this is that Sun didn't drink the open source "Kool Aid".
So my questions are: do you encounter these credibility problems? Are they a problem for you? Are you (or Sun) doing anything to change these perceptions?
Tradtionally, UMA is a huge performance issue because all the components are accessing memory over the same, narrow bus. However, Xbox uses AMD's HyperTransport bus, which effectively provides a dedicated channel for each device on the bus (in the Xbox's case I believe just the CPU and GPU are on the bus).
Correct me if I'm wrong, but I believe the frequency band used by 802.11a is also unlicensed. The only difference is that there aren't a lot of devices out there using it, as compared to 2.4GHz.
The issue of keeping the network protocol consistent on multiple platforms is BS. That being said there are still lots of issues.
The truth of the matter is that no matter how rich your protocol, you still have only a small portion of your code, on both the client and the server, dedicated to the protocol. It is entirely possible to have this part of the code isolated from the rest of the code, and for it to be completely platform independant. It's also possible to allow for updates to the protocol code independant of the rest of the code.
Most well implemented protocols have built in support for handling multiple versions of the protocol simultaneously (typically implemented through some form of extension mechanism or flat out versioning). I've worked on projects using extremely complex binary protocols which make games like Sims Online seem pathetic. It can be done.
The real reality is that most game houses have not yet developed this expertise, nor are they likely to in the near future. Furthermore, even if they DID develop this expertise, heck even if it cost them ZERO $'s to develop on an additional platform, it still doesn't make economic sense. Why? Because no matter how hard you try, each new platform dramatically adds to the support costs for the product. You now have to support a whole new set of OS bugs, train your tech support people on how to support a new platform, etc.
As everyone in the open source world knows, support costs are the real costs of software development. Until your userbase grows large enough outweigh the support costs, well, you won't get a lot of commercial software. So be it.
....I guess that answers any question as to it's stability!