I think i kind of just wish they'd commandeered Chimera
That was my first reaction too, but thinking about it I'm glad they didn't. This way Chimera remains independent of Apple and we'll have good competition both between Gecko and KHTML and between the Chimera and Safari UIs. Safari looks decent, but without tabs I won't be switching from Chimera. Definitely worth keeping as a secondary browser though (thereby demoting IE to tertiary).
if it's any more fully-featured than Chimera
If you haven't used Chimera since 0.1, you're missing a lot.
Abandoning all common sense, I just installed Apple's X11 over the top of fink. Both want to dump stuff in/usr/X11R6, but since fink uses/sw for almost everything else I figured it would be ok, which it is so far. Upon firing up X11.app, it tried to read my.xinitrc file, which I have set up in fink to start Gnome with the sawfish window manager. It came up fine, but I wanted to use Apple's window manager that's integrated with the Dock, so I commented out my.xinitrc and restarted X11. This gave me an xterm window with no WM, oops. Fortunately I found "quartz-wm" installed in/usr/X11R6/bin and running that gave me a window manager with Aqua titlebars and buttons, and it even minimizes to the dock exactly like native OS X apps. I then renamed ~/.xinitrc so it wouldn't be found at all, and now when I start X11.app I get an xterm with quartz-wm already running, which is what I want. I've only tried a couple of X (er, X11) apps from my fink installation, but so far they've all worked flawlessly.
the firewire based TV recorder that also records HDTV and is designed for real high bandwidth video
That's what I've been wanting ever since Steve went to the "digital hub" strategy. Specifically, a Tivo-like box running OS X that your Mac connects to via Rendezvous and programs with a nice Cocoa app (with a web interface for non-Mac or remote users). It should use a channel guide delivered as part of.mac (which would be worth $100/year by itself) and be able to transfer video to Macs and new MPEG-enabled iPods. The profits should be more than sufficient to cover the flood of lawsuits from MPAA weasels.
I expect this product to be available shortly after a lasting peace is established in the Middle East.
Personally I think something along the lines of the LGPL, or a modified BSD license which requires that the software being used and any modifications/enhancements to it be made available under the terms the original software was gotten under
Our Linux production servers run heavily threaded Java apps. We end up with tons of processes thereby making top mostly unusable, and we had to write scripts to kill all the "threads" in a "process", but aside from those minor annoyances they work pretty well.
And yes, we did lose something when MS used software developed by the DoD and NASA without paying: we lost the funds that went into developing it and that aren't being recouped.
You didn't lose anything. The DoD and NASA source code is still there for you to use.
Personally I think something along the lines of the LGPL, or a modified BSD license which requires that the software being used and any modifications/enhancements to it be made available under the terms the original software was gotten under
Sounds good to me. I don't have a problem with requiring modifications to taxpayer-funded software to be public, but requiring developers to GPL their own code that touches it goes too far.
unless you include everything you need with your application
Which is exactly what Apple recommends that developers do. The potential size increase is irrelevant given that 20 GB is now a small HD, and I've yet to hear of any licensing issues (there are vendors selling libraries for OS X, which you just include in your application package). I'm sure you can come up with contrived examples where this doesn't work, but the vast majority of the time it's much easier than dealing with dependency management.
It's just $29.99 to turn off the fscking nag screen
Advance your clock to the year 2020 or so, launch QT Player, click the cancel button, reset the clock, and it won't bother you again for 17 years. But yeah, it is obnoxious and silly.
in the vain hope of making enough money to do some serious R&D to catch up with PCs, hardware-wise
More specifically, they may be recognizing that they have a revenue problem for the next 2 or 3 quarters. With the PPC 970 due later this year, nobody who can afford to wait is going to buy the high-margin G4 towers.
Why not? If it is a sqrt() function in a free software library, I think that does count.
I'll agree if sqrt() ends up statically linked in my program, but if it's dynamically linked, no way. In that case I'm not dependent on any particular implementation, I'm just assuming that somewhere in the runtime on the user's system there is a function called "sqrt" that performs a certain operation. It doesn't matter if that function was created by me, Microsoft, the FSF, or aliens from Blargon 7; which of those functions I used when developing the program is irrelevant.
And if you like your Terminial on your OS X you should give Command a try in Windows. Just run 'cmd' and you'll get a similar app with similar commands.
Apple wants people to port their applications to Cocoa. That's the only kind of GUI they want on OSX.
True, and false. Apple emphasizes Cocoa and doesn't provide a built-in X server, but that doesn't mean they're hostile to the concept of running X apps. They even link to the XFree86 Darwin port.
I don't see any point in fighting it, and I don't see any point for open source efforts to waste any time on doing something Apple doesn't want in the first place.
There's nothing to fight, and even if there were, Apple doesn't control what software you run. By that reasoning developing Mozilla for Windows is pointless since Microsoft doesn't like it.
Oh and I'd much rather not use Objective-C for anything, I find it incredibly hard to read, and I know many languages.
That's exactly what I thought, until I started using it. The method syntax actually makes it more readable than most other languages. (Ugh, tried to paste examples but the lameness filter doesn't like it).
language neutral APIs are generally much nicer imho
You can write Cocoa apps in many languages, including Java, Perl, Python, Ruby, Smalltalk, and Lisp.
It is now. There used to be a national speed limit, but it was repealed. (Actually I don't think it was an official federal law, just one of the "impose a 55 mph speed limit or you don't get funding" extortion games).
Yes, mainly revenue generation. If safety were the primary goal they would be significantly higher (see the repeal of the national 55 mph limit, where the predicted bloodbath never materialized).
Having said that, I wouldn't object to automated enforcement, *provided* the limits were set such that a driver exceeding them would actually be acting dangerously. This is nowhere near the case with the majority of speed limits today.
One would be to declare a static method that returns an instance of that class. Register it with a class factory via a static constructor. Any decent framework that supports serialization is going to have this.
Ok, you can go to a fair amount of effort to achieve an inferior version of what other environments have built in, but why reinvent the wheel? And what if I want to use it with classes from another framework? I know, find an entry point and register those classes too. The point is, it's more work than necessary, and increases the amount of your code and thus the potential for bugs.
The Cocoa apps I've played with are cute when all that's at issue is a widget or two, but once you start trying to do real work everything slows down to the point where it's unusable.
Cocoa is derived from NextStep, which ran acceptably on 68030 and 60840 boxes. Today's Macs are multiple orders of magnitude faster; the Objective C runtime overhead is unnoticeable. Quartz clearly could use some improvements and CoreFoundation may have issues, but that has nothing to do with C++ vs ObjC.
The Finder is an excellent example here. It's an embarrassment.
This is true. Although the Finder is a C++ Carbon app...
Not knowing how to code in C++ isn't a reason to go running away and betting everybody's future on a toy language.
I know how to code in C++. That's why I prefer to code in Objective C. As for it being a "toy language", there are plenty of mission critical custom apps still running on NextStep/OpenStep, often after failures to port them to "modern" environments like C++.
The language has been mature for many years now, and there are many tutorials that will help you get your footing.
Sounds like a better description of ObjC than C++. How long did it take before there was a C++ compiler that correctly implemented the full spec? Look, if you like C++, go ahead and use it. You can even call it transparently from Objective C methods. But Apple isn't going to downgrade Cocoa by shoehorning into it support for a language that clearly isn't a good fit.
And the fact that Macintosh is built around that model is going to hurt it badly.
How on earth is the Mac "built around that model"? That makes no sense at all considering Apple gives away their high-quality IDE and actively supports open source. Perhaps you mean that Mac developers haven't traditionally been involved in open source; this is true but rapidly changing.
My parents were asking me: why can't we just run all those Linux games? Well, sorry, they don't run on OS X.
They probably would if you installed Fink. There are dozens of Gnome and KDE games available as Fink packages, and others can be built easily.
And even after you track stuff down, installing it on OS X is confusing for the average user: drag this here, drag that there, click here to let me do this, click there to let me do that, etc.
Once again I have no idea what you're talking about. To install: drag app to "Applications" folder. To uninstall: drag app to trash.
Microsoft has lots of influence on Apple, and Apple won't be able to get out of DRM
Which they had no difficulty in replicating for Java.
Because Java has sufficient dynamic capabilities so that it's a reasonable fit for the Cocoa API and runtime. C++ does not, and is not. Simple example: show me the C++ equivalent of NSClassFromString() or java.lang.Class.forName(). More complicated example: explain how to replicate the functionality of -[NSUndoManager prepareWithInvocationTarget] in C++.
How does one turn off the the bouncing icons? (I'm on 10.2.3)
System Preferences->Dock->"Animate opening applications" checkbox. Also in regard to the parent post, if you're trying to run OS X with less than 256 MB of RAM, don't. 256 is just about the minimum acceptable amount, and on a laptop where hitting VM really hurts (both battery life and performance), I recommend at least 512. I saw a significant improvement on my 667 MHz TiBook going from 512 to 1024.
Yes, the DMCA survives, but I don't think anyone expected it to be overturned as a result of this case. I'm not even sure that's possible in a jury trial; there's the possibility of nullification but that doesn't establish a firm ruling that the law is unconstitutional. But this is still an excellent ruling, because it establishes precedent against the broad interpretation of the DMCA that the **AA cartels would like to use to stifle any products that could conceivably violate copyright even when they have legitimate uses.
Providing something that can be used illicitly is different from providing something that can only be used illicitly.
Exactly. An excellent argument to that effect was inadvertently made by Mr. Valenti himself when he called DeCSS a "digital crowbar". Note to Jack: crowbars are legal, and with good reason.
Slashdot Mirror
That was my first reaction too, but thinking about it I'm glad they didn't. This way Chimera remains independent of Apple and we'll have good competition both between Gecko and KHTML and between the Chimera and Safari UIs. Safari looks decent, but without tabs I won't be switching from Chimera. Definitely worth keeping as a secondary browser though (thereby demoting IE to tertiary).
if it's any more fully-featured than Chimera
If you haven't used Chimera since 0.1, you're missing a lot.
Abandoning all common sense, I just installed Apple's X11 over the top of fink. Both want to dump stuff in /usr/X11R6, but since fink uses /sw for almost everything else I figured it would be ok, which it is so far. Upon firing up X11.app, it tried to read my .xinitrc file, which I have set up in fink to start Gnome with the sawfish window manager. It came up fine, but I wanted to use Apple's window manager that's integrated with the Dock, so I commented out my .xinitrc and restarted X11. This gave me an xterm window with no WM, oops. Fortunately I found "quartz-wm" installed in /usr/X11R6/bin and running that gave me a window manager with Aqua titlebars and buttons, and it even minimizes to the dock exactly like native OS X apps. I then renamed ~/.xinitrc so it wouldn't be found at all, and now when I start X11.app I get an xterm with quartz-wm already running, which is what I want. I've only tried a couple of X (er, X11) apps from my fink installation, but so far they've all worked flawlessly.
Valid point. It's possible there are issues with Microsoft, who probably doesn't want AppleWorks to be *too* good...
That's what I've been wanting ever since Steve went to the "digital hub" strategy. Specifically, a Tivo-like box running OS X that your Mac connects to via Rendezvous and programs with a nice Cocoa app (with a web interface for non-Mac or remote users). It should use a channel guide delivered as part of
I expect this product to be available shortly after a lasting peace is established in the Middle East.
The logical explanation is that they're rewriting it in Cocoa with all sorts of OS X goodies. (At least, that's my favorite explanation).
Our Linux production servers run heavily threaded Java apps. We end up with tons of processes thereby making top mostly unusable, and we had to write scripts to kill all the "threads" in a "process", but aside from those minor annoyances they work pretty well.
You didn't lose anything. The DoD and NASA source code is still there for you to use.
Personally I think something along the lines of the LGPL, or a modified BSD license which requires that the software being used and any modifications/enhancements to it be made available under the terms the original software was gotten under
Sounds good to me. I don't have a problem with requiring modifications to taxpayer-funded software to be public, but requiring developers to GPL their own code that touches it goes too far.
Haven't used it myself, but ThinkFree Office is supposedly halfway decent.
Which is exactly what Apple recommends that developers do. The potential size increase is irrelevant given that 20 GB is now a small HD, and I've yet to hear of any licensing issues (there are vendors selling libraries for OS X, which you just include in your application package). I'm sure you can come up with contrived examples where this doesn't work, but the vast majority of the time it's much easier than dealing with dependency management.
Advance your clock to the year 2020 or so, launch QT Player, click the cancel button, reset the clock, and it won't bother you again for 17 years. But yeah, it is obnoxious and silly.
More specifically, they may be recognizing that they have a revenue problem for the next 2 or 3 quarters. With the PPC 970 due later this year, nobody who can afford to wait is going to buy the high-margin G4 towers.
I'll agree if sqrt() ends up statically linked in my program, but if it's dynamically linked, no way. In that case I'm not dependent on any particular implementation, I'm just assuming that somewhere in the runtime on the user's system there is a function called "sqrt" that performs a certain operation. It doesn't matter if that function was created by me, Microsoft, the FSF, or aliens from Blargon 7; which of those functions I used when developing the program is irrelevant.
Too bad you're serious or this would be +5 Funny.
Not by Apple, but GNUstep is coming along nicely.
True, and false. Apple emphasizes Cocoa and doesn't provide a built-in X server, but that doesn't mean they're hostile to the concept of running X apps. They even link to the XFree86 Darwin port.
I don't see any point in fighting it, and I don't see any point for open source efforts to waste any time on doing something Apple doesn't want in the first place.
There's nothing to fight, and even if there were, Apple doesn't control what software you run. By that reasoning developing Mozilla for Windows is pointless since Microsoft doesn't like it.
That's exactly what I thought, until I started using it. The method syntax actually makes it more readable than most other languages. (Ugh, tried to paste examples but the lameness filter doesn't like it).
language neutral APIs are generally much nicer imho
You can write Cocoa apps in many languages, including Java, Perl, Python, Ruby, Smalltalk, and Lisp.
It is now. There used to be a national speed limit, but it was repealed. (Actually I don't think it was an official federal law, just one of the "impose a 55 mph speed limit or you don't get funding" extortion games).
Yes, mainly revenue generation. If safety were the primary goal they would be significantly higher (see the repeal of the national 55 mph limit, where the predicted bloodbath never materialized).
Having said that, I wouldn't object to automated enforcement, *provided* the limits were set such that a driver exceeding them would actually be acting dangerously. This is nowhere near the case with the majority of speed limits today.
Ok, you can go to a fair amount of effort to achieve an inferior version of what other environments have built in, but why reinvent the wheel? And what if I want to use it with classes from another framework? I know, find an entry point and register those classes too. The point is, it's more work than necessary, and increases the amount of your code and thus the potential for bugs.
The Cocoa apps I've played with are cute when all that's at issue is a widget or two, but once you start trying to do real work everything slows down to the point where it's unusable.
Cocoa is derived from NextStep, which ran acceptably on 68030 and 60840 boxes. Today's Macs are multiple orders of magnitude faster; the Objective C runtime overhead is unnoticeable. Quartz clearly could use some improvements and CoreFoundation may have issues, but that has nothing to do with C++ vs ObjC.
The Finder is an excellent example here. It's an embarrassment.
This is true. Although the Finder is a C++ Carbon app...
Not knowing how to code in C++ isn't a reason to go running away and betting everybody's future on a toy language.
I know how to code in C++. That's why I prefer to code in Objective C. As for it being a "toy language", there are plenty of mission critical custom apps still running on NextStep/OpenStep, often after failures to port them to "modern" environments like C++.
The language has been mature for many years now, and there are many tutorials that will help you get your footing.
Sounds like a better description of ObjC than C++. How long did it take before there was a C++ compiler that correctly implemented the full spec?
Look, if you like C++, go ahead and use it. You can even call it transparently from Objective C methods. But Apple isn't going to downgrade Cocoa by shoehorning into it support for a language that clearly isn't a good fit.
And the fact that Macintosh is built around that model is going to hurt it badly.
How on earth is the Mac "built around that model"? That makes no sense at all considering Apple gives away their high-quality IDE and actively supports open source. Perhaps you mean that Mac developers haven't traditionally been involved in open source; this is true but rapidly changing.
My parents were asking me: why can't we just run all those Linux games? Well, sorry, they don't run on OS X.
They probably would if you installed Fink. There are dozens of Gnome and KDE games available as Fink packages, and others can be built easily.
And even after you track stuff down, installing it on OS X is confusing for the average user: drag this here, drag that there, click here to let me do this, click there to let me do that, etc.
Once again I have no idea what you're talking about. To install: drag app to "Applications" folder. To uninstall: drag app to trash.
Microsoft has lots of influence on Apple, and Apple won't be able to get out of DRM
I see no evidence for either of these assertions.
Because Java has sufficient dynamic capabilities so that it's a reasonable fit for the Cocoa API and runtime. C++ does not, and is not. Simple example: show me the C++ equivalent of NSClassFromString() or java.lang.Class.forName(). More complicated example: explain how to replicate the functionality of -[NSUndoManager prepareWithInvocationTarget] in C++.
System Preferences->Dock->"Animate opening applications" checkbox. Also in regard to the parent post, if you're trying to run OS X with less than 256 MB of RAM, don't. 256 is just about the minimum acceptable amount, and on a laptop where hitting VM really hurts (both battery life and performance), I recommend at least 512. I saw a significant improvement on my 667 MHz TiBook going from 512 to 1024.
Deus Ex: Best...game...ever. Looking very forward to DX 2 (there will be a Mac port, right?)
Yes, the DMCA survives, but I don't think anyone expected it to be overturned as a result of this case. I'm not even sure that's possible in a jury trial; there's the possibility of nullification but that doesn't establish a firm ruling that the law is unconstitutional. But this is still an excellent ruling, because it establishes precedent against the broad interpretation of the DMCA that the **AA cartels would like to use to stifle any products that could conceivably violate copyright even when they have legitimate uses.
Exactly. An excellent argument to that effect was inadvertently made by Mr. Valenti himself when he called DeCSS a "digital crowbar". Note to Jack: crowbars are legal, and with good reason.