Slashdot Mirror

← Back to Stories (view on slashdot.org)

10 Years of OpenStep

Posted by CmdrTaco on from the back-in-the-day dept.

tarzeau writes "Today, the OpenStep API celebrates its 10th anniversary. What started out as a joint adventure of NeXT and SUN to define an application development standard that would run on all machines, making 'write once, compile everywhere' a reality, is still unfolding within the vivid and active community of GNUstep, old NeXT and Apple lovers. The magic 10 appears in GNUstep's current 1.10.x release and in Apple's Mac OS X 'Cocoa' release. Programmers worldwide can develop their programs on Mac OS, Linux, the BSDs, Solaris, and with a couple of hurdles -- even on Windows. This solid and well-defined standard is reaching out to the world of software development, slowly but surely. Program your applications in days or weeks, rather than years or never. Use the advanced API of a development framework that hasn't needed significant modification for 10 years, because it rocks, is stable and just works."

62 of 338 comments (clear)

  1. Next by 2.7182 · · Score: 4, Insightful

    I was a really big Next user, and for me OS X seems to be the natural extension of it. But it was amazing to be using Next machines in the early 90's. They were remarkably ahead of their time.

    1. Re:Next by sgant · · Score: 2, Informative

      GNUstep isn't a windowing environment...it's a development environment. Windowmaker is the windowing environment that looks like NeXTStep.

      Right on www.gnustep.org it states:

      GNUstep itself is not an operating system, window manager or desktop environment, though there are several desktop environments in development that are based on it.

      just some info.

      --

      "Leo Fender was in a 'state of grace' when he designed the Stratocaster." -- Paul Reed Smith
    2. Re:Next by Daengbo · · Score: 4, Interesting
      OK, suppose I want an OpenStep desktop on a GNU/Linux system... What desktop should I use? GnuStep gives me no good answer!
      GNUstep is development environment, not a window manager Many people have confused GNUstep with WindowMaker. GNUstep, however, is not a window manager. WindowMaker is the most often-used NeXT-looking application on a non-NeXT system. WindowMaker also uses a derivation of the GNUstep logo. WindowMaker is the preferred GNUstep window manager, but GNUstep applications also work with any window manager, although you're most likely, currently, to have a more cohesive desktop experience if you use the two in conjunction.

      Relation to WindowMaker WindowMaker is a window manager, not a workspace manager nor a file browser. It is nothing more. WindowMaker and GNUstep share almost no libraries or functionality. WindowMaker is written in C, and GNUstep is written in Objective-C. WindowMaker does make certain things easier for GNUstep, but it is not GNUstep itself, although it is a part of the project.
      Well, then... GnuStep seems to recommend WM as the choice for Gnustep applications, but isn't itself Gnustep in any way.

      Is there anything that is? I would like to install and play for at least five minutes...
      --
      Put identity in the browser.
    3. Re:Next by roard · · Score: 3, Informative

      You could want to install/use Backbone or Garma, which are GNUstep-based Desktops...

    4. Re:Next by Daengbo · · Score: 3, Insightful

      I appreciate the long explanation, but I understood that part and was looking for a wm (not WM, haha) that was based on GnuStep, but there doesn't appear to be anything like that, though several attempts have been made and a distro (Linux-Step?) aborted.

      Although this is going to sound a lto like flamebait, it is a real question... Is GnuStep a viable platform? Ten years without a wm based on it? It sounds like a perfect match for the Hurd, a technically superior solution that never goes anywhere and never dies. (OK, maybe the last sentence WAS flamebait)

      --
      Put identity in the browser.
    5. Re:Next by Anonymous Coward · · Score: 3, Informative

      NeXT wasn't modeled on Smalltalk. I was there for years and no one talked about Smalltalk. Maybe you mean that Objective-C was modeled on Smalltalk, which was true, but no one was thinking, "Let's make a better version of Smalltalk"; it wasn't even on the radar.

      The beauty of Objective-C was that it was just enough OO. In practice, you could make your code as efficient as C and you could have full control over your (small) memory footprint, and we made great use of inheritance, reuse, polymorphism, and late binding and linking, but it was lightweight enough that a full system ran well in 32 megs of RAM, and for everything I did, you wouldn't even be swapping if you had 48 megs for the entire system. We even had Objective-C in the kernel so you could subclass drivers. I like the syntax of Java, but it's a bloated pig by comparison and I would never use it on a server that I expected to scale, while I wouldn't hesitate to use Obj-C in this manner.

      Smalltalk may have been a more pure OO environment or better for rapid turnaround development, but no one has used it for the kinds of applications or system that NeXTstep excelled at 15 years ago (or OSX does of late).

    6. Re:Next by roard · · Score: 3, Informative

      Hm..I thinkg you misunderstand how things are related in fact.. under X-Window, you need a special program, in charge of the window management (ie, to move them, etc.). It's called.. a window manager. WindowMaker is a X11 window manager.

      Then you have X11 programs, that are in charge of their window's content. As programming directly using XLib is not fun, there is a lot of X11 "toolkits". Qt and Gtk are examples of toolkits.

      GNUstep is an implementation of the OpenStep API. Basically, it's a programming library, a toolkit like Qt and Gtk if you want -- not only for graphic apps, but also for non-graphic apps. In fact, the OpenStep API is divided in two frameworks: Foundation (which deals with non-graphical things such as threads, files, unicode strings, etc.) and AppKit (which provides all the nifty widgets and how you use them). But, additionally to that, GNUstep *also* provides development applications: Gorm, a graphical interface builder, and ProjectBuilder, an IDE.

      Actually, GNUstep runs mainly on X11, but the way it is architectured, it's not that complex to use other drawing display. For example, there is 3 backends for X11 -- one using xlib, the other using libart, and the third using Cairo. And there is a backend for Windows GDI. So in fact, it's not tied at all to a X11, and the notion of an independant window manager is specific to X11 (actually, GNUstep apps don't really need a window manager even under X11 -- they can manage themselves..).

      But, if you're under X11, chances are that you want to run other programs alongside GNUstep programs -- KDE/GNOME programs for example. You then *need* a window manager. WindowMaker is the "default" window manager recommanded by the GNUstep project, mainly because its look and feel match the GNUstep look and feel. But you can use others window manager.

      And WindowMaker itself doesn't use GNUstep.

      Not sure if I understood well your questions, I tried to explain how things are related, hopefully more clearly.

  2. Call me stupid, but.... by rwven · · Score: 2, Interesting

    I've been around computers a long time and i've never heard of it. What major application can anyone mention that has been developed on it? A 10th anniversary of something that barely anyone has ever used (in the big scheme of things) is really not any great thing to celebrate... I like the idea of it, but i'm not sure it's as wonderful of a hit as this news article is trying to make it seem.... Or am i off the mark here?

    1. Re:Call me stupid, but.... by CoolMoDee · · Score: 4, Informative

      The first web browser was developed with NeXT and Openstep...

      --
      Jisho - A Japanese English German Russian French Dictionary for the rest of us.
    2. Re:Call me stupid, but.... by Nexum · · Score: 5, Informative

      What about the first web browser for a start?

      The first wholescale industrial use of OOP practices?

      etc. Do some googling.

      --

      This sig has been deprecated.
    3. Re:Call me stupid, but.... by oudzeeman · · Score: 2, Insightful

      Most OS X apps...

    4. Re:Call me stupid, but.... by AKAImBatman · · Score: 5, Informative

      The NeXTStep (a.k.a. OpenStep) API was developed as part of the NeXTOS that ran on NeXT workstations during the 90's. Several deals were made with other Unix vendors (including Sun) for them to support the "OpenStep" standard.

      NeXT was bought off by Apple, and was developed into Mac OS X. The OS X Cocoa API is really nothing more than the NeXTStep API set, and is almost 100% source compatible with programs from the old NeXT machines.

      More Information

      --
      Javascript + Nintendo DSi = DSiCade
    5. Re:Call me stupid, but.... by mirko · · Score: 5, Informative

      The game Doom was also developed on NeXT.

      --
      Trolling using another account since 2005.
    6. Re:Call me stupid, but.... by WillAdams · · Score: 5, Informative

      WorldWideWeb.app and Doom have already been mentioned --- lengthy discussion of the former in the book _Weaving the Web_ by Sir Tim Berners-Lee, check the source for Doom.app and John Carmack's blog to learn how he feels about NeXTstep.

      Other things:

      - Altsys Virtuoso (this became Macromedia FreeHand)
      - Lotus Improv (which lives on as Quantrix or Flexisheet)
      - MusicKit
      - MiscKit
      - Pages by Pages
      - TouchType.app

      Other more recent developments:

      - Cenon - http://www.cenon.info
      - GNUmail
      - ProjectCenter
      - GORM

      William

      --
      Sphinx of black quartz, judge my vow.
    7. Re:Call me stupid, but.... by AKAImBatman · · Score: 3, Insightful

      and the cases burned really well due to the fact that they were cast magnesium

      Poppycock. The cases were a magnesium alloy. The only way the guy got it to burn was to heat it to several thousand degrees so that the alloy broke down. Not to mention that he had to try it with two different cases, AND use tons of lighter fluid to get one to ignite. :-)

      --
      Javascript + Nintendo DSi = DSiCade
    8. Re:Call me stupid, but.... by NoMoreNicksLeft · · Score: 3, Insightful

      Both good examples, but you missed one. Mac OSX.

    9. Re:Call me stupid, but.... by DrXym · · Score: 3, Insightful
      Don't be facetious. Any programmer unfamiliar with the interface builder would sit there boggling at the screen for minutes in total incomprehension. I've used all kinds of UI development tools over the years running the gamut from horrible to sublime. XCode definitely falls near the bottom. Certainly not as bad as trying to visually design a Swing app but close.

      Interface builder is not intuitive, it's not even discoverable. Joining objects residing in two separate windows with lines doesn't even make sense from a usability perspective. Even when you eventually figure out how to create classes and join them up to buttons, it is non-obvious how that maps onto actual code. On top of these problems you have to learn a new language just to be able to get your UI to do anything. If the documentation & help system were up to snuff it might shorten the learning curve but they're not - it takes seconds to do a search on MSDN, so why does it takes minutes on OS X?

      Thus, the new programmer is faced with an unfamiliar language, an unfamiliar metaphor for UI building, and an unfamiliar framework with bad documentation. I haven't seen such an uncompromising and steep learning curve for a long time. And all that to programme a supposedly user friendly OS.

      So yes I do think it is non obvious. In my case it was the first time I actually had to buy a book ("Cocoa Programming for Mac OS X") before I could even figure out what was happening. I haven't seen XCode 2.0 it has to be said, but I sure hope they intend to make it easier to use. Even a few wizards with common design patterns might help somewhat.

    10. Re:Call me stupid, but.... by bnenning · · Score: 3, Interesting

      Most OS X apps use Cocoa & Objective-C for their front-end.

      Or Carbon and C/C++.

      That's not to say I don't think Objective-C is elegant but I'd still prefer C++

      No, you really wouldn't. C++ just doesn't have the dynamic capabilities that Cocoa apps exploit to substantially reduce code. Simple example: given an arbitrary object, determine if it implements a named method. One line of code in ObjC, and this allows Cocoa apps to automatically enable and disable menu items depending on what actions are valid for the current selection.

      --
      How to solve most of our problems: 1.Lots of nuclear plants. 2.Cure aging.
    11. Re:Call me stupid, but.... by FuzzieNorn · · Score: 2, Insightful

      Xcode 2 does fix the documentation/help system. And, yes, Xcode does take a bit of getting used to, but you certainly don't have to buy a *book*. Just reading the online tutorial, which just consists of a few pages of text, was more than enough to get me to understand everything except the language (and you can't possibly call an unfamiliar language a problem with Xcode, any new language is going to be unfamiliar, shock).

    12. Re:Call me stupid, but.... by Cobalt+Jacket · · Score: 2, Interesting

      A lot of proprietary systems were developed on it. The CIA had (not sure if they still do) a lot of NeXTstep apps. And First Chicago (now J.P. Morgan) developed a lot of their internal systems using NeXTstep. That stuff is still around in various forms.

    13. Re:Call me stupid, but.... by Lars+T. · · Score: 3, Funny
      Nothing like posting a web page as proof - that debunks your little story.
      With these test shots out of the way, we started to think about burning the cube itself. When I had called NeXT to find out what kind of paint they had used to paint the cube, one of the people I had spoken with told me that the cube was made out of "magnesium alloy which is specially designed to be difficult to ignite." These words came back to me as I stood in front of the burn chamber at Livermore. What if we couldn't get the cube to ignite? The idea stood out in my mind like a sore thumb.

      [...]

      We put the rear panel into the burn chamber. The panel is a square piece of metal, 14'' on each side, and roughly half an inch thick. We stood it on end with a pair of bricks. Then we hit it with the MAP gas tource.

      Nothing happened.

      We kept the torch focused on the rear panel. Slowly it heated up in the spot where the flame lapped. Soon the metal started to melt. Then it puffed up with a white, caky ash.

      "What's going on?" somebody asked.

      We kept the flame on the spot. After another minute, we saw that same telltale white spark. "It's caught!" somebody said. The person holding the torch backed away.

      The flame sputtered for a few seconds, then it went out. Something was clearly wrong.

      We tried again with the MAP gas torch, with similar results. "We have problems like this all of the time," Kirk said, trying to reassure me. "Sometimes its really hard to get things burning." He then walked over to a storage shed and wheeled back an oxygen-acetylene torch. "This should set it on fire," he said with a gleam in his eyes.

      The acetylene torch bruned a lot brighter than the MAP gas, but the results were similar. The back panel glowed red, burned white, sputtered a little, then went, leaving a caky white residue --- and a hole.

      "This is so NeXT," I told Sally. "Everything works great in the tests, then when you try to make it work for real, in the field, nothing works. They build a computer out of magnesium, and it doesn't even burn!"

      --

      Lars T.

      To the guy who modded me down from perfect to terrible Karma - Apple haters still suck

    14. Re:Call me stupid, but.... by Altus · · Score: 2, Interesting


      all of the internal tool and editors that produced the content were developed using Objective-C and openstep.

      --

      "In America, first you get the sugar, then you get the power, then you get the women..." -H. Simpson

    15. Re:Call me stupid, but.... by Kplusplus · · Score: 2, Insightful

      I have to admit that I did the same when I first launched Interface Builder, but guess what I opened the help and it told of connecting objects to code and I was done, I understood.

      You seem to speak ill of IB because its not like everything else you used, you seem unable to realize that this is a GOOD thing, a strength, not a weakness. Interface Builder doesn't generate crappy code for you, instead it generates real objects that are instantiated at runtime then bound to your code. Show me a pre-existing GUI designer that does that and then your point makes sense.

      Interface Builder is unilke everything you have ever seen in every way, but every way is better. There is no craapy code generated, there is no retarded boxes nor grids to lay things out with, but instead struts that decide the resizeMask of widgets, and almost all the setting can be made in IB, much more powerful than all teh other GUI editors, and so much easier once you udnerstand.

      Unfamiliar framework, yes, bad documentation, no. I mean come on, its new to you so your not familiar with its ins and outs, but just because it doesn't do something like API or library foo doesn't mean it is somehow limited. The docs and the API itself has a clear seperation of tasks and responsibilities, all you need to do is glance through the API docs, or if thats not clear enough for you, start at the Conceptual Docs that explain things without introducing the code involved in detail.

      Also as to searching the OS X developer resources, your not doing it right, since the ADC library consolidation makes looking up info generally work the first time and finds exactly what I was looking for when I search not related documents, or documents that will lead me to teh answet, but th answer itself.

      The language, lets not cry foul there either, ObjC is blindingly simple to learn if you already know C. It's a few extensions and a CLEAR way of handling objects. The entire reason for teh bracket syntax is to clearly dileaneate object interaction from just memory manipulations of other functions.

      You bought a book to introduce you to something new that you didn't know and had to learn, what is surprising about this? Some buy books, some read example code, some just get it. No shame in not understanding, seeking out the knowledge doesn't hurt anyone.

      --
      -"I'm one of those Mac people that will break a bottle on the bar and hold it to your throat for bad-mouthing my system"
    16. Re:Call me stupid, but.... by Brett+Johnson · · Score: 2, Insightful

      The NeXTstep and OpenStep APIs are extremely well designed. The are both comprehensive and consistent. Even as new "kits" (now call frameworks) were created, they shared a great deal of consistency with existing frameworks.

      The quality of the designs are evident in the very small number of frameworks that needed to be modified in an incompatible way or completely replaced. (The inadequately designed DBKit being replaced by EOF comes to mind.)

      When I compare these attributes to Sun's highly inconsistent Java APIs and Microsoft's frequent replacement of frameworks with a completely different "improved yet incompatible" API, I just groan. Even though Sun and NeXT had a relationship, I couldn't figure out why Sun didn't copy some of NeXT's obviously better designs for its own Java frameworks.

      I used the high quality, ease of use, and consistency of the NeXTstep/OpenStep APIs as examples that help me significantly improve my own OO design skills.

  3. Re:Sorry. by uid100 · · Score: 2, Interesting

    Why is it ugly?
    What's wrong with programming with a standard?
    Doesn't it make sense to write once - compile anywhere?

    --
    ...yup...
  4. Another French pioneer... by mirko · · Score: 4, Informative

    Kudos to Jean-Marie Hullot, who contributed to this by designing "Interface Builder" !

    --
    Trolling using another account since 2005.
  5. What's NeXT? by mrchapp · · Score: 4, Interesting

    Looking back at my old NeXT (we never lose a chance to brag about having one) makes me wonder what's coming in the next 10 years, and how much of that will arrive from Steve Jobs' hand.

    1. Re:What's NeXT? by CodeWanker · · Score: 2, Funny

      And there's another advantage: job security. If you can port an existing mission critical system to this or develop a new on with this, you've got a real hostage :)

      --


      "Wow. Now THAT'S a lot of angry Indians." - Lt. Col. George Armstrong Custer
  6. to understand this in context by minus_273 · · Score: 5, Interesting

    consider that tin burns lee when developing the www and the original browser gave up on his old projects and got a next box becasue the development of the UI and software was so easy on it. I wonder what would have have happened hsd he not gotten it :).
    On a side note, it is really quite sad the linux developers are not using/updating openstep. The fact that it is nearly completely compatible with OSX's Cocoa is a huge plus. I discovered this while developing software in Cocoa and have often thought about how cool it would be to have a GL based desktop with a slick Openstep ui ( the current one looks like it is stuck in 1993) on linux.. Then I got a Mac

    --
    The war with islam is a war on the beast
    The war on terror is a war for peace
  7. There was never anything so consistent, stable.... by WillAdams · · Score: 4, Interesting

    and productive out of the box as NeXTstep (says the guy who still uses a NeXT Cube as his main production machine at home).

    - Command= in any app to get a definition in Webster.app rocks
    - having all of your man pages, the sysadmin refs, and the works of Will Shakespeare and anything else you wish to add in Digital Librarian ensures one can look up what one needs at will.
    - Being able to improve the functionality of _any_ app by installing a Service or an app which provides a Service provides a synergy one doesn't get in Mac OS X where it's hit-or-miss whether or no an app supports Services (Cocoa apps do, Carbon and Java apps have to be specially coded)
    - having total control over the screen (you can drag off-screen and hide all but one pixel of the vertical menu, one tile of the Dock)
    - The vertical menu makes tear-off sub-menus make sense, which allows effortless customization of one's working environment for a given task w/o inscrutable toolbars
    - the pop-up menu means that the menu for the current app is always instantly available --- some commands can even become gestural in one's access to them, e.g., ``Punch'' in Altsys Virtuso, right-button-menu click, down a bit and straight over and release

    I could go on, and I have, check my rants on groups.google.com in comp.sys.next/mac.advocacy

    I've got a little bit more on my site, http://members.aol.com/willadams look for my nascent gnustep pages, or the NeXT brochure in my portfolio

    Or of course, visit http://www.gnustep.org or http://www.stepwise.com for some good programming info

    William

    --
    Sphinx of black quartz, judge my vow.
  8. Some links about OpenStep/GNUstep/Cocoa .. by roard · · Score: 3, Informative
    Some GNUstep links:

    Other links, Objective-C and Apple Cocoa
  9. portability by _|()|\| · · Score: 2, Interesting
    It's not their fault, but GNUstep isn't exactly ubiquitous, so it's not a shoo-in for Unix development. After spending some time with the Xcode tutorials, I was eager to try Objective C on Linux. I then realized that a lot of what was cool about ObjC was in the foundation framework, which was part of GNUstep. Since this wasn't packaged for either of my readily available distributions (SuSE and Red Hat), I built it from source, which was routine, but non trivial.

    After GNUstep was finally installed, it took a few trips to Google to figure out how to actually compile a program. It turns out that GCC for OS X has some options that are not present on Linux, such as (IIRC) -framework. The other problem had something to do with having to add code to enable garbage collection.

    The final annoyance I encountered, before moving on to other projects, was the lack of autoconf support for Objective C. Again, it's not their fault, but ObjC/*Step feels like a second-class development environment on Linux.

    1. Re:portability by Abcd1234 · · Score: 2, Interesting

      I built it from source, which was routine, but non trivial.

      Well, my first question is, what was non-trivial about it? You download four packages (gnustep-make, gnustep-base, gnustep-gui, gnustep-backend) and build them (in the order I listed them) just like any other application. Then, just source $GNUSTEP_ROOT/System/Makesfiles/GNUstep.sh in your .bashrc and you're all set to go. Any other GNUstep apps you wish to build are a simple untar and "make && make install".

      It turns out that GCC for OS X has some options that are not present on Linux, such as (IIRC) -framework.

      Yes, there are some issues with OSX compatibility (in particular, the "import" versus "include + ifdefs" issue), but they're fairly easy to work around (just ask the GNUmail folks). (BTW, the answer is "include + ifdefs", if you want your code to be portable. :)

      And as for garbage collection, GC in GNUstep is still experimental, AFAIK, and isn't really necessary (though very convenient). The OpenStep way is to use NSAutoreleasePools and the related retain: release: and autorelease: messages in NSObject itself. It's an odd paradigm to get used to, but once you understand it, it works fairly well (aside from it using straight reference counting which, as well all know, breaks in the face of circular dependencies).

      The final annoyance I encountered, before moving on to other projects, was the lack of autoconf support for Objective C.

      Why, dear god, would you ever *want* autoconf support? The whole point of the Makefiles package is to take care of all your build requirements for you. All you have to do is create a simple Makefile for your project, and voila, the system does everything else for you. All you have to do is a basic "make && make install" to build and install your package. Frankly, I consider this a *far* superior solution to the mess that is autoconf. The fact is, autoconf has no place in the world of GNUstep (other than to, of course, build some of the GNUstep packages, themselves, before the Makfiles package is available)... and it's a better world as a result.

    2. Re:portability by roard · · Score: 2, Informative

      Actually, the "import" versus "include + ifdefs" is not a problem. It's not even really a GNUstep problem -- more a gcc one. At one point, they deprecated the "import" (but the support was still there..). Now, the "import" is no more deprecated in the current gcc. So... if you want to use import, go on, it works with the apple gcc and the fsf gcc..

      The automatic garbage collection support (using boehm library) in GNUstep is, afaik, only available for -base (Foundation), not -gui (AppKit), although I could be wrong. I must confess that I never tried it, as the retain/release/autorelease garbage collector scheme works well enough (and is very flexible) as soon as you understand it (a very good article about it is this one).

  10. Re:Write once run anywhere will *NEVER* happen by animaal · · Score: 2, Insightful

    With leading-edge games like Doom3? You're right.
    With device drivers? You're right again.

    However, some class of applications can be written once and run anywhere. I've written enterprise apps on Linux that just ran fine the first time they were tried on Windows, Solaris, etc.

    Technologies like Java, Python and Ruby make it real. And I'd bet that in the not-too-distant future, games for mobile devices will be "write once run anywhere". J2ME is a good stab at it, but I don't think it's quite there yet.

  11. PARCPlace's Environment Beat It by Baldrson · · Score: 2, Interesting

    Just shy of 8 years ago I was involved in a startup that was taking an insurance company paperless. Some developers who had been using NeXT since the first beta release of the black cube were there and decided to run a test of development environments. One was NeXTSTEP and the other was PARCPlace's Smalltalk environment. The test involved the same set of forms presented as paper to the developers, whose job it was to make those forms into computer applications updating a database. One developer useed PARCPlace's Smalltalk environment. The other used NeXTSTEP. PARCPlace's environment beat NeXTSTEP by better than a factor of 2.

    --
    Seastead this.
  12. Objective C by RAMMS+EIN · · Score: 3, Interesting

    The *step development environment is greatly loved by those that use it, and largely ignored by the rest of the world, because they refuse to learn Objective C. Instead, they use Java, which is very much the same idea in a different shape. This is a great pity, because with OpenStep the world could have had it all so much earlier.

    Oh, and I wanted to mention that GNUStep is pretty universally percieved to be ugly, but support for theming is being worked on (it already works, but appears very limited).

    --
    Please correct me if I got my facts wrong.
  13. OpenStep vs. KDE and Gnome by Florian · · Score: 5, Insightful
    It's a pity that, at the peak of the Linux desktop hype in the late 1990s, when evangelists predicted the near death of Microsoft, KDE and Gnome were rushed out of the door, and GNUstep development remained obscure. It was the first time that distributed free software development defected from its proven practice of implementing standardized, proven APIs and technology (like POSIX) and created major APIs of its own. The result is that KDE and Gnome have created APIs that nobody uses for serious large-scale software development projects [except those companies who have large investments into KDE/Gnome themselves, like Ximian with Evolution]. Now KDE and Gnome have a long way to go to clean up and standardize their APIs (via freedesktop.org), usability (via UI guidelines) and code, solving issues that adherence to an existing open GUI specification like OpenStep would have prevented in the first place.

    Imagine the massive development efforts on KDE and Gnome, including the massive rewrites of their codebases, would instead had gone into GNUstep, so that the GNU/Linux and *BSD desktop would be OS X/Cocao source compatibile today [and companies developing for OS X port their software to Linux basically with one more compiler run]...

    --
    gopher://cramer.plaintext.cc http://cramer.plaintext.cc:70
    1. Re:OpenStep vs. KDE and Gnome by muecksteiner · · Score: 5, Insightful

      The main trouble - then and now - is that the majority of folks simply "don't get it" why OpenStep is superior to crippleware APIs like Qt/KDE.

      KDE is "trying to do an improved Windows on Linux" (and taking a lot of its bad design choices with them in the process), while OpenStep is something entirely different. And for an average, M$-infected programmer using something like that would require some re-thinking of some of one's own assumptions how apps should be coded, so most simply don't bother. Sheep, that's what I call them... ;-)

      I guess the apathy towards OpenStep also stems from the fact that most people have never seen NeXTStep development in action - it left most witnesses drooling for more - and/or because they're too conventionally-minded to try anything outside their mainstream C++/Java box. To paraphrase a famous quote, "nobody was ever fired for choosing C++", right? And who's ever heard of Objective C - apart from geeks, that is?.

      If you're particularly uncharitable you could argue that the selection process which gave us Linux itself followed a similar pattern. There were technologically more advanced and initially cleaner OS projects out there at the time, but somehow the crowd choose a less-than-cutting-edge project they could at least *understand*.

      I used NeXTStep for years, and I'm still doing my software development in ObjC - luckily I work in a niche where this is possible. If all others want to make their life difficult - well, that's their choice... ;-)

      Just my two euro cents

      A.W.

    2. Re:OpenStep vs. KDE and Gnome by Brandybuck · · Score: 3, Insightful

      You are making gross mischaracterizations about KDE. KDE was started to create a destkop, not an API. The API was merely a pleasant side effect. We're not all a bunch of ex-MFC programmers. Some of us have NEVER written native Windows software.

      The apathy towards OpenStep stems from two facts. First, until recently there was no Free OpenStep desktop. There was a Free OpenStep API, but not a desktop. And that API wasn't complete at the time Qt/KDE and GTK+/GNOME became popular. The second reason is Objective C. Despite the good things about the language, you must admit if you have any honesty that it is not a common language. Until the release of OSX is was almost a dead language. People starting with a new API prefer to use a language they know. The most common systems languages are still C and C++.

      Qt/KDE is not "crippleware". That's below-the-belt FUD that cheapens your whole argument. Even if you have a small enough mind to truly believe that, stating will only hurt your "cause".

      --
      Don't blame me, I didn't vote for either of them!
    3. Re:OpenStep vs. KDE and Gnome by muecksteiner · · Score: 3, Interesting

      KDE was started to create a destkop, not an API. The API was merely a pleasant side effect.

      Given that my original claim was that the basic structure of KDE is not nearly as well thought out as it should be I can only say - "and your point is?"

      With a well thought out comprehensive application development toolkit like OS on the one side, and something which started out as one of these retarded "X desktop projects" ("one more kewl way of drawing Xterms" - granted, it's evolved beyond recognition into something genuinely useable now, but still >;-) and added most of the useful stuff as an afterthought, where do you think my sympathies lie?

      I am actually amazed how much the KDE team has achieved, given that the entire software structure is suboptimal compared to e.g. (but probably not only) OpenStep.

      The galling thought which the parent poster wanted to bring across was that if all that precious effort put into KDE had been invested into something with a more solid foundation - like for instance OpenStep - we could be much, much further on now than we currently are. People would in all probability be flocking to Linux due to its RAD prototyping capabilites, like they did with NeXTStep - and as a consequence there would not be such a lack of sophisticated GUI applications for the platform.

      The apathy towards OpenStep stems from two facts. First, until recently there was no Free OpenStep desktop.

      Yes, I agree, that was the thing which broke the back of any widespread OStep adoption. You could download an - arguably buggy and unfinished, but basically USEABLE - version of KDE when the GNUStep guys were still tinkering with the nth unuseable prerelease of their perfect uberdesktop. They did their work well (in the sense of being thorough), and the last sentence was not meant to deride them and their effort. Given the complexity of the project they have fared very well, but they are a bit late to the party now...

      Qt/KDE is not "crippleware". That's below-the-belt FUD that cheapens your whole argument.

      You are right - that was a rather over-the-top comment; apologies to the KDEers out there.

      And I have to add that even if one were in a mood to flame KDE the nomenclature I used would not be entirely correct anyway; KDE is certainly not crippleware as such (this would imply broken functionality, which is generally not the case nowadays), but rather something I would call "conceptual crippleware" - a fundamentally limited design which is being meticulously implemented by a very dedicated team... >;-)

      0.2E-32 EUR

      A.W.

  14. Re:Sounds great!! by Anonymous Coward · · Score: 2, Informative

    GNUStep's version of the Foundation Kit (basic non-GUI classes) works great on Windows. I've used it to port MacOS X code with much success.

    GNUStep's version of the Application Kit (GUI classes) is still pretty much unusable on Windows. Even if it were usuable, it's insistence on being a holistic "environment" with various services running, rather than just an API, is annoying.

    No, it's not language agnostic. You'll need to use objective-c, or some other langauge like python that can bridge to objective-c easily.

    -Helpful AC

  15. Screenshots are dated by idiotnot · · Score: 2, Interesting

    I will admit that very recently, some of the GNUStep stuff was stuff that only a mother could love.

    However, in the past few months, the interface has come a long way, and things look much better now. No, it doesn't have the eye-candy of Gnome, KDE, or OSX, but it's not really ugly anymore.

    FWIW, the real thing, NeXTStep looks very nice on my low-res monochrome NeXT monitor, in much the same way old MacOS looks okay on an old Mac.

    WindowMaker, the WM most people use for GNUStep is kind of in need of help, too. There have been a couple of GNUStep/Cocoa WM projects, but nothing's ever really gotten off the ground.

  16. Informative background by Pan+T.+Hose · · Score: 4, Informative

    I've been around computers a long time and i've never heard of it. What major application can anyone mention that has been developed on it? A 10th anniversary of something that barely anyone has ever used (in the big scheme of things) is really not any great thing to celebrate... I like the idea of it, but i'm not sure it's as wonderful of a hit as this news article is trying to make it seem.... Or am i off the mark here?

    Apparently.

    In the future, when you so desperately want to learn about something, you can use Wikipædia, a free on-line encyclopædia:

    OpenStep is an open object-oriented API specification for an object-oriented operating system that uses any modern operating system as its core, principly developed by NeXT. It is important to recognize that while OpenStep is an API specification, OPENSTEP (all capitalized) is a specific implementation of this OpenStep developed by NeXT. While originally built on a Mach-based Unix (such as the core of NeXTSTEP), versions of OPENSTEP were available for Solaris and Windows NT as well. Furthermore the OPENSTEP libraries (the libraries that shipped with the OPENSTEP operating system) are in fact a superset of the original OpenStep specification. The OpenStep API was created as the result of a 1993 collaboration between NeXT Computer and Sun Microsystems, allowing this cut-down version of NeXT's NeXTSTEP operating system object layers to be run on Sun's Solaris operating system (more specifically, Solaris on SPARC-based hardware). Most of the OpenStep effort was to strip away those portions of NeXTSTEP that depended on Mach or NeXT-specific hardware being present. This resulted in a smaller system that consisted primarily of Display PostScript, the Objective-C runtime and compilers, and the majority of the NeXTSTEP Objective-C libraries. Not included was the basic operating system, or the display system. The first draft of the API was published by NeXT in summer 1994. Later that year they released an OpenStep compliant version of their flagship operating system NeXTSTEP running on several of their supported platforms and rebranded it OPENSTEP. OPENSTEP remained NeXT's primary operating system product until they were purchased by Apple Computer in 1997. OPENSTEP was then combined with technologies from the existing Mac OS to produce Mac OS X. Sun never seemed terribly interested in the product, likely a result of the NIH syndrome. In fact it's somewhat unclear why they were ever interested, although it appears it was an attempt to "get in" on the object-oriented operating system market before Microsoft released its plans for the object-oriented Cairo OS (which never happened). Nevertheless they started their port to Solaris some time in 1994, and released it in 1996. When Sun started work on Java just after this point, Solaris OpenStep was never seen again.

    NeXTSTEP is the original object-oriented, multitasking operating system that NeXT Computer, Inc. developed to run on its proprietary NeXT computers (informally known as "black boxes"). NeXTSTEP 1.0 was released on 18 September 1989 after several previews starting in 1986, and the last release 3.3 in early 1995, by which time it ran not only on Motorola 68000 series processors (specifically the original black boxes), but also generic IBM compatible x86/Intel, Sun SPARC, and HP PA-RISC). About the time of the 3.2 release NeXT teamed up with Sun Microsystems to develop OpenStep, a cross-platform standard and implementation (for Sun Solaris, Microsoft Windows, and NeXT's version of the Mach kernel) based on NEXTSTEP 3.2. The format of the name had many camel case variants, initially being NextStep, then NeXTstep, then NeXTSTEP, and became NEXTSTEP (all

    --
    Sincerely,
    Pan Tarhei Hosé, PhD.
    "Homo sum et cogito ergo odi profanum vulgus et libido."
  17. annoyed by phoxix · · Score: 3, Insightful

    why does GNUstep need to have a top devel dir in my home directory ? Why couldn't it be a freaking dot-dir like every other program ?

    it seems a bit arrogant to me that something needs its own directory in the root of my home directory.

    I don't even use GNUstep, but its always there. It keeps coming back too, after I remove it.

    Sunny Dubey

    1. Re:annoyed by drinkypoo · · Score: 2, Insightful

      As long as Unix lacks a flag or ACL to hide files, the dot-convention is absolutely necessary. It is quite simply the way one hides files on Unix systems and it would be better to do so. If you're so worried about the user's experience, leave it to the user whether they need to see those directories or not.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
  18. Re:Qt acheived this already by OmniVector · · Score: 5, Insightful

    any program worth his shit should have no trouble picking up objective-c (a far simpler and more powerful language than c++). the language barrier really isn't an issue. it's more an issue of mindshare. there are a lot of things that are better in the computing world by design but get largely ignored due to lack of marketing.

    --
    - tristan
  19. 80% of all software is custom built by KamuSan · · Score: 3, Insightful

    OpenStep was really popular with several large banks for their internal applications.

    Good question, but the fact that you don't see a lot of programs made with a particular framework doesn't mean it's not widely used. 80% of all software (just a guess, maybe it's even more) that is written is custom built software for a specific customer or purpose.

  20. Re:Qt acheived this already by akeep · · Score: 2, Informative

    Pay attention junior. When OpenStep was released in it's first PRODUCTION version, having evolved from several years of NeXTStep development, Qt was just a gleam in the eye of Trolltech, who was just incorporating with a vision of building something like this.

  21. Is Windowmaker dead? (No, I'm not a troll.) by Glytch · · Score: 2, Interesting

    The website hasn't been updated since February, I've gotten no CVS updates since July, there's been no official releases since 0.80.2, there's no working mailing list archives on the site, and my emails go unanswered.

    I'm seriously interested in knowing. I'm a big Windowmaker fan, but I'm worried about its' apparent lack of development. Does anyone, anyone at all, know what the heck is going on?

  22. No gnuSTEP link in the writeup? by RdsArts · · Score: 3, Funny

    Why isn't there a link to the GNUstep website in the writeup? You'd think they could link to the GNUstep website in a story that talks about GNUstep. What's with that?

    Seriously, next time there's a story that has GNUstep in the writeup, they should probably link the text "GNUstep" to the GNUstep website, which is (of course) www.GNUstep.org.

  23. Re:There was never anything so consistent, stable. by jkujawa · · Score: 2, Interesting

    Port of webster.app:

    http://www.omnigroup.com/applications/omnidictiona ry/

  24. Re:I don't understand... by Seanasy · · Score: 2, Insightful
    If this is the case, then why aren't more commercial OSX applications appearing on the free UNIXen with GNUStep libraries?

    Unfortunately, GNUStep is still a bit immature despite being around for many years. The reason there aren't commercial apps isn't because OpenStep isn't great/easy-to-use. It's more likely because the free OpenStep-like environment isn't stable/mature. QT and GTK are stable and mature but you don't see a plethora of non-niche commercial apps for those either.

    If it is so easy to port, then why don't I see Photoshop for Red Hat Linux? This is a big market.

    Photoshop, I believe, is still mostly Carbon, not Cocoa. And, Photoshop on Linux is not a big market. If it were, there would be a QT or GTK Photoshop.

    Anything serious use of Objective-C appears to be confined to the Mac platform.

    OpenStep has been popular in niche areas like banking and scientific apps. Swarm is developed mainly in cross-platform Obj-C. GNU gcc is still relatively behind in Obj-C support but I think Apple is helping to change that.

  25. In 1986 NeXT ran fast on a 25mhz processor by walterbyrd · · Score: 2, Interesting

    And without a lot of RAM.

    After nearly 20 years of "progress" we need at least a 400mhz processor, with 256mb of RAM to equal it.

    Why?

  26. Ugly menus. by argent · · Score: 2, Interesting

    The big problem with the classic NeXT look is the menus. Whether they're in the corner in classic NeXTstep, or hovering next to the active window in GNUstep, they're just plain inconvenient and obtrusive.

    Windows-style title bars work better. Apple's "all menus at the top of the screen" are OK, if you have good and consistent context menus (unfortunately Apple doesn't). But the big grey box is obtrusive and needs to change. It shouldn't be too hard... they could be made as configurable as you want without changing the API... but they've been enough to make me shy away from GNUstep apps.

    The best alternative, I think, might be to attach them to the title bar of the active window, but in a horizontal menu-bar layout.

    1. Re:Ugly menus. by rthille · · Score: 2, Informative

      Well, if you left the menu in the upper left corner of the screen, it was sort of a problem. But if you moved it to the bottom left of the screen, with just the application's name showing and used the left mouse button to bring up the menu wherever your mouse happened to be on the screen(s), it was way way way more convenient then either OS-X or Windows.
      Also, the ability to tear off a sub-menu (say the font menu) and leave it (like a readable tool bar) hovering next to where you were working was an excellent feature.
      And don't get me started on the fact that scroll bars should be on the left sice of windows since the right side of a large window is the side more likely to be offscreen!

      --
      Awesome furniture, accessories and cabinetry in Santa Rosa, CA: http://humanity-home.com/
  27. One reason why... by argent · · Score: 2, Interesting

    After nearly 20 years of "progress" we need at least a 400mhz processor, with 256mb of RAM to equal it. Why?

    High quality rendering and automatic double-buffering. Every window requires megabytes of backing store, and antialiasing slows down the rendering.

    1. Re:One reason why... by mpaque · · Score: 2, Interesting

      The original NeXT Cube, and the various NeXTStation products all did double-buffering of windows by default. Now the Cube and monochrome NeXTStation used only 2 bits per pixel, which helped, but consider the NeXTStation Color:

      16 bit per pixel color with alpha channel
      1120 x 832 pixel display
      25 MHz 68040 processor
      16 Mbytes of memory

      Double-buffered windows, compositing in the Display PostScript drawing engine, color correction, and a clever dithering scheme to improve color quality. It's still pretty snappy by today's standards, especially when porked out with a huge 64 Mbytes of memory. Woo hoo!

  28. A couple more links by tarzeau · · Score: 3, Informative

    Read the OpenStep specification. Try a GNUstep Live CD.

    --
    Windoze not found: (C)heer, (P)arty or (D)ance
  29. Win32 Ports Please! by JPyObjC+Dude · · Score: 2, Interesting

    Although I use Mac at home, I work for a bunch of microsofties. There is so little out there on runing OpenStep Obj-C code on Win32. I'd love to see these frameworks and particuarily ObjC get more usage.

    I've been avoiding any c'ish programming on win32 since I generally don't like C++ and hate using M$ frameworks. Anybody know of and REAL projects to bring ObjC to win32?

    JsD

    [Use Firefox or Die]

  30. Try GNUStep Live CD Re: Next by jmcgarey · · Score: 2, Informative

    One way to check GNUStep out is by downloading and booting the GNUStep Live CD
    Did no one think of this yet?

  31. GNUstep Live CD by Pan+T.+Hose · · Score: 2, Informative

    It's a pity that, at the peak of the Linux desktop hype in the late 1990s, when evangelists predicted the near death of Microsoft, KDE and Gnome were rushed out of the door, and GNUstep development remained obscure.

    Very true...

    It is interesting to note that the new GNUstep Live CD was announced on GNUstep Core News in June:

    What is it?
    GNUstep Live CD contains a lot of software for GNUstep, a free implementation of the OPENSTEP framework (which was also the base as Cocoa in Mac OS X). Display Postscript is one of its powerful features. It includes an excellent application called Gorm for RAD (Apple Software Design Guidelines). More about the Objective-C Language.

    Features
    Software using GNUstep (Addresses, Agenda, AClock, Affiche, CamelBones, Camera, Charmap, Cenon, Connect, Cynthiune, DisplayCalibrator, EasyDiff, EdenMath, Gridlock, GMines, Gorm, Gomoku, GNUMail, GNUstep-icons, GNUWash, GWorkspace, HelpViewer, ImageViewer, LuserNET, MPDCon, ProjectCenter, PRICE, Poe, Preferences, PlopFolio, Preview, Renaissance, Stepulator, StepTalk, StepBill, Terminal, TalkSoup, TextEdit, ViewPDF, VolumeControl, Waiho, WildMenus, Zipper)

    In development and not yet on the CD (3DKit, AgentFarms, Burn / CDPlayer, Duncan, Emacs on GNUstep, Encod, Expense, GTAMS, GRASStep GIS, GShisen, GNUstepWeb (WebObjects 4.x), GNUstepWrapper, ILogin, Installer, InnerSpace, LaTeX Service, Localize, MusicKit, MyWiki / MyLibrary, ModPlugPlay, Paje, Pixen, Popup, Position, Rhydot / Skfxdemo, RSS Reader, WebKit / SimpleWWW, Tryst)

    The currently used window manager is Window Maker.
    Rescue System (lde, gpart, parted, grub, raidtools, portmap, nfs-common, QTParted)
    3d Software Blender, Wings3d, Games NetHack, Jump n Bump and SuperTux, LaTeX, TeXmacs, Emacs, GIMP2
    Tools (screen, irssi-text, ngrep, tcpdump, openssl, ssh, imagemagick, netpbm, nail, iptraf, mc, gnupg, ibackup, cowsay, hdparm, feh, tetradraw)
    The Debian GNU/Hurd K6 mini.iso for easy installation in /cdrom/hurd
    C Compiler and development environment
    Webbrowsers (dillo, links2), TV Software (xawtv, alevt)
    Some music (www.chiptune.com, www.maktone.tk)

    This is a very interesting project, though of course not as popular as Knoppix.

    It was the first time that distributed free software development defected from its proven practice of implementing standardized, proven APIs and technology (like POSIX) and created major APIs of its own. [...] Imagine the massive development efforts on KDE and Gnome, including the massive rewrites of their codebases, would instead had gone into GNUstep, so that the GNU/Linux and *BSD desktop would be OS X/Cocao source compatibile today [and companies developing for OS X port their software to Linux basically with one more compiler run]...

    Imagine the efforts on Knoppix would instead had gone into GNUstep Live CD... Imagine the development efforts on Linux would instead had gone into The Hurd... Just imagine... The entire computing world as we know it would be completely different. But what do we expect? People have no idea that GNU even exists, let alone the kernel development! Just few days ago Slashdot posted a story about the Seattle Times interview with Linus Torvalds with this opening paragraph: "Linus Torvalds [pronounced LEE-nus] started a revolution of sorts in the computer industry when he created the Linux operating system and decided to share it with fellow programmer

    --
    Sincerely,
    Pan Tarhei Hosé, PhD.
    "Homo sum et cogito ergo odi profanum vulgus et libido."