This isn't so far from the truth. My grandson recently was given for his birthday the game that was released with the recent Star Wars movie. After initial trouble installing it (it didn't like his video drivers or something), he probably played it for about an hour before he had enough of it.
He told me about it the last time I saw him. I believe his quote was, "Gramps, this game fucking sucks." He's not one to swear much, so I knew he was truly disappointed. I suggested we play a good old game of Monopoly, and so we did. And you know what? He had fun. He improved his math skills, too.
Indeed. A game like Goldeneye is truly a masterpiece. It drew from the best of both the gaming and movie worlds. You get the rock-solid story of the 007 movie, and combine it with the fantastically original and playable Goldeneye gaming engine.
I would hardly call Tim Burton a cinematic genius. Look at the tripe he has directed recently: Charlie and the Chocolate Factory. I would hardly call that innovative. Besides the fact that it is based on a book that is decades old, and already cinematically done decades ago as well, it just isn't creative in any way. All he did was look next door to Michael Jackson's boy ranch for inspiration. Hell, he even used the persona and image of Michael Jackson for the character of Willy Wonka! Sorry, but anyone who uses Michael Jackson as a source of inspiration isn't a "genius".
Indeed, they're experiencing what may be a significant problem with American-style capitalism. There is no place for innovation (due to the risk of not making immediate profit) in Big Business American-style capitalism. That's clearly displayed in the vast selection of sequals and triquels Hollywood puts out today. But the unwillingness of the Big Boys of Hollywood to truly innovate (ie. produce new movies) actually decreases quality, and thus purchases. Their revenue, and thus profits, decrease.
Now, in true capitalism these businesses would either exit the market or would fold. Profits are the potential benefit of risk. Profits are not to be expected in a true capitalistic marketplace, but are the reward for those who successfully innovate and make a worthwhile contribution to the market. But that is not how American-style Big Business capitalism works. Profits are treated as a right, regardless of the products that the firms produce. It is that socialistic-corporate view of profits as a God-given right that is giving us these shitty movies year after year.
But that's the same with everything. There is just a lot of shit out there, regardless of the item in question. You have a gem like Ruby on Rails, but you have far more utter crap like ASP, ColdFusion, and PHP. It's the same with movies and TV shows. For every good show or movie there are tens of shittier shows/movies.
What exactly is a "triple A" title? Is that marketing speak for all those shitty movie-themed games released at the same time as movies? The ones that places like GameSpot and GameFAQs overhype just because they're being paid to provide such hype?
Would a person in a high-gravity situation (relative to earth's gravity) gain far more bone mass? Perhaps in the future days of commercial space travel we will see professional athletes going on sabbaticals to space stations around Jupiter to take advantage of the increased gravity. When they come back to earth with higher bone mass they could then proceed to gain more muscle mass when working out, in order to gain an edge over their competition.
You are a hit at parties. That's because you get piss drunk after your first beer, you pull down your pants, and then proceed to urinate on pets and sofas.
I'm well aware of those links. Those are the first that anyone searching for information on embedding Gecko would find. Like I said earlier, they're outdated or just plain incomplete.
Take the first link, for example. There is missing information for a number of interfaces at the bottom of the page. Look at your second link. It specifically states at the bottom of the page, "Last modified August 20, 2002". The third link lists the frozen interfaces as of "August 28, 2002". We are in August of 2005, just about three years after the final modifications to those documents.
While there are useful bits in those documents, they tell me very little about what has changed since then. Are any of those interfaces deprecated now? Which newer ones may take the place of deprecated ones? What changes have been made to the non-frozen interfaces since then?
Commercial developers have deadlines. We can't be bothered to waste time trying to sync between three-year-old documentation and today's source code. Examples are excellent provided that they convey useful information in a quick and efficient fashion. Unfortunately, the Mozilla examples fail to do that.
Maybe those developing in a university setting have the luxury of spending time tinkering with examples. Developers in the real world need clear, current information so we can properly design and build the systems that clients want NOW. Those systems must function, and they must function well. Outdated design docs and half assed examples only hinder real-world development.
Indeed, I believe we have been having very similar experiences. Perhaps the worst part is the documentation that was correct in 2002, but today is outdated and thus misleading.
If the Mozilla developers themselves cannot offer such documentation because they're busy with their development tasks as well, then perhaps a company such as IBM could step forward to provide such documentation.
Indeed, that would have been my first choice. I'm quite fond of Konqueror, and KHTML. But unfortunately the project I'm assigned to requires cross platform support.
While I've heard of efforts like KHTML for Win32, they don't seem usable enough yet or lack the continued momentum that we require. WebCore might be an option under OS X, but we'd prefer one solution for all platforms. Mozilla theoretically provides this.
The high code, documentation and comment quality of the KDE KHTML part merged with the development impetus of Gecko/Mozilla would be fantastic.
Yes, I'm well aware of the examples. That is what I've been using so far.
But now read from my previous post: While the various embedding examples are a start, they are very poorly commented and as such are quite useless.
They're better than nothing, but they're still not enough. Myself and many other developers don't have time to sift through numerous examples for platforms we are not necessarily experienced with. Maybe an unemployed university student has time to play with such examples that lack documentation. Professional developers do not.
Like I mentioned before, the examples need to be very well commented, and must be accompanied by up-to-date and usable design docs. Sure, that takes effort, but it is the key to widespread adoption of Gecko.
While this doesn't necessary concern Firefox itself, I would like to comment on embedding Gecko. For the past week or so I have been attempting to embed Gecko into a proprietary C++ graphical user interface toolkit. So far I have found it quite difficult.
The existing documentation is either extremely out of date (ie. 2002 or earlier), or partially complete. Some of the documentation contains old names for various XPCOM interfaces. While the various embedding examples are a start, they are very poorly commented and as such are quite useless.
Now, I realize that Gecko is a very complex piece of software, but in order for it to become widely accepted there needs to be many pieces of software which use it. But as of this time it is quite difficult for a developer to quickly embed Gecko within an existing application. That may very well be because there is a complete lack of documentation describing how to do so.
The path to more users is more products. The path to more products is easier development. And easier development is often due to accessible, correct and descriptive documentation. So please, if there is someone reading this who has the knowledge and resources, write us developers a decent guide on embedding Gecko.
While this doesn't necessary concern the widespread adoption of Firefox, I would like to comment on embedding Gecko. For the past week or so I have been attempting to embed Gecko into a proprietary C++ graphical user interface toolkit. So far I have found it quite difficult.
The existing documentation is either extremely out of date (ie. 2002 or earlier), or partially complete. Some of the documentation contains old names for various XPCOM interfaces. While the various embedding examples are a start, they are very poorly commented and as such are quite useless.
Now, I realize that Gecko is a very complex piece of software, but in order for it to become widely accepted there needs to be many pieces of software which use it. But as of this time it is quite difficult for a developer to quickly embed Gecko within an existing application. That may very well be because there is a complete lack of documentation describing how to do so.
The path to more users is more products. The path to more products is easier development. And easier development is often due to accessible, correct and descriptive documentation. So please, if there is someone reading this who has the knowledge, write us developers a decent guide on embedding Gecko.
Now, I have been contemplating the use of PHP5 for various webapps, but after reading that I am unsure about whether or not I should use it. Mind you I do not want to invest large sums of money into an accelerator, which appears to be necessary if reasonable server memory usage is a goal.
Does PHP5 indeed suffer from excessive memory consumption, and if so, can it be easily remedied? Considering I have a low-end server hosting several fairly busy personal sites, minimal memory usage is extremely important.
You should be thankful that this site isn't like the forums at GameFAQs.com. While the moderation system here isn't perfect, at least it doesn't take censorship to the GameFAQs forums extreme. At least here you can view every post that has been made, unlike at GameFAQs, where any post that the moderators dislike is permanently removed.
I'd take the semi-democratic method of moderation used here over the dictatorial, elitist system used at a place like GameFAQs any day.
While your post may be moderated down, at least others will still be able to read it months and years from now. Unlike at GameFAQs, where it would probably be long gone already, inaccessible to all, forever.
Re:PHP's effect on Linux's reputation.
on
Spring Into PHP 5
·
· Score: 1
Indeed, I'd welcome any effort to improve the security of languages such as C, Perl and assembly. Such efforts have been made (ie. Cyclone in the case of C).
One part of this issue is that PHP's main use is in a hostile environment (the World Wide Web). That's a well known fact. But the truth of the matter is that it just doesn't live up to the security necessary for operating in such an environment. That is a flaw with PHP itself. Worse off, due to various social reasons, PHP is often associated with Linux by non-technical users. So when a PHP script (not even PHP itself) misbehaves and is exploited, it tains the image of Linux quite badly.
It's no secret that many of the users of PHP are amateurs. That is why the PHP crew needs to get their act together, and develop features into PHP to limit the damage that can be done by exploited scripts.
Just as companies like AMD and Intel are starting to implement measures in their CPUs to prevent the execution of code after a stack overflow, it is time for the PHP developers to start doing the same. Not just for the sake of providing a secure, quality product, but also for the sake of the reputation of Linux.
This problem requires two solutions.
on
Spring Into PHP 5
·
· Score: 1
That's what I'm saying. Of course PHP isn't Linux. But most people, including the managers who are the ones making the final decisions regarding the use of Linux in enterprise or business settings, don't know that. They've come to think of the flaws in PHP scripts as being flaws in Linux.
This is both a social and a technical problem. You have to fix PHP so it is difficult, if not almost completely impossible, for amateurs to write scripts that can be exploited. Likewise, PHP and Linux shouldn't be linked as often by Linux advocates. The only way to fix this is to deal with all aspects of the problem.
It is too bad that they do not come right out and state whether or not they have legal access to the source code of the product they're selling, assuming they could even legally say that. It would put a lot of minds at ease to know that software from them is legitimate, and can be used without running into legal problems.
Mrs. OSNews: Can you expand on your statement? Were these hardware incompatibilities? An inability to run existing BeOS applications? What about the bugs? Were they with the core utilities, or with the kernel, or with the drivers, or what?
"No, Zeta is NOT as stable as Linux,OSX or Windows or BSD, but it is WAAAAAYYYY stabler and more functional than Haiku that moves like a snail in its development targets."
How exactly are you measuring the stability of Zeta versus the other operating systems you mentioned? I used BeOS for years, and never ran into any sort of stability problems with it.
Now, I have not used Zeta, so I cannot comment on its current state, but considering it is based on the very solid BeOS, I can only imagine that it is fairly solid as well.
Slashdot Mirror
"Game Player: Scrabble anyone?"
This isn't so far from the truth. My grandson recently was given for his birthday the game that was released with the recent Star Wars movie. After initial trouble installing it (it didn't like his video drivers or something), he probably played it for about an hour before he had enough of it.
He told me about it the last time I saw him. I believe his quote was, "Gramps, this game fucking sucks." He's not one to swear much, so I knew he was truly disappointed. I suggested we play a good old game of Monopoly, and so we did. And you know what? He had fun. He improved his math skills, too.
Indeed. A game like Goldeneye is truly a masterpiece. It drew from the best of both the gaming and movie worlds. You get the rock-solid story of the 007 movie, and combine it with the fantastically original and playable Goldeneye gaming engine.
I would hardly call Tim Burton a cinematic genius. Look at the tripe he has directed recently: Charlie and the Chocolate Factory. I would hardly call that innovative. Besides the fact that it is based on a book that is decades old, and already cinematically done decades ago as well, it just isn't creative in any way. All he did was look next door to Michael Jackson's boy ranch for inspiration. Hell, he even used the persona and image of Michael Jackson for the character of Willy Wonka! Sorry, but anyone who uses Michael Jackson as a source of inspiration isn't a "genius".
Indeed, they're experiencing what may be a significant problem with American-style capitalism. There is no place for innovation (due to the risk of not making immediate profit) in Big Business American-style capitalism. That's clearly displayed in the vast selection of sequals and triquels Hollywood puts out today. But the unwillingness of the Big Boys of Hollywood to truly innovate (ie. produce new movies) actually decreases quality, and thus purchases. Their revenue, and thus profits, decrease.
Now, in true capitalism these businesses would either exit the market or would fold. Profits are the potential benefit of risk. Profits are not to be expected in a true capitalistic marketplace, but are the reward for those who successfully innovate and make a worthwhile contribution to the market. But that is not how American-style Big Business capitalism works. Profits are treated as a right, regardless of the products that the firms produce. It is that socialistic-corporate view of profits as a God-given right that is giving us these shitty movies year after year.
But that's the same with everything. There is just a lot of shit out there, regardless of the item in question. You have a gem like Ruby on Rails, but you have far more utter crap like ASP, ColdFusion, and PHP. It's the same with movies and TV shows. For every good show or movie there are tens of shittier shows/movies.
What exactly is a "triple A" title? Is that marketing speak for all those shitty movie-themed games released at the same time as movies? The ones that places like GameSpot and GameFAQs overhype just because they're being paid to provide such hype?
Would a person in a high-gravity situation (relative to earth's gravity) gain far more bone mass? Perhaps in the future days of commercial space travel we will see professional athletes going on sabbaticals to space stations around Jupiter to take advantage of the increased gravity. When they come back to earth with higher bone mass they could then proceed to gain more muscle mass when working out, in order to gain an edge over their competition.
You are a hit at parties. That's because you get piss drunk after your first beer, you pull down your pants, and then proceed to urinate on pets and sofas.
I'm well aware of those links. Those are the first that anyone searching for information on embedding Gecko would find. Like I said earlier, they're outdated or just plain incomplete.
Take the first link, for example. There is missing information for a number of interfaces at the bottom of the page. Look at your second link. It specifically states at the bottom of the page, "Last modified August 20, 2002". The third link lists the frozen interfaces as of "August 28, 2002". We are in August of 2005, just about three years after the final modifications to those documents.
While there are useful bits in those documents, they tell me very little about what has changed since then. Are any of those interfaces deprecated now? Which newer ones may take the place of deprecated ones? What changes have been made to the non-frozen interfaces since then?
Commercial developers have deadlines. We can't be bothered to waste time trying to sync between three-year-old documentation and today's source code. Examples are excellent provided that they convey useful information in a quick and efficient fashion. Unfortunately, the Mozilla examples fail to do that.
Maybe those developing in a university setting have the luxury of spending time tinkering with examples. Developers in the real world need clear, current information so we can properly design and build the systems that clients want NOW. Those systems must function, and they must function well. Outdated design docs and half assed examples only hinder real-world development.
Indeed, I believe we have been having very similar experiences. Perhaps the worst part is the documentation that was correct in 2002, but today is outdated and thus misleading.
i c.mozilla.general/browse_thread/thread/6b4bfc1c8c6 baa4c/
But apparently stuff like this has been a problem since around 1999, per this newsgroup post I ran across:
http://groups-beta.google.com/group/netscape.publ
If the Mozilla developers themselves cannot offer such documentation because they're busy with their development tasks as well, then perhaps a company such as IBM could step forward to provide such documentation.
Indeed, that would have been my first choice. I'm quite fond of Konqueror, and KHTML. But unfortunately the project I'm assigned to requires cross platform support.
While I've heard of efforts like KHTML for Win32, they don't seem usable enough yet or lack the continued momentum that we require. WebCore might be an option under OS X, but we'd prefer one solution for all platforms. Mozilla theoretically provides this.
The high code, documentation and comment quality of the KDE KHTML part merged with the development impetus of Gecko/Mozilla would be fantastic.
Yes, I'm well aware of the examples. That is what I've been using so far.
But now read from my previous post:
While the various embedding examples are a start, they are very poorly commented and as such are quite useless.
They're better than nothing, but they're still not enough. Myself and many other developers don't have time to sift through numerous examples for platforms we are not necessarily experienced with. Maybe an unemployed university student has time to play with such examples that lack documentation. Professional developers do not.
Like I mentioned before, the examples need to be very well commented, and must be accompanied by up-to-date and usable design docs. Sure, that takes effort, but it is the key to widespread adoption of Gecko.
While this doesn't necessary concern Firefox itself, I would like to comment on embedding Gecko. For the past week or so I have been attempting to embed Gecko into a proprietary C++ graphical user interface toolkit. So far I have found it quite difficult.
The existing documentation is either extremely out of date (ie. 2002 or earlier), or partially complete. Some of the documentation contains old names for various XPCOM interfaces. While the various embedding examples are a start, they are very poorly commented and as such are quite useless.
Now, I realize that Gecko is a very complex piece of software, but in order for it to become widely accepted there needs to be many pieces of software which use it. But as of this time it is quite difficult for a developer to quickly embed Gecko within an existing application. That may very well be because there is a complete lack of documentation describing how to do so.
The path to more users is more products. The path to more products is easier development. And easier development is often due to accessible, correct and descriptive documentation. So please, if there is someone reading this who has the knowledge and resources, write us developers a decent guide on embedding Gecko.
While this doesn't necessary concern the widespread adoption of Firefox, I would like to comment on embedding Gecko. For the past week or so I have been attempting to embed Gecko into a proprietary C++ graphical user interface toolkit. So far I have found it quite difficult.
The existing documentation is either extremely out of date (ie. 2002 or earlier), or partially complete. Some of the documentation contains old names for various XPCOM interfaces. While the various embedding examples are a start, they are very poorly commented and as such are quite useless.
Now, I realize that Gecko is a very complex piece of software, but in order for it to become widely accepted there needs to be many pieces of software which use it. But as of this time it is quite difficult for a developer to quickly embed Gecko within an existing application. That may very well be because there is a complete lack of documentation describing how to do so.
The path to more users is more products. The path to more products is easier development. And easier development is often due to accessible, correct and descriptive documentation. So please, if there is someone reading this who has the knowledge, write us developers a decent guide on embedding Gecko.
I read a post a few days back regarding PHP5's supposed excessive use of memory:
c id=13297391
http://books.slashdot.org/comments.pl?sid=158685&
Now, I have been contemplating the use of PHP5 for various webapps, but after reading that I am unsure about whether or not I should use it. Mind you I do not want to invest large sums of money into an accelerator, which appears to be necessary if reasonable server memory usage is a goal.
Does PHP5 indeed suffer from excessive memory consumption, and if so, can it be easily remedied? Considering I have a low-end server hosting several fairly busy personal sites, minimal memory usage is extremely important.
It looks like you fucked that up, Antwon.
Indeed. That describes the situtation at GameFAQs perfectly.
You should be thankful that this site isn't like the forums at GameFAQs.com. While the moderation system here isn't perfect, at least it doesn't take censorship to the GameFAQs forums extreme. At least here you can view every post that has been made, unlike at GameFAQs, where any post that the moderators dislike is permanently removed.
I'd take the semi-democratic method of moderation used here over the dictatorial, elitist system used at a place like GameFAQs any day.
While your post may be moderated down, at least others will still be able to read it months and years from now. Unlike at GameFAQs, where it would probably be long gone already, inaccessible to all, forever.
Indeed, I'd welcome any effort to improve the security of languages such as C, Perl and assembly. Such efforts have been made (ie. Cyclone in the case of C).
One part of this issue is that PHP's main use is in a hostile environment (the World Wide Web). That's a well known fact. But the truth of the matter is that it just doesn't live up to the security necessary for operating in such an environment. That is a flaw with PHP itself. Worse off, due to various social reasons, PHP is often associated with Linux by non-technical users. So when a PHP script (not even PHP itself) misbehaves and is exploited, it tains the image of Linux quite badly.
It's no secret that many of the users of PHP are amateurs. That is why the PHP crew needs to get their act together, and develop features into PHP to limit the damage that can be done by exploited scripts.
Just as companies like AMD and Intel are starting to implement measures in their CPUs to prevent the execution of code after a stack overflow, it is time for the PHP developers to start doing the same. Not just for the sake of providing a secure, quality product, but also for the sake of the reputation of Linux.
That's what I'm saying. Of course PHP isn't Linux. But most people, including the managers who are the ones making the final decisions regarding the use of Linux in enterprise or business settings, don't know that. They've come to think of the flaws in PHP scripts as being flaws in Linux.
This is both a social and a technical problem. You have to fix PHP so it is difficult, if not almost completely impossible, for amateurs to write scripts that can be exploited. Likewise, PHP and Linux shouldn't be linked as often by Linux advocates. The only way to fix this is to deal with all aspects of the problem.
You wouldn't happen to have a link to the article in question, would you?
No, of course not. I just choose to not use Microsoft products.
That's interesting.
It is too bad that they do not come right out and state whether or not they have legal access to the source code of the product they're selling, assuming they could even legally say that. It would put a lot of minds at ease to know that software from them is legitimate, and can be used without running into legal problems.
Mrs. OSNews: Can you expand on your statement? Were these hardware incompatibilities? An inability to run existing BeOS applications? What about the bugs? Were they with the core utilities, or with the kernel, or with the drivers, or what?
"No, Zeta is NOT as stable as Linux,OSX or Windows or BSD, but it is WAAAAAYYYY stabler and more functional than Haiku that moves like a snail in its development targets."
How exactly are you measuring the stability of Zeta versus the other operating systems you mentioned? I used BeOS for years, and never ran into any sort of stability problems with it.
Now, I have not used Zeta, so I cannot comment on its current state, but considering it is based on the very solid BeOS, I can only imagine that it is fairly solid as well.