You -- the rightful recipient of an encrypted message -- have to have all three of the following: the encrypted file, the decryption key and the player {which contains the decryption algorithm}. Without the file you have nothing to watch / listen to, without the key you have no way to decrypt it and without the player you have no way to view / hear it. If you had the source code to the player, you could find out where the key is obtained from {it might be in the encrypted file or it might be in the player itself} and use the decryption algorithm independently to decrypt the file.
Of course, reverse-engineering a binary-only program is possible -- it's just not easy. DRM is fundamentally flawed {in the worst case, it can be defeated with cameras and microphones}. This is likely to persist until we get schemes that perform the final decryption in your brain.
All you need to do, in that case, is write a C interpreter in assembler that can interpret enough of the C language to run the compiler interpretatively as it compiles the compiler. Then you know what the interpreted compiler is doing {because you wrote the interpreter code yourself} and that the compiler it's compiling really is clean {because you checked the compiler source}.
Of course, even then, you don't know for certain what a simple instruction like ADC AL S R6,R4,R2 might be doing. Sure it says it's an unconditional addition of R4 + R2 + C with the result going into R6 and the carry updated, but that's just what they want you to think.....
Last time I tried, the BBC stuff wouldn't work in the Open Source Helix player. I had to install the closed source RealPlayer. Fortunately, I was able to do this as a non-root user.
Also, one of the supposed "advantages" of WMA/WMV is that it supports Digital Restrictions Management. Something tells me the Open Source codec won't do that {DRM requires security-through-obscurity}. Of course, having an Open Source version might well make reverse-engineering the closed source version a bit easier.....
Perhaps by hosting it in a country where software is not patentable, and relying on Fair Use defence if it is used in a country where software is patentable?
1000 lines of code to capitalise names properly? What language were you using? I could fit it in my sig as a Perl regex if it wasn't taken up with a witty comment.
Sometimes I can't be bothered to use both hands for typing; or I'm really multi-tasking as opposed to inter-tasking {i.e. drinking tea while typing as opposed to merely taking a sip betwen keystrokes. And sometimes, I need to type a capital letter which is far from the shift keys. At such times, I find a quick press of the Caps Lock key allows me to accomplish what I'm trying to do with one hand. Of course, it needs a second press afterward to turn it off, but for one-handed typing it's actually quite useful.
I also like to capitalise HTML tags and SQL reserved words {Hey, I take advantage of case-insensitivity wherever I can get it!}; and Caps Lock saves me from having to hold down the shift key to do that.
What I wouldn't object to would be removing the rightmost 5mm. from the key, so leaving a half-centimetre gap between the Caps Lock and A {Q in France} keys so that this doesn't haPPEN so often. I might buy me a cheap keyboard and carry out such a modification, using some highly sophisticated equipment {a hacksaw!} to see if it's an improvement.
Which is why I firmly believe that people should only be arrested for child abuse offences if and when they actually abuse a child. Granted, that's a lot harder to prove in a court of law.....
How much further can we take the concept that words and images have some power to damage the reader's mind irreparably? Should reading car magazines be equated with speeding? Should visiting tech news sites be equated with cracking?
The three holes that really matter are (1) If a message has been encrypted using a one-time pad, then it's absolutely unbreakable; every plaintext of the right length is equally plausible. There are other encryption systems that can lead to multiple plaintexts, including some that allow the sender deliberately to implant an innocuous message which will do less damage if discovered. (2) You can certainly brute-force a key, knowing that a particular algorithm was used; but you can't brute-force an algorithm. (3) If the only copy of the source code to implement the Digital Fortress algorithm had been encrypted using Digital Fortress, then you would still need a copy of the Digital Fortress binary with which to decrypt the source code. And it'd be quicker just to disassemble that {and guess variable and function names} than to piss around trying to decrypt it.
How likely would a real-life crypto expert be not to work out the meaning of "without wax" in one go {presumably she would know at least a few words in a few languages}, much less spot obvious anagrams such as NDAKOTA = TANKADO? Not knowing the name of the coin used in a country is hardly forgivable either! You can find out what the currency of Spain is in any travel agent. Clue: it's not the Peseta!
The first plot hole I noticed in that book was when he got the name of the Spanish currency wrong. Brown also doesn't seem to know the difference between data and executable code, let alone give thought to the fact that differences between instruction set / addressing schema architectures would mean code executable on one kind of computer would do nothing useful on another; he doesn't know the difference between an algorithm and a key, in fact I'm not sure he understands much crypto theory; and doesn't even seem to know the density of soil. If I had access to a copy of the book right now I'd give references, but I haven't, so I'm not going to.
I'm just glad I'd already read -- and enjoyed, in spite of lesser plot holes -- Angels and Demons and The da Vinci Code before I picked up Digital Fortress, because the plot holes really ruined my enjoyment of DF and soured my opinion of Dan Brown. Also, I thought A&D would make a better film than dVC.
You're comparing a cabinet maker to a software developer.
What would you say if someone took a tape measure to a piece of furniture, made notes and sketches; then went out and bought some wood with their own money, and used this together with tools that they had bought and paid for with their own money, to make a broadly identical piece of furniture?
If you think that is O.K., why do you think there is anything wrong with substituting a blank CD for the wood, a CD reader for the tape measure, a hard disc drive for the notebook, and a CD burner for the woodworking tools?
Under American-style capitalism, if somebody had a cure for AIDS then condoms would be outlawed.
Anyway, most pharmaceutical drugs could be done without if people just lived healthier lifestyles. Think wholesome, home-cooked, maybe even home-grown food. Walking or cycling occasionally instead of driving everywhere. Owning a pet. Being content to be the way Nature made you and not trying to be what you are not just because someone else is.
Congratulations! You're finding out the hard way that there's no future for closed source payware. The fact is, software can be reproduced at essentially zero cost: it is a plentiful good. You can't expect to be able to apply the old economics of scarcity to software, and any attempt to do so will fail.
You're basically in the same situation as somebody trying to make a living operating a pay toilet in a forest. Ask yourself the questions: Why would someone pay me to do basically the same thing as they could do for nothing elsewhere? What can I offer my loyal, paying customers, that people can't get if they choose not to pay for it?
BTW, if you have used any "pirated" software in developing your product, including in the course of learning whatever it took to develop your project, you're not alone. Bill Gates and Paul Allen never paid for the computer time they used developing Microsoft BASIC, the subject of Gates's famous "$2 an hour" whinge.
Let us never forget what was the original intention of copyright. It was to reward people not for merely creating material, but for actually sharing that material -- in the form of a promise to release it into the Public Domain some day soon.
Which raises the question. Times have changed..... Is a temporary monopoly on distribution still really the best way to reward people for sharing their creations with the world at large, or might there now exist a better way of accomplishing the same end?
The 6502's "zero page" instructions were a timesaver. Most instructions had a "shorthand" form which accessed a byte in the address space $0000-$00FF, using only one byte for the operand address, so saving a clock cycle and a byte of RAM. You could use zero page memory as an extended register set. If you were very clever, you could pull stunts with mapping different 256-byte chunks of memory into that space. Or you could use those addresses for faster-than-usual I/O {like the Atari 2600}. {The 6502 did not have separate I/O and memory buses.}
The BBC microcomputer used the 6502 {actually the 65C102 in its later incarnations} and that had an absolutely amazing BASIC. Even ran faster than some rival computers' machine code {thanks mostly to the use of hardware rather than software to generate the bitmapped display, which required up to 20KB of the 32KB for the framebuffer}.
The 6502, and the way the BBC used it, was also the inspiration for the ARM processor. SWIs were based on the BBC's MOS {kind of a BIOS on steroids; a full abstraction layer}. Basically, in order to access the BBC's hardware, you would set up a parameter block in memory; load its address into the X and Y registers and an instruction code into the accumulator; and call a fixed address in ROM {which pointed to an indirect jump instruction deriving its address from RAM, allowing user code to intercept MOS calls if necessary. You could have hours of fun with this}. If you only needed to pass two bytes and an instruction code then you could use the X and Y registers and call a different address. {I know, nowadays we pass parameters on the stack. This was the 1980s. Also, the 6502's hardware stack can only ever be 256 bytes big due to the S register -- the stack pointer -- being only 8 bits wide.} The whole display subsystem {including text, graphics, user-defined characters, display windows and colour/palette selection} was controlled by non-printable characters {and the graphics display was organised as 1280x1024, even though in real life it was only 160/320/640x256}. There was, of course, a MOS call to print a character. Every other piece of hardware -- the sound system, the keyboard, the printer, the serial port, the A-to-D converter, the cassette and disc file systems -- could be accessed through MOS calls. You didn't have to touch the hardware directly at all; in fact, as long as you didn't, the same programs {in BASIC or machine code} would work without modification on a plain Model B, a B with a 6502 second processor, a Master Series or a RISC-based machine with 6502 emulation. BBC BASIC was merely a layer on top of the MOS. For instance, the Beeb's sound chip had a programmable envelope generator controlled by 14 parameters. There was a MOS call which took a block of 14 parameters and loaded these into the sound chip's registers. The ENVELOPE statement in BASIC took 14 parameters, and merely made the MOS call for you.
The nasty secret conspiracy you're painting on the wall here is neither secret nor a conspiracy, but just standard business practice.
That still in no way makes it acceptable.
If you make your "second best" products by starting with your "best" products and then doing something to them which makes them less desirable so you can sell them for a lower price, you are effectively using labour to subtract value. The implication is that if you hadn't done the downgrading work {which must cost some money}, you could actually afford to sell the "best" product at a cheaper price than the "second best" product.
Well, simple common-law property rights mean that if you own a piece of hardware, then you are privy to any secret embodied in that hardware: you, by definition, aren't one of the people it's secret from. By selling it to you, they invited you in on the secret. So by not providing owners of their graphics cards with documentation, nVidia and ATI are already breaking the law.
Another reason why they are unwilling to release the information might be because it would prove that they have been bullshitting us for a long time.
Chances are that the difference between a £50 card and a £300 card is in the software: by changing just one bit in one byte in the huge, bloated blob of a driver, you could extract £300 performance from a £50 graphics card. It can't be economically viable for them to fabricate different GPUs to use on "cheap" and "expensive" cards. Instead, they have an I/O pin {maybe several pins?} on the GPU which they tie to 0V {so it reads as a 0} on the cheap cards, or leave unconnected {so it looks like a 1} on the expensive cards. The driver software reads the state of the pin and determines whether or not to run the card in "expensive" mode.
{Then, of course, there are the various "cheats" built into games to make them run faster or better with certain graphics cards -- or, to put it more accurately, to make them run slower or worse with other graphics cards. Games companies are certainly not above accepting bakshish.}
The RAW formats used by digital cameras are similarly undocumented for pretty much the same reason: the JPEG files are interpolated up to much higher resolutions than the sensor actually generates. Revealing the format of the RAW file would also reveal the real number of pixels on the image sensor, and likely open up camera manufacturers to prosecution under consumer protection law.
I tried to develop a shopping site for a friend to host on a similarly cheap server. I tested it on my "Internet Connection Sharer", an old K6/1 running at 200MHz with just 48MB of RAM {and still able to run Apache, Perl, PHP and MySQL}. I swear that little machine was faster and more reliable than the hosted server.
The also made some really awful mistakes. Like using the same password for FTP {which, of course, is your unix login password} and MySQL. That would not have been too bad if it weren't for the fact that any PHP or Perl script could read any files in any user's home directory {they have to be world-readable just so the low-privileged Apache daemon can see them} which might very likely include the username and password for connecting to the database {and thus, the user's unix login and password}. Fortunately for them, I was too polite to demonstrate what this meant.
It's NOT complex to develop software to run on an Open Source platform. It only becomes complex when you try to conceal the source code from users. The configure - make - install process generally works well, unless the packager ballsed up and forgot a dependency that didn't get autodetected.
This method worked really well for Microsoft Windows -- absolutely nobody can ever copy it because they can't see the source code. Wheras all the high-end proprietary Unix programs that came in a source tarball without permission to redistribute, well, the world and his cat have copies of all of them.
We need either a law mandating user access to source code, or a decompiler good enough almost to guarantee this anyway. Then, the only thing that makes it hard to develop on Open Source platforms will not be there. And, as a side effect, we'd all be in more in control of our computers.
What happened was simply that they were crap. They were crap because people were greedy at multiple levels.
The PC manufacturers were greedy, offering woefully under-specified machines in flashy housings that still managed not to look like serious pieces of A/V kit. {Hint: quit trying the fanless thing already. DVD recorders have fans. Nobody's even going to hear the fan noise if the volume is turned up loud enough. Which it won't be if the amplifier and/or speakers distort when turned up above "restaurant conversation" level. So please, give us heavy speakers, so the enclosure stands approximately still when the cone moves -- recall Newton's 3rd law -- and a power supply with a chunky transformer and smoothing capacitors rated in millifarads. Enough to keep the "on" LED lit for several minutes.}
Microsoft were greedy, charging a fortune for a crippled OS.
And the media companies were greedy, they didn't dare release anything in a PC-friendly way in case it got copied. Apparently they haven't worked out that simply walking round to a friend's house to watch a movie on their equipment doesn't actually cost them any fewer sales than rampant copying.
In fact, there's nothing to stop a person or organisation from setting up a private bit of the Internet, with all its own nameservers and all its own routers which will only route packets from certain places {like subscription-only servers} to certain other places {like paid-up subscribers}. Basically, I could set up "AJS media", offer ADSL to subscribers, and have some servers {including a whole new.ajs TLD, that wouldn't even be visible unless you were connected to the Internet via one of my lines} firewalled off from anyone except my customers. Now I can make anything I like accessible from those servers and only my subscribers will be able to see it. All I need now is some content.....
Slashdot Mirror
Yes it does.
You -- the rightful recipient of an encrypted message -- have to have all three of the following: the encrypted file, the decryption key and the player {which contains the decryption algorithm}. Without the file you have nothing to watch / listen to, without the key you have no way to decrypt it and without the player you have no way to view / hear it. If you had the source code to the player, you could find out where the key is obtained from {it might be in the encrypted file or it might be in the player itself} and use the decryption algorithm independently to decrypt the file.
Of course, reverse-engineering a binary-only program is possible -- it's just not easy. DRM is fundamentally flawed {in the worst case, it can be defeated with cameras and microphones}. This is likely to persist until we get schemes that perform the final decryption in your brain.
There is an analogous exception for patents too.
All you need to do, in that case, is write a C interpreter in assembler that can interpret enough of the C language to run the compiler interpretatively as it compiles the compiler. Then you know what the interpreted compiler is doing {because you wrote the interpreter code yourself} and that the compiler it's compiling really is clean {because you checked the compiler source}.
.....
Of course, even then, you don't know for certain what a simple instruction like ADC AL S R6,R4,R2 might be doing. Sure it says it's an unconditional addition of R4 + R2 + C with the result going into R6 and the carry updated, but that's just what they want you to think
Last time I tried, the BBC stuff wouldn't work in the Open Source Helix player. I had to install the closed source RealPlayer. Fortunately, I was able to do this as a non-root user.
.....
Also, one of the supposed "advantages" of WMA/WMV is that it supports Digital Restrictions Management. Something tells me the Open Source codec won't do that {DRM requires security-through-obscurity}. Of course, having an Open Source version might well make reverse-engineering the closed source version a bit easier
Perhaps by hosting it in a country where software is not patentable, and relying on Fair Use defence if it is used in a country where software is patentable?
You could always add the feature to the software yourself -- that's what Freedom Three means.
1000 lines of code to capitalise names properly? What language were you using? I could fit it in my sig as a Perl regex if it wasn't taken up with a witty comment.
Sometimes I can't be bothered to use both hands for typing; or I'm really multi-tasking as opposed to inter-tasking {i.e. drinking tea while typing as opposed to merely taking a sip betwen keystrokes. And sometimes, I need to type a capital letter which is far from the shift keys. At such times, I find a quick press of the Caps Lock key allows me to accomplish what I'm trying to do with one hand. Of course, it needs a second press afterward to turn it off, but for one-handed typing it's actually quite useful.
I also like to capitalise HTML tags and SQL reserved words {Hey, I take advantage of case-insensitivity wherever I can get it!}; and Caps Lock saves me from having to hold down the shift key to do that.
What I wouldn't object to would be removing the rightmost 5mm. from the key, so leaving a half-centimetre gap between the Caps Lock and A {Q in France} keys so that this doesn't haPPEN so often. I might buy me a cheap keyboard and carry out such a modification, using some highly sophisticated equipment {a hacksaw!} to see if it's an improvement.
Which is why I firmly believe that people should only be arrested for child abuse offences if and when they actually abuse a child. Granted, that's a lot harder to prove in a court of law .....
How much further can we take the concept that words and images have some power to damage the reader's mind irreparably? Should reading car magazines be equated with speeding? Should visiting tech news sites be equated with cracking?
The three holes that really matter are (1) If a message has been encrypted using a one-time pad, then it's absolutely unbreakable; every plaintext of the right length is equally plausible. There are other encryption systems that can lead to multiple plaintexts, including some that allow the sender deliberately to implant an innocuous message which will do less damage if discovered. (2) You can certainly brute-force a key, knowing that a particular algorithm was used; but you can't brute-force an algorithm. (3) If the only copy of the source code to implement the Digital Fortress algorithm had been encrypted using Digital Fortress, then you would still need a copy of the Digital Fortress binary with which to decrypt the source code. And it'd be quicker just to disassemble that {and guess variable and function names} than to piss around trying to decrypt it.
How likely would a real-life crypto expert be not to work out the meaning of "without wax" in one go {presumably she would know at least a few words in a few languages}, much less spot obvious anagrams such as NDAKOTA = TANKADO? Not knowing the name of the coin used in a country is hardly forgivable either! You can find out what the currency of Spain is in any travel agent. Clue: it's not the Peseta!
The first plot hole I noticed in that book was when he got the name of the Spanish currency wrong. Brown also doesn't seem to know the difference between data and executable code, let alone give thought to the fact that differences between instruction set / addressing schema architectures would mean code executable on one kind of computer would do nothing useful on another; he doesn't know the difference between an algorithm and a key, in fact I'm not sure he understands much crypto theory; and doesn't even seem to know the density of soil. If I had access to a copy of the book right now I'd give references, but I haven't, so I'm not going to.
I'm just glad I'd already read -- and enjoyed, in spite of lesser plot holes -- Angels and Demons and The da Vinci Code before I picked up Digital Fortress, because the plot holes really ruined my enjoyment of DF and soured my opinion of Dan Brown. Also, I thought A&D would make a better film than dVC.
If it's all strongly encrypted end-to-end, how's anyone except a party to the transaction going to know it's child porn anyway?
You're comparing a cabinet maker to a software developer.
What would you say if someone took a tape measure to a piece of furniture, made notes and sketches; then went out and bought some wood with their own money, and used this together with tools that they had bought and paid for with their own money, to make a broadly identical piece of furniture?
If you think that is O.K., why do you think there is anything wrong with substituting a blank CD for the wood, a CD reader for the tape measure, a hard disc drive for the notebook, and a CD burner for the woodworking tools?
Under American-style capitalism, if somebody had a cure for AIDS then condoms would be outlawed.
Anyway, most pharmaceutical drugs could be done without if people just lived healthier lifestyles. Think wholesome, home-cooked, maybe even home-grown food. Walking or cycling occasionally instead of driving everywhere. Owning a pet. Being content to be the way Nature made you and not trying to be what you are not just because someone else is.
Wouldn't the obvious way of doing that be to offer material for download from premium-rate dial-up servers invisible to the rest of the Internet?
Congratulations! You're finding out the hard way that there's no future for closed source payware. The fact is, software can be reproduced at essentially zero cost: it is a plentiful good. You can't expect to be able to apply the old economics of scarcity to software, and any attempt to do so will fail.
You're basically in the same situation as somebody trying to make a living operating a pay toilet in a forest. Ask yourself the questions: Why would someone pay me to do basically the same thing as they could do for nothing elsewhere? What can I offer my loyal, paying customers, that people can't get if they choose not to pay for it?
BTW, if you have used any "pirated" software in developing your product, including in the course of learning whatever it took to develop your project, you're not alone. Bill Gates and Paul Allen never paid for the computer time they used developing Microsoft BASIC, the subject of Gates's famous "$2 an hour" whinge.
Let us never forget what was the original intention of copyright. It was to reward people not for merely creating material, but for actually sharing that material -- in the form of a promise to release it into the Public Domain some day soon.
..... Is a temporary monopoly on distribution still really the best way to reward people for sharing their creations with the world at large, or might there now exist a better way of accomplishing the same end?
Which raises the question. Times have changed
The 6502's "zero page" instructions were a timesaver. Most instructions had a "shorthand" form which accessed a byte in the address space $0000-$00FF, using only one byte for the operand address, so saving a clock cycle and a byte of RAM. You could use zero page memory as an extended register set. If you were very clever, you could pull stunts with mapping different 256-byte chunks of memory into that space. Or you could use those addresses for faster-than-usual I/O {like the Atari 2600}. {The 6502 did not have separate I/O and memory buses.}
The BBC microcomputer used the 6502 {actually the 65C102 in its later incarnations} and that had an absolutely amazing BASIC. Even ran faster than some rival computers' machine code {thanks mostly to the use of hardware rather than software to generate the bitmapped display, which required up to 20KB of the 32KB for the framebuffer}.
The 6502, and the way the BBC used it, was also the inspiration for the ARM processor. SWIs were based on the BBC's MOS {kind of a BIOS on steroids; a full abstraction layer}. Basically, in order to access the BBC's hardware, you would set up a parameter block in memory; load its address into the X and Y registers and an instruction code into the accumulator; and call a fixed address in ROM {which pointed to an indirect jump instruction deriving its address from RAM, allowing user code to intercept MOS calls if necessary. You could have hours of fun with this}. If you only needed to pass two bytes and an instruction code then you could use the X and Y registers and call a different address. {I know, nowadays we pass parameters on the stack. This was the 1980s. Also, the 6502's hardware stack can only ever be 256 bytes big due to the S register -- the stack pointer -- being only 8 bits wide.} The whole display subsystem {including text, graphics, user-defined characters, display windows and colour/palette selection} was controlled by non-printable characters {and the graphics display was organised as 1280x1024, even though in real life it was only 160/320/640x256}. There was, of course, a MOS call to print a character. Every other piece of hardware -- the sound system, the keyboard, the printer, the serial port, the A-to-D converter, the cassette and disc file systems -- could be accessed through MOS calls. You didn't have to touch the hardware directly at all; in fact, as long as you didn't, the same programs {in BASIC or machine code} would work without modification on a plain Model B, a B with a 6502 second processor, a Master Series or a RISC-based machine with 6502 emulation. BBC BASIC was merely a layer on top of the MOS. For instance, the Beeb's sound chip had a programmable envelope generator controlled by 14 parameters. There was a MOS call which took a block of 14 parameters and loaded these into the sound chip's registers. The ENVELOPE statement in BASIC took 14 parameters, and merely made the MOS call for you.
If you make your "second best" products by starting with your "best" products and then doing something to them which makes them less desirable so you can sell them for a lower price, you are effectively using labour to subtract value. The implication is that if you hadn't done the downgrading work {which must cost some money}, you could actually afford to sell the "best" product at a cheaper price than the "second best" product.
Well, simple common-law property rights mean that if you own a piece of hardware, then you are privy to any secret embodied in that hardware: you, by definition, aren't one of the people it's secret from. By selling it to you, they invited you in on the secret. So by not providing owners of their graphics cards with documentation, nVidia and ATI are already breaking the law.
Good luck enforcing it, though.
Possibly.
Another reason why they are unwilling to release the information might be because it would prove that they have been bullshitting us for a long time.
Chances are that the difference between a £50 card and a £300 card is in the software: by changing just one bit in one byte in the huge, bloated blob of a driver, you could extract £300 performance from a £50 graphics card. It can't be economically viable for them to fabricate different GPUs to use on "cheap" and "expensive" cards. Instead, they have an I/O pin {maybe several pins?} on the GPU which they tie to 0V {so it reads as a 0} on the cheap cards, or leave unconnected {so it looks like a 1} on the expensive cards. The driver software reads the state of the pin and determines whether or not to run the card in "expensive" mode.
{Then, of course, there are the various "cheats" built into games to make them run faster or better with certain graphics cards -- or, to put it more accurately, to make them run slower or worse with other graphics cards. Games companies are certainly not above accepting bakshish.}
The RAW formats used by digital cameras are similarly undocumented for pretty much the same reason: the JPEG files are interpolated up to much higher resolutions than the sensor actually generates. Revealing the format of the RAW file would also reveal the real number of pixels on the image sensor, and likely open up camera manufacturers to prosecution under consumer protection law.
So ..... you're pleased that you finally have an i-tal driver, because it will work with Google Earth?
You do realise Google Earth isn't i-tal, don't you?
Have they not heard the old saying .....
If you pay peanuts, you get monkeys!
I tried to develop a shopping site for a friend to host on a similarly cheap server. I tested it on my "Internet Connection Sharer", an old K6/1 running at 200MHz with just 48MB of RAM {and still able to run Apache, Perl, PHP and MySQL}. I swear that little machine was faster and more reliable than the hosted server.
The also made some really awful mistakes. Like using the same password for FTP {which, of course, is your unix login password} and MySQL. That would not have been too bad if it weren't for the fact that any PHP or Perl script could read any files in any user's home directory {they have to be world-readable just so the low-privileged Apache daemon can see them} which might very likely include the username and password for connecting to the database {and thus, the user's unix login and password}. Fortunately for them, I was too polite to demonstrate what this meant.
It's NOT complex to develop software to run on an Open Source platform. It only becomes complex when you try to conceal the source code from users. The configure - make - install process generally works well, unless the packager ballsed up and forgot a dependency that didn't get autodetected.
This method worked really well for Microsoft Windows -- absolutely nobody can ever copy it because they can't see the source code. Wheras all the high-end proprietary Unix programs that came in a source tarball without permission to redistribute, well, the world and his cat have copies of all of them.
We need either a law mandating user access to source code, or a decompiler good enough almost to guarantee this anyway. Then, the only thing that makes it hard to develop on Open Source platforms will not be there. And, as a side effect, we'd all be in more in control of our computers.
In fact, there's nothing to stop a person or organisation from setting up a private bit of the Internet, with all its own nameservers and all its own routers which will only route packets from certain places {like subscription-only servers} to certain other places {like paid-up subscribers}. Basically, I could set up "AJS media", offer ADSL to subscribers, and have some servers {including a whole new