er... the iPhone is possibly not the miracle that some hailed, but it's difficult to be sure until they actual sell it:-)
In particular, most of your "problems" are misleading:
No 3G. A killer in Europe for something at that level. I'm assuming this won't be a problem by the time of launch though, because I simply cannot imagine anyone trying to launch a 2.5G smart phone here these days. Well, THIS model does not have 3G, only 2.5G. But Steve Jobs specifically said they were working on a 3G model. Considering it's only supposed to come in europe around september (so, likely introduced at the paris expo) I frankly expect that it will be a 3G model.
No video calling. Minor league problem for me and directly related to no 3G. As you said, without 3G, video calling is useless anyway. Beside, video calling is more a gadget than something useful, really... did you ever try videoconf with your webcam ? do you use it regularly ? most people in then do not use it apart from an initial "wow it's cool". And with a webcam there's still a few occasions where it is useful (showing kids to grandparents, business conf..) but these uses are anyway quite impractical for a frickin mobile PHONE. Now tell me that Apple would let you plug an iSight on their new AppleTV, and do videoconf in your living room, and here it would be interesting.
"First proper browser on a phone" says Jobs in the keynote. Err...no, no at all. My phone is happily running Opera, as are plenty of others.
Er, I have opera on my 3G mobile. You can't seriously compare it to what was shown on the iPhone. The only vaguely comparable browser on a mobile device I know of is opera, but running on the nokia 770, eg with a high res screen. Certainly not the mobile browsers you have on mobile phones.
No user-replaceable battery. No spare batteries? Are they serious? Not a problem with an iPod, you just lose your music for a while. Annoying but liveable. For a phone however, that's a much bigger hassle. Yes, that sucks. The autonomy seems fairly good though, and there was this talk about using two batteries, but still, it would be better to have a user-replaceable battery. At first I even thought that this black part on the back was here for just that...
No third-party software. Err...no. Won't fly for me. There WILL be 3rd party software -- jobs said it, and if you think about it, why mention Cocoa and Core Animation if not ! The question is not that. The question is that apparently Apple wants to "control" the software that will run on the iPhone; how THAT will work is unknown yet (eg, could be a compliance test your app will need to pass, or could be more closed -- we just do not know. Wait for the developer conference this summer...). I admit, as a cocoa developer I'm quite pissed about it, I would have prefererred an open access. Though if it's just a compliance test it will be ok for me (depends of course if it wil be costly or not, or if the compliance test will apply to all apps or only the ones using the GSM chip, etc.). As you see, there's a lot of possible combinations on how that will work, and we can only make conjectures for the moment. But there will be 3rd party software, they said it, and it would be moronic to not have them.
Can't use your "iTunes music" as a ring tone. Now admittedly the source I read for this didn't make it clear if they really meant iTMS-purchased music or just any old MP3 but either way that's pretty poor. First time I hear that rumor. I frankly doubt you'll have a problem to set your ring tone... anyway, it's only a rumor. Wait for the real device.
No GPS (that I'm aware of). I'm spending that amount of money, I'd like a GPS-enabled phone please. Far from a deal-breaker. Sure that would be a nice addition.
No radio. For the love of god, what is it that Apple have against radios? Even the built-in Radio function of iTunes is utterly useless. I don't want to car
it's very likely running Quartz (or more probably, a suitably cut-down version), and I wouldn't be surprised if the whole display is vector-based -- after all tiger can already do it (albeit it's unstable/buggy so not activated by default) and leopard *will* be vector-based, officially.
Quartz is very close to a DisplayPDF, so indeed displaying PDF is straightforward -- there's a reason it's one of the native format for OS X. And they indeed stated that the iPhone will be able to display PDF files.
The way I see it, they ARE running OS X, but simply a stripped-down version with the major frameworks they needed (eg, Cocoa). And as a developper, I couldn't care less if they were running a completely different kernel or even userland -- as long as Cocoa is there.
But it's extremely likely that they are, indeed, running a scaled-down version of the "real" OS X -- why would they develop a completely brand new OS ?? knowing that devices regularly increase in power ? that would be seriously stupid. Better to try to shoe-horn OS X on the iPhone, even if it means cutting down some of the stuff for the moment.
OpenBSD really is slower. However, that's because of its security functionality (cryptographically random process IDs and encrypted swap, anyone?) and not because of poor design.
Oh, of course. I was just stating why and how I ended up with FreeBSD. With a more recent hardware and/or more ram I could have perhaps sticked to OpenBSD, and for a server anyway it's obviously something I'd consider:-)
But for this old laptop, FreeBSD looks like the right choice;-)
FreeBSD is faster. It just is. Its the fastest OS I've ever used, and unlike Linux, doesn't ever seem sluggish under heavy load
I must say I agree here:-)
I never used bsd until a couple of weeks ago, when I ended up without a laptop, and a friend lend me an old one (celeron 1ghz, 128mb ram). As a long time debian user, I started by installing the last touted "desktop os" based on debian: ubuntu. Everything worked as usual and was recognized, but.. it was sluggish (those pesky 128Mb were the cause more than the celeron, I believe). Still, I was outraged: I started linux on a p166+ with 24Mb of ram, and it was faster (or at least in my memory) to use, even after ditching gnome and installing window maker + gnustep apps.
Then, on a whim, I installed OpenBSD 3.9, just to test -- why did I never try bsd before in all those years, after all ?
Well,.. it felt even slower -- probably because of X11 though. But I liked OpenBSD a lot -- very neat, excellent docs, and it just felt "clean".
So I installed FreeBSD 6. And. Wow. That's friggin FAST:-) even on this machine. I even recompiled the kernel to change the scheduler, and now it's even more responsive under X11 (although it _seems_ things are slightly slower to start, but the trade off is good on this machine).
So count me in the *BSD supporters now -- although apt is wonderful, pkg/ports are quite ok. And I like how it feels like unix again;-)
How so ? Not A Problem,... if you are not using something that's not implemented in GNUstep, obviously. Of course, it can be very annoying (cocoa bindings aren't implemented yet, so if you use them...). Even then, a few #if#def to replace the offending code with another solution can prove to be quite simple to do (as most of the code can still be ported easily)...
Frankly, I think that if you can get rather complex apps like GNUmail or Cenon running both on OSX and on GNUstep, surely it's in the domain of the reality, not just pie in the sky.
The problem is more about OSX developers not beeing really interested in porting their apps to linux. On the other hand, they are very interested to port their app to Windows, but somehow most of them just wait for Apple to release YellowBox and/or wait for a good GNUstep/Windows port, with very few actually helping GNUstep (sure, not that surprising...)
Note that GNUstep/Windows status is getting better, although GNUstep apps aren't integrated graphically with Windows, at least now it kinda work (eg like addresses, but more importantly, Gorm (the GNUstep gui builder) compiles on Windows since a few releases).
Imagine running GNUStep on OpenDarwin and being able to run all Mac apps -- that's what the goal ought to be!
Not Possible. GNUstep is not Wine, it's not binary compatible with Cocoa, it's source compatible (mostly).
Anyway, sure, it's not always as easy as a simple recompilation from OSX to GNUstep, but it often is. And when it's not.. it's not that difficult to do the "port", in my opinion/experience, particularly with recent progresses with nib loading (not complete yet, but very close now).
I thought they still supported some things from OpenStep that Cocoa dropped or diverged a little or something
...er.. what's the problem with this approach ? it's not like you can't actually compile that stuff on OSX if you need it too...
It's sad, but this focus on "OpenStep with a bit of Cocoa, and maybe some of our own stuff if it's better" is why nobody uses GNUStep. If their mission was "100% compatibility with Cocoa" instead, then it would be a lot more popular.
Gni ?..
What's the problem with the GNUstep approach ? If you propose some code to the GNUstep project which improve Cocoa compatibility or implements new Cocoa api, you won't be turned off, to the contrary ! While many GNUstep people like OpenStep...
They are also pragmatic, and obviously Cocoa compatibility is important nowadays
Cocoa is an evolution of OpenStep, as such it's more about adding new api than replacing _existing_ OpenStep api.. Thus, it's fairly easy for GNUstep to have this stance...
100% compatibility with Cocoa is a noble goal, but you'll always lag behind (hint: Wine), for obvious reasons. GNUstep's goal is just pragmatic: it started as a project to implement OpenStep api, thus it's (still) the official goal. But implementations of new Cocoa api are routinely added to GNUstep...
Actually, it's not completely true. The first HWR engine was, indeed, from that russian company that does calligrapher now. But there was another HWR engine on NewtonOS 2.0 that was developped in-house at apple (you can choose which one you want). It works wonderfully, and many people talks about this one, not the original calligrapher one.
Well, it was more the general philosophy than any particular example. I mean, you can always show a cool thing that the Newton is doing, and you'll say "oh but I can do that on my pocketpc using this or that 3rd party software !". So what's the big deal ?
Well, firstly, the User Interface is excellent. It's the best UI of all the PDA I owned (PalmOS, PocketPC, Nokia 770). Why ? because it's really MEANT to be used with a pen. You can write everywhere on the screen, not just in a small part; you scribble to delete something; you have an easy and quick way of changing input and drawing methods (eg you can choose to have your drawings "straightened" -- draw a kind of circle, the newt will automatically transform it into a real circle, etc). Everything you draw is vectorial and you can easily manipulate it.
And other than beeing really built around the use of a pen, the UI is very clean, slick and uncluterred.
Secondly, the recognition engine is incredible. Truely impressive. Basically, it works. Really, really cool. The simplicity of mixing some written text (automatically recognised) with some "ink" text, and any kind of drawing... really gives you a _working_ notepad. It's the only PDA I ever used that could really be used for taking notes (and I _did_ once try to write down a course on my Palm Vx;-) -- absolutely unusable apart from the "let's try it" factor).
Thirdly, NewtonOS is built on a real OO core, and NewtonScript is a very neat language. That's basically how things like the fat driver / patch or einstein were possible, as you can intercept messages. But more importantly for the user, you don't have files, but a kind of simple OO database. Why is it important ? because it lets applications _easily_ cooperate, picking and sharing informations. Real cooperation between apps is possible. It helps a lot to remove the apps at the back, and put your datas at the front.
Fourthly, there is this neat "assistant" technology that actually make a good use of the OO databases. That's how you can write "meet dave next friday", click on the assistant button, and automatically the Newt will propose you to add a new meeting entry into your calendar, for the next friday, with the most likely dave you know from your address book (and of course it's easy to change the propositions in the dialog box).
There's also the possibility to "send" apps results (by mail, by fax, to the printer, etc.) easily. Plus an I/O general mechanism to deal with everything you send or receive on the newt.
And lastly, the form factor. That's something that, sadly, is forgotten by the so called PDA today. Having a *big* screen helps a lot to write proper notes -- I mean, physically, not the resolution, even if the Newt resolution is rather good. Basically, while it's smaller than a tabletpc, it's also big enough to be useful for real note taking (and more).
Oh, and something that everybody forget to say: as it used flash memory, you never lost anything, even if your battery run out. Speaking of batteries, mine simply used standard AA batteries..
I really miss my newton 2100 (it was stolen...) .
And my new shiny nokia 770 is so far behind on the UI side it's not even funny (even if it's better on some technical aspects, mainly, the screen resolution). And I actually think that Maemo is a quite ok UI, compared to the other available choices today ! So, if I can put Einsteing on my 770... You bet I'll use it;-)
For those interested, I wrote a few posts about the newton, the dynabook, and the nokia:
Personally, I really started to dislike the French as a whole after a trip to Europe. Spaniards, Enlgishmen, Germans, and Italians were all so much nicer than the French. It seemed like the French looked down their noses at us. The Germans seemed a little distant, but that is just how Germans are. I think many French people really think they are better than Americans, and probably everyone else. My wife had the same impression after a recent trip to Paris.
You know, don't mix Parisians and the rest of the country -- Parisians have that bad (sometimes justified) reputation as rude and snob people even in France;-)
Of course, with the recent tensions between US and France, some stupid people can be ruder than usual -- stupidity is sadly international, as those freedom fries thing proved it.
It's scripted in the sense that the executable runs without any compilation step and because Objective-C is a dynamic language (interperted) at runtime I believe.
Well... you're wrong. Objective-C is a compiled language, not an interpreted one.
Do you have any links for plugins for Gorm? It seems like the whole interface was based on the user writing ObjC for complex actions/methods.
Indeed, the basic idea is to use ObjC for complex actions/methods (considers though that ObjC is a strict superset of the ANSI C, so you could simply put your C code in an ObjC method without any modifications, and the next release of gcc will even allow you to mix ObjC and C++). There's no repository for Gorm palettes, but you can have a look on my blog to get the StepTalk palette.
Oh, how does the philosophy matter at all?
By the philosophy is different, I'm talking about the framework (GNUstep/OpenStep) and the language (ObjC) -- they are vastly different from Qt and C++. And frankly, I rather like Qt, programmed with it before jumping on the GNUstep ship; the signals/slots mechanism of Qt is actually quite inspired by OpenStep target/action. But ObjC and OpenStep are without a doubt much better suited for the job than Qt/C++, really (I would use C++ for a 3D engine, but ObjC for the gui -- the right tool for the right job, period). Partly because of ObjC functionalities and its dynamism (introspection, modify things at runtime, true polymorphism, replace a class by another, catch any messages, etc.) and partly because of the sheer design quality of OpenStep. It's an amazingly well designed framework. I may remind you that Cocoa on OSX is actually an OpenStep implementation..
i didn't see anything in the demo which couldn't be done on a different platform and the right interface builder. I mean QT designer can do 50% of what Gorm does with the exception of the custom actions. (I admit that is a large shortcoming though). However the entire concept of writing actions in a tiny window will not scale for medium to large applications. So I hope Obj-C's import facilities are good. Just look at the hoops Flash developers go through.
Ouch.. the point of Gorm is frankly NOT to write actions in a tiny window -- actually Gorm don't do it, in the demo it was done by the StepTalk palette. Gorm is an Object Modeller more than a GUI builder, in a sense. Its real job is to connect objects, graphical or non graphical. And you're working on the "real" objects. A.gorm file is simply the serialization of the object graph... So, no, you can't do that in any other UI builder, apart (obviously) from InterfaceBuilder on OPENSTEP^WMacOSX:-)
And yes, of course you usually import ObjC headers in Gorm, or create the class in Gorm itself.
If you only saw the "StepTalk" demo, have a look to the Dataset demo, and if you want to see an example of ObjC code with Gorm, check the third demo.
Well, don't you think it's a bit sad to actually get _this_ troll article instead of a proper article, with links and good explanations about Gorm and GNUstep ?
.. hmm perhaps not actually, that way people can have fun on/. while some gnustep devs are here trying to explain their project...
Well actually, neither Afterstep or WindowMaker are based on GNUstep -- they are written in C, not Objective-C, and they don't use at all the GNUstep libraries.
Gorm actually looks pretty neat.
Too bad it needs several years of work to catch up to
KDE/GNOME in terms of infurstructure work.
Actually, no, that's the point. Not that much is missing... the problem with GNUstep is that before implementing nearly the complete api (which is done) and having an InterfaceBuilder like (which is done by Gorm), it was rather difficult to use it and be it of any interest...
Thus KDE and GNOME catched rather than GNUstep, in my opinion because they were able to incrementally build their desktop, and thus, propose something immediately of some use. Vicious circle of course for gnustep, as it then didn't attract many developers, etc.,etc.
It really does illistrate the power of scripted interfaces through.
Scripted interfaces ???? Gorm is not that, at all:)... if you just saw the StepTalk demo, check the rest:) -- The StepTalk Palette is just a "plugin" for Gorm if you want...
I want to see the same thing (but better!!:) coming from QtRuby/Korundum
since it sould be SOOOOO easy to do so.
That, I doubt it.. although Ruby is dynamic enough to build interesting things.. but the philosophy of OpenStep is rather different..
It's a bit tedious to explain with words what Gorm is all about -- it's much simpler to actually *see* it:-)
If you have only one video to see, check the one about the custom palette -- but the other are interesting too:-) (the StepTalk one demonstrate a creation of a simple calculator *entirely* in Gorm, using the StepTalk palette, which let you code in various languages).
While Ruby on Rails is nice, particularly for CRUD applications, I wonder why nobody speak of Seaside...
\begin{rant}
Ok, I know, it's probably because it's written in that extremely complex and arcane language, Smalltalk... not. Smalltalk is extremely simple to use -- literally a child's play;-)
\end{rant}
Anyway, Seaside is an incredible framework to develop Web Applications -- not just CRUD apps. It has a wonderful component system, inspired by WebObjects (another wonderful framework !), and leverage Smalltalk: you have compilation on the fly, you can modify something at runtime (and I mean, even without quitting the current web session !), use the incredible debugging/refactoring possibilities, and reuse of the zillions of libraries and code available for Squeak.
More over, it has continuations. And that's really useful (as Paul Graham demonstrated..) for building neat webapps. Basically with Seaside you program applications nearly the same way you'd program a "normal" application. The whole HTTP process is completely abstracted (check the videos).
Frankly, it's really a joy to develop with Seaside, and you should have a look:-)
Don't go for over-structured languages like Ada - they're as bad for newbies as the totally unstructured ones.
Bullshit. In my freshman year, the language choosen to teach programming was, indeed, Ada. And it's an excellent choice: things are very well structured, it has all the things you need to teach concepts (threads, etc.), it has a compiler with "real" (as in, useful) error messages... basically, it "felt" very rigorous, but isn't what we miss in general ?;-)
Frankly, a much better choice than say, Java. In second year we used C++ though, funtional languages, etc.
I agree with you, C++ in first year would have been catastrophic, Java is anyway a better choice than C++ to teach people.
Although I'm tutoring an introductory programming class at uni, and we use Java.. and frankly, I would have much preffered explaining them things using Smalltalk or Ruby.. or even ada, after all:-)
GNUstep on Linux is not yet a Mac OS X or Windows replacement for the typical user, as suggested by the earlier poster. That is my point
But.. I agree with the "not yet":-) -- though mainly because of missing gnustep-based programs (even if the live cd starts to give a good idea) than because of the UI...
What I disagreed in your post was dismissing GNUstep in an hypothetic future, for stuffs that are really quick to fix (and well, "fix" is not automatically the right term considering that many actually don't consider the vertical menus as a problem;-) but hey..)
As you said, it's already possible to have horizontal menu.. if the lack of a graphical UI to choose which style of menu you want is your main problem with gnustep, that's great, because it's not difficult to solve:-) that's all I was saying !
As a side note, when I show GNUstep apps to "normal" people (ok, not computer scientists/power users), many actually like the actual "gray" UI (!) so hated around here, because for them it's 1) simple 2) consistent 3) not intrusive. Vertical menus didn't seem to be a problem...
\begin{rant}
People aren't stupid, if they understand that a menu is a bunch of commands, the fact that it's vertical don't change much their understanding... and vertical menus aren't completely foreign: after all, an horizontal menu transform itself into a vertical menu once passed the first level, isn't that more difficult to grasp ?;-) at least the vertical menus are consistent... and things like contextual menus are vertical menus... so really, I'm not convainced the vertical menus is such a big deal, specially in a GNUstep-only environment (in a mixed env that's another story).
Now, there are some people who are going to say, "But I can already check my email with GNUMail!", and to them I say, "Yes." But the fact remains that the NeXT-style vertical menus are too powerful for the average user. Apple realized that, and ditched them. While it is claimed that horizontal menus can be used when using bundles, it is far beyond the capabilities of your typical user to make such a change.
Uh... I'm not saying that GNUstep is perfect:-) but you basically reject it because it uses "too powerful" vertical menus ?... frankly, vertical menus aren't a problem to USE. Sure, some like horizontal menus (particularly with small resolutions..), but have you any difficulty using window maker's menus ?.. (I guess more people on/. used wmaker's menus than gnustep/nextstep apps...)
And as you say, you CAN easily have horizontal menus in GNUstep. Making that change isn't difficult, but you need to type one line in a terminal, indeed. But nothing prevent us to have a nice GUI -- a Preferences.app module for example -- to choose the kind of menu !
I'm a bit baffled that you reject GNUstep GUI on such small and obviously easily solvable grounds..
Maybe GNUstep would help people migrate over - if they ever get round to beautifying it. Compared to OSX it looks a serious step back
Camaelon 2 brings theme support to GNUstep... check my blog:-)
The Nesedah theme by Jesse Ross is quite nice imho:)
Ok, at the moment Camaelon 2 is not officially released -- that is, I didn't make a tgz because I'd like to fix a few things before, but you can grab it from cvs easily, and the current version works fairly well anyway...
A new GNUstep Live CD will be out in less than a month I'll try to make the release before, in order to have Camaelon 2 on it.
Objective-C was created in 1983 by Brad Cox, then used on NeXT, so it's not exactly something that came in the last ten year;-)
And actually drivers on the NeXT were written in Objective-C;-)
Anyway, it's all a problem of using the right tool for the right job. Objective-C is excellent (particularly with AppKit + InterfaceBuilder on OSX, or with GNUstep+Gorm) for creating graphical applications.
If you need a very optimized code, you can do it in C, or C++... and still keep the rest of the app in Objective-C, as Objective-C is just a superset of C, and the Objective-C++ thingy let you mix C++ code an ObjC code in the same place...
But as they say, early optimisation is the root of all evils:-) which is why most of the time you're much better off with a high-level dynamic language than with a low level or static language. My opinion.
Slashdot Mirror
Well, THIS model does not have 3G, only 2.5G. But Steve Jobs specifically said they were working on a 3G model. Considering it's only supposed to come in europe around september (so, likely introduced at the paris expo) I frankly expect that it will be a 3G model.
As you said, without 3G, video calling is useless anyway. Beside, video calling is more a gadget than something useful, really... did you ever try videoconf with your webcam ? do you use it regularly ? most people in then do not use it apart from an initial "wow it's cool". And with a webcam there's still a few occasions where it is useful (showing kids to grandparents, business conf..) but these uses are anyway quite impractical for a frickin mobile PHONE. Now tell me that Apple would let you plug an iSight on their new AppleTV, and do videoconf in your living room, and here it would be interesting.
Yes, that sucks. The autonomy seems fairly good though, and there was this talk about using two batteries, but still, it would be better to have a user-replaceable battery. At first I even thought that this black part on the back was here for just that...
There WILL be 3rd party software -- jobs said it, and if you think about it, why mention Cocoa and Core Animation if not ! The question is not that. The question is that apparently Apple wants to "control" the software that will run on the iPhone; how THAT will work is unknown yet (eg, could be a compliance test your app will need to pass, or could be more closed -- we just do not know. Wait for the developer conference this summer...). I admit, as a cocoa developer I'm quite pissed about it, I would have prefererred an open access. Though if it's just a compliance test it will be ok for me (depends of course if it wil be costly or not, or if the compliance test will apply to all apps or only the ones using the GSM chip, etc.). As you see, there's a lot of possible combinations on how that will work, and we can only make conjectures for the moment. But there will be 3rd party software, they said it, and it would be moronic to not have them.
First time I hear that rumor. I frankly doubt you'll have a problem to set your ring tone... anyway, it's only a rumor. Wait for the real device.
Far from a deal-breaker. Sure that would be a nice addition.
it's very likely running Quartz (or more probably, a suitably cut-down version), and I wouldn't be surprised if the whole display is vector-based -- after all tiger can already do it (albeit it's unstable/buggy so not activated by default) and leopard *will* be vector-based, officially. Quartz is very close to a DisplayPDF, so indeed displaying PDF is straightforward -- there's a reason it's one of the native format for OS X. And they indeed stated that the iPhone will be able to display PDF files. The way I see it, they ARE running OS X, but simply a stripped-down version with the major frameworks they needed (eg, Cocoa). And as a developper, I couldn't care less if they were running a completely different kernel or even userland -- as long as Cocoa is there. But it's extremely likely that they are, indeed, running a scaled-down version of the "real" OS X -- why would they develop a completely brand new OS ?? knowing that devices regularly increase in power ? that would be seriously stupid. Better to try to shoe-horn OS X on the iPhone, even if it means cutting down some of the stuff for the moment.
Learn how to play chess. :)
Even better: learn how to play Go :-)
Oh, of course. I was just stating why and how I ended up with FreeBSD. With a more recent hardware and/or more ram I could have perhaps sticked to OpenBSD, and for a server anyway it's obviously something I'd consider :-)
But for this old laptop, FreeBSD looks like the right choice ;-)
I must say I agree here :-)
I never used bsd until a couple of weeks ago, when I ended up without a laptop, and a friend lend me an old one (celeron 1ghz, 128mb ram). As a long time debian user, I started by installing the last touted "desktop os" based on debian: ubuntu. Everything worked as usual and was recognized, but.. it was sluggish (those pesky 128Mb were the cause more than the celeron, I believe). Still, I was outraged: I started linux on a p166+ with 24Mb of ram, and it was faster (or at least in my memory) to use, even after ditching gnome and installing window maker + gnustep apps.
Then, on a whim, I installed OpenBSD 3.9, just to test -- why did I never try bsd before in all those years, after all ? Well,.. it felt even slower -- probably because of X11 though. But I liked OpenBSD a lot -- very neat, excellent docs, and it just felt "clean".
So I installed FreeBSD 6. And. Wow. That's friggin FAST :-) even on this machine. I even recompiled the kernel to change the scheduler, and now it's even more responsive under X11 (although it _seems_ things are slightly slower to start, but the trade off is good on this machine).
So count me in the *BSD supporters now -- although apt is wonderful, pkg/ports are quite ok. And I like how it feels like unix again ;-)
How so ? Not A Problem, ... if you are not using something that's not implemented in GNUstep, obviously. Of course, it can be very annoying (cocoa bindings aren't implemented yet, so if you use them...). Even then, a few #if#def to replace the offending code with another solution can prove to be quite simple to do (as most of the code can still be ported easily)...
Frankly, I think that if you can get rather complex apps like GNUmail or Cenon running both on OSX and on GNUstep, surely it's in the domain of the reality, not just pie in the sky.
The problem is more about OSX developers not beeing really interested in porting their apps to linux. On the other hand, they are very interested to port their app to Windows, but somehow most of them just wait for Apple to release YellowBox and/or wait for a good GNUstep/Windows port, with very few actually helping GNUstep (sure, not that surprising...)
Note that GNUstep/Windows status is getting better, although GNUstep apps aren't integrated graphically with Windows, at least now it kinda work (eg like addresses, but more importantly, Gorm (the GNUstep gui builder) compiles on Windows since a few releases).
Imagine running GNUStep on OpenDarwin and being able to run all Mac apps -- that's what the goal ought to be!
Not Possible. GNUstep is not Wine, it's not binary compatible with Cocoa, it's source compatible (mostly).
Anyway, sure, it's not always as easy as a simple recompilation from OSX to GNUstep, but it often is. And when it's not.. it's not that difficult to do the "port", in my opinion/experience, particularly with recent progresses with nib loading (not complete yet, but very close now).
...er.. what's the problem with this approach ? it's not like you can't actually compile that stuff on OSX if you need it too...
It's sad, but this focus on "OpenStep with a bit of Cocoa, and maybe some of our own stuff if it's better" is why nobody uses GNUStep. If their mission was "100% compatibility with Cocoa" instead, then it would be a lot more popular.
Gni ?..
What's the problem with the GNUstep approach ? If you propose some code to the GNUstep project which improve Cocoa compatibility or implements new Cocoa api, you won't be turned off, to the contrary ! While many GNUstep people like OpenStep...
100% compatibility with Cocoa is a noble goal, but you'll always lag behind (hint: Wine), for obvious reasons. GNUstep's goal is just pragmatic: it started as a project to implement OpenStep api, thus it's (still) the official goal. But implementations of new Cocoa api are routinely added to GNUstep ...
Actually, it's not completely true. The first HWR engine was, indeed, from that russian company that does calligrapher now. But there was another HWR engine on NewtonOS 2.0 that was developped in-house at apple (you can choose which one you want). It works wonderfully, and many people talks about this one, not the original calligrapher one.
Well, firstly, the User Interface is excellent. It's the best UI of all the PDA I owned (PalmOS, PocketPC, Nokia 770). Why ? because it's really MEANT to be used with a pen. You can write everywhere on the screen, not just in a small part; you scribble to delete something; you have an easy and quick way of changing input and drawing methods (eg you can choose to have your drawings "straightened" -- draw a kind of circle, the newt will automatically transform it into a real circle, etc). Everything you draw is vectorial and you can easily manipulate it. And other than beeing really built around the use of a pen, the UI is very clean, slick and uncluterred.
Secondly, the recognition engine is incredible. Truely impressive. Basically, it works. Really, really cool. The simplicity of mixing some written text (automatically recognised) with some "ink" text, and any kind of drawing ... really gives you a _working_ notepad. It's the only PDA I ever used that could really be used for taking notes (and I _did_ once try to write down a course on my Palm Vx ;-) -- absolutely unusable apart from the "let's try it" factor).
Thirdly, NewtonOS is built on a real OO core, and NewtonScript is a very neat language. That's basically how things like the fat driver / patch or einstein were possible, as you can intercept messages. But more importantly for the user, you don't have files, but a kind of simple OO database. Why is it important ? because it lets applications _easily_ cooperate, picking and sharing informations. Real cooperation between apps is possible. It helps a lot to remove the apps at the back, and put your datas at the front.
Fourthly, there is this neat "assistant" technology that actually make a good use of the OO databases. That's how you can write "meet dave next friday", click on the assistant button, and automatically the Newt will propose you to add a new meeting entry into your calendar, for the next friday, with the most likely dave you know from your address book (and of course it's easy to change the propositions in the dialog box).
There's also the possibility to "send" apps results (by mail, by fax, to the printer, etc.) easily. Plus an I/O general mechanism to deal with everything you send or receive on the newt.
And lastly, the form factor. That's something that, sadly, is forgotten by the so called PDA today. Having a *big* screen helps a lot to write proper notes -- I mean, physically, not the resolution, even if the Newt resolution is rather good. Basically, while it's smaller than a tabletpc, it's also big enough to be useful for real note taking (and more).
Oh, and something that everybody forget to say: as it used flash memory, you never lost anything, even if your battery run out. Speaking of batteries, mine simply used standard AA batteries..
I really miss my newton 2100 (it was stolen...) .
And my new shiny nokia 770 is so far behind on the UI side it's not even funny (even if it's better on some technical aspects, mainly, the screen resolution). And I actually think that Maemo is a quite ok UI, compared to the other available choices today ! So, if I can put Einsteing on my 770... You bet I'll use it ;-)
For those interested, I wrote a few posts about the newton, the dynabook, and the nokia:
http://camaelon.blogspot.com/2005/07/newton-toil.h tml
http://camaelon.blogspot.com/2005/10/nokia-770.htm l
You know, don't mix Parisians and the rest of the country -- Parisians have that bad (sometimes justified) reputation as rude and snob people even in France ;-)
Of course, with the recent tensions between US and France, some stupid people can be ruder than usual -- stupidity is sadly international, as those freedom fries thing proved it.
Speaking as a French, that sounds like a nice compromise ;-)
Well... you're wrong. Objective-C is a compiled language, not an interpreted one.
Do you have any links for plugins for Gorm? It seems like the whole interface was based on the user writing ObjC for complex actions/methods.
Indeed, the basic idea is to use ObjC for complex actions/methods (considers though that ObjC is a strict superset of the ANSI C, so you could simply put your C code in an ObjC method without any modifications, and the next release of gcc will even allow you to mix ObjC and C++). There's no repository for Gorm palettes, but you can have a look on my blog to get the StepTalk palette.
Oh, how does the philosophy matter at all?
By the philosophy is different, I'm talking about the framework (GNUstep/OpenStep) and the language (ObjC) -- they are vastly different from Qt and C++. And frankly, I rather like Qt, programmed with it before jumping on the GNUstep ship; the signals/slots mechanism of Qt is actually quite inspired by OpenStep target/action. But ObjC and OpenStep are without a doubt much better suited for the job than Qt/C++, really (I would use C++ for a 3D engine, but ObjC for the gui -- the right tool for the right job, period). Partly because of ObjC functionalities and its dynamism (introspection, modify things at runtime, true polymorphism, replace a class by another, catch any messages, etc.) and partly because of the sheer design quality of OpenStep. It's an amazingly well designed framework. I may remind you that Cocoa on OSX is actually an OpenStep implementation..
i didn't see anything in the demo which couldn't be done on a different platform and the right interface builder. I mean QT designer can do 50% of what Gorm does with the exception of the custom actions. (I admit that is a large shortcoming though). However the entire concept of writing actions in a tiny window will not scale for medium to large applications. So I hope Obj-C's import facilities are good. Just look at the hoops Flash developers go through.
Ouch.. the point of Gorm is frankly NOT to write actions in a tiny window -- actually Gorm don't do it, in the demo it was done by the StepTalk palette. Gorm is an Object Modeller more than a GUI builder, in a sense. Its real job is to connect objects, graphical or non graphical. And you're working on the "real" objects. A .gorm file is simply the serialization of the object graph... So, no, you can't do that in any other UI builder, apart (obviously) from InterfaceBuilder on OPENSTEP^WMacOSX :-)
And yes, of course you usually import ObjC headers in Gorm, or create the class in Gorm itself. If you only saw the "StepTalk" demo, have a look to the Dataset demo, and if you want to see an example of ObjC code with Gorm, check the third demo.
Well actually, neither Afterstep or WindowMaker are based on GNUstep -- they are written in C, not Objective-C, and they don't use at all the GNUstep libraries.
Actually, no, that's the point. Not that much is missing... the problem with GNUstep is that before implementing nearly the complete api (which is done) and having an InterfaceBuilder like (which is done by Gorm), it was rather difficult to use it and be it of any interest... Thus KDE and GNOME catched rather than GNUstep, in my opinion because they were able to incrementally build their desktop, and thus, propose something immediately of some use. Vicious circle of course for gnustep, as it then didn't attract many developers, etc.,etc.
It really does illistrate the power of scripted interfaces through.
Scripted interfaces ???? Gorm is not that, at all :) ... if you just saw the StepTalk demo, check the rest :) -- The StepTalk Palette is just a "plugin" for Gorm if you want...
I want to see the same thing (but better!! :) coming from QtRuby/Korundum
since it sould be SOOOOO easy to do so.
That, I doubt it.. although Ruby is dynamic enough to build interesting things.. but the philosophy of OpenStep is rather different..
Did you notice that there's actually sound (as in me, talking and making sense of all the mousewaving) in those videos ? :-)
what I'm seeing here is Visual Basic, with object orientation. Not to knock it because of this.
Frankly, no, it's vastly different. Or, in a way, yes, it's "VB with object orientation"... but:
So yes, it's "VB with OO" if you want to see it that way :-D but it's FAR from following the "VB paradigm".
It's a bit tedious to explain with words what Gorm is all about -- it's much simpler to actually *see* it :-)
If you have only one video to see, check the one about the custom palette -- but the other are interesting too :-) (the StepTalk one demonstrate a creation of a simple calculator *entirely* in Gorm, using the StepTalk palette, which let you code in various languages).
Apparently GNU Smalltalk technically could have a Seaside port (see the bottom of the download page), but nobody wrote one.
As one comment said, you can use VisualWorks. But.. you really should try Squeak anyway. Sure, it has a.. well.. unusual UI. But it's really good :-)
\begin{rant} ;-)
Ok, I know, it's probably because it's written in that extremely complex and arcane language, Smalltalk... not. Smalltalk is extremely simple to use -- literally a child's play
\end{rant}
Anyway, Seaside is an incredible framework to develop Web Applications -- not just CRUD apps. It has a wonderful component system, inspired by WebObjects (another wonderful framework !), and leverage Smalltalk: you have compilation on the fly, you can modify something at runtime (and I mean, even without quitting the current web session !), use the incredible debugging/refactoring possibilities, and reuse of the zillions of libraries and code available for Squeak.
More over, it has continuations. And that's really useful (as Paul Graham demonstrated..) for building neat webapps. Basically with Seaside you program applications nearly the same way you'd program a "normal" application. The whole HTTP process is completely abstracted (check the videos).
Frankly, it's really a joy to develop with Seaside, and you should have a look :-)
Bullshit. In my freshman year, the language choosen to teach programming was, indeed, Ada. And it's an excellent choice: things are very well structured, it has all the things you need to teach concepts (threads, etc.), it has a compiler with "real" (as in, useful) error messages... basically, it "felt" very rigorous, but isn't what we miss in general ? ;-)
Frankly, a much better choice than say, Java. In second year we used C++ though, funtional languages, etc.
I agree with you, C++ in first year would have been catastrophic, Java is anyway a better choice than C++ to teach people.
Although I'm tutoring an introductory programming class at uni, and we use Java.. and frankly, I would have much preffered explaining them things using Smalltalk or Ruby.. or even ada, after all :-)
But.. I agree with the "not yet" :-) -- though mainly because of missing gnustep-based programs (even if the live cd starts to give a good idea) than because of the UI ...
What I disagreed in your post was dismissing GNUstep in an hypothetic future, for stuffs that are really quick to fix (and well, "fix" is not automatically the right term considering that many actually don't consider the vertical menus as a problem ;-) but hey..)
As you said, it's already possible to have horizontal menu.. if the lack of a graphical UI to choose which style of menu you want is your main problem with gnustep, that's great, because it's not difficult to solve :-) that's all I was saying !
As a side note, when I show GNUstep apps to "normal" people (ok, not computer scientists/power users), many actually like the actual "gray" UI (!) so hated around here, because for them it's 1) simple 2) consistent 3) not intrusive. Vertical menus didn't seem to be a problem...
\begin{rant}
;-) at least the vertical menus are consistent... and things like contextual menus are vertical menus... so really, I'm not convainced the vertical menus is such a big deal, specially in a GNUstep-only environment (in a mixed env that's another story).
People aren't stupid, if they understand that a menu is a bunch of commands, the fact that it's vertical don't change much their understanding... and vertical menus aren't completely foreign: after all, an horizontal menu transform itself into a vertical menu once passed the first level, isn't that more difficult to grasp ?
\end{rant}
Uh... I'm not saying that GNUstep is perfect :-) but you basically reject it because it uses "too powerful" vertical menus ?... frankly, vertical menus aren't a problem to USE. Sure, some like horizontal menus (particularly with small resolutions..), but have you any difficulty using window maker's menus ?.. (I guess more people on /. used wmaker's menus than gnustep/nextstep apps...)
And as you say, you CAN easily have horizontal menus in GNUstep. Making that change isn't difficult, but you need to type one line in a terminal, indeed. But nothing prevent us to have a nice GUI -- a Preferences.app module for example -- to choose the kind of menu !
I'm a bit baffled that you reject GNUstep GUI on such small and obviously easily solvable grounds..
Camaelon 2 brings theme support to GNUstep... check my blog :-)
The Nesedah theme by Jesse Ross is quite nice imho :)
Ok, at the moment Camaelon 2 is not officially released -- that is, I didn't make a tgz because I'd like to fix a few things before, but you can grab it from cvs easily, and the current version works fairly well anyway...
A new GNUstep Live CD will be out in less than a month I'll try to make the release before, in order to have Camaelon 2 on it.
And actually drivers on the NeXT were written in Objective-C ;-)
Anyway, it's all a problem of using the right tool for the right job. Objective-C is excellent (particularly with AppKit + InterfaceBuilder on OSX, or with GNUstep+Gorm) for creating graphical applications.
If you need a very optimized code, you can do it in C, or C++... and still keep the rest of the app in Objective-C, as Objective-C is just a superset of C, and the Objective-C++ thingy let you mix C++ code an ObjC code in the same place...
But as they say, early optimisation is the root of all evils :-) which is why most of the time you're much better off with a high-level dynamic language than with a low level or static language. My opinion.