It isn't that the brain isn't "satisfied" simply because yellow is being formed from red and green; it's that different eyes will have different responses to true yellow, and to the red and green phosphors. If trying to reproduce something that was originally true yellow, instead of being made of the exact frequencies of the phosphors, it won't look the same yellow to everyone. Increasing the number of discrete frequencies being detected, transmitted and reproduced, would reduce the amount of error for anyone who doesn't match the exact sensitivity used in the design of the camera/monitor system.
Of course, RGB can't really reproduce a "true yellow" anyway (the effect on the blue cones will be different between a true yellow and the closest mix you can get in RGB, leading to a slightly less saturated-looking yellow than "true").
That's only if you make cyan be a mixture of blue and green. If, instead, you make cyan be cyan light (a frequency between green and blue), it doesn't do that at all.
I'd think that at least some artists would be concerned about the actual spectral values of the colors they're using. There are many different combinations of spectra that yield the same perception to an individual eye - but maybe different perceptions to different people, e.g. the difference between a true "orange" pigment (reflects only orange light), and one that reflects a mix of red and yellow or red and green (by absorbing mostly blue). The differences will also be noticeable in different lighting conditions.
Rods have their own characteristic sensitivity curve, just as the red/green/yellow-green cones. See Cone cell, for example. In strong light, rods are fully saturated, so they can't do much effective color sensing. In medium light (mesopic), rods and cones are all active, and thus rods might well have an effect on color perception.
Apparently, violet light also stimulates the yellow-green cones as well, which is why purple (a mix of red and blue) and violet are perceptually similar. I'd expect true violet and indigo light (which can not be represented in RGB) to stimulate the green receptor less than a RB mix.
If we weren't so insensitive to blue light in general, maybe an enhanced-primary system would include violet or indigo. Adding Cyan and Yellow makes sense, though.
What's really needed is a multi-spectral recorder - this would reduce the differences people will see between "real life" and a reproduction due to individual differences in spectral sensitivity (including extremes such as color-blindness).
The whole point of using a heat pump is that it is more efficient. They aren't appropriate in some climates, but where they are they work well. What's your source for them being inefficient? Also, how do you mean "uncomfortable heat"? The only difference in heating is the temperature of the air being heated and the humidity. How is a heat pump more uncomfortable?
Ummm, as demand goes down, so does price. Price goes up as demand goes up and supply goes down. That's "simple supply and demand economics".
Now, it may well be that, as demand goes down, you have to raise prices in order to meet costs. That's "simple economy of scale" economics. Or "simple bankruptcy" economics, if you've now priced yourself out of the market (demand * price curve is decreasing with increasing price, means you make less money as you increase the price).
"demand" is based on price - at a given price, you'll have a certain number of people who will buy at that price. If you plot demand * price, then subtract demand * cost (where cost is cost/unit at that quantity - often can be expressed as K1 + K2/N, where K1 is a reasonably constant cost/unit, and K2 is a reasonably constant fixed overhead, although economy of scale might, at some point, see a decrease in K1 and an increase in K2), you'll get a profit curve based on price. The rational price to set is the maximum of that curve. If that maximum is negative, you should stop selling that product.
Other than a commission to the underwriters of what, around 3% I think I read, 55% of the money raised will go to Google, the others will go to current stockholders who are selling their own shares.
All the other stock that already exists won't change a thing. Those people won't get any of the money. The stock they own is already worth whatever the price is going to be, by definition. Only if the stock price shoots up after the IPO will the company be getting less money than it "should" have, and that's what the auction process is designed to inhibit.
Sure, they can set the price to whatever they want, but no one is obligated to buy them at any price above what they bid. They'd have no reason to set the price to something that isn't reasonably close to what they expect the market price to be, and the auction process is a good way of helping to determine that. The bidding and pricing process is pretty clear, I don't see how they can deviate from it - and even in the cases where they only say "we expect to...", they'd need to show a good reason for doing it differently, e.g. they'd need to have a good reason NOT to sell it at the clearing price.
In previous auctions, championed by Hambrecht, market price has generally been stable following the auction. It isn't a guarantee that the company will do well in the longer term, but the auction process should have the effect it is designed to - eliminate the unfair insider's network getting a bunch of shares that are almost guaranteed to shoot way up in the first day. This process gets most of the money to the company offering the shares, which is what selling stock is supposed to do.
The price to the public and allocation of shares will be determined by an auction process. The minimum size for a bid in the auction will be five shares of our Class A common stock. The method for submitting bids and a more detailed description of this auction process are included in "Auction Process" beginning on page34. As part of this auction process, we are attempting to assess the market demand for our ClassA common stock and to set the size and price to the public of this offering to meet that demand. As a result, buyers should not expect to be able to sell their shares for a profit shortly after our Class A common stock begins trading. We will determine the method for allocating shares to bidders who submitted successful bids following the closing of the auction.
The whole thing about "a huge portion of the OS" being in ROM is sort of lame. It had a 64K ROM. The operating system, including the Finder shell, plus two applications (MacWrite and MacPaint) could fit on a 400K diskette, with enough room for some documents. Although 64K matters, it isn't THAT big a deal. Replacing the ROM with more RAM wouldn't made a big difference in the price. With the 128K Mac, you really only had about 88K available, since about 40K was used up for screen, audio and diskette-control memory.
Note that the Lisa could boot into MacWorks (either off of diskette or hard drive), loading a ROM image into memory. The Lisa had either 512K or 1MB of memory, with minimal ROM for booting, plus a debugger.
Having the ROM installed did two things: tied the OS to Apple hardware, and gave a nice graphical boot interface, with the Happy Mac etc. By the time the MacPlus came out, with 1MB RAM and a 20MB hard drive, there was no technical reason why the ROM routines couldn't have been loaded in at boot time.
When I bought a Lisa, there was nothing in a PC that came close. The only drawback was that it was monochrome, but the resolution was so much higher than a PC, it was great. I had been doing a lot of programming using CP/M, so you'd think I'd have wanted to stick with the PC paradigm, but there was just no comparison. I find it funny these days that the biggest complaint about the Mac was that it was "too hard to program" because you had to have THREE WHOLE BOOKS that described the programming environment.
So you bought one of them snazzy new PC's that has SCSI and ADB, right? You forgot floppy disk drives so you could read all of your Mac diskettes on your new PC.
So what all peripherals did you have that you needed SCSI and ADB? And why didn't you just buy SCSI Firewire, ADB USB, Serial USB, Floppy disk USB adapters as necessary? Or add in a SCSI and/or IDE PCI card? You'd need to do the same thing to a PC in order to use your old peripherals. So what did you need serial ports for, MIDI? Are PC (standard, pre-installed) serial ports up to being used for real work yet, or do you still have to go out and get a serial card with real ports that work almost as well as the serial ports Macs have had since, well, since the Lisa.
Punish Apple for doing what everyone wanted, go to the standards being touted by the Wintel crowd, like USB and IDE? What about SATA, Apple is supporting it, yet Best Buy doesn't stock them in-store yet (you can buy them on-line only). I thought SATA was supposed to blow everything else away, and the great advantage was that it was totally compatible with IDE/ATA. You'd think that PC manufacturers by now would be using SATA exclusively.
For display, I'd rather have something in a pair of glasses, preferably in true stereo-vision. If it can do HD-resolution or higher, on a virtual 50" screen at an appropriate distance away, that would be just fine with me. Audio from the earpieces from the glasses.
Virtual projected keyboard is fine, but a data glove interface might work well too. Give it tactile feedback, and use the glasses for the keyboard overlay, and you wouldn't even need a flat surface to project it onto. Another input device might be recent developments in picking up sub-vocal nerve impulses. People on a train, sitting back, typing in midair or sub-vocalizing, might become a very common sight.
That would be cheating the authors! It needs to be lifetime of the author plus one million years. Not a day shorter, otherwise you're not giving an incentive to authors to live longer.
You also have to show that you didn't abandon the invention. And, even if you did invent it first, you have to file within 1 year of anyone (including yourself) using or disclosing it publicly, even if you invented it before they did (but hung on to it, maybe trying to improve it before patenting it). Also, proving the actual date of invention can be difficult. A "signed piece of paper" is probably not enough, you'd have to keep dated detailed notes about the development of the idea, and even then proving the date can be difficult (it isn't particularly convenient or practical to go have your lab notebook notarized every week or so). These days, keeping a running journal on-line and getting it time-stamped and digitally signed by a well-known commercial service might be one way to authenticate the moment of invention.
With software "inventions", it can be even more difficult. You're just sitting there solving problems, trying to get something to work. You're (or at least, I'm) not thinking about it being patentable, any more than I'm thinking about whether there's some stupid patent that I might be infringing. A few years down the road, someone else patents the exact same thing you were doing. Now go back and prove when you first released it, or told someone about the cool hack you figured out to make it work, and even harder, when you first figured out how to do it (if the 1 year disclosure period isn't long enough).
There's one good reason to patent rather than simply disclose. If it turns out that someone else has already patented part of your new invention, but yours is an improvement over it, you could still get patent protection for the improvements. Doesn't let you practice it, but let's you exclude the other inventor from using your improvements as well, unless they come to some agreement with you. It may be worth it to them to allow use in GPL or Open Source projects only if they get to use your improvement to "their" invention.
The problem is defining what qualifies as "prior art". The "prior" part is usually easy, there's usually a clear priority date - if the "invention" was publicly used or disclosed, by anyone, more than one year before the date the patent was filed, then it qualifies. Additionally, if it was "invented" earlier by someone else, then it also qualifies, but that can be a lot harder to prove - the filing date and the 1 year disclosure limit is a lot more straightforward.
The hard part is to show that the particular disclosure actually is the same thing being claimed, and when not exactly the same (and nothing is ever exactly the same), that the differences in the patented invention are "obvious". That's when the real fun begins, because the definition of "obvious" in patent law is totally non-obvious.
So, for example, I once sold "Think Ahead, Impeach Reagan Now" buttons (after he was elected, before he took office). It was on-line, it used a bidding process (the equivalent of a dutch auction), it automatically calculated the optimal price for me to sell at, based on set up costs, per button and quantity discounts. The people ordering were identified solely by their login id, and there was a database of login ids publicly available with real names, addresses, phone numbers, office locations. So, would that be "prior art" for one-click? For a dutch auction held over the Internet on a web site? I'd think so, but I'd have to convince the judge or jury that the wording in the patent about "on a Web site using HTML over the Internet" is not sufficiently different and non-obvious from what I was doing. Maybe the patent says "network method between a client and a server", but we were using a terminal program connecting to a time-shared system. Is that equivalent?
That's the hard part. That, and proving the dates. "Can you prove that this source code you've printed out was actually written in 1979? Can you show us documentation on the system architecture that shows it was using a "network method to communicate between a server and a client"? Can you prove the date on those documents?"
Absolutely. About the time the DEC Alpha came out, we decided it was the perfect platform to emulate a Cyber to run our custom-built system that had been in development for over 20 years at the time. PLATO is written in assembly language, which then implements a timesharing system running a custom-built programming language that the rest of the system was written in. The Alpha was ideal because the Cyber architecture is 60 bits. Handling the one's complement arithmetic was easy, the floating point was fussy but doable, and the result was a machine that ran 5 times faster than the original hardware. That's on a 300MHz Alpha. Today's are much faster. Fall on the floor with your jaw hanging down faster. Too bad that HPaq is dropping it in favor of Itanium.
For the emulator, we took the easy way out, only emulating the CPU instructions. Operating system calls were written in C, no hardware emulation or PPU emulation (PPUs were auxiliary processors that handled all the I/O; large amounts of the operating system were implemented in them, and in actuality they controlled the CPU side, which was effectively a very fast co-processor to the PPUs). To speed things up even more, I wrote a static translator to push out Alpha assembly code for much of the emulated code; that code was linked in as a dynamic library. A bit tricky, as Cyber code is inherently self-modifying, and standard programming practice was to use self-modifying code a fair bit. Using the "native translation" sped up the emulation by up to a factor of 10 times more. It's amazing that you can run around 5,000 simultaneous on-line interactive users on an emulated timesharing system running a pcode-style emulated language on a machine about as powerful as a Mac G5 (dual 1.8GHz, 1GB RAM).
Recently another group of people got together to work on their various Cyber emulators, with one of them (DtCyber) now being fairly mature. It takes a different approach to our "practical" approach, emulating PPUs (including some tricky timing issues), hardware, and all. It can bootstrap various versions of NOS and earlier Cyber operating systems. It isn't nearly as fast as the translated CPU-only emulation, but it is way cooler.
There's a small group of us bringing up a PLATO system on DtCyber for public use. For more information, see my journal entry.
Section 3 says "you may copy and distribute the program in binary form."
Section 4 says "you can only distribute under the terms of the GPL."
Section 6 says "recipient automatically is licensed under the GPL, and you may not modify the terms."
Taken together, if YOU distribute it, you must do so under the GPL, and the person who receives it has full rights under the GPL, binary-only distribution or not. One of those rights is to redistribute the binary, subject to certain restrictions.
Ok, I'm giving up here. We're basically saying the exact same thing, except you keep saying I'm not. We're looking at it from two different viewpoints, one as how it is, one as how it would be if you accept certain conclusions (e.g. from the GPL FAQ). I make a conditional statement, you take either or both the condition and the conclusion as me saying that's how it is. Or, I make a statement with certain conditions (e.g. a 3a distribution), and you say "no, that's not true, since (changed condition, e.g. 3b distribution)".
The more we continue, the less we're communicating. It's been interesting, and has clarified a few points for me, but we're at rapidly diminishing returns now.
Thanks for the exchange! I'd say thanks for the debate, but I'm not really sure it was one.
Oops, put in a < incorrectly, lost most of the second-to-last paragraph:
The "equivalent access" clause (which is a qualifier on what can count as a proper 3a distribution) needs to not have a huge loophole like that either. The FAQ answer that "equivalent access" means you don't charge more for the source than the binaries (i.e. (source + binary) <= 2 * (binary only) seems looser than the base 3a. My additional point is that "you are allowed to charge for the act of copying" should not be interpreted to mean you can make per-megabyte charges, or per-CD charges - to be 3a you specify your price, and that price must include the source, including media or bandwidth charges or whatever to get both the binary and source. You don't HAVE to get the source (you're free to not download the source, or throw away the CD I give you), but you don't get a discount for not taking it. Equivalent access shouldn't be interpreted in terms of price, but in terms of bandwidth available or any other limitations that might prevent you from downloading the source as easily as you downloaded the binary. Again, the whole point is to prevent people from being binary-only distributors by making the source available only if you pay a lot of money or spend 10 weeks downloading or whatever. Remember, it's to my advantage if they choose not to get the source (as long as it stays under 3a), since then the GPL says they can't redistribute the binary, thus preserving my market.
Remember, the "equivalent access " clause is referring to "offering access to copy from a designated place", such as downloading (though not necessarily so). I think you're putting too much weight on equivalent access. My making the copies and offering them to you does not have anything to do with "equivalent access".
In the scenarios regarding selling source and binaries at "separate but equivalent" prices, I was specifically restricting it to 3a distributions. Not 3b, not source-only. The original question was, if I am selling you a binary, can I sell you the source at an additional price and still remain under the conditions of 3a. I'm not offering the sources to you alone at any price, so that isn't a consideration. I'm not making an offer to make a copy at a later time of the sources for no more than my cost of doing so, so that isn't a consideration. I am selling you a copy of the binary for $20, plus charging you $30/CD for the distribution. I explicitly acknowledge that you have the right to the sources. So, do you want the binary CD only for $50, or do you want the binary CD plus the 30 source CDs for $950. Remember, my INTENT here is that I want to be just selling binaries - it doesn't matter in the slightest that someone can buy source CDs somewhere else for less, that isn't the customer base I'm looking for. I'm trying to sell binaries for $50, and remain under 3a ONLY, yet avoid distributing source unless I'm very well paid.
I had originally said that "I had always interpreted 3a as meaning you couldn't charge more (i.e. add an additional charge) for the source." That's 3a, meaning (binary + source). I was making the point that being able to charge additional for the source (under 3a) (i.e. (binary + source) > (binary only)) defeated the purpose of the clause, that source be made available. 3a doesn't say anything about equivalent access, 3a doesn't say anything about source only, 3a doesn't say anything about written offers. If 3a can be interpreted to mean you CAN add an additional charge for the act of distributing the sources (plus the binary), as opposed to just distributing the binary, then it isn't really requiring the sources to be distributed. Thus my interpretation that it can't mean that, it must mean that you can not charge more for (binary + source) than you can for (binary only), under 3a. Originally, your response was essentially that I was nuts, though your later responses repeatedly basically say exactly what I was saying.
The "equivalent access" clause (which is a qualifier on what can count as a proper 3a distribution) needs to not have a huge loophole like that either. The FAQ answer that "equivalent access" means you don't charge more for the source than the binaries (i.e. (source + binary)
You can do that, but you're not likely to stay in business for long. Also, you may be open to false-advertising suits if you advertise "100s of MBs of free software!" and the bulk of it is 0-padding.
It only causes a problem if you want the source, most people only want the binary, so none of the customers I want to sell to are affected (unlike those busy-body free software advocates, I don't want them as customers anyway!). And I never advertised the source code, certainly not how big it was. Besides, all those zeroes are certainly free, and I'm distributing them as completely public domain.
Short answer: no. You can not restrict redistribution of the binary, the only restrictions are those the GPL makes, which are the ones regarding distributing source and not adding any additional restrictions.
This is pretty cool, I think we're converging on agreement.
I had said in an earlier message that However, I had always interpreted the 3a rule as not allowing an additional charge for the source code, which you disagreed with: "I dont see how you could make such an interpretation." I see now we simply failed to communicate, as what I was referring to was "here's the binary for $20, do you want the source CD for another $20" - that's "an additional charge for the source code" under 3a. This was in response to the GPL FAQ's claim that you could, when providing the binary by download (for a fee) charge an additional fee for transferring the source code (and still be under 3a):
Does the GPL allow me to charge a fee for downloading the program from my site?
Yes. You can charge any fee you wish for distributing a copy of the program. If you distribute binaries by download, you must provide "equivalent access" to download the source--therefore, the fee to download source may not be greater than the fee to download the binary.
which seems at odds with not being able to make an additional charge for the source CD (again, to clarify, above what you're already charging for the binary CD). In addition, the above FAQ answer is not clear if "the fee" can be a per-megabyte fee, which can be easily abused by grossly packing the source tar file with lots of extraneous junk. In other words, if my "fee for downloading source" is the same as my fee for downloading binaries, which is $5/megabyte for a 4 megabyte binary, and I pack the source tar file with the source packages for gcc, glibc, make, bash, texinfo, binutils, textutils, fileutils, shellutils, binutils, and emacs, I'm going to be doing exactly what you said: binary for $REASONABLE_AMOUNT, source for $TOTALLY_RIDICULOUS_AMOUNT_THAT_I_CAN_RETIRE_ON, effectively making a binary-only distribution. That's what I'm talking about with this, and that could easily be considered "equivalent access" as the GPL requires for a 3a distribution by download. Remember that I'm coming at this from the viewpoint of the unscrupulous distributor trying to circumvent the GPL.
I said If I can charge you a different amount for "binary + source" than "binary (but I offered you source and you didn't want it)", and both fall under 3a (thus no written offer, no obligation to provide source in the future), then that seems to defeat the purpose. to which you responded: "What purpose?" The purpose I was referring to is the GPL's, which is to make sure that anyone who receives a copy of the binary can get a copy of the source for reasonable terms. I see a conflict with your responses; on the one hand, your explanation of "No you cant, because then you're not distributing the source with the binaries obviously. " is pretty much exactly what I was trying to get at, but then you also agree that you can charge whatever you want for physical media. So, does that mean I can (under 3a, remember) sell you a binary for $20, including the source, for a fee of $30 per CD - the binary is on one CD, the source is on 100 more (because I thoughtfully included a copy of the first 10 GB of/dev/zero on the source tar file, which I neglected to compress; and I didn't know you could put more than 100 MB per CD!), so that'll be another $3000 if you want the source.
that's a 3b distribution and now they (and anyone else) can get the source from you at cost.
Right. Though, we're not sure about what "and anyone else" means exactly, remember?:)
Exactly. I figured we've already beaten that horse into dog food.
From your description, that sounds like it is changing the default system time format for more than just the clock display. Even if it isn't, an inexperienced user is going to be afraid to change it, and an experienced user is going to waste time determining if it is or isn't. And if it is changing the default, then you still don't have a solution to how to make THIS clock display in 24 hour format and not change the default for other programs that use that setting.
Slashdot Mirror
It isn't that the brain isn't "satisfied" simply because yellow is being formed from red and green; it's that different eyes will have different responses to true yellow, and to the red and green phosphors. If trying to reproduce something that was originally true yellow, instead of being made of the exact frequencies of the phosphors, it won't look the same yellow to everyone. Increasing the number of discrete frequencies being detected, transmitted and reproduced, would reduce the amount of error for anyone who doesn't match the exact sensitivity used in the design of the camera/monitor system.
Of course, RGB can't really reproduce a "true yellow" anyway (the effect on the blue cones will be different between a true yellow and the closest mix you can get in RGB, leading to a slightly less saturated-looking yellow than "true").
That's only if you make cyan be a mixture of blue and green. If, instead, you make cyan be cyan light (a frequency between green and blue), it doesn't do that at all.
I'd think that at least some artists would be concerned about the actual spectral values of the colors they're using. There are many different combinations of spectra that yield the same perception to an individual eye - but maybe different perceptions to different people, e.g. the difference between a true "orange" pigment (reflects only orange light), and one that reflects a mix of red and yellow or red and green (by absorbing mostly blue). The differences will also be noticeable in different lighting conditions.
Rods have their own characteristic sensitivity curve, just as the red/green/yellow-green cones. See Cone cell, for example. In strong light, rods are fully saturated, so they can't do much effective color sensing. In medium light (mesopic), rods and cones are all active, and thus rods might well have an effect on color perception.
Apparently, violet light also stimulates the yellow-green cones as well, which is why purple (a mix of red and blue) and violet are perceptually similar. I'd expect true violet and indigo light (which can not be represented in RGB) to stimulate the green receptor less than a RB mix.
If we weren't so insensitive to blue light in general, maybe an enhanced-primary system would include violet or indigo. Adding Cyan and Yellow makes sense, though.
What's really needed is a multi-spectral recorder - this would reduce the differences people will see between "real life" and a reproduction due to individual differences in spectral sensitivity (including extremes such as color-blindness).
The whole point of using a heat pump is that it is more efficient. They aren't appropriate in some climates, but where they are they work well. What's your source for them being inefficient? Also, how do you mean "uncomfortable heat"? The only difference in heating is the temperature of the air being heated and the humidity. How is a heat pump more uncomfortable?
Ummm, as demand goes down, so does price. Price goes up as demand goes up and supply goes down. That's "simple supply and demand economics".
Now, it may well be that, as demand goes down, you have to raise prices in order to meet costs. That's "simple economy of scale" economics. Or "simple bankruptcy" economics, if you've now priced yourself out of the market (demand * price curve is decreasing with increasing price, means you make less money as you increase the price).
"demand" is based on price - at a given price, you'll have a certain number of people who will buy at that price. If you plot demand * price, then subtract demand * cost (where cost is cost/unit at that quantity - often can be expressed as K1 + K2/N, where K1 is a reasonably constant cost/unit, and K2 is a reasonably constant fixed overhead, although economy of scale might, at some point, see a decrease in K1 and an increase in K2), you'll get a profit curve based on price. The rational price to set is the maximum of that curve. If that maximum is negative, you should stop selling that product.
It wouldn't be any worse than it looked in the theater, wearing the red/blue glasses.
Other than a commission to the underwriters of what, around 3% I think I read, 55% of the money raised will go to Google, the others will go to current stockholders who are selling their own shares.
All the other stock that already exists won't change a thing. Those people won't get any of the money. The stock they own is already worth whatever the price is going to be, by definition. Only if the stock price shoots up after the IPO will the company be getting less money than it "should" have, and that's what the auction process is designed to inhibit.
Sure, they can set the price to whatever they want, but no one is obligated to buy them at any price above what they bid. They'd have no reason to set the price to something that isn't reasonably close to what they expect the market price to be, and the auction process is a good way of helping to determine that. The bidding and pricing process is pretty clear, I don't see how they can deviate from it - and even in the cases where they only say "we expect to ...", they'd need to show a good reason for doing it differently, e.g. they'd need to have a good reason NOT to sell it at the clearing price.
In previous auctions, championed by Hambrecht, market price has generally been stable following the auction. It isn't a guarantee that the company will do well in the longer term, but the auction process should have the effect it is designed to - eliminate the unfair insider's network getting a bunch of shares that are almost guaranteed to shoot way up in the first day. This process gets most of the money to the company offering the shares, which is what selling stock is supposed to do.
From the prospectus:
The whole thing about "a huge portion of the OS" being in ROM is sort of lame. It had a 64K ROM. The operating system, including the Finder shell, plus two applications (MacWrite and MacPaint) could fit on a 400K diskette, with enough room for some documents. Although 64K matters, it isn't THAT big a deal. Replacing the ROM with more RAM wouldn't made a big difference in the price. With the 128K Mac, you really only had about 88K available, since about 40K was used up for screen, audio and diskette-control memory.
Note that the Lisa could boot into MacWorks (either off of diskette or hard drive), loading a ROM image into memory. The Lisa had either 512K or 1MB of memory, with minimal ROM for booting, plus a debugger.
Having the ROM installed did two things: tied the OS to Apple hardware, and gave a nice graphical boot interface, with the Happy Mac etc. By the time the MacPlus came out, with 1MB RAM and a 20MB hard drive, there was no technical reason why the ROM routines couldn't have been loaded in at boot time.
When I bought a Lisa, there was nothing in a PC that came close. The only drawback was that it was monochrome, but the resolution was so much higher than a PC, it was great. I had been doing a lot of programming using CP/M, so you'd think I'd have wanted to stick with the PC paradigm, but there was just no comparison. I find it funny these days that the biggest complaint about the Mac was that it was "too hard to program" because you had to have THREE WHOLE BOOKS that described the programming environment.
So you bought one of them snazzy new PC's that has SCSI and ADB, right? You forgot floppy disk drives so you could read all of your Mac diskettes on your new PC.
So what all peripherals did you have that you needed SCSI and ADB? And why didn't you just buy SCSI Firewire, ADB USB, Serial USB, Floppy disk USB adapters as necessary? Or add in a SCSI and/or IDE PCI card? You'd need to do the same thing to a PC in order to use your old peripherals. So what did you need serial ports for, MIDI? Are PC (standard, pre-installed) serial ports up to being used for real work yet, or do you still have to go out and get a serial card with real ports that work almost as well as the serial ports Macs have had since, well, since the Lisa.
Punish Apple for doing what everyone wanted, go to the standards being touted by the Wintel crowd, like USB and IDE? What about SATA, Apple is supporting it, yet Best Buy doesn't stock them in-store yet (you can buy them on-line only). I thought SATA was supposed to blow everything else away, and the great advantage was that it was totally compatible with IDE/ATA. You'd think that PC manufacturers by now would be using SATA exclusively.
For display, I'd rather have something in a pair of glasses, preferably in true stereo-vision. If it can do HD-resolution or higher, on a virtual 50" screen at an appropriate distance away, that would be just fine with me. Audio from the earpieces from the glasses.
Virtual projected keyboard is fine, but a data glove interface might work well too. Give it tactile feedback, and use the glasses for the keyboard overlay, and you wouldn't even need a flat surface to project it onto. Another input device might be recent developments in picking up sub-vocal nerve impulses. People on a train, sitting back, typing in midair or sub-vocalizing, might become a very common sight.
That would be cheating the authors! It needs to be lifetime of the author plus one million years. Not a day shorter, otherwise you're not giving an incentive to authors to live longer.
Personally, I want 64 bits (and have it, in the form of Alphas and Mac G5s) to emulate 60-bit processors.
It will also speed up Java using 64-bit integers.
There are many programming tricks that can use long word sizes to do interesting things using bitwise logical operations.
You also have to show that you didn't abandon the invention. And, even if you did invent it first, you have to file within 1 year of anyone (including yourself) using or disclosing it publicly, even if you invented it before they did (but hung on to it, maybe trying to improve it before patenting it). Also, proving the actual date of invention can be difficult. A "signed piece of paper" is probably not enough, you'd have to keep dated detailed notes about the development of the idea, and even then proving the date can be difficult (it isn't particularly convenient or practical to go have your lab notebook notarized every week or so). These days, keeping a running journal on-line and getting it time-stamped and digitally signed by a well-known commercial service might be one way to authenticate the moment of invention.
With software "inventions", it can be even more difficult. You're just sitting there solving problems, trying to get something to work. You're (or at least, I'm) not thinking about it being patentable, any more than I'm thinking about whether there's some stupid patent that I might be infringing. A few years down the road, someone else patents the exact same thing you were doing. Now go back and prove when you first released it, or told someone about the cool hack you figured out to make it work, and even harder, when you first figured out how to do it (if the 1 year disclosure period isn't long enough).
There's one good reason to patent rather than simply disclose. If it turns out that someone else has already patented part of your new invention, but yours is an improvement over it, you could still get patent protection for the improvements. Doesn't let you practice it, but let's you exclude the other inventor from using your improvements as well, unless they come to some agreement with you. It may be worth it to them to allow use in GPL or Open Source projects only if they get to use your improvement to "their" invention.
The problem is defining what qualifies as "prior art". The "prior" part is usually easy, there's usually a clear priority date - if the "invention" was publicly used or disclosed, by anyone, more than one year before the date the patent was filed, then it qualifies. Additionally, if it was "invented" earlier by someone else, then it also qualifies, but that can be a lot harder to prove - the filing date and the 1 year disclosure limit is a lot more straightforward.
The hard part is to show that the particular disclosure actually is the same thing being claimed, and when not exactly the same (and nothing is ever exactly the same), that the differences in the patented invention are "obvious". That's when the real fun begins, because the definition of "obvious" in patent law is totally non-obvious.
So, for example, I once sold "Think Ahead, Impeach Reagan Now" buttons (after he was elected, before he took office). It was on-line, it used a bidding process (the equivalent of a dutch auction), it automatically calculated the optimal price for me to sell at, based on set up costs, per button and quantity discounts. The people ordering were identified solely by their login id, and there was a database of login ids publicly available with real names, addresses, phone numbers, office locations. So, would that be "prior art" for one-click? For a dutch auction held over the Internet on a web site? I'd think so, but I'd have to convince the judge or jury that the wording in the patent about "on a Web site using HTML over the Internet" is not sufficiently different and non-obvious from what I was doing. Maybe the patent says "network method between a client and a server", but we were using a terminal program connecting to a time-shared system. Is that equivalent?
That's the hard part. That, and proving the dates. "Can you prove that this source code you've printed out was actually written in 1979? Can you show us documentation on the system architecture that shows it was using a "network method to communicate between a server and a client"? Can you prove the date on those documents?"
Absolutely. About the time the DEC Alpha came out, we decided it was the perfect platform to emulate a Cyber to run our custom-built system that had been in development for over 20 years at the time. PLATO is written in assembly language, which then implements a timesharing system running a custom-built programming language that the rest of the system was written in. The Alpha was ideal because the Cyber architecture is 60 bits. Handling the one's complement arithmetic was easy, the floating point was fussy but doable, and the result was a machine that ran 5 times faster than the original hardware. That's on a 300MHz Alpha. Today's are much faster. Fall on the floor with your jaw hanging down faster. Too bad that HPaq is dropping it in favor of Itanium.
For the emulator, we took the easy way out, only emulating the CPU instructions. Operating system calls were written in C, no hardware emulation or PPU emulation (PPUs were auxiliary processors that handled all the I/O; large amounts of the operating system were implemented in them, and in actuality they controlled the CPU side, which was effectively a very fast co-processor to the PPUs). To speed things up even more, I wrote a static translator to push out Alpha assembly code for much of the emulated code; that code was linked in as a dynamic library. A bit tricky, as Cyber code is inherently self-modifying, and standard programming practice was to use self-modifying code a fair bit. Using the "native translation" sped up the emulation by up to a factor of 10 times more. It's amazing that you can run around 5,000 simultaneous on-line interactive users on an emulated timesharing system running a pcode-style emulated language on a machine about as powerful as a Mac G5 (dual 1.8GHz, 1GB RAM).
Recently another group of people got together to work on their various Cyber emulators, with one of them (DtCyber) now being fairly mature. It takes a different approach to our "practical" approach, emulating PPUs (including some tricky timing issues), hardware, and all. It can bootstrap various versions of NOS and earlier Cyber operating systems. It isn't nearly as fast as the translated CPU-only emulation, but it is way cooler.
There's a small group of us bringing up a PLATO system on DtCyber for public use. For more information, see my journal entry.
Section 3 says "you may copy and distribute the program in binary form."
Section 4 says "you can only distribute under the terms of the GPL."
Section 6 says "recipient automatically is licensed under the GPL, and you may not modify the terms."
Taken together, if YOU distribute it, you must do so under the GPL, and the person who receives it has full rights under the GPL, binary-only distribution or not. One of those rights is to redistribute the binary, subject to certain restrictions.
Ok, I'm giving up here. We're basically saying the exact same thing, except you keep saying I'm not. We're looking at it from two different viewpoints, one as how it is, one as how it would be if you accept certain conclusions (e.g. from the GPL FAQ). I make a conditional statement, you take either or both the condition and the conclusion as me saying that's how it is. Or, I make a statement with certain conditions (e.g. a 3a distribution), and you say "no, that's not true, since (changed condition, e.g. 3b distribution)".
The more we continue, the less we're communicating. It's been interesting, and has clarified a few points for me, but we're at rapidly diminishing returns now.
Thanks for the exchange! I'd say thanks for the debate, but I'm not really sure it was one.
Oops, put in a < incorrectly, lost most of the second-to-last paragraph:
The "equivalent access" clause (which is a qualifier on what can count as a proper 3a distribution) needs to not have a huge loophole like that either. The FAQ answer that "equivalent access" means you don't charge more for the source than the binaries (i.e. (source + binary) <= 2 * (binary only) seems looser than the base 3a. My additional point is that "you are allowed to charge for the act of copying" should not be interpreted to mean you can make per-megabyte charges, or per-CD charges - to be 3a you specify your price, and that price must include the source, including media or bandwidth charges or whatever to get both the binary and source. You don't HAVE to get the source (you're free to not download the source, or throw away the CD I give you), but you don't get a discount for not taking it. Equivalent access shouldn't be interpreted in terms of price, but in terms of bandwidth available or any other limitations that might prevent you from downloading the source as easily as you downloaded the binary. Again, the whole point is to prevent people from being binary-only distributors by making the source available only if you pay a lot of money or spend 10 weeks downloading or whatever. Remember, it's to my advantage if they choose not to get the source (as long as it stays under 3a), since then the GPL says they can't redistribute the binary, thus preserving my market.
Remember, the "equivalent access " clause is referring to "offering access to copy from a designated place", such as downloading (though not necessarily so). I think you're putting too much weight on equivalent access. My making the copies and offering them to you does not have anything to do with "equivalent access".
In the scenarios regarding selling source and binaries at "separate but equivalent" prices, I was specifically restricting it to 3a distributions. Not 3b, not source-only. The original question was, if I am selling you a binary, can I sell you the source at an additional price and still remain under the conditions of 3a. I'm not offering the sources to you alone at any price, so that isn't a consideration. I'm not making an offer to make a copy at a later time of the sources for no more than my cost of doing so, so that isn't a consideration. I am selling you a copy of the binary for $20, plus charging you $30/CD for the distribution. I explicitly acknowledge that you have the right to the sources. So, do you want the binary CD only for $50, or do you want the binary CD plus the 30 source CDs for $950. Remember, my INTENT here is that I want to be just selling binaries - it doesn't matter in the slightest that someone can buy source CDs somewhere else for less, that isn't the customer base I'm looking for. I'm trying to sell binaries for $50, and remain under 3a ONLY, yet avoid distributing source unless I'm very well paid.
I had originally said that "I had always interpreted 3a as meaning you couldn't charge more (i.e. add an additional charge) for the source." That's 3a, meaning (binary + source). I was making the point that being able to charge additional for the source (under 3a) (i.e. (binary + source) > (binary only)) defeated the purpose of the clause, that source be made available. 3a doesn't say anything about equivalent access, 3a doesn't say anything about source only, 3a doesn't say anything about written offers. If 3a can be interpreted to mean you CAN add an additional charge for the act of distributing the sources (plus the binary), as opposed to just distributing the binary, then it isn't really requiring the sources to be distributed. Thus my interpretation that it can't mean that, it must mean that you can not charge more for (binary + source) than you can for (binary only), under 3a. Originally, your response was essentially that I was nuts, though your later responses repeatedly basically say exactly what I was saying.
The "equivalent access" clause (which is a qualifier on what can count as a proper 3a distribution) needs to not have a huge loophole like that either. The FAQ answer that "equivalent access" means you don't charge more for the source than the binaries (i.e. (source + binary)
It only causes a problem if you want the source, most people only want the binary, so none of the customers I want to sell to are affected (unlike those busy-body free software advocates, I don't want them as customers anyway!). And I never advertised the source code, certainly not how big it was. Besides, all those zeroes are certainly free, and I'm distributing them as completely public domain.
Short answer: no. You can not restrict redistribution of the binary, the only restrictions are those the GPL makes, which are the ones regarding distributing source and not adding any additional restrictions.
This is pretty cool, I think we're converging on agreement.
I had said in an earlier message that However, I had always interpreted the 3a rule as not allowing an additional charge for the source code, which you disagreed with: "I dont see how you could make such an interpretation." I see now we simply failed to communicate, as what I was referring to was "here's the binary for $20, do you want the source CD for another $20" - that's "an additional charge for the source code" under 3a. This was in response to the GPL FAQ's claim that you could, when providing the binary by download (for a fee) charge an additional fee for transferring the source code (and still be under 3a):
which seems at odds with not being able to make an additional charge for the source CD (again, to clarify, above what you're already charging for the binary CD). In addition, the above FAQ answer is not clear if "the fee" can be a per-megabyte fee, which can be easily abused by grossly packing the source tar file with lots of extraneous junk. In other words, if my "fee for downloading source" is the same as my fee for downloading binaries, which is $5/megabyte for a 4 megabyte binary, and I pack the source tar file with the source packages for gcc, glibc, make, bash, texinfo, binutils, textutils, fileutils, shellutils, binutils, and emacs, I'm going to be doing exactly what you said: binary for $REASONABLE_AMOUNT, source for $TOTALLY_RIDICULOUS_AMOUNT_THAT_I_CAN_RETIRE_ON, effectively making a binary-only distribution. That's what I'm talking about with this, and that could easily be considered "equivalent access" as the GPL requires for a 3a distribution by download. Remember that I'm coming at this from the viewpoint of the unscrupulous distributor trying to circumvent the GPL.I said If I can charge you a different amount for "binary + source" than "binary (but I offered you source and you didn't want it)", and both fall under 3a (thus no written offer, no obligation to provide source in the future), then that seems to defeat the purpose. to which you responded: "What purpose?" The purpose I was referring to is the GPL's, which is to make sure that anyone who receives a copy of the binary can get a copy of the source for reasonable terms. I see a conflict with your responses; on the one hand, your explanation of "No you cant, because then you're not distributing the source with the binaries obviously. " is pretty much exactly what I was trying to get at, but then you also agree that you can charge whatever you want for physical media. So, does that mean I can (under 3a, remember) sell you a binary for $20, including the source, for a fee of $30 per CD - the binary is on one CD, the source is on 100 more (because I thoughtfully included a copy of the first 10 GB of /dev/zero on the source tar file, which I neglected to compress; and I didn't know you could put more than 100 MB per CD!), so that'll be another $3000 if you want the source.
Exactly. I figured we've already beaten that horse into dog food.
From your description, that sounds like it is changing the default system time format for more than just the clock display. Even if it isn't, an inexperienced user is going to be afraid to change it, and an experienced user is going to waste time determining if it is or isn't. And if it is changing the default, then you still don't have a solution to how to make THIS clock display in 24 hour format and not change the default for other programs that use that setting.