Robert Cringely has an idea that may or may not ultimately be legal, but that would instantly change the complexion of the debates over copyright in music recording.
The beauty of Cringely’s proposal is that he’s writing on behalf of reality, the reality of a change in the structures that make necessary (or unnecessary) an industry for compiling and distributing recorded music. No doubt he looks forward to getting inexpensive, legal copies of his favorite performances — but the driving force for his argument comes from his frustration at the way that the music oligopolies are posturing and threatening to hold back technological change, in order to perpetuate a defunct business model.
I know nothing about investments, and I know nothing about the legalities of corporate “beneficial ownership.” But if Cringely has his way, I will take up every cent at my disposal to buy some of the shares he describes — not just for the music, not just for the investment value, but because he ought to be supported in his effort to force the so-called free market actually to make sense.
I came to Cringely via boingboing, where Xeni notes that Roxio Corp. owns the Snapster trademark. One may take that as a positive sign, since Roxio markets the Toast CD-burning software that would be especially useful under a Snapster regime, or one may take it as a negative sign that Roxio’s already in place to impede implementing such an idea. I don’care. Call it “Enrique,” or whatever — just get it started, and let the industries that hold music hostage get out of the way.
Posted by AKMA at July 25, 2003 09:32 AM | TrackBackThe most basic duality that exists with variables is how the programmer sees them in a totally different way than the computer does. When you're typing away in Project Builder, your variables are normal words smashed together, like software titles from the 80s. You deal with them on this level, moving them around and passing them back and forth.
Posted by: Petronella at January 12, 2004 11:06 PMNote first that favoriteNumbers type changed. Instead of our familiar int, we're now using int*. The asterisk here is an operator, which is often called the "star operator". You will remember that we also use an asterisk as a sign for multiplication. The positioning of the asterisk changes its meaning. This operator effectively means "this is a pointer". Here it says that favoriteNumber will be not an int but a pointer to an int. And instead of simply going on to say what we're putting in that int, we have to take an extra step and create the space, which is what does. This function takes an argument that specifies how much space you need and then returns a pointer to that space. We've passed it the result of another function, , which we pass int, a type. In reality, is a macro, but for now we don't have to care: all we need to know is that it tells us the size of whatever we gave it, in this case an int. So when is done, it gives us an address in the heap where we can put an integer. It is important to remember that the data is stored in the heap, while the address of that data is stored in a pointer on the stack.
Posted by: Hugh at January 12, 2004 11:06 PMWhen compared to the Stack, the Heap is a simple thing to understand. All the memory that's left over is "in the Heap" (excepting some special cases and some reserve). There is little structure, but in return for this freedom of movement you must create and destroy any boundaries you need. And it is always possible that the heap might simply not have enough space for you.
Posted by: Alan at January 12, 2004 11:06 PMInside each stack frame is a slew of useful information. It tells the computer what code is currently executing, where to go next, where to go in the case a return statement is found, and a whole lot of other things that are incredible useful to the computer, but not very useful to you most of the time. One of the things that is useful to you is the part of the frame that keeps track of all the variables you're using. So the first place for a variable to live is on the Stack. This is a very nice place to live, in that all the creation and destruction of space is handled for you as Stack Frames are created and destroyed. You seldom have to worry about making space for the variables on the stack. The only problem is that the variables here only live as long as the stack frame does, which is to say the length of the function those variables are declared in. This is often a fine situation, but when you need to store information for longer than a single function, you are instantly out of luck.
Posted by: Richard at January 13, 2004 12:36 PMOur next line looks familiar, except it starts with an asterisk. Again, we're using the star operator, and noting that this variable we're working with is a pointer. If we didn't, the computer would try to put the results of the right hand side of this statement (which evaluates to 6) into the pointer, overriding the value we need in the pointer, which is an address. This way, the computer knows to put the data not in the pointer, but into the place the pointer points to, which is in the Heap. So after this line, our int is living happily in the Heap, storing a value of 6, and our pointer tells us where that data is living.
Posted by: Phillip at January 13, 2004 12:36 PMLet's take a moment to reexamine that. What we've done here is create two variables. The first variable is in the Heap, and we're storing data in it. That's the obvious one. But the second variable is a pointer to the first one, and it exists on the Stack. This variable is the one that's really called favoriteNumber, and it's the one we're working with. It is important to remember that there are now two parts to our simple variable, one of which exists in each world. This kind of division is common is C, but omnipresent in Cocoa. When you start making objects, Cocoa makes them all in the Heap because the Stack isn't big enough to hold them. In Cocoa, you deal with objects through pointers everywhere and are actually forbidden from dealing with them directly.
Posted by: Elizabeth at January 13, 2004 12:38 PM