I'd wager it's homegrown -- they can hook into the API that notifies of file changes (See Amit Singh's blog for info) and just stuff the versions off in the background somewhere -- Throw a little database on top of it to log versions (CoreData) and there you have it. Make a pretty UI with CoreAnimation and ship it...
@@SCOPE_IDENTITY is IMO a better option because if your table has triggers attached that do data operations (think audit logging) then @@IDENTITY can change, but @@SCOPE_IDENTITY won't.
Makes sense when you look at it from that perspective -- I had always assumed (given the "for the user" leanings of the GPL) that it was the _user's_ option to bind themselves to later versions of the license.
From that perspective then, it appears that the GPL (or, indeed, ANY licence with an "upgrade" clause that doesn't allow retroactive changes like that) is a problem waiting to happen. Developers are dependent upon the creator of the license to Do No Evil with the future revisions of the license. That's an awful lot of trust to put in someone else's hands, IMO.
Not wanting to get into a flamefest here, but a few points...
Even though a product may be commercial, if it is GPL it instantly becomes free-as-in-beer the second one person buys it -- because they have the source, they can do whatever they want with it (within the terms of the GPL of course) -- Which means they can freely give away copies, fork the source, put the source out on an ftp server, whatever... No more income for the initial developer.
Now I'm not saying that all the money just dries up instantly (that would be silly), but the software is _effectively_ free-as-in-beer, even though people _may_ _choose_ to continue to purchase it.
The second point has to do with GPL versioning. Now, I just re-read the GPL to be sure, and in Section 9 it states that the author may specify a version which governs it. The "and any later version" clause is optional. This raises a few questions:
1) Can another person relicense the software under a newer version? This seems a question for the legal types...
2) The boilerplate text that the FSF recommends to include in each source file include the "any later version" clause. Now granted, it is the responsibility of the programmer to verify the licencing terms they wish to operate under, but I bet many of them just copy the boilerplate text.
3) What happens if a program is licensed under GPLv2, and GPLv3 comes out and demands sacrifice of your firstborn, or some other unsavory licence term. Can a program be retroactively changed to remove the "any later version" clause?
Don't ask me how I remember that. IIRC, I read in an interview that the dog also was involved in the chip design -- Dave Heinie(?) said that Jay would ask the dog whether to include a gate or not, and if the dog barked, the gate would go in -- otherwise not.
Computers today are missing this kind of hobbyist spirit that infused the Amiga... I had more enjoyment coding for that system than anything else, ever.
Found my password, re-posting my post so it gets seen:P
A slight clarification, if memory serves... The blitter (which I believe lived on the 'Fat' Agnes chip, along with the copper) was a general-purpose data mover. Set source & destination addresses, define which of 256 possible transformations you wanted it to do, and let it rip. This was useful when doing video games, obviously, but I remeber someone re-wrote Conway's Game of Life to use the blitter as a computation engine. It could play an entire round with 9 blits, which meant the game SCREAMED, especially compared to other hardware of the time which had to do all the work in the cpu.
Now the copper was literally another CPU of sorts, except it only had 4 instructions (read, write, skip and wait IIRC). The neat trick to do with the copper was to use the CPU to write a copper program during the vblank (when the CPU had full access to the bus), and then during the frame, the copper program would execute, making calls to the blitter, sound chips (denise? paula? one was sound, the other was the floppy controller). This is where the "copper bars" demos came about from -- just the copper executing a program to make calls to the display chips to change screen background colors on the fly, including the overscan areas.
Ok, the CEO just said that they will NOT be selling the cpu's directly to end users... oem's only --- also, he mentioned some linux tweaks they did for mobile processing...
Slashdot Mirror
It's old timer's day here on /.!
Something else that I just noticed that went unmentioned (look in right side of http://www.apple.com/macosx/leopard/xcode.html)
"Modern garbage collection" in Obj-C!!!!
/me impatiently keeps reloading the xcode page...
I'd wager it's homegrown -- they can hook into the API that notifies of file changes (See Amit Singh's blog for info) and just stuff the versions off in the background somewhere -- Throw a little database on top of it to log versions (CoreData) and there you have it. Make a pretty UI with CoreAnimation and ship it...
/me gets his walker out...
five digits? bah, whippersnappers
No. That was easy. Nothing to see here, move along, move along
Nice DT reference in your sig
Ooh, my blankie! All soft and fuzzy!
Eh?
/. with lower id's to show up and post)
(waits patiently for the handful people still active on
McDonalds is ALREADY an affront to mankind
HOLY SHIT!
@@SCOPE_IDENTITY is IMO a better option because if your table has triggers attached that do data operations (think audit logging) then @@IDENTITY can change, but @@SCOPE_IDENTITY won't.
Makes sense when you look at it from that perspective -- I had always assumed (given the "for the user" leanings of the GPL) that it was the _user's_ option to bind themselves to later versions of the license.
From that perspective then, it appears that the GPL (or, indeed, ANY licence with an "upgrade" clause that doesn't allow retroactive changes like that) is a problem waiting to happen. Developers are dependent upon the creator of the license to Do No Evil with the future revisions of the license. That's an awful lot of trust to put in someone else's hands, IMO.
Not wanting to get into a flamefest here, but a few points...
Even though a product may be commercial, if it is GPL it instantly becomes free-as-in-beer the second one person buys it -- because they have the source, they can do whatever they want with it (within the terms of the GPL of course) -- Which means they can freely give away copies, fork the source, put the source out on an ftp server, whatever... No more income for the initial developer.
Now I'm not saying that all the money just dries up instantly (that would be silly), but the software is _effectively_ free-as-in-beer, even though people _may_ _choose_ to continue to purchase it.
The second point has to do with GPL versioning. Now, I just re-read the GPL to be sure, and in Section 9 it states that the author may specify a version which governs it. The "and any later version" clause is optional. This raises a few questions:
1) Can another person relicense the software under a newer version? This seems a question for the legal types...
2) The boilerplate text that the FSF recommends to include in each source file include the "any later version" clause. Now granted, it is the responsibility of the programmer to verify the licencing terms they wish to operate under, but I bet many of them just copy the boilerplate text.
3) What happens if a program is licensed under GPLv2, and GPLv3 comes out and demands sacrifice of your firstborn, or some other unsavory licence term. Can a program be retroactively changed to remove the "any later version" clause?
Beware, that statement is contrary to slashthink, prepare to get flamed into oblivion.
Yes
Sorry, can't do 1/10, but how about a uid of 1/2 of yours... Besides, right shifting uid's is more geeky than divison by 10 :)
Misha -- Jay's dog's name was Misha
Don't ask me how I remember that. IIRC, I read in an interview that the dog also was involved in the chip design -- Dave Heinie(?) said that Jay would ask the dog whether to include a gate or not, and if the dog barked, the gate would go in -- otherwise not.
Computers today are missing this kind of hobbyist spirit that infused the Amiga... I had more enjoyment coding for that system than anything else, ever.
Found my password, re-posting my post so it gets seen :P
:P
A slight clarification, if memory serves... The blitter (which I believe lived on the 'Fat' Agnes chip, along with the copper) was a general-purpose data mover. Set source & destination addresses, define which of 256 possible transformations you wanted it to do, and let it rip. This was useful when doing video games, obviously, but I remeber someone re-wrote Conway's Game of Life to use the blitter as a computation engine. It could play an entire round with 9 blits, which meant the game SCREAMED, especially compared to other hardware of the time which had to do all the work in the cpu.
Now the copper was literally another CPU of sorts, except it only had 4 instructions (read, write, skip and wait IIRC). The neat trick to do with the copper was to use the CPU to write a copper program during the vblank (when the CPU had full access to the bus), and then during the frame, the copper program would execute, making calls to the blitter, sound chips (denise? paula? one was sound, the other was the floppy controller). This is where the "copper bars" demos came about from -- just the copper executing a program to make calls to the display chips to change screen background colors on the fly, including the overscan areas.
I spent way too much time coding my amiga
I don't post enough to have karma to burn, but what the hell :)
JOGL (www.javagaming.org)
How about me? 3 digits baby! :)
Ok, the CEO just said that they will NOT be selling the cpu's directly to end users... oem's only --- also, he mentioned some linux tweaks they did for mobile processing...