GNUstep has a lot of different projects to offer - from entry level improvements for the beginner (like compiling the missing classes in GNUstep compared to current Cocoa and creating the header files) to advanced tasks like porting Apple's WebKit over to GNUstep (here you would need proper ObjC++ and C++ skills) or improving GNUsteps integration into the MS Windows Platform (tighter integration into the Windows look and feel, Windows programming skills are welcome). So there is something for everybody.
I am doing WO development for my living and until recently I used some XP machine for this. Never had any troubles so far (besides the restriction to W0 5.2.4 instead of 5.3 when using Apple tools) but our company went for WOLips (Eclipse plug in, see http://wiki.objectstyle.org/confluence/display/WOL /WOLips ) which gives you all the stuff you need to develop. Yes, it can sometimes be tricky to do WO on XP but somehow you get it to work (I didn't fiddle out all the nitty gritty detail of installing it - our admins did - so I had a smooth journey)
regards
Apple still doesn't got it. WebObjects was one of the first application servers and it is still great and more advanced than all the other stuff in that area. Despite this Apple has shrunk all its efforts to market and support it to nearly zero. Yes, they still maintain it (since they use it inhouse too (for their Website and the iTMS)) but the periods between new versions grow longer and longer and the times when new features were introduced are long gone. They also stopped advertising for it a long time ago and it merely plays a minor part on WWDC. WebObjects was one of the apps that meant "Enterprise IT" for NeXT, in fact it was NeXTs financial butt-saver until Apple came along.
So if you want to port to GNUstep don't use Carbon / QuickTime / CoreBlah stuff in your application. Also keep in mind that GNUstep has a certain lag when it comes to the latest features of Cocoa since the GNUsteppers always have to keep up with Apple (and since Apple NDAs new features GNUstep learns about those at earliest when Apple releases a new Version of OS X). Thats the reason they announce only: "Applications written for GnuStep can be recompiled to target OS X with little-to-no work."
Sure, I understand all the reasons for those duplications. My original "rant" was not about backwards compatibility but the poor start of Java given the fact that SUN was a (marginal?) co-author of OpenStep so one could expect they've learned something from that co-authorship. Obvoiusly that wasn't the case, Java is worse than OpenStep in many (not all) regards.
cheers, sqar
So tell me why there is java.util.Vector AND java.util.ArrayList. Same for java.util.Hashtable and java.util.HashMap, java.util.Dictionary and java.util.Map subclasses...
why Java is so suboptimal compared to languages like Objective-C and APIs like OpenStep/Cocoa. I mean Java is like some sort of second infusion of Coffee (and we all know that only green tea is better at the second infusion;-) ): you know what it is supposed to be but it just doesn't taste like the real thing.
Doubly astonishing so since SUN was co-developing OpenStep in team with NeXT, so they should have known how to design a proper API and what language features are needed for this. Now the Java API is bloated to no end and still incomplete: I miss the virtuosity of the small but feature complete OpenStep API (why aren't there methods like componentsJoinedByString and componentsSeparatedByString or the goodie makeObjectsPerformSelector in the counterpart java.util.ArrayList available? Or just simple things like a constructor like this: NSArray(java.lang.Object[]). Those were only some randomly picked small examples. Not to speak of key value coding or EOF what most of you probably don't know.). I am linking here not to the Objective-C Cocoa docs (here I miss categories most, although I must admit that those would be a potential security issue for Java Applets (that's where Java made it's first steps: in the webbrowser)) but to the Webobjects JavaDoc to show that such stuff is possible with Java. Only god (and the SUN) knows why they did not make it so. In lieu thereof we've got a plethora of collection classes which overlap a lot in functionality. That pattern shows everywhere in the "official" Java APIs.
And don't get me started on WO/EOF vs. J2EE;-)
exuse my poor english, it is not my native tongue.
but they're already cheating: the original asteroids game http://www.klov.com/A/Asteroids.html had no "autonomous navigation system" equipped bullets that were "primed for up to 3 course corrections". That outright unfair!
Important is what they say in two years and even more important is what they're going to do. Besides this there are a lot more vendors that might "think different" about that issue.
At the latest when the next crisis hits the industry a lot of vendors will straighten their portfolio. Then it comes in handy if you have to maintain only one codebase.
When Apple switches to x86 I propose the following:
After a while some sort of Windows emulation layer will come into existence. Whether this happens by a port of WINE, some Apple approach or another third party doesn't matter, it will only be a question of time.
Now this newly gained "feature" will result in some Application providers to "support" Mac OS X thru this Windows layer. That doesn't sound bad at the first look *but* in the end the support for native Mac OS X APIs will diminish: It is a lot easier for Software Vendors to program only against a single API and in that case it will be the Windows API.
Remember the retention big Software Vendors showed when pushed by Apple to support things like the Cocoa API. Adobe for instance was very reluctant to this, in fact there are virtually no big companies which offer Cocoa apps until today. This was the reason it took so long for Mac OS X to get out (after Rhapsody was a washout because of this) since they had to implement Carbon a overhauled version of the ancient Mac OS toolbox.
I think Adobe and others will be very happy to have to support only one namely the Windows API and therefore would welcome such a switch. But with more and more applications only supporting the Windows API the relevance for Mac OS X will disappear. In the long run it will end up with the same fate as OS/2 did: No more native Applications for Mac OS X and therefore no difference to Windows (since the use of the Windows API gives you no access to those nice features of Mac OS X). Mac OS X will die this way.
When Apple switches to x86 I propose the following:
After a while some sort of Windows emulation layer will come into existence. Whether this happens by a port of WINE, some Apple approach or another third party doesn't matter, it will only be a question of time.
Now this newly gained "feature" will result in some Application providers to "support" Mac OS X thru this Windows layer. That doesn't sound bad at the first look *but* in the end the support for native Mac OS X APIs will diminish: It is a lot easier for Software Vendors to program only against a single API and in that case it will be the Windows API.
Remember the retention big Software Vendors showed when pushed by Apple to support things like the Cocoa API. Adobe for instance was very reluctant to this, in fact there are virtually no big companies which offer Cocoa apps until today. This was the reason it took so long for Mac OS X to get out (after Rhapsody was a washout because of this) since they had to implement Carbon a overhauled version of the ancient Mac OS toolbox.
I think Adobe and others will be very happy to have to support only one namely the Windows API and therefore would welcome such a switch. But with more and more applications only supporting the Windows API the relevance for Mac OS X will disappear. In the long run it will end up with the same fate as OS/2 did: No more native Applications for Mac OS X and therefore no difference to Windows (since the use of the Windows API gives you no access to those nice features of Mac OS X). Mac OS X will die this way.
regards, sqar
> Everybody's wrong about the video iPod thing. A video iPod > would be a dumb idea for lots of reasons, some technical, > some psychological.
Well, since the name of the thingy is iPod (and not iMusicPlayer) I don't see why the Pod shouldn't be suited well for Video. Yeah, it turned out that the main use of it *is* to be a MusicPlayer, but on the other hand it wasn't intended to be so. When it came to market the use as a transportable external harddisk was also important (hence the presence of a FireWire Port, to hook it directly up on a Mac/PC where ever there is one) That use dimmished since the success of the ITMS and the introduction of the iPod Docking Station (which you most likely hook up to the computer where your iTunes Library is on and don't carry around).
However, the iPod could have so much more uses. - PictureTank, e.g. backUp storage for your digicam. This is already implemented (iPod Camera Connector)
but why limit this ability to Photos? Every digital camcorder has a build in FireWire Connector. So why not use the iPod as VideoTank too? Hook up your camcorder and extend your recording capacity. Maybe you could then even playback what you recorded on the small screen just to get an idea of what you got on there. If you want to present the stuff to others you just hook it up a TV like when you present your photos. Nobody said that you should use the small screen as the main appliance to replay video. It's more like the small screen/viewfinder on your camcorder for inspection purposes.
While we are on recording capabilities:
- Audio recording in CD Stereo quality. When I am on the road to record some sounds (for a video etc.) I usually use my portable Sony TCD D7 DAT recorder. The thing is pretty old (from 1994 IIRC) but it still fulfills its purpose. However, tapes are delicate and I already lost some recordings due to "tape salad" as we say in german. And there is the need to dub the recordings into my computer (using the optical Toslink connector that was recently introduced with the G5s). Since this is an audio connection it takes nevertheless the same time like the recording did to get the stuff into the Mac. Long story short: a CD stereo audio recording iPod would make this lots easier and safer.
Maybe you're in a position to communicate my ideas. Please consider it at least.
the maiden flight was originally planned for 2007-2008 if I remember that correctly (read it in a German aviation magazine (Fliegerrevue) some time ago), but as usual with such projects and russia: sadly they have no more money to complete it. Relatively little american money could have a huge effect here. But I guess national pride on both sides will prevent this from coming true.
I particularly dislike the string theories. If they could prove that string theories are right this would diminish my respect for god as a smart guy/girl/whatever. I hold the quantum-loop theory or the heim theory in much higher regards as they are smarter.
Slashdot Mirror
sign here: http://www.petitiononline.com/laafs/petition.html
GNUstep has a lot of different projects to offer - from entry level improvements for the beginner (like compiling the missing classes in GNUstep compared to current Cocoa and creating the header files) to advanced tasks like porting Apple's WebKit over to GNUstep (here you would need proper ObjC++ and C++ skills) or improving GNUsteps integration into the MS Windows Platform (tighter integration into the Windows look and feel, Windows programming skills are welcome). So there is something for everybody.
i n_Google_Summer_of_Code_2007e -2007.html
2 007 (the wiki requires a registration here: webmasters@gnustep.org since we got a lot of wikispam before)
newspieces:
http://digg.com/programming/GNUstep_participates_
http://gnustep.blogspot.com/2007/03/summer-of-cod
ideas:
http://wiki.gnustep.org/index.php/Summer_Of_Code_
regards, Lars
I am doing WO development for my living and until recently I used some XP machine for this. Never had any troubles so far (besides the restriction to W0 5.2.4 instead of 5.3 when using Apple tools) but our company went for WOLips (Eclipse plug in, see http://wiki.objectstyle.org/confluence/display/WOL /WOLips ) which gives you all the stuff you need to develop. Yes, it can sometimes be tricky to do WO on XP but somehow you get it to work (I didn't fiddle out all the nitty gritty detail of installing it - our admins did - so I had a smooth journey)
regards
Apple still doesn't got it. WebObjects was one of the first application servers and it is still great and more advanced than all the other stuff in that area. Despite this Apple has shrunk all its efforts to market and support it to nearly zero. Yes, they still maintain it (since they use it inhouse too (for their Website and the iTMS)) but the periods between new versions grow longer and longer and the times when new features were introduced are long gone. They also stopped advertising for it a long time ago and it merely plays a minor part on WWDC. WebObjects was one of the apps that meant "Enterprise IT" for NeXT, in fact it was NeXTs financial butt-saver until Apple came along.
Regards
So if you want to port to GNUstep don't use Carbon / QuickTime / CoreBlah stuff in your application. Also keep in mind that GNUstep has a certain lag when it comes to the latest features of Cocoa since the GNUsteppers always have to keep up with Apple (and since Apple NDAs new features GNUstep learns about those at earliest when Apple releases a new Version of OS X). Thats the reason they announce only: "Applications written for GnuStep can be recompiled to target OS X with little-to-no work."
Sure, I understand all the reasons for those duplications. My original "rant" was not about backwards compatibility but the poor start of Java given the fact that SUN was a (marginal?) co-author of OpenStep so one could expect they've learned something from that co-authorship. Obvoiusly that wasn't the case, Java is worse than OpenStep in many (not all) regards. cheers, sqar
So tell me why there is java.util.Vector AND java.util.ArrayList. Same for java.util.Hashtable and java.util.HashMap, java.util.Dictionary and java.util.Map subclasses ...
That just doesn't look well designed for me
sqar
why Java is so suboptimal compared to languages like Objective-C and APIs like OpenStep/Cocoa. I mean Java is like some sort of second infusion of Coffee (and we all know that only green tea is better at the second infusion ;-) ): you know what it is supposed to be but it just doesn't taste like the real thing.
;-)
Doubly astonishing so since SUN was co-developing OpenStep in team with NeXT, so they should have known how to design a proper API and what language features are needed for this. Now the Java API is bloated to no end and still incomplete: I miss the virtuosity of the small but feature complete OpenStep API (why aren't there methods like componentsJoinedByString and componentsSeparatedByString or the goodie makeObjectsPerformSelector in the counterpart java.util.ArrayList available? Or just simple things like a constructor like this: NSArray(java.lang.Object[]). Those were only some randomly picked small examples. Not to speak of key value coding or EOF what most of you probably don't know.). I am linking here not to the Objective-C Cocoa docs (here I miss categories most, although I must admit that those would be a potential security issue for Java Applets (that's where Java made it's first steps: in the webbrowser)) but to the Webobjects JavaDoc to show that such stuff is possible with Java. Only god (and the SUN) knows why they did not make it so. In lieu thereof we've got a plethora of collection classes which overlap a lot in functionality. That pattern shows everywhere in the "official" Java APIs.
And don't get me started on WO/EOF vs. J2EE
exuse my poor english, it is not my native tongue.
regards, sqar
but they're already cheating: the original asteroids game http://www.klov.com/A/Asteroids.html had no "autonomous navigation system" equipped bullets that were "primed for up to 3 course corrections". That outright unfair!
This is what they say now.
Important is what they say in two years and even more important is what they're going to do. Besides this there are a lot more vendors that might "think different" about that issue.
At the latest when the next crisis hits the industry a lot of vendors will straighten their portfolio. Then it comes in handy if you have to maintain only one codebase.
Sqar
Bad day today, third attempt:
When Apple switches to x86 I propose the following:
After a while some sort of Windows emulation layer will come into existence. Whether this happens by a port of WINE, some Apple approach or another third party doesn't matter, it will only be a question of time.
Now this newly gained "feature" will result in some Application providers to "support" Mac OS X thru this Windows layer. That doesn't sound bad at the first look *but* in the end the support for native Mac OS X APIs will diminish: It is a lot easier for Software Vendors to program only against a single API and in that case it will be the Windows API.
Remember the retention big Software Vendors showed when pushed by Apple to support things like the Cocoa API. Adobe for instance was very reluctant to this, in fact there are virtually no big companies which offer Cocoa apps until today. This was the reason it took so long for Mac OS X to get out (after Rhapsody was a washout because of this) since they had to implement Carbon a overhauled version of the ancient Mac OS toolbox.
I think Adobe and others will be very happy to have to support only one namely the Windows API and therefore would welcome such a switch. But with more and more applications only supporting the Windows API the relevance for Mac OS X will disappear. In the long run it will end up with the same fate as OS/2 did: No more native Applications for Mac OS X and therefore no difference to Windows (since the use of the Windows API gives you no access to those nice features of Mac OS X). Mac OS X will die this way.
regards, sqar
When Apple switches to x86 I propose the following: After a while some sort of Windows emulation layer will come into existence. Whether this happens by a port of WINE, some Apple approach or another third party doesn't matter, it will only be a question of time. Now this newly gained "feature" will result in some Application providers to "support" Mac OS X thru this Windows layer. That doesn't sound bad at the first look *but* in the end the support for native Mac OS X APIs will diminish: It is a lot easier for Software Vendors to program only against a single API and in that case it will be the Windows API. Remember the retention big Software Vendors showed when pushed by Apple to support things like the Cocoa API. Adobe for instance was very reluctant to this, in fact there are virtually no big companies which offer Cocoa apps until today. This was the reason it took so long for Mac OS X to get out (after Rhapsody was a washout because of this) since they had to implement Carbon a overhauled version of the ancient Mac OS toolbox. I think Adobe and others will be very happy to have to support only one namely the Windows API and therefore would welcome such a switch. But with more and more applications only supporting the Windows API the relevance for Mac OS X will disappear. In the long run it will end up with the same fate as OS/2 did: No more native Applications for Mac OS X and therefore no difference to Windows (since the use of the Windows API gives you no access to those nice features of Mac OS X). Mac OS X will die this way. regards, sqar
> Everybody's wrong about the video iPod thing. A video iPod
> would be a dumb idea for lots of reasons, some technical,
> some psychological.
Well, since the name of the thingy is iPod (and not iMusicPlayer) I don't see why the Pod shouldn't be suited well for Video. Yeah, it turned out that the main use of it *is* to be a MusicPlayer, but on the other hand it wasn't intended to be so. When it came to market the use as a transportable external harddisk was also important (hence the presence of a FireWire Port, to hook it directly up on a Mac/PC where ever there is one) That use dimmished since the success of the ITMS and the introduction of the iPod Docking Station (which you most likely hook up to the computer where your iTunes Library is on and don't carry around).
However, the iPod could have so much more uses.
- PictureTank, e.g. backUp storage for your digicam. This is already implemented (iPod Camera Connector)
but why limit this ability to Photos? Every digital camcorder has a build in FireWire Connector. So why not use the iPod as VideoTank too? Hook up your camcorder and extend your recording capacity. Maybe you could then even playback what you recorded on the small screen just to get an idea of what you got on there. If you want to present the stuff to others you just hook it up a TV like when you present your photos. Nobody said that you should use the small screen as the main appliance to replay video. It's more like the small screen/viewfinder on your camcorder for inspection purposes.
While we are on recording capabilities:
- Audio recording in CD Stereo quality. When I am on the road to record some sounds (for a video etc.) I usually use my portable Sony TCD D7 DAT recorder. The thing is pretty old (from 1994 IIRC) but it still fulfills its purpose. However, tapes are delicate and I already lost some recordings due to "tape salad" as we say in german. And there is the need to dub the recordings into my computer (using the optical Toslink connector that was recently introduced with the G5s). Since this is an audio connection it takes nevertheless the same time like the recording did to get the stuff into the Mac.
Long story short: a CD stereo audio recording iPod would make this lots easier and safer.
Maybe you're in a position to communicate my ideas. Please consider it at least.
regards, sqar
... they could have a new type of spacecraft much earlier. Russian engineers are pretty advanced in their plannings for a soyuz replacement: Kliper
http://www.russianspaceweb.com/kliper.html
http://www.astronautix.com/craft/kliper.htm
http://en.wikipedia.org/wiki/Kliper
the maiden flight was originally planned for 2007-2008 if I remember that correctly (read it in a German aviation magazine (Fliegerrevue) some time ago), but as usual with such projects and russia: sadly they have no more money to complete it. Relatively little american money could have a huge effect here. But I guess national pride on both sides will prevent this from coming true.
regards, sqar
I particularly dislike the string theories. If they could prove that string theories are right this would diminish my respect for god as a smart guy/girl/whatever. I hold the quantum-loop theory or the heim theory in much higher regards as they are smarter.
http://www.heim-theory.com/Contents/contents.html
http://en.wikipedia.org/wiki/Heim-Theory
regards, sqar