Forgot your password?
GNU is Not Unix Programming Technology

10 Years of OpenStep 338

Posted by CmdrTaco
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."
This discussion has been archived. No new comments can be posted.

10 Years of OpenStep

Comments Filter:
  • Next (Score:4, Insightful)

    by 2.7182 (819680) on Tuesday October 19, 2004 @09:44AM (#10564385)
    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.
    • Re:Next (Score:4, Interesting)

      by Daengbo (523424) <> on Tuesday October 19, 2004 @11:01AM (#10565186) Homepage Journal
      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...
      • Re:Next (Score:4, Informative)

        by roard (661272) on Tuesday October 19, 2004 @11:48AM (#10565870) Homepage
        You could want to install/use Backbone [] or Garma [], which are GNUstep-based Desktops...
      • by Florian (2471)

        Well, then... GnuStep seems to recommend WM as the choice for Gnustep applications, but isn't itself Gnustep in any way.

        The answer is simple: Window Maker is a mockup of the original NextStep desktop look'n'feel, but doesn't use any OpenStep/Gnustep/Cococa libraries or programming paradigms - just like fvwm95 superficially looks like Win95/98, but implements nothing of the underlying Windows API/framework, an infinitely more complex effort pursued, for example, by WINE. So GNUstep is not a window manager

        • Re:Next (Score:3, Insightful)

          by Daengbo (523424)
          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
    • What was even more amazing was using Smalltalk a decade before NeXT. NeXT was modeled on Smalltalk, but relative to Smalltalk, even NeXT seemed cumbersome.

      And the guys who brought you Smalltalk are bringing you more neat stuff; see the story on OpenCroquet earlier.
      • Re:Next (Score:3, Informative)

        by Anonymous Coward
        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 l
  • by rwven (663186)
    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?
    • by CoolMoDee (683437) on Tuesday October 19, 2004 @09:46AM (#10564403) Homepage Journal
      The first web browser was developed with NeXT and Openstep...
    • by Nexum (516661) on Tuesday October 19, 2004 @09:47AM (#10564420)
      What about the first web browser for a start?

      The first wholescale industrial use of OOP practices?

      etc. Do some googling.
    • Most OS X apps...
    • by AKAImBatman (238306) * <> on Tuesday October 19, 2004 @09:49AM (#10564433) Homepage Journal
      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 []
    • by WillAdams (45638) on Tuesday October 19, 2004 @09:56AM (#10564498) Homepage 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 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

      Other more recent developments:

      - Cenon -
      - GNUmail
      - ProjectCenter
      - GORM


    • by DrXym (126579)
      Most OS X apps use Cocoa & Objective-C for their front-end. Whether this is through choice, or because XCode compells you to do this is a matter for debate.

      Personally I think the tools that ship in XCode / Project Builder for constructing UIs are (ironically) the most user-unfriendly and unintuitive I've ever encountered. Part of the blame falls squarely on the interactive help which is awful compared to the MSDN for example.

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

      • User un-friendly? Interface builder? So placing a button on a window and drawing a line from the button to the class is un-friendly to you? Do you have no arms?
        • by DrXym (126579) on Tuesday October 19, 2004 @10:40AM (#10564950)
          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.

          • Maybe I just had a different experience learning it... it made more sense to me than .NET's GUI (I still don't like the idea of GUI and code living together, they should be separate.)

            I admit that Objective-C can be slightly painful especially when you get stuff that looks like

            [[[[object message] message] message] message]

            it rubbed me the wrong way at first but now I can honestly say I'd rather code in XCode than Visual Studio.
            • Oh I got used to it alright, it was just that first week. I experienced a sense of elation when I finally got something going in it. It's not so much a learning curve as a brick wall. I don't think there is anything intractably bad about Cocoa+XCode, it's just that the tools are not as good as they could be.

              It's hard to say what environment I'm most comfortable with. It's probably VC98 because it's so uncluttered yet practical. I'm also partial to Eclipse, but the visual editing component (VE) has some wa

          • 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).
      • by bnenning (58349) on Tuesday October 19, 2004 @10:51AM (#10565061)
        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.
    • by Pan T. Hose (707794) on Tuesday October 19, 2004 @10:25AM (#10564784) Homepage Journal

      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?


      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

      • 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?

    • by KamuSan (680564) on Tuesday October 19, 2004 @10:52AM (#10565078) Journal
      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.
    • 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.
  • by mirko (198274) on Tuesday October 19, 2004 @09:47AM (#10564418) Journal
    Kudos to Jean-Marie Hullot [], who contributed to this by designing "Interface Builder []" !
  • What's NeXT? (Score:4, Interesting)

    by mrchapp (823433) < minus cat> on Tuesday October 19, 2004 @09:48AM (#10564428)
    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.
    • 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 :)
    • Let's look at history:
      • NeXT kernel--from CMU
      • ObjC--from StepStone (indirectly from PARC)
      • Postscript--from Adobe (indirectly from PARC)
      • WIMP--from Alan Kay and PARC
      • library architecture--from Smalltalk 80

      Jobs did a great job selecting, integrating, and marketing. But what did he or his companies actually invent?
  • by minus_273 (174041) <> on Tuesday October 19, 2004 @09:49AM (#10564436) Journal
    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
    • If this is the case, then why aren't more commercial OSX applications appearing on the free UNIXen with GNUStep libraries?

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

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

      • by Seanasy (21730)
        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

    • Maybe it's because Linux developers have other choices: PyGnome, wxPython, Java+SWT, Eclipse, ...
    • On a side note, it is really quite sad the linux developers are not using/updating openstep.

      They are. It's called GNUStep []. They could use more help, though.

  • by WillAdams (45638) on Tuesday October 19, 2004 @09:51AM (#10564459) Homepage
    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 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 in

    I've got a little bit more on my site, look for my nascent gnustep pages, or the NeXT brochure in my portfolio

    Or of course, visit or for some good programming info

  • by Qwavel (733416)
    Except for that big about the hurdles getting it to work on Windows. You will forgive me for suggesting that how well it works on Windows, where 95% of users are, is really important.

    Also, since you are talking about GNUstep as one of the creators of this, I assume this is open source?

    And finally, is is language agnostic? I personally would want to use C++.

    Yes, I did not RTFA. Sorry.
    • Re:Sounds great!! (Score:2, Informative)

      by Anonymous Coward
      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
    • Also, since you are talking about GNUstep as one of the creators of this, I assume this is open source?

      GNUstep is LGPL.

      And finally, is is language agnostic?

      Sort of. There are bindings available for many languages such as Perl, Python, and Ruby. C++ won't work because it doesn't have the necessary dynamic and introspective capabilities.
  • by roard (661272) on Tuesday October 19, 2004 @09:53AM (#10564476) Homepage
    Some GNUstep links:

    Other links, Objective-C [] and Apple Cocoa []
  • portability (Score:3, Interesting)

    by _|()|\| (159991) on Tuesday October 19, 2004 @09:54AM (#10564479)
    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.

    • > lack of autoconf support

      And this is a negative, how? Autoconf/automake create a sucking sound that threatens the doppler shifting of galaxies. Anything that helps you escape from their grip is a good thing.
    • Re:portability (Score:3, Interesting)

      by Abcd1234 (188840)
      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/ 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
      • Re:portability (Score:3, Informative)

        by roard (661272)

        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 b

  • ...but isn't that what Java was supposed to do?

    (Disclaimer: The most programming I have ever done was 10 line batch file. That gave you a few options.)
    • But, this is a completely different set of people behind this. Plus, it isn't nearly as easy to make it work on Linux or windows. And the product is not used by any major fortune 500 company in any missions critical sense that I know of.
  • by Baldrson (78598) on Tuesday October 19, 2004 @10:06AM (#10564583) Homepage Journal
    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.
  • Objective C (Score:4, Interesting)

    by RAMMS+EIN (578166) on Tuesday October 19, 2004 @10:08AM (#10564600) Homepage Journal
    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).
    • Yep, it's hard to appreciate how the program seems to magically fall into place once you've laid things out with the interface builder until you've tried it. Both Cocoa and GNUstep have Java bindings these days, so fear of ObjC is no longer a reason to avoid them.
  • by Florian (2471) <> on Tuesday October 19, 2004 @10:09AM (#10564605) Homepage
    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, 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]...

    • by muecksteiner (102093) on Tuesday October 19, 2004 @10:38AM (#10564927)
      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

      • The funny thing is that people who actually experienced the generation of GUIs before NeXT might say the same thing about NeXT. I mean, you have to deal with C, memory allocation, and pointers? You can't inspect and change the code of a running program? Your GUI runs in a separate process and needs to be programmed in a different language? You can have type errors in your running system without anything flagging an error? What kind of backwards system is that?

        I agree to the degree that C++ has always be
      • by Brandybuck (704397) on Tuesday October 19, 2004 @02:40PM (#10567764) Homepage Journal
        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".
        • 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 someth
    • It's easy to say, "what if". What if rather than the hopelessly inelegant Objective-C/C/Java combo MacOS X uses, it had been written entirely in Lisp as the old Symbolics machines were? (reason lisp failed: performance and cost). What if the moon was made of cheese?
    • GNUstep Live CD (Score:3, Informative)

      by Pan T. Hose (707794)

      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

  • so where is SUN?

  • annoyed (Score:4, Insightful)

    by phoxix (161744) on Tuesday October 19, 2004 @10:41AM (#10564966)
    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
  • by RdsArts (667685) on Tuesday October 19, 2004 @11:22AM (#10565512) Homepage Journal
    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.
  • I [] love [] my [] NeXT []. And praise Steve and the NeXT crew for taking over Apple and giving me the latest NEXTSTEP/OpenStep (Mac OS X) on blazing hardware...namely, my dual G5 2.5 [].


  • by walterbyrd (182728) on Tuesday October 19, 2004 @11:46AM (#10565844)
    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.

    • yeah, my 1990 NeXTStation ran with 8MB of RAM, and the OS plus Mathematica & the usual NeXT apps fit on a 200MB disk. The UI had very crisp response, not the mushie feel of X11 derived stuff
    • One reason why... (Score:3, Interesting)

      by argent (18001)
      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.
      • Re:One reason why... (Score:3, Interesting)

        by mpaque (655244)
        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 snap
  • by Jonathan (5011)
    A lot of the comments here seem to suggest that many people find the traditional NeXTStep (GNUStep) look ugly. But I can't believe that *all* people believe that -- look at the popularity of windowmanagers like WindowMaker and AfterStep. Plus practically every theming utility for every platform includes a NeXTStep theme. It might not be as flashy as Aqua, but I rather like the traditional NeXTStep look.
    • Add to this the fact that there is a theme engine called Camaelon which can change the default look dramatically.

    • Ugly menus. (Score:3, Interesting)

      by argent (18001)
      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 c
      • Re:Ugly menus. (Score:3, Informative)

        by rthille (8526)
        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 excelle
  • A couple more links (Score:3, Informative)

    by tarzeau (322206) <> on Tuesday October 19, 2004 @12:50PM (#10566656) Homepage
    Read the OpenStep specification []. Try a GNUstep Live CD [].

Byte your tongue.