A beggar found shelter in a tavern and sat by a fireplace where a hunk of meat was roasting on a spit. Before eating his meager dinner, consisting of a piece of dry bread, he held it out toward the meat to catch some of the flavour. The tavern keeper saw him and demanded payment, causing the poor fellow considerable distress, since he had no money. A wise man who was eating at a nearby table saw the commotion and asked the keeper what the problem was. "This thief is stealing the flavour of my meat!" the keeper said. "If he wants it, he better pay for it or git out." "That's all right," said the wise man. He pulled out a coin, threw it down on the fireplace, picked it back up and replaced it in his pocket. "For the flavour of your meat, I have now paid you with the chime of my coin."
Instead of looking for someone to blame in the California legislature, we should take action. Just add the following clause to the EULA of any software you write: "this software can not be sold, purchased, or used in the state of California." Sure it's a big state, but it's full of communists who won't want to pay for your games anyhow, so your revenue loss ought to be negligible.
> By "development" I assume you mean the actual programming which > on most large projects only takes about a third or less of the > total effort. Most of the effort is spent on testing and fixing > defects in the code.
I don't know where you work, but on my projects there's no difference between the two. You can not separate "actual programming" and "testing and fixing defects" because you should do them concurrently. Implement a feature, and it goes to the testers; then you start on the next one while they are running tests and other programmers submit their features/bugfixes. Then testers find something that doesn't work and file a bug report. You fix the bug, resubmit, and the cycle continues. If you find yourself needing a special "testing" cycle, you're doing it wrong. Without continuous testing and feedback you'll just keep digging yourself into the hole; deeper and deeper.
1. Creating good interfaces is hard. Really hard. Most programmers create lousy interfaces that nobody but them wants to use. I know; I've written quite a few of them. Good APIs take thought, creativity, and a lot of effort, none of which are allowed in a typical business environment.
2. Reusing code will not necessarily save work. See point one for the first reason. The second reason is that it is often faster to reimplement the functionality and then refactor. This generates more code than reusing someone else's library, but may save development time. Saved development time is a good thing in the type of business that is always in crunch time.
Are there some publicly available complex Office documents that could be used to test compatibility? I hear a lot of complaints about how StarOffice-saved files look different in MSOffice, but I've never seen that happen myself. Could someone please post an example? That way office suite programmers could use it as a test case to debug their layout engines.
Now would also be a good time to celebrate the expiration of any patents that existed for that game. We're sure to see some innovation in the field of platformers now!:)
> Back then every computer brand was utterly different, > different OS, different base language, often a different > processor. It was chaos and it was glorious.
It was only glorious if you could lock in your customers onto your little niche hardware. That is acceptable when you are bundling your software with the hardware, like a cellphone. Nobody would need or want to run your cellphone UI on another cellphone.
The situation is completely different for a general-purpose desktop application. If you write a linux application for Debian, you are targeting only those users who have it or its derivative. That decimates your market right there. If you want to support another platform, you need to provide another package. You'll need to spend time writing it, figuring out an entirely different filesystem layout and configuration format suite, help the user figure out which one he needs (normal users don't remember what distribution they are running), verify which libraries are available on the new target, and provide them if they are not.
You have to do this for each distribution you want to support. This takes time and money. Time and money from a budget that is much smaller than those companies you are talking about had, since they made money selling hardware, throwing in the software as a bonus.
> Nobody complained to my knowledge.
Of course not. In those times, nobody ever tried to distribute an application for more than one platform.
> Too many people have grown up in a monopolist, monoculture society, > they think computing has to be that way and always has been.
No, it doesn't have to be. But it should be. Standards save time and money for software developers by allowing them to target the largest possible customer base. Until you have those standards, you won't have any Linux applications, since very few companies would want to put in time and effort to target a specific distribution. The Linux market is small enough already, and selling to only a fraction of it is hardly sensible in business. And, to add insult to injury, you can't even be sure that the distribution will still exist by the time you release your program.
> I don't exactly know what people's problem with multiple distros is.
The lack of a usable standard to develop toward. When distributing a program, you have to support many distributions. That means multiple package formats, different file paths, different configuration file formats (init scripts being the worst, if your program is a daemon), different libraries bundled, different desktop types and ways to make your program visible, etc.
Lois McMaster Bujold wrote a book about a planet with no women, called "Ethan of Athos". The protagonist is sent on a mission to procure more ovaries for the breeding labs where the old ovarian cultures are showing their age. You might find the descriptions of their culture curious, if you are not as opposed to homosexuality as I am.
I don't know about you, but I haven't bought a game in a store in a decade. They are just so much cheaper on eBay, especially if you wait a while after the release. Children, especially, would benefit from those lower prices; as it is, a single game takes a pretty big chunk of a kid's allowance.
Install a 2400 baud modem in his machine before you demo the site. I bet it will take him only a few agonizing minutes to see the difference your performance improvements make.
Yet another fine example of galactic garbage disposal system working properly. Roger Wilco's involvement is rumored, although StarCon declined to confirm it.
I see that he has remembered the "We will bury you" line without having remembered the fate of the utterer which he is likely to emulate in some near future.
Why not just set all the passwords to the same value and then tell everyone what it is? It's not like you're gaining any security by having multiple passwords; everyone knows them all anyway.
> They have you using words like "ripping off" to describe > what they do with thos public domain stories.
Copying a public domain story can also be rightfully described as "ripping off". The difference is that ripping off a copyrighted work is illegal, while ripping off a public domain work simply shows your lack of originality.
> You know how many times I've edited the system > registry since its inception? Less than 5. I really > doubt that anyone *needs* to edit their registry ever.
I need to edit the registry all the time to get stuff running under a non-Administrator account (W2K). Nearly all games assume write permission to HKEY_LOCAL_MACHINE, even when they don't need it, so I always have to go in and grant it on that game's subkey manually. I used to do the same for the game directory to allow saved games and stuff, but now I just put the games on a separate FAT drive and let them die if they want to.
Slashdot Mirror
Due to the decline in the US educational standards, of course.
A beggar found shelter in a tavern and sat by a fireplace where a hunk of meat was roasting on a spit. Before eating his meager dinner, consisting of a piece of dry bread, he held it out toward the meat to catch some of the flavour. The tavern keeper saw him and demanded payment, causing the poor fellow considerable distress, since he had no money. A wise man who was eating at a nearby table saw the commotion and asked the keeper what the problem was. "This thief is stealing the flavour of my meat!" the keeper said. "If he wants it, he better pay for it or git out." "That's all right," said the wise man. He pulled out a coin, threw it down on the fireplace, picked it back up and replaced it in his pocket. "For the flavour of your meat, I have now paid you with the chime of my coin."
Instead of looking for someone to blame in the California legislature, we should take action. Just add the following clause to the EULA of any software you write: "this software can not be sold, purchased, or used in the state of California." Sure it's a big state, but it's full of communists who won't want to pay for your games anyhow, so your revenue loss ought to be negligible.
> Nobody will want to get drunk on the steps of the Capitol with them except the Kennedy's.
On the contrary, quite a few people will want to. For the same reason Orren Boyle got drunk with Wesley Mouch.
And exactly how much memory does your mighty 80386 support?
> By "development" I assume you mean the actual programming which
> on most large projects only takes about a third or less of the
> total effort. Most of the effort is spent on testing and fixing
> defects in the code.
I don't know where you work, but on my projects there's no difference between the two. You can not separate "actual programming" and "testing and fixing defects" because you should do them concurrently. Implement a feature, and it goes to the testers; then you start on the next one while they are running tests and other programmers submit their features/bugfixes. Then testers find something that doesn't work and file a bug report. You fix the bug, resubmit, and the cycle continues. If you find yourself needing a special "testing" cycle, you're doing it wrong. Without continuous testing and feedback you'll just keep digging yourself into the hole; deeper and deeper.
1. Creating good interfaces is hard. Really hard. Most programmers create lousy interfaces that nobody but them wants to use. I know; I've written quite a few of them. Good APIs take thought, creativity, and a lot of effort, none of which are allowed in a typical business environment.
2. Reusing code will not necessarily save work. See point one for the first reason. The second reason is that it is often faster to reimplement the functionality and then refactor. This generates more code than reusing someone else's library, but may save development time. Saved development time is a good thing in the type of business that is always in crunch time.
Are there some publicly available complex Office documents that could be used to test compatibility? I hear a lot of complaints about how StarOffice-saved files look different in MSOffice, but I've never seen that happen myself. Could someone please post an example? That way office suite programmers could use it as a test case to debug their layout engines.
On... Off... On... Off... ... On...
It might be a relic, but I call it a "holy relic"!
Q: How many Oregonians does it take to screw in a light bulb?
A: One. But the one can't be you.
Now would also be a good time to celebrate the expiration of any patents that existed for that game. We're sure to see some innovation in the field of platformers now! :)
> Back then every computer brand was utterly different,
> different OS, different base language, often a different
> processor. It was chaos and it was glorious.
It was only glorious if you could lock in your customers onto your little niche hardware. That is acceptable when you are bundling your software with the hardware, like a cellphone. Nobody would need or want to run your cellphone UI on another cellphone.
The situation is completely different for a general-purpose desktop application. If you write a linux application for Debian, you are targeting only those users who have it or its derivative. That decimates your market right there. If you want to support another platform, you need to provide another package. You'll need to spend time writing it, figuring out an entirely different filesystem layout and configuration format suite, help the user figure out which one he needs (normal users don't remember what distribution they are running), verify which libraries are available on the new target, and provide them if they are not.
You have to do this for each distribution you want to support. This takes time and money. Time and money from a budget that is much smaller than those companies you are talking about had, since they made money selling hardware, throwing in the software as a bonus.
> Nobody complained to my knowledge.
Of course not. In those times, nobody ever tried to distribute an application for more than one platform.
> Too many people have grown up in a monopolist, monoculture society,
> they think computing has to be that way and always has been.
No, it doesn't have to be. But it should be. Standards save time and money for software developers by allowing them to target the largest possible customer base. Until you have those standards, you won't have any Linux applications, since very few companies would want to put in time and effort to target a specific distribution. The Linux market is small enough already, and selling to only a fraction of it is hardly sensible in business. And, to add insult to injury, you can't even be sure that the distribution will still exist by the time you release your program.
> I don't exactly know what people's problem with multiple distros is.
The lack of a usable standard to develop toward. When distributing a program, you have to support many distributions. That means multiple package formats, different file paths, different configuration file formats (init scripts being the worst, if your program is a daemon), different libraries bundled, different desktop types and ways to make your program visible, etc.
Lois McMaster Bujold wrote a book about a planet with no women, called "Ethan of Athos". The protagonist is sent on a mission to procure more ovaries for the breeding labs where the old ovarian cultures are showing their age. You might find the descriptions of their culture curious, if you are not as opposed to homosexuality as I am.
I don't know about you, but I haven't bought a game in a store in a decade. They are just so much cheaper on eBay, especially if you wait a while after the release. Children, especially, would benefit from those lower prices; as it is, a single game takes a pretty big chunk of a kid's allowance.
> Would *you* dine with the devil?
Of course I would. Depriving him of food is a good way of fighting evil, and boy, you gotta see me eat!
Install a 2400 baud modem in his machine before you demo the site. I bet it will take him only a few agonizing minutes to see the difference your performance improvements make.
Yet another fine example of galactic garbage disposal system working properly. Roger Wilco's involvement is rumored, although StarCon declined to confirm it.
I see that he has remembered the "We will bury you" line without having remembered the fate of the utterer which he is likely to emulate in some near future.
Why not just set all the passwords to the same value and then tell everyone what it is? It's not like you're gaining any security by having multiple passwords; everyone knows them all anyway.
> They have you using words like "ripping off" to describe
> what they do with thos public domain stories.
Copying a public domain story can also be rightfully described as "ripping off". The difference is that ripping off a copyrighted work is illegal, while ripping off a public domain work simply shows your lack of originality.
> You know how many times I've edited the system
> registry since its inception? Less than 5. I really
> doubt that anyone *needs* to edit their registry ever.
I need to edit the registry all the time to get stuff running under a non-Administrator account (W2K). Nearly all games assume write permission to HKEY_LOCAL_MACHINE, even when they don't need it, so I always have to go in and grant it on that game's subkey manually. I used to do the same for the game directory to allow saved games and stuff, but now I just put the games on a separate FAT drive and let them die if they want to.
Yeah, but you won't be able to afford insurance for it.
1+10=11
11>10