It's obviously stupid to actually believe that, information doesn't "want" anything. What it actually means is that information tends to gravitate towards wide dissemination. It's commenting on the inevitability for information to become public. We can put effort in to try and stop that, but it's ultimately futile.
Pointing out the flaws of DRM schemes with "information wants to be free" doesn't mean that you necessarily think information should be free, merely that it's the natural state of things.
Ridiculous portrayals of females. Women have breasts. Get over it.
Yeah, because game portrayals of male characters are so lifelike. It's not like their biceps are bigger than all of me curled up in a ball, with veins as thick as my fingers.
Game characters are caricatures. It's not sexist because it's applied to both sexes.
If somebody gives you $70 for something you don't use anymore, then that deal is worth $70 to you. It doesn't matter whether that person goes on to make $5 or $25 when they sell it on, the bottom line is you just made $70.
Seems to me that this is just filtering. While that's still not good, it's a lot more understandable and acceptable than editing what people say. Yet another misleading Slashdot headline, I guess.
Killing other players is OK, but if your character becomes more powerful by doing this, it somehow becomes more harmful.
No, you're still twisting it out of context. This is a blanket ban on killing other players. It doesn't matter whether your player gets more powerful or not, that was merely a short description of the typical scenario.
It's like reading the sentence "Getting drunk, getting into your car and driving home is bad" as specifically saying that driving home when drunk is bad, above and beyond driving anywhere else. You aren't reading it right.
I'm not sure what you're proposing: that only the developers drive the product requirements?
No, simply that you shouldn't take the requirements from the customer on blind faith. I've seen it happen time and time again, and it's incredibly demoralising to see a problem a mile in advance, but be forced to go down that path yet again because "it's what they asked for".
Customers ask for ridiculous things sure, but it's the job of product mangement to determine what's the true need behind the ridiculous request
Agreed, but this is the very foundation of the product, and when it gets fucked up - which is pretty damn common - the whole development process breaks down. It's like sprinting as fast as you can for as long as you can, only to look up and find you've been running in the wrong direction. Do that enough times, and you're simply not going to put the effort into running quite so fast any more.
The only problem is, there was basically nobody that wanted to buy it.
Like I say; don't spend the time to make sure you're building the right thing, and things go pear-shaped.
The reason why this is less of a problem for hobbyists is because they know what they want, and have the knowledge to side-step pitfalls that, generally speaking, customers rush headlong into when laying out their requirements.
not all "amateur-driven" software is guaranteed to be good.
Of course not, and I'd never claim that.
If you're ultimately not making what the customer wants and they're not buying it, you can't justify the payroll for the programmers.
Agreed 100% and is actually one of the points I was trying to get across (not very clearly).
So we have some people saying that there are DRM chips in the x86 macs, and some people saying that there aren't DRM chips in the x86 macs... did it ever occur to anybody that Apple might be shipping different configurations to different people? It makes sense that they'd try a few different things out before release.
I'm reading that acts of violence in video games are marginally OK (because it's OK to kill NPC's), but spending too much time trying to increase the power of a character is what pushes the issue over the edge. Am I missing something huge here?
Yeah, you left off the most important part of the quote:
...that allow players to increase the power of their own online game characters by killing other players
It's not the fact that they are increasing the power of their characters that is the issue, it's that they are doing it by killing something that represents an actual person playing the game.
I don't really see a big deal in that, it's only pixels, but I have to admit, it makes a lot more sense to ban pixellated violence than pixellated sex.
Customers often times have no clue as to what they need (and therefore the requirements that the design and implementation flow from are flawed/wrong) and this can caues issues. However, this has less of an effect on whether or not the code is "up to scratch".
Perhaps you misunderstand me. I'm not saying that bad requirements directly cause bad code. I'm saying that programmers who know they are building the wrong thing are going to find it difficult to care enough to create high-quality code.
The first reason is that many, many businesses are focused on building what the customers ask for. Clue number one: customers know fuck all about building software. If they were remotely clued in, they wouldn't need to ask somebody else to build it, would they?
So customers ask for stupid things. That's what makes them customers. The problem arises when the business doesn't care that it's stupid, but builds it for them anyway. Now you have a suboptimal solution that cost lots of money.
Compare this with the amateurs. They are building it for themselves, so they are qualified on both the problem domain and the software construction. They aren't going to build something stupid because they are going to be the ones using it.
Then there's the morale. The professionals are fully aware that what they are building is stupid. It's demoralising. They offer sensible solutions instead, but get knocked back with "it's not what the customer asked for". They begin to understand that their job isn't to build good software, it's to spend their time programming, and if the result is somewhat functional when they reach the deadline, that's just a bonus. It's not surprising that they don't really give a shit whether the code is up to scratch or not, because the whole exercise is pointless beyond collecting a paycheck.
Again, compare with the amateurs. They get satisfaction not only from using the software they wrote (being both users and developers simultaneously), but they get the satisfaction from finding that others appreciate it too. They know they've solved a problem well, and they take pride in their work. People who take pride in their work generally put in more effort.
If there's anything that businesses can learn from this, it's that they need to be able to say no to customers. To put off deadlines. To say "You know what? This is solving the wrong problem!" and go back to the drawing board with the customers to figure out a better approach. It's only when the professional programmers see that they are actually doing something productive that they'll feel motivated enough to take pride in their work, and feel like they are in an environment where they can contribute actual solutions instead of banging their head against a brick wall.
There were certain tags and technologies that (arguably) needed to be made or developed that netscape had to do
Element types. Not "tags".
but there were also W3C standards that Netscape blatantly ignored. For example the CSS standard was made prior to Netscape 4, but Netscape had notoriously poor support for it, while IE had CSS support (albeit very limited) back in version 3.
Get your facts straight. At the time Microsoft were implementing CSS, it wasn't a published W3C recommendation. And Netscape submitted their own stylesheet language, JSSS to the W3C too. Unfortunately for Netscape, the W3C rejected JSSS and published CSS as a recommendation. Netscape was left scrambling to support CSS at the last minute, and did it by transforming CSS to JSSS on the fly, which was understandably limited.
The kicker was that one of the reasons the W3C rejected JSSS was because it violated the Principle of Least Power, while CSS didn't. Once Netscape were out of the way, Microsoft went ahead and added their own proprietary extensions to CSS that also violated the principle of least power.
So, while Netscape do have a history of ignoring the W3C, they certainly tried to work with them in this instance, only to get steamrollered by Microsoft who saw it as an opportunity to get a lead over Netscape in the browser wars.
Agreed. The thing that annoys me is that my PS2 has a perfectly good USB port that you can plug flash disks into, and yet it won't let me save anything on them.
I cannot even imagine try to to explain to my grandmother how to "right-click" without her being able to SEE the right button.
The whole reason Apple has stayed with the one-button mouse for so long is because grandmas don't right-click. Why would you be explaining this to her?
The default setting for this mouse is to register a click anywhere on the mouse as a left click. This is exactly the same as the one button mouse Apple have shipped for the past umpteen years.
The value in this mouse is that it caters to the grandmas, while the advanced users who always whine about Apple not shipping a multi-button mouse can reconfigure it to suit their needs better. If you want a one-button mouse, that's what it is. If you want a multi-button mouse, then just change the settings. It's the best of both worlds.
So if the TaskBar display the currently running programs in Windows, you can't click on a shortcut in the Quick Launch toolbar to launch a new application?
The address bar is not similar to the taskbar and quick launch toolbar at all. The quick launch toolbar is context-free; it doesn't display information on the current application and doesn't change status when you switch to another application.
The address bar, on the other hand, is directly linked to the current tab - when you perform an operation on the current tab, the address bar changes, and when you perform an operation on the address bar, the current tab changes, but no others do. There's a 1:1 correspondence between the address bar and the current tab. You simply can't say the same thing about the quick launch toolbar. The only way in which they are remotely similar is that you can click stuff.
Again, been doing usability for a long time
What's your point? That you can't possibly be wrong?
So, IE7 Beta 1 really IS IE6 with tabbed browsing?
Basically, yes.
Is it me, or is that actually an alpha?
No, lots of people have pointed out the same thing. 'Beta' in normal usage, is generally feature-complete.
Its been 3 years.
Actually, it's been four years (well, over three years and eleven months).
Re:"Graceful Degradation" = Don't Use It.
on
DHTML Utopia
·
· Score: 1
The sign up app could also do it in less than 1K per request if it asked for the user name first, by itself, on a page without a lot of other crap on it.
No, it couldn't. A typical HTTP request/response without an entity body is around 1K. That's before you've even begun to send any HTML.
An XMLHttpRequest approach, on the other hand, can signal when a username is already taken with a 409 response, so there isn't any need for an entity body at all.
So unless you've found some magical way of sending HTML without using any bandwidth, the traditional approach can't beat the XMLHttpRequest approach.
I was a web developer for 7 years and sure, maybe it took a little more effort to get things to work right in IE. But that's the reality of the world. Personally I think it's more annoying having to put a font tag inside every single table column to satisfy Netscape's misunderstanding of tables.
You were a web developer for seven years, and you don't understand the difference between block element types and inline element types? <table> elements can't be children of <font> elements. Netscape did the right thing, there's no "misunderstanding of tables" there.
You're referring to the host objects provided by the implementation, not the implementation itself. The majority of host objects have been formalised in the DOM specifications.
Yeah, there have been proprietary host objects added over the years, but generally they have been supplanted with the DOM - the last browser you needed to use document.all with was Internet Explorer 4.0, newer versions support document.getElementById and the only browser you needed to use document.layers with was Netscape 4, newer versions support changing CSS dynamically.
Right now, Microsoft is planning on releasing an Internet Explorer 7 that has the majority of the real bastard bugs and missing features in CSS eliminated. This will probably ship before Vista, so there'll probably be a subsequent release of Internet Explorer (e.g. 7.5) to go with it. This version can be the focus for the Acid test or whatever.
Suppose this boycott is effective. Microsoft will delay Internet Explorer 7 until they fix up the rest of it - stuff that's certainly nice to have, but in no way compares to the stuff they've already fixed. That will probably delay it enough to ship Internet Explorer 7 with Vista.
Not only will a successful boycott delay the release of Internet Explorer 7 for months (prolonging the frustrations of web developers for months too), but it makes it less likely that there'll be a quick turnaround for the next version.
Right now, we know that the really important bits are fixed in their current codebase. We should want them to release this as soon as possible, rather than making them delay it for less important stuff.
Slashdot Mirror
It's obviously stupid to actually believe that, information doesn't "want" anything. What it actually means is that information tends to gravitate towards wide dissemination. It's commenting on the inevitability for information to become public. We can put effort in to try and stop that, but it's ultimately futile.
Pointing out the flaws of DRM schemes with "information wants to be free" doesn't mean that you necessarily think information should be free, merely that it's the natural state of things.
Ridiculous portrayals of females. Women have breasts. Get over it.
Yeah, because game portrayals of male characters are so lifelike. It's not like their biceps are bigger than all of me curled up in a ball, with veins as thick as my fingers.
Game characters are caricatures. It's not sexist because it's applied to both sexes.
If somebody gives you $70 for something you don't use anymore, then that deal is worth $70 to you. It doesn't matter whether that person goes on to make $5 or $25 when they sell it on, the bottom line is you just made $70.
Seems to me that this is just filtering. While that's still not good, it's a lot more understandable and acceptable than editing what people say. Yet another misleading Slashdot headline, I guess.
Killing other players is OK, but if your character becomes more powerful by doing this, it somehow becomes more harmful.
No, you're still twisting it out of context. This is a blanket ban on killing other players. It doesn't matter whether your player gets more powerful or not, that was merely a short description of the typical scenario.
It's like reading the sentence "Getting drunk, getting into your car and driving home is bad" as specifically saying that driving home when drunk is bad, above and beyond driving anywhere else. You aren't reading it right.
I'm not sure what you're proposing: that only the developers drive the product requirements?
No, simply that you shouldn't take the requirements from the customer on blind faith. I've seen it happen time and time again, and it's incredibly demoralising to see a problem a mile in advance, but be forced to go down that path yet again because "it's what they asked for".
Customers ask for ridiculous things sure, but it's the job of product mangement to determine what's the true need behind the ridiculous request
Agreed, but this is the very foundation of the product, and when it gets fucked up - which is pretty damn common - the whole development process breaks down. It's like sprinting as fast as you can for as long as you can, only to look up and find you've been running in the wrong direction. Do that enough times, and you're simply not going to put the effort into running quite so fast any more.
The only problem is, there was basically nobody that wanted to buy it.
Like I say; don't spend the time to make sure you're building the right thing, and things go pear-shaped.
The reason why this is less of a problem for hobbyists is because they know what they want, and have the knowledge to side-step pitfalls that, generally speaking, customers rush headlong into when laying out their requirements.
not all "amateur-driven" software is guaranteed to be good.
Of course not, and I'd never claim that.
If you're ultimately not making what the customer wants and they're not buying it, you can't justify the payroll for the programmers.
Agreed 100% and is actually one of the points I was trying to get across (not very clearly).
So we have some people saying that there are DRM chips in the x86 macs, and some people saying that there aren't DRM chips in the x86 macs... did it ever occur to anybody that Apple might be shipping different configurations to different people? It makes sense that they'd try a few different things out before release.
I'm reading that acts of violence in video games are marginally OK (because it's OK to kill NPC's), but spending too much time trying to increase the power of a character is what pushes the issue over the edge. Am I missing something huge here?
Yeah, you left off the most important part of the quote:
It's not the fact that they are increasing the power of their characters that is the issue, it's that they are doing it by killing something that represents an actual person playing the game.
I don't really see a big deal in that, it's only pixels, but I have to admit, it makes a lot more sense to ban pixellated violence than pixellated sex.
Customers often times have no clue as to what they need (and therefore the requirements that the design and implementation flow from are flawed/wrong) and this can caues issues. However, this has less of an effect on whether or not the code is "up to scratch".
Perhaps you misunderstand me. I'm not saying that bad requirements directly cause bad code. I'm saying that programmers who know they are building the wrong thing are going to find it difficult to care enough to create high-quality code.
The first reason is that many, many businesses are focused on building what the customers ask for. Clue number one: customers know fuck all about building software. If they were remotely clued in, they wouldn't need to ask somebody else to build it, would they?
So customers ask for stupid things. That's what makes them customers. The problem arises when the business doesn't care that it's stupid, but builds it for them anyway. Now you have a suboptimal solution that cost lots of money.
Compare this with the amateurs. They are building it for themselves, so they are qualified on both the problem domain and the software construction. They aren't going to build something stupid because they are going to be the ones using it.
Then there's the morale. The professionals are fully aware that what they are building is stupid. It's demoralising. They offer sensible solutions instead, but get knocked back with "it's not what the customer asked for". They begin to understand that their job isn't to build good software, it's to spend their time programming, and if the result is somewhat functional when they reach the deadline, that's just a bonus. It's not surprising that they don't really give a shit whether the code is up to scratch or not, because the whole exercise is pointless beyond collecting a paycheck.
Again, compare with the amateurs. They get satisfaction not only from using the software they wrote (being both users and developers simultaneously), but they get the satisfaction from finding that others appreciate it too. They know they've solved a problem well, and they take pride in their work. People who take pride in their work generally put in more effort.
If there's anything that businesses can learn from this, it's that they need to be able to say no to customers. To put off deadlines. To say "You know what? This is solving the wrong problem!" and go back to the drawing board with the customers to figure out a better approach. It's only when the professional programmers see that they are actually doing something productive that they'll feel motivated enough to take pride in their work, and feel like they are in an environment where they can contribute actual solutions instead of banging their head against a brick wall.
There were certain tags and technologies that (arguably) needed to be made or developed that netscape had to do
Element types. Not "tags".
but there were also W3C standards that Netscape blatantly ignored. For example the CSS standard was made prior to Netscape 4, but Netscape had notoriously poor support for it, while IE had CSS support (albeit very limited) back in version 3.
Get your facts straight. At the time Microsoft were implementing CSS, it wasn't a published W3C recommendation. And Netscape submitted their own stylesheet language, JSSS to the W3C too. Unfortunately for Netscape, the W3C rejected JSSS and published CSS as a recommendation. Netscape was left scrambling to support CSS at the last minute, and did it by transforming CSS to JSSS on the fly, which was understandably limited.
The kicker was that one of the reasons the W3C rejected JSSS was because it violated the Principle of Least Power, while CSS didn't. Once Netscape were out of the way, Microsoft went ahead and added their own proprietary extensions to CSS that also violated the principle of least power.
So, while Netscape do have a history of ignoring the W3C, they certainly tried to work with them in this instance, only to get steamrollered by Microsoft who saw it as an opportunity to get a lead over Netscape in the browser wars.
Agreed. The thing that annoys me is that my PS2 has a perfectly good USB port that you can plug flash disks into, and yet it won't let me save anything on them.
Save yourself some time and deploy GNU Hello. And yes, it really does include a mail client.
I think we will be seeing some more serious collaboration between Mozilla and Google now.
What kind of collaboration would this change enable? Seems to me there's nothing stopping them collaborating now.
I cannot even imagine try to to explain to my grandmother how to "right-click" without her being able to SEE the right button.
The whole reason Apple has stayed with the one-button mouse for so long is because grandmas don't right-click. Why would you be explaining this to her?
The default setting for this mouse is to register a click anywhere on the mouse as a left click. This is exactly the same as the one button mouse Apple have shipped for the past umpteen years.
The value in this mouse is that it caters to the grandmas, while the advanced users who always whine about Apple not shipping a multi-button mouse can reconfigure it to suit their needs better. If you want a one-button mouse, that's what it is. If you want a multi-button mouse, then just change the settings. It's the best of both worlds.
I wasn't "rewording your thoughts", I was pointing out that you are blaming Netscape for something that was entirely your own fault.
It is a bit more severe there if you get caught apparently.
No, the USA DMCA can put you away for ten years.
So if the TaskBar display the currently running programs in Windows, you can't click on a shortcut in the Quick Launch toolbar to launch a new application?
The address bar is not similar to the taskbar and quick launch toolbar at all. The quick launch toolbar is context-free; it doesn't display information on the current application and doesn't change status when you switch to another application.
The address bar, on the other hand, is directly linked to the current tab - when you perform an operation on the current tab, the address bar changes, and when you perform an operation on the address bar, the current tab changes, but no others do. There's a 1:1 correspondence between the address bar and the current tab. You simply can't say the same thing about the quick launch toolbar. The only way in which they are remotely similar is that you can click stuff.
Again, been doing usability for a long time
What's your point? That you can't possibly be wrong?
So, IE7 Beta 1 really IS IE6 with tabbed browsing?
Basically, yes.
Is it me, or is that actually an alpha?
No, lots of people have pointed out the same thing. 'Beta' in normal usage, is generally feature-complete.
Its been 3 years.
Actually, it's been four years (well, over three years and eleven months).
The sign up app could also do it in less than 1K per request if it asked for the user name first, by itself, on a page without a lot of other crap on it.
No, it couldn't. A typical HTTP request/response without an entity body is around 1K. That's before you've even begun to send any HTML.
An XMLHttpRequest approach, on the other hand, can signal when a username is already taken with a 409 response, so there isn't any need for an entity body at all.
So unless you've found some magical way of sending HTML without using any bandwidth, the traditional approach can't beat the XMLHttpRequest approach.
I was a web developer for 7 years and sure, maybe it took a little more effort to get things to work right in IE. But that's the reality of the world. Personally I think it's more annoying having to put a font tag inside every single table column to satisfy Netscape's misunderstanding of tables.
You were a web developer for seven years, and you don't understand the difference between block element types and inline element types? <table> elements can't be children of <font> elements. Netscape did the right thing, there's no "misunderstanding of tables" there.
It's easy to do on php.
Obviously not. Your code has a bug that could serve the warning to other browsers too. Read up on the Vary header.
You're referring to the host objects provided by the implementation, not the implementation itself. The majority of host objects have been formalised in the DOM specifications.
Yeah, there have been proprietary host objects added over the years, but generally they have been supplanted with the DOM - the last browser you needed to use document.all with was Internet Explorer 4.0, newer versions support document.getElementById and the only browser you needed to use document.layers with was Netscape 4, newer versions support changing CSS dynamically.
You have to pick your battles.
Right now, Microsoft is planning on releasing an Internet Explorer 7 that has the majority of the real bastard bugs and missing features in CSS eliminated. This will probably ship before Vista, so there'll probably be a subsequent release of Internet Explorer (e.g. 7.5) to go with it. This version can be the focus for the Acid test or whatever.
Suppose this boycott is effective. Microsoft will delay Internet Explorer 7 until they fix up the rest of it - stuff that's certainly nice to have, but in no way compares to the stuff they've already fixed. That will probably delay it enough to ship Internet Explorer 7 with Vista.
Not only will a successful boycott delay the release of Internet Explorer 7 for months (prolonging the frustrations of web developers for months too), but it makes it less likely that there'll be a quick turnaround for the next version.
Right now, we know that the really important bits are fixed in their current codebase. We should want them to release this as soon as possible, rather than making them delay it for less important stuff.
The broken code is one item on a list of over a dozen things being checked. The idea that the Acid2 test is all about broken code is a myth.