Actually, this product is older than Cherry OS. The GPL volations were discovered after, that's all. I think they probably started behaving with Cherry OS in an effort to stop this from being spotted.
Now imagine if Microsoft hadn't given away IE with their operating system. Netscape still would have failed, only a bit later, because now there's Firefox which is free and better. If Microsoft didn't package IE with Windows, PC manufacturers surely would have packaged Firefox with them instead.
I agree with the rest of your post), but this part is just absurd. Netscape's failure caused Firefox's existence. If Microsoft hadn't given away IE, perhaps something would have killed Netscape anyway... but it certainly wouldn't have been Firefox.
The last should read: It would be insane to suggest Apple not leverage Quartz. That's what Quartz was created for. And there's certainly no provision on the LGPL that source compatibility for all previously supported platforms must be maintained in a fork.
Apple is providing full source to their web kit, which is a supset of KHTML. What they are not providing is the source code to Quartz, one of the basic components of Mac OS X, which their web kit (including their version of KHTML) calls. Thus, Apple's KHTML compiles only for Mac OS X.
It would be insane to suggest Apple not leverage Quartz. That's what Quartz was created for. And there's certainly no provision on the LGPL that source compatibility must be maintained in a fork.
What you should be asking yourself is "why not read the article?"
Apple has given back the changes. Apple has even built a new framework around KHTML. What Apple hasn't done is do all the integration work for the KHTML people. Who are now whining about how hard the changes are to work back in.
The KHTML team doesn't seem to be working very hard, so a fork happens. Forks happen. They rarely stop at one, either. I expect sooner or later we'll see another fork of KHTML that will try to bring the Apple changes onboard, and will thus leap over the existing KHTML project.
But in the meantime, we get to hear the lamentations opf the lazy.
Please ignore the previous reply. I clicked send and thought it hadn't gone through, so I kept editing. This is more along the lines of what I meant to say...
Pixel count doesn't really mean that much in cameras. Don't get me wrong, I'd rather have a 4.0MP than a 3.2, but I'd rather have a 3.2 with good focus and sharpness, good color balance and low noise.
Unfortunately, camera-phones (I'll lump camera PDAs in here, too) take lousy pictures. I have never seen a decent looking photo out of one. The lack of a flash is a good example of why. No flash = long exposure = fuzzy action photos. Picture taking is just not the focus of a camera-phone (pun unintentional, but I like it). We know what shape a camera should be for good balance, stability and ease of framing. If you were to adopt the form factor, you'd have a camera that people hold up to their face. That would be weird.
Camera-phones are nice for taking a quick shot of something for amusement or when having the image fast is more important than having it decent (I'm thinking of accident scenes for insurance purposes), but if you want something suitable for printing (or even using as a desktop background) you're going to be disappointed.
Me, I've had a Sony PDA camera, a Ericsson camera-phone and now a Motorola camera-phone. I'm glad I've got it.... it came in handy when someone rear-ended my car. But I use the P71 for serious photography (usually dialed down a bit on picture size).
Pixel count doesn't really mean that much in cameras. Don't get me wrong, I'd rather have a 4.0MP than a 3.2, but I'd rather have a 3.2 with good focus and sharpness, good color balance and low noise.
Unfortunately, camera-phones (I'll lump camera PDAs in here, too) take lousy pictures. I have never seen a decent looking photo out of one. The lack of a flash is a good example of why. Camera-phones are nice for taking a quick shot of something for amusement or when having the image fast is more important than having it decent (I'm thinking of accident scenes for insurance purposes), but if you want something suitable for printing (or even using as a desktop background) you're going to be disappointed.
Me, I've had a Sony PDA camera, a Ericsson camera-phone and now a Motorola camera-phone. I'm glad I've got it.... it came in handy when someone rear-ended my car. But I use the P71 for serious photography.
A stand-alone camera has better quality than the phone....but we are starting to see that change.
Name one, please. Seriously.
I've seen a few camera phones that advertise high pixel counts, but so far I haven't seen anything that approaches even a $25 USB chat camera, let alone coming close to replacing my old Sony P71 (yes, I know it's old and crap. That is, sadly, the point).
Until they start to use the same lenses as digital cameras (which won't happen, because it would change the form factor too much for it to be a useful phone), I think they'll always be a poor, three-toed inbred cousin from Arkansas at best.
I went through a course like that in high school, actually. The book we used was called Just Enough Pascal.
I went looking for it and found this old description from MacTech.
If you want just enough Pascal to get you started, Symantec has a product that has been out since the introduction of THINK Pascal version 2.0 a few years ago. The product "Just Enough Pascal" (JEP) is a self paced course introducing you to programming with THINK Pascal and the Macintosh ROM routines. Although the product is still version 1.0, a 13 page manual is included to explain how to use JEP with THINK Pascal 3.0. Most of the differences are cosmetic since Pascal 3.0 changed a few of the menus around.
JEP consists of a desk accessory and source code for the tutorial. It is designed so that you can open your Pascal application and JEP at the same time. The JEP DA then takes you through the development of a Macintosh application. Each "lesson" is divided into 20 stages of the development. You can start out at any stage (the source code for each stage is provided). Each stage teaches a new concept in Pascal programming and at the same time gets you familiar with using Macintosh ROM Calls.
During a stage of the development of the sample project, you are directed to modify the source code from previous stages to add more functionality. You can copy and paste the new code directly from the JEP DA into your open source code. An explanation is provided and suggestions for "Tinkering" around with the code. The tinkering is where you have a chance to try things out and just see what happens. JEP is a great way to get started at your own pace.
It would definitely be of limited value now, but some of the other students were proof that it was a good way to learn to program.
Well... I read most of those decisions prior to Adams' death, so unless you have evidence to the contrary I don't think it's fair to accuse him of lying.
It was quite a money grab for the application developers; many simply had to re-compile against the 32-bit libraries and do some minor tweaks to release their preemptive-enabled applications. People bought it up.
A lot of the APIs changed between Windows 3.1 and Windows 95, and for no particular reason Microsoft did not make many of them backward compatible. There was a lot more to it than tweaks and a recompile. One thing I did *not* need to do is any changes for pre-emptive multitasking. That just worked.
Or continuing to think he's off his nut. Just because he has a vision doesn't mean he's right. He's got some good ideas, but when was the last time anyone was complete right?
I'd go further: I think they're less than "not great" but are in fact activele "bad." I like Zahn as a writer, and I like Star Wars, but the two combined were far less interesting than they should have been. About the best that can be said about them is they set up excellent sequels.
Well, personally I don't really care if Microsoft is copying. Copying ideas is the name of the game in software and has been for decades. Anyone remember who said "We don't actually create anything new in computers, we just rename old things"? What I find amusing is the number of people who insist they aren't.
Personally, I don't find a paragraph or two on the subject in front of a live audience to be whining. I consider it a bit of showmanship.
You really need to look at what exactly Xerox did vs. Apple. Apple did the objects-on-desktop thing; Xerox did verbs-on-screen. Both did menus, although Apple did the first pulldown menu.
Not only has Microsoft announced their search feature before Apple, but there have been numerous others that did it before (Google, Yahoo, MSN).
Apple has been attempting to find the right search technology to deploy to desktops for a decade. Am I really the only one that remembers VTWIN?
Dashboard is a straight rippof of Konfabulator. Developers of Konfabulator (originally for Mac OS X) switched to Win32 programming after Apple announced it for Tiger.
Thus claims the Konfabulator developers. Meanwhile, those of us who have actually been with Mac OS for a while remember widgets fondly from the 1980s as "desk accessories." I even wrote a few desk accessories, so don't try to retroactively tell me they didn't exist.
Tiger is not fully 64-bit, while Windows XP 64 is, and so will be Longhorn. Tiger is for one platform, Longhorn will ship (so they say) for x86, IA64, Itanium and probably more...
Um, sorry, this just doesn't make sense. First of all, Windows XP 64 won't support Itanium. It'a a completely different chipset. Secondly, Windows XP 64 includes nearly the same level of support for 64 bit code as Panther, let alone Tiger. Call one of them "not really" if you want, but only if you're willing to call the other one the same.
btw, rumour has it that the next OS X release might even feature support for a mouse wheel:)
Well, Apple's search efforts date back to VTWIN at least, which was Mac OS 7.6 or so. I'm glad to see it's finally shipping as part of something other than the Help application.
Are you saying bad design can only be recognized in hindsight? Or that having a bad design kill once is an excuse not to change it going forward? Either way, I think you need to go through the Klingon Rite of Design School Passage again.:)
Bad document template design is easy to show. Give a bunch of document mock-ups to average people and immiedately ask what information the documents convey. See how long it takes them to extract the information and how accurate it is
Apple has two methods for putting items in the menu bar: The "right" way to do things, and the way that looks good to users.
The wrong way to do things -- and the way Apple uses for their menulets -- reserved involves injecting code into SystemUIServer's running space. If one menulet crashes, all menulets crash under this model. It is not surprising they want to discourage this mechanism for end-developer use.
Personally, I expect that sooner or later Apple will port the features of the "wrong" way to the right way, then upgrade thier menulets to use the documented API instead of the undocumented one. However, I expect there are much higher priorities.
Slashdot Mirror
Don't forget Robert Maxwell.
Actually, this product is older than Cherry OS. The GPL volations were discovered after, that's all. I think they probably started behaving with Cherry OS in an effort to stop this from being spotted.
Now imagine if Microsoft hadn't given away IE with their operating system. Netscape still would have failed, only a bit later, because now there's Firefox which is free and better. If Microsoft didn't package IE with Windows, PC manufacturers surely would have packaged Firefox with them instead.
I agree with the rest of your post), but this part is just absurd. Netscape's failure caused Firefox's existence. If Microsoft hadn't given away IE, perhaps something would have killed Netscape anyway... but it certainly wouldn't have been Firefox.
The last should read: It would be insane to suggest Apple not leverage Quartz. That's what Quartz was created for. And there's certainly no provision on the LGPL that source compatibility for all previously supported platforms must be maintained in a fork.
Apple is providing full source to their web kit, which is a supset of KHTML. What they are not providing is the source code to Quartz, one of the basic components of Mac OS X, which their web kit (including their version of KHTML) calls. Thus, Apple's KHTML compiles only for Mac OS X.
It would be insane to suggest Apple not leverage Quartz. That's what Quartz was created for. And there's certainly no provision on the LGPL that source compatibility must be maintained in a fork.
What you should be asking yourself is "why not read the article?"
Apple has given back the changes. Apple has even built a new framework around KHTML. What Apple hasn't done is do all the integration work for the KHTML people. Who are now whining about how hard the changes are to work back in.
The KHTML team doesn't seem to be working very hard, so a fork happens. Forks happen. They rarely stop at one, either. I expect sooner or later we'll see another fork of KHTML that will try to bring the Apple changes onboard, and will thus leap over the existing KHTML project.
But in the meantime, we get to hear the lamentations opf the lazy.
Please ignore the previous reply. I clicked send and thought it hadn't gone through, so I kept editing. This is more along the lines of what I meant to say...
Pixel count doesn't really mean that much in cameras. Don't get me wrong, I'd rather have a 4.0MP than a 3.2, but I'd rather have a 3.2 with good focus and sharpness, good color balance and low noise.
Unfortunately, camera-phones (I'll lump camera PDAs in here, too) take lousy pictures. I have never seen a decent looking photo out of one. The lack of a flash is a good example of why. No flash = long exposure = fuzzy action photos. Picture taking is just not the focus of a camera-phone (pun unintentional, but I like it). We know what shape a camera should be for good balance, stability and ease of framing. If you were to adopt the form factor, you'd have a camera that people hold up to their face. That would be weird.
Camera-phones are nice for taking a quick shot of something for amusement or when having the image fast is more important than having it decent (I'm thinking of accident scenes for insurance purposes), but if you want something suitable for printing (or even using as a desktop background) you're going to be disappointed.
Me, I've had a Sony PDA camera, a Ericsson camera-phone and now a Motorola camera-phone. I'm glad I've got it.... it came in handy when someone rear-ended my car. But I use the P71 for serious photography (usually dialed down a bit on picture size).
Pixel count doesn't really mean that much in cameras. Don't get me wrong, I'd rather have a 4.0MP than a 3.2, but I'd rather have a 3.2 with good focus and sharpness, good color balance and low noise.
Unfortunately, camera-phones (I'll lump camera PDAs in here, too) take lousy pictures. I have never seen a decent looking photo out of one. The lack of a flash is a good example of why. Camera-phones are nice for taking a quick shot of something for amusement or when having the image fast is more important than having it decent (I'm thinking of accident scenes for insurance purposes), but if you want something suitable for printing (or even using as a desktop background) you're going to be disappointed.
Me, I've had a Sony PDA camera, a Ericsson camera-phone and now a Motorola camera-phone. I'm glad I've got it.... it came in handy when someone rear-ended my car. But I use the P71 for serious photography.
Well, it's a step in the right direction at least. Thank you. :)
A stand-alone camera has better quality than the phone. ...but we are starting to see that change.
Name one, please. Seriously.
I've seen a few camera phones that advertise high pixel counts, but so far I haven't seen anything that approaches even a $25 USB chat camera, let alone coming close to replacing my old Sony P71 (yes, I know it's old and crap. That is, sadly, the point).
Until they start to use the same lenses as digital cameras (which won't happen, because it would change the form factor too much for it to be a useful phone), I think they'll always be a poor, three-toed inbred cousin from Arkansas at best.
I went through a course like that in high school, actually. The book we used was called Just Enough Pascal.
I went looking for it and found this old description from MacTech.
If you want just enough Pascal to get you started, Symantec has a product that has been out since the introduction of THINK Pascal version 2.0 a few years ago. The product "Just Enough Pascal" (JEP) is a self paced course introducing you to programming with THINK Pascal and the Macintosh ROM routines. Although the product is still version 1.0, a 13 page manual is included to explain how to use JEP with THINK Pascal 3.0. Most of the differences are cosmetic since Pascal 3.0 changed a few of the menus around.
JEP consists of a desk accessory and source code for the tutorial. It is designed so that you can open your Pascal application and JEP at the same time. The JEP DA then takes you through the development of a Macintosh application. Each "lesson" is divided into 20 stages of the development. You can start out at any stage (the source code for each stage is provided). Each stage teaches a new concept in Pascal programming and at the same time gets you familiar with using Macintosh ROM Calls.
During a stage of the development of the sample project, you are directed to modify the source code from previous stages to add more functionality. You can copy and paste the new code directly from the JEP DA into your open source code. An explanation is provided and suggestions for "Tinkering" around with the code. The tinkering is where you have a chance to try things out and just see what happens. JEP is a great way to get started at your own pace.
It would definitely be of limited value now, but some of the other students were proof that it was a good way to learn to program.
Well... I read most of those decisions prior to Adams' death, so unless you have evidence to the contrary I don't think it's fair to accuse him of lying.
It was quite a money grab for the application developers; many simply had to re-compile against the 32-bit libraries and do some minor tweaks to release their preemptive-enabled applications. People bought it up.
A lot of the APIs changed between Windows 3.1 and Windows 95, and for no particular reason Microsoft did not make many of them backward compatible. There was a lot more to it than tweaks and a recompile. One thing I did *not* need to do is any changes for pre-emptive multitasking. That just worked.
Or continuing to think he's off his nut. Just because he has a vision doesn't mean he's right. He's got some good ideas, but when was the last time anyone was complete right?
I'd go further: I think they're less than "not great" but are in fact activele "bad." I like Zahn as a writer, and I like Star Wars, but the two combined were far less interesting than they should have been. About the best that can be said about them is they set up excellent sequels.
An equal number of people agree the world is flat, and are just as in tune with reality.
Depends. Some of us remember System 7.5.4 disappearing due to critical bugs. Had it been shipped to some early...
Well, personally I don't really care if Microsoft is copying. Copying ideas is the name of the game in software and has been for decades. Anyone remember who said "We don't actually create anything new in computers, we just rename old things"? What I find amusing is the number of people who insist they aren't.
Personally, I don't find a paragraph or two on the subject in front of a live audience to be whining. I consider it a bit of showmanship.
You really need to look at what exactly Xerox did vs. Apple. Apple did the objects-on-desktop thing; Xerox did verbs-on-screen. Both did menus, although Apple did the first pulldown menu.
I smell a troll.
'Not only has Microsoft announced their search feature before Apple, but there have been numerous others that did it before (Google, Yahoo, MSN).
Apple has been attempting to find the right search technology to deploy to desktops for a decade. Am I really the only one that remembers VTWIN?
Dashboard is a straight rippof of Konfabulator. Developers of Konfabulator (originally for Mac OS X) switched to Win32 programming after Apple announced it for Tiger.
Thus claims the Konfabulator developers. Meanwhile, those of us who have actually been with Mac OS for a while remember widgets fondly from the 1980s as "desk accessories." I even wrote a few desk accessories, so don't try to retroactively tell me they didn't exist.
Tiger is not fully 64-bit, while Windows XP 64 is, and so will be Longhorn. Tiger is for one platform, Longhorn will ship (so they say) for x86, IA64, Itanium and probably more...
Um, sorry, this just doesn't make sense. First of all, Windows XP 64 won't support Itanium. It'a a completely different chipset. Secondly, Windows XP 64 includes nearly the same level of support for 64 bit code as Panther, let alone Tiger. Call one of them "not really" if you want, but only if you're willing to call the other one the same.
btw, rumour has it that the next OS X release might even feature support for a mouse wheel :)
Supported since Mac OS 10.0, thank you.
Well, Apple's search efforts date back to VTWIN at least, which was Mac OS 7.6 or so. I'm glad to see it's finally shipping as part of something other than the Help application.
Sorry, but I have to disagree. Good design is definitely something that matters for nerds. And any particular reminder of it is welcome.
Are you saying bad design can only be recognized in hindsight? Or that having a bad design kill once is an excuse not to change it going forward? Either way, I think you need to go through the Klingon Rite of Design School Passage again. :)
Bad document template design is easy to show. Give a bunch of document mock-ups to average people and immiedately ask what information the documents convey. See how long it takes them to extract the information and how accurate it is
Apple has two methods for putting items in the menu bar: The "right" way to do things, and the way that looks good to users.
The wrong way to do things -- and the way Apple uses for their menulets -- reserved involves injecting code into SystemUIServer's running space. If one menulet crashes, all menulets crash under this model. It is not surprising they want to discourage this mechanism for end-developer use.
Personally, I expect that sooner or later Apple will port the features of the "wrong" way to the right way, then upgrade thier menulets to use the documented API instead of the undocumented one. However, I expect there are much higher priorities.
Yeah. You can tell when they moved -- it's when the shows first started sucking. :)