Close. OS X doesn't have three user interfaces, but three programmign interfaces (APIs). There is BSD, Carbon, and Cocoa. BSD is what it sounds like; Carbon is a port of a cleaned up version of the current Mac OS toolbox (the API Mac OS uses); and Cocoa, is simply the next version of the OpenStep API, which is object oriented, and quite sophisticated. Carbon allows pretty easy porting of current Mac OS applications to Mac OS X. The Carbon API also exists on the traditional Mac OS, so you can produce a binary for Mac OS 8 - 9 and Mac OS X with a compiler flag, and making changes to have it run on System 7 shouldn't be too hard either. It's for these reasons many Mac OS X developers coming from previous Mac development will use Carbon. You're getting Carbon confused with Classic. Classic is an appliation which runs on Mac OS X which runs a copy of Mac OS 9 in emulation for the purpose of running non-ported prorgams. Carbon isn't as a nice of an API as Cocoa is, but it does take advantage of all of the advantages Mac OS X has over it's predecessors. When MS says they'll have Office 2001 on OS X, they're most likely to use Carbon, for the above reasons. What does this mean in the context of getting MS apps on Unix in general? Not much. Carbon and Cocoa are portable APIs, and do not require Unix at all. ARDI is trying to implement Carbon on top of Linux/X and Windows toward the end of portable programs. Apple themselves has an older version of the Cocoa API available on Windows, as a part of WebObjects development. My point? Mac OS X doesn't use X, but it's own Display PDF window server. But that doesn't matter at all. It all depends on whether or not the API is implemented on the target platform. If an app was written in Cocoa for Mac OS X, there's a good chance, sometime in the future, they could very easily be ported to Linux and other Unices via GNUstep, an implementation of the OpenStep/YellowBox/Cocoa API, which is coming along slowly, but very surely. Porting an app from Mac OS X/Cocoa to Linux/GNUstep shouldn't be that hard, as it's a high-level API. The companies writting these apps simply need an ecomical incentive to do so.
Uh... No. QuickTime can be seperated from it's "integrated player," as you put it. I've seen it as a part of more elaborate applications on Mac OS and Windows, and know on the Mac OS, there are players which people have written in RealBasic (more or less like Visual Basic), which basically hook into the QT libs, and there you go, a QuickTime player, as good as the "official" QT4 player, but with a standard interface.
It'd be great to be able to actually watch high-quality QuickTime clips without either proprietary hardware / software combinations...
I suppose this is referring to running QuickTime on a Mac, perhaps a bitter statement in regards to the fact that there is not a QuickTime player for Linux. QuickTime 4 does run under Mac OS and Windows. Aside from that, QuickTime is far more open than RealPlayer. I've seen many programs, both on the Mac OS and Windows which utilize the QuickTime libraries - movie players and non-linear video editing applications, mostly. The QuickTime libraries can be called and used from other programs, and not just confined to the QT4 player.
Because of this, at least on the Mac, there are QuickTime players, using the QT4 libs, but not the QT4 interface, for people who don't like the brushed metal UI/look.
It is a bummer (for me as well) that there is no QuickTime player/libraries for Linux, but Apple doesn't owe you a thing. Next time, think before you tag something biased and uninformed onto the post.
Two languages which are great for kids are Python and Smalltalk. They are both languages with the intent of making computer programming accessable to anyone who might want to program. They're both Object Oriented (Python still allows procedural programming though). Why does that matter? Studies have shown that teaching kids OOPL as a first language makes it easier to switch to or decide to use a procedural language, while those first taught a procedural language like Pascal or C, have a much harder time picking up on the ideas of Object technology.
I personally would stray from teaching them VB, Delphi, or C++. VB and Delphi can produce visual results fast, but teaching Python or Smalltalk could help them get a real handle on what's going on. C++ is simply too complex that it'll just muddle them up, and probably make them bitter little programmers.
Not to start a language/paradigm war, but do your kids a favor, and don't default to teaching them a structured or procedural language like BASIC or Pascal, two typical teaching languages. Like many others, I learned BASIC first. But the fact of the matter is, BASIC was designed back in the day when as a beginner's language, when what you moved on to were Fortran and COBOL. While Fortran and COBOL are still in use today, they're nowhere near being truely modern languages. Pascal would lead to C. I reccommend Python and Smalltalk because they're both comprehensible by kids, but usable in real applications by adults (or kids too, for that matter!).
You can find Python here, and Squeak Smalltalk here. Others have mentioned Alice -- Squeak Smalltalk includes a 3D system like Alice as well, where you can program and intereact with 3D objects. It's a lot of fun!:)
Squeak Smalltalk based OSes
on
AtheOS
·
· Score: 1
There are some attempts to build an OS out of Squeak, with or without Linux. One of them is SqueakOS which uses SVGAlib. For a project this summer, I'm planning on doing something similat, but which uses the Linux framebuffer, largely for cross-platform compatibility (SVGAlib, to my understanding, only works with x86 and ARM architechures). Hopefully something will come out of this idea! Stay tuned!
I used this a while back to generate pages from a template for a project where I work. You'll have to to a little work (write some Python code saying what variables to substitute with what), as well as taking a HTML page and making that into a template, but both are really easy and can integrate with the web via CGI (or Zope) really well.
From a true nerd perspective, I wouldn't say that NeXT won. From a developer perspective, somewhat, as that beautiful OpenStep/Cocoa API is still there and will form the framework for what is to come.
But from an end-user nerd perspective, NeXT didn't win in everyway. After all, it looks like Mac OS X won't have the NeXT shelf -- one of my most favorite things in NeXTSTEP and OpenStep.
I don't understand the Be-NeXT analogy. NeXT wasn't moving anywhere in the direction toward being an Internet Appliance OS. They were moving toward enterprise database connectivity, client/server apps, and away from plain old desktop stuffs. The moving away from desktop OS is the same, but it ends there.
What is the big deal with the MS PocketPC? From the hype, I'm gathering it's supposed to be some next-generation of Windows CE devices -- but the devices seem to be the same hardware as the old WinCE devices, and the software... seems to be still WinCE. Is it a new version of WinCE, or is it that Pocket Internet Explorer now is there (was it not before?), or is there any semblence of actual progress or change?
Although I'd like to see what becomes of this product (I can't even connect to the site!), I'd just like to inform everyone that Quake on a PDA is not only possible, but has been done.:)
The Newton has a pretty large display though, and the screen shots look very nice. Haven't got a chance to play it, but it almost makes me want to get a Newton 2100 to replace my lost Newton 100!
I sure they were manufacturing these themselves and selling them. I'd buy one.
What I'd like even more, is a StrongArm based notebook. I mean, when people get so excited about the Transmeta chip, not for it's code morphing, but for it's ultra-low power features. I got excited about it too -- I'd love to have a laptop which ran for 8 hours+. But why doesn't someone make a StrongArm based notebook? I mean, it consumes even less power -- and it could probably go for even longer than 8 hours.
You could run Linux on it. X, GNOME/KDE, the whole bag -- all in a package which is cheaper and more energy effecient than a conventional x86 laptop, and even a Transmeta-based notebook.
Even better, Intel just demoed (I think) 1 GHz StrongArm chips. How incredible would one of those in a notebook be? Wouldn't be as fast as a 1GHz Athlon/PIII, but it'd sure be fast, and with phenomonal battery life.
It's not a bug in the sense that it's a small problem out of which they need to work out the kinks. The reason Windows 95/98 brings the system down to an unusable pace is that it uses co-operative multitasking, and not true preemptive multitasking.
MS and Windows 9x proponents usually spout off that Windows 9x has true preemtive multitasking, but the classic test for preemtive multitasking is to watch the performance of the machine while formatting a floppy, or copying a lot of files to one. If the system slows down to a grind, then the OS is using primitive, co-operative multitasking, and if the system performs more or less like usual, then it has preemtive multitasking.
Contrary to propaganda and popular belief, Windows 9x does not. I don't know about NT -- it's supposed to, but I've never performed the classic test.:)
However, Cocoa works with both Java and ObjC, as well as C, C++ and ObjC++.
I don't believe Cocoa is accessable from any lanauges other than Objective-C or Java now. I know Apple's been working on Objective-C++, allowing for C++ and Objective-C code to be mixed, but I haven't read anything about this being completed, or the Cocoa APIs being accessible from C++ or C. I'd love to a see a link to prove me wrong, though.:)
Why woud Mac OS X bring MIDI/Audio apps to Linux? I don't mean to rain on yoru parade, but that's simply not likely. Why? For two reasons: 1. Most, nearly all, applications which will be brought from the tradiitonal Mac OS and brought to Mac OS X will be ported using Carbon, which is a library which reimplements the parts of the Mac OS Toolbox with all the kludge taken out. 2. If an App was written for OS X using Cocoa, that is, Objective-C (or Java), that still wouldn't get ported to Linux. Why? GNUstep isn't (and won't be for a while) mature enough to port apps to Linux, easily. That, and because of the semi-crappy sound support under Linux, there aren't many Audio pros using Linux for production -- giving them [Audio-app companies] little or no incentive to port the apps. oh... and another one. 3. Mac OS X doesn't use the X Window System as it's display technology. The only reason I mention this is to make sure you're not under that impression., believing that it could lead to all sorts of great apps from OS X on Linux and visa versa. Aaron
I wonder if you have shell access, or a web based interface which excutes a set of commands like configure, make, and so forth. Hmm! Interesting stuff!
Reminds me of the book _The Origins of Consciousness in the Breakdown of the Bicameral Mind_ by a psychologist by the name os Julian Joyce (I believe). Absolutely fascinating information, simply fascinating. If you are interested in consciousness science, and are looking to read the book reviewed, try your hand at _The Origins of Consciousness..._ very good read!
That's the thing- Darwin isn't NeXTSTEP. It was derived from the underlying BSD of NeXTSTEP and OpenStep/Mach, but that doesn't make it NeXTSTEP. Signifigant changes have taken place, including a new version of the Mach kernel between OpenStep 4.2 and what is now called Mac OS X. I personally haven't looked at the Darwin source yet. Apple might've maintianed the i386 port, but there's an equal chance that they let it die in upgrading the BSD system. While it probably wouldn't be that hard to have a Darwin/Intel, it's not a trivial matter.
Darwin on Intel: not yet a reality
on
Darwin on Crusoe?
·
· Score: 1
This is pretty cool news, seeing how Darwin has not found it's way onto Intel yet (as far as I've seen). OpenStep/Mach (from which Mac OS X/Darwin derive) has gone through a lot of change, especially on the lower level (what is now Darwin) to be come what it is. This'll be interesting to see! People have X running on Darwin on their PPC systems, and have more or less, a usable system. I just cannot wait to the day when I can buy a G4 to run Mac OS X. I think it's worthy to be the heir of NeXTSTEP/OpenStep, the best OS ever produced, as far as I see.
People seem to be kind of confused about what GNUstep is and implies, I'll try to clarify:
GNUstep is: an implementation of the OpenStep API. The OpenStep API makes it quite easy to develop programs for it, as the developer doesn't have to worry about the little things, and spend their time innovating and writing great code . It's cross-platform (between Windows w/ the YellowBox, anything running GNUstep, Mac OS X/Cocoa). It's a dream to develop with, and the Objective-C language, to me, is much nicer to use than C++ (although I think there's wrappers for Java, and perhaps C/C++).
GNUstep will: Allow for easy ports to platforms running GNUstep from source written under OpenStep, Rhapsody, or Mac OS X (using Cocoa/YellowBox). This encourages cross-platform development, and hopefully will help bring many apps to Mac OS X/Cocoa, as well as Linux/FreeBSD/etc.
GNUstep is not: a window manager or a desktop environment. Desktop environments can (and quite easily) built with GNUstep. In fact, someone is working on a NeXT-like file manager right now, which is working and developed under OpenStep, and easily recompiled on a FreeBSD box using GNUstep.
For more information, see the GNUstep website or the unofficial GNUstep website, both of which have plenty of information on the OpenStep spec, and where GNUstep is going.
Slashdot Mirror
Close. OS X doesn't have three user interfaces, but three programmign interfaces (APIs). There is BSD, Carbon, and Cocoa. BSD is what it sounds like; Carbon is a port of a cleaned up version of the current Mac OS toolbox (the API Mac OS uses); and Cocoa, is simply the next version of the OpenStep API, which is object oriented, and quite sophisticated. Carbon allows pretty easy porting of current Mac OS applications to Mac OS X. The Carbon API also exists on the traditional Mac OS, so you can produce a binary for Mac OS 8 - 9 and Mac OS X with a compiler flag, and making changes to have it run on System 7 shouldn't be too hard either. It's for these reasons many Mac OS X developers coming from previous Mac development will use Carbon. You're getting Carbon confused with Classic. Classic is an appliation which runs on Mac OS X which runs a copy of Mac OS 9 in emulation for the purpose of running non-ported prorgams. Carbon isn't as a nice of an API as Cocoa is, but it does take advantage of all of the advantages Mac OS X has over it's predecessors. When MS says they'll have Office 2001 on OS X, they're most likely to use Carbon, for the above reasons. What does this mean in the context of getting MS apps on Unix in general? Not much. Carbon and Cocoa are portable APIs, and do not require Unix at all. ARDI is trying to implement Carbon on top of Linux/X and Windows toward the end of portable programs. Apple themselves has an older version of the Cocoa API available on Windows, as a part of WebObjects development. My point? Mac OS X doesn't use X, but it's own Display PDF window server. But that doesn't matter at all. It all depends on whether or not the API is implemented on the target platform. If an app was written in Cocoa for Mac OS X, there's a good chance, sometime in the future, they could very easily be ported to Linux and other Unices via GNUstep, an implementation of the OpenStep/YellowBox/Cocoa API, which is coming along slowly, but very surely. Porting an app from Mac OS X/Cocoa to Linux/GNUstep shouldn't be that hard, as it's a high-level API. The companies writting these apps simply need an ecomical incentive to do so.
Uh... No. QuickTime can be seperated from it's "integrated player," as you put it. I've seen it as a part of more elaborate applications on Mac OS and Windows, and know on the Mac OS, there are players which people have written in RealBasic (more or less like Visual Basic), which basically hook into the QT libs, and there you go, a QuickTime player, as good as the "official" QT4 player, but with a standard interface.
It'd be great to be able to actually watch high-quality QuickTime clips without either proprietary hardware / software combinations...
I suppose this is referring to running QuickTime on a Mac, perhaps a bitter statement in regards to the fact that there is not a QuickTime player for Linux. QuickTime 4 does run under Mac OS and Windows. Aside from that, QuickTime is far more open than RealPlayer. I've seen many programs, both on the Mac OS and Windows which utilize the QuickTime libraries - movie players and non-linear video editing applications, mostly. The QuickTime libraries can be called and used from other programs, and not just confined to the QT4 player.
Because of this, at least on the Mac, there are QuickTime players, using the QT4 libs, but not the QT4 interface, for people who don't like the brushed metal UI/look.
It is a bummer (for me as well) that there is no QuickTime player/libraries for Linux, but Apple doesn't owe you a thing. Next time, think before you tag something biased and uninformed onto the post.
Two languages which are great for kids are Python and Smalltalk. They are both languages with the intent of making computer programming accessable to anyone who might want to program. They're both Object Oriented (Python still allows procedural programming though). Why does that matter? Studies have shown that teaching kids OOPL as a first language makes it easier to switch to or decide to use a procedural language, while those first taught a procedural language like Pascal or C, have a much harder time picking up on the ideas of Object technology.
:)
I personally would stray from teaching them VB, Delphi, or C++. VB and Delphi can produce visual results fast, but teaching Python or Smalltalk could help them get a real handle on what's going on. C++ is simply too complex that it'll just muddle them up, and probably make them bitter little programmers.
Not to start a language/paradigm war, but do your kids a favor, and don't default to teaching them a structured or procedural language like BASIC or Pascal, two typical teaching languages. Like many others, I learned BASIC first. But the fact of the matter is, BASIC was designed back in the day when as a beginner's language, when what you moved on to were Fortran and COBOL. While Fortran and COBOL are still in use today, they're nowhere near being truely modern languages. Pascal would lead to C. I reccommend Python and Smalltalk because they're both comprehensible by kids, but usable in real applications by adults (or kids too, for that matter!).
You can find Python here, and Squeak Smalltalk here. Others have mentioned Alice -- Squeak Smalltalk includes a 3D system like Alice as well, where you can program and intereact with 3D objects. It's a lot of fun!
There are some attempts to build an OS out of Squeak, with or without Linux. One of them is SqueakOS which uses SVGAlib. For a project this summer, I'm planning on doing something similat, but which uses the Linux framebuffer, largely for cross-platform compatibility (SVGAlib, to my understanding, only works with x86 and ARM architechures). Hopefully something will come out of this idea! Stay tuned!
They certainly aren't useless! At the school I go to, we use an old 6100/60 MHz as our webcam! :) See it here.
I used this a while back to generate pages from a template for a project where I work. You'll have to to a little work (write some Python code saying what variables to substitute with what), as well as taking a HTML page and making that into a template, but both are really easy and can integrate with the web via CGI (or Zope) really well.
You can find htmlPARSER here, and Python here.
From a true nerd perspective, I wouldn't say that NeXT won. From a developer perspective, somewhat, as that beautiful OpenStep/Cocoa API is still there and will form the framework for what is to come.
But from an end-user nerd perspective, NeXT didn't win in everyway. After all, it looks like Mac OS X won't have the NeXT shelf -- one of my most favorite things in NeXTSTEP and OpenStep.
I don't understand the Be-NeXT analogy. NeXT wasn't moving anywhere in the direction toward being an Internet Appliance OS. They were moving toward enterprise database connectivity, client/server apps, and away from plain old desktop stuffs. The moving away from desktop OS is the same, but it ends there.
What is the big deal with the MS PocketPC? From the hype, I'm gathering it's supposed to be some next-generation of Windows CE devices -- but the devices seem to be the same hardware as the old WinCE devices, and the software... seems to be still WinCE. Is it a new version of WinCE, or is it that Pocket Internet Explorer now is there (was it not before?), or is there any semblence of actual progress or change?
Or just a revision of marketing?
Although I'd like to see what becomes of this product (I can't even connect to the site!), I'd just like to inform everyone that Quake on a PDA is not only possible, but has been done. :)
There's a port to the Apple Newton at the NewtonQuake homepage.
The Newton has a pretty large display though, and the screen shots look very nice. Haven't got a chance to play it, but it almost makes me want to get a Newton 2100 to replace my lost Newton 100!
I sure they were manufacturing these themselves and selling them. I'd buy one.
What I'd like even more, is a StrongArm based notebook. I mean, when people get so excited about the Transmeta chip, not for it's code morphing, but for it's ultra-low power features. I got excited about it too -- I'd love to have a laptop which ran for 8 hours+. But why doesn't someone make a StrongArm based notebook? I mean, it consumes even less power -- and it could probably go for even longer than 8 hours.
You could run Linux on it. X, GNOME/KDE, the whole bag -- all in a package which is cheaper and more energy effecient than a conventional x86 laptop, and even a Transmeta-based notebook.
Even better, Intel just demoed (I think) 1 GHz StrongArm chips. How incredible would one of those in a notebook be? Wouldn't be as fast as a 1GHz Athlon/PIII, but it'd sure be fast, and with phenomonal battery life.
Please, someone make a StrongArm based notebook!
No, Windows 98 has not resolved this problem.
:)
It's not a bug in the sense that it's a small problem out of which they need to work out the kinks. The reason Windows 95/98 brings the system down to an unusable pace is that it uses co-operative multitasking, and not true preemptive multitasking.
MS and Windows 9x proponents usually spout off that Windows 9x has true preemtive multitasking, but the classic test for preemtive multitasking is to watch the performance of the machine while formatting a floppy, or copying a lot of files to one. If the system slows down to a grind, then the OS is using primitive, co-operative multitasking, and if the system performs more or less like usual, then it has preemtive multitasking.
Contrary to propaganda and popular belief, Windows 9x does not. I don't know about NT -- it's supposed to, but I've never performed the classic test.
However, Cocoa works with both Java and ObjC, as well as C, C++ and ObjC++.
:)
I don't believe Cocoa is accessable from any lanauges other than Objective-C or Java now. I know Apple's been working on Objective-C++, allowing for C++ and Objective-C code to be mixed, but I haven't read anything about this being completed, or the Cocoa APIs being accessible from C++ or C. I'd love to a see a link to prove me wrong, though.
This looks *way* interesting! I really'd like to buy one of these, but I just bought a G4, and have a hard time rationalizing buying another computer.
:)
In any case, that could be used for many things. It's good to see people thinking out there!
Why woud Mac OS X bring MIDI/Audio apps to Linux? I don't mean to rain on yoru parade, but that's simply not likely. Why? For two reasons: 1. Most, nearly all, applications which will be brought from the tradiitonal Mac OS and brought to Mac OS X will be ported using Carbon, which is a library which reimplements the parts of the Mac OS Toolbox with all the kludge taken out. 2. If an App was written for OS X using Cocoa, that is, Objective-C (or Java), that still wouldn't get ported to Linux. Why? GNUstep isn't (and won't be for a while) mature enough to port apps to Linux, easily. That, and because of the semi-crappy sound support under Linux, there aren't many Audio pros using Linux for production -- giving them [Audio-app companies] little or no incentive to port the apps. oh... and another one. 3. Mac OS X doesn't use the X Window System as it's display technology. The only reason I mention this is to make sure you're not under that impression., believing that it could lead to all sorts of great apps from OS X on Linux and visa versa. Aaron
I wonder if you have shell access, or a web based interface which excutes a set of commands like configure, make, and so forth. Hmm! Interesting stuff!
I sent this story in days ago, but they didn't post it. Curious. This seems to happen whenever I send a story in.
Reminds me of the book _The Origins of Consciousness in the Breakdown of the Bicameral Mind_ by a psychologist by the name os Julian Joyce (I believe). Absolutely fascinating information, simply fascinating. If you are interested in consciousness science, and are looking to read the book reviewed, try your hand at _The Origins of Consciousness..._ very good read!
Well, nothing we ain't heard anymore, but I suppose it might be good info for any other "suits" stopping by slashdot...
That's the thing- Darwin isn't NeXTSTEP. It was derived from the underlying BSD of NeXTSTEP and OpenStep/Mach, but that doesn't make it NeXTSTEP. Signifigant changes have taken place, including a new version of the Mach kernel between OpenStep 4.2 and what is now called Mac OS X. I personally haven't looked at the Darwin source yet. Apple might've maintianed the i386 port, but there's an equal chance that they let it die in upgrading the BSD system. While it probably wouldn't be that hard to have a Darwin/Intel, it's not a trivial matter.
This is pretty cool news, seeing how Darwin has not found it's way onto Intel yet (as far as I've seen). OpenStep/Mach (from which Mac OS X/Darwin derive) has gone through a lot of change, especially on the lower level (what is now Darwin) to be come what it is. This'll be interesting to see! People have X running on Darwin on their PPC systems, and have more or less, a usable system. I just cannot wait to the day when I can buy a G4 to run Mac OS X. I think it's worthy to be the heir of NeXTSTEP/OpenStep, the best OS ever produced, as far as I see.
People seem to be kind of confused about what GNUstep is and implies, I'll try to clarify:
GNUstep is: an implementation of the OpenStep API. The OpenStep API makes it quite easy to develop programs for it, as the developer doesn't have to worry about the little things, and spend their time innovating and writing great code . It's cross-platform (between Windows w/ the YellowBox, anything running GNUstep, Mac OS X/Cocoa). It's a dream to develop with, and the Objective-C language, to me, is much nicer to use than C++ (although I think there's wrappers for Java, and perhaps C/C++).
GNUstep will: Allow for easy ports to platforms running GNUstep from source written under OpenStep, Rhapsody, or Mac OS X (using Cocoa/YellowBox). This encourages cross-platform development, and hopefully will help bring many apps to Mac OS X/Cocoa, as well as Linux/FreeBSD/etc.
GNUstep is not: a window manager or a desktop environment. Desktop environments can (and quite easily) built with GNUstep. In fact, someone is working on a NeXT-like file manager right now, which is working and developed under OpenStep, and easily recompiled on a FreeBSD box using GNUstep.
For more information, see the GNUstep website or the unofficial GNUstep website, both of which have plenty of information on the OpenStep spec, and where GNUstep is going.
In short-- definately check it out!
Aaron