My understanding that Sun actually themselves refused to do porting to any platform except Solaris (mainly deployment) and Windows (mainly development).
I see more Linux servers running Java, yet Sun also refused to port Java to Linux themselves. Worse: it didn't even allow *BSD people to do their own port.
As Java porting goes, Sun many times had proven themselves to be a bunch of a**h*les.
Mac OS software takes special pride in its taste and aesthetics - something Java can never achieve.
And now as more users and developers focus on notebooks, resource hungry Java applications are again bad fit. Spinning cycles for nothing is forgivable on desktops and servers - not on notebooks.
The simple truth is that for Apple, Java was always and is a secondary/tertiary technology. What I heard from Linux's Java porters in past, Sun JDK/JRE is a total mess, demanding loads of time for any sort of trivial maintenance task. As Apple uses Sun's JDK/JRE, I guess they are in the same boat as Linux (in times of blackdown.org) was before.
In my experience, code reviews are generally useless. Main problem is that very few software projects have decent documentation which can be used as base for code review. Without documentation, reviews generally end up being a R&D-wide (or worse) squabble.
As development manager, one should try to make the reviews an integral part of development process. Keyword is "integral." Results of review are hard to quantify, thus something should be done to make them useful to the other phases of development process. IOW, results of reviews shouldn't be something on their own, they should be used somewhere too.
One major use for code reviews is when their results are fed back into testing effort. There are companies which test software based solely on high level list of features. I witnessed at least once quite huge mess, caused by bogus design done by R&D: essentially trivial global option was switching code in several programs to alternative code paths. R&D on tight schedule to implement the option simply copy-pasted with minor modifications piles of code. Test department obviously had no idea about that and the option wasn't even properly documented. Code review might have discovered that sooner (e.g. before we actually had several customers attempting to deploy the feature), pushing R&D to do proper design w/o code duplication (unrealistic for commercially developed software) or at least feeding the finding to test department so that they could have tested the whole system twice (option is on, options is off).
Our code is intended for desktop, non-critical use, so I asked my boss to consider whether it was worth spending so much time on examining built code, given our experience not getting much out of it.
No results from core review is a positive result.
But there is a gotcha: if all your developers have similar/save background, then efficiency of code review would be extremely low as such developers tend to do same mistakes. For effective code review, you need people who view the software differently: e.g. developers of one component review another component. Best of all if they would also have different education and background.
But obviously developers themselves should be willing to participate in code reviews. Code review is quite exhausting (e.g. I can review only about 3.5K LOC per day - more my brains do not manage) and poorly motivated developers would do very sloppy job at that. If you can show developers with some graphs from issue tracking system that code review improves quality, then they might be more interested in the process. Yet, still, do not expect any miracles.
Honestly though code review was always my dream. As developer I do quite a number of trivial coding mistakes. When possible I adjust my coding style so that compilers can detect such errors, but commercial compilers I have to use are quite moronic (compared to GCC) when it comes to warnings. And not on one project I had seen people disabling compiler warnings altogether because... because... like hell I know what goes in heads of generic developers on pay roll.
Sure, they have a few franchises going (Mario, Metroid, Zelda, etc.) but they keep innovating and reinventing them in new ways, and they do introduce great new games once in a while (Pikmin comes to mind).
My point was not that I'm not interested in the rehashed, sequeled to death Nintendo games (and I have tried number of them on my DS and Wii).
My point is that none of the games are actually suited for WiiMote.
Even Metroid Prime (FPA, First Person Adventure as they say) falls flat on simple reality that it is more about running around and jumping than pointing at something. And for running and jumping you do not need the WiiMote - classical controller is better at the tasks.
I haven't played all the Wii games, but majority use it exclusively for waggle: convert motion pattern/gesture into virtual button press. Few use it as one big analogue stick. Finally, even fewer games (where WiiSports fall) use it as something everybody expected it to be used.
And even the MPAA itself recommends using a camcorder pointed at a TV as a way to make fair use copies, creating another analog hole.
Just wait for MPAA to get a wind of watermarking and demand camcorder makers to embed watermark recognition to disable video capture of the oh-so-precious intellectual property of theirs.
BTW, in my personal experience, WiiMote suffers from the same problem, as sometimes you have to keep it pointed at screen for a long time. Right hand gets tired quite fast since you can't relax it, maintaining its position at right level all the time.
games are the way non-athletes feel cool (i being one myself) but this 3d stuff, if there is no remote, the athletic people start being better and then what are we left with? back to being a loser that 's not good at anything.
I guess that would be one of the reasons why WiiMote is widely known as "WaggleMote". To make games more accessible (read: wider audience, larger market) instead of full swing (what is already possible with WiiMote) most game reduced the actions to simple wagle/flip of the controller.
To quote improperly, to "level the playing field."
Expecting different reaction of publishers on Natal is silly.
Nintendo pioneered the miniature joystick as well. The n64 had analog sticks more than a year before the dual shock debuted. Nintendo always innovates, while everyone else takes.
I wish Nintendo also "pioneered" some new games... Motion controls are great, but useless if there are no new games to take advantage of them. WiiSports seems to be more of an exception.
The only thing which "excites" me about Natal is that MS is known for pushing hard technology on developers. In other words once released, I expect better support for Natal on Xbox360 than that of WiiMote on Wii.
Though there is also a probability that (similarly to WiiMote) Natal would degrade into some sort of "Waggle HD", when you need to waggle your limbs to trigger some action in a game. At least with WiiMote one waggles only with hands.
It is also worth noting that though Nintendo itself has number of talented developers on pay roll, they are all apparently being kept busy making retro games and sequels. Rather humiliating for them I gather....
But I agree with GP - The developers are lacking. It hadn't occurred to me before his post that UR2004 could be ported to Wii.
"Developers are lacking" isn't variable. It was always like that. The point I'm trying to make, that Xbox360 and PS3 are better at accommodating lacking developers - Wii isn't. In fact, due to all packed innovations, it calls for talented developers who are rather hard to come by in any age.
Last time I seen attachment rates comparison, Wii's was about 1 point below Xbox360. I wouldn't call that abysmal. Likewise, PS3 higher attachment rate also doesn't translate into better financial performance.
Most reports indicate that Wii owners buy games, but they buy games differently but only few publishers have caught the wind.
Filesystems often don't appear to be extensible, which is why Sun invented VFS
I think you need to read the linked article yourself.
VFS serves completely different purpose.
As soon as you change presentation of files/meta information - even by mean of VFS - from point of view of user it is already different file system. Even if it would misleadingly named ZFS+, it wouldn't be compatible with ZFS: you might be able to mount it as ZFS, yet hierarchy/files wouldn't be readily accessible.
I'm frankly more interested to see how Mac OS X can run on UFS. Because if Apple made OS independent of file system features, then really there is no barriers to adoption of ZFS.
P.S. I might look here as ZFS advocate. In reality I'm Linux fanboi. Yet, as Mac OS X goes, anything would be better than archaic HFS/HFS+. Apple needs new file system sooner than later. E.g. I do not want to find that SSD in my MBP17 is a toast year later only because HFS+ can't manage it properly. And it is a fact that HFS+ (though better than NTFS still) can't be tuned to better support needs of SSD.
Of course, the other person answering your flawed arguments about 'crap hardware' is right to the point: What good is a fault tolerant file system if it isn't tolerant of faults?
Or in layman's terms: if shit happens, system shouldn't help to spread it, but to localize it.
(The mods opting for 'informative' of your post obviously don't read the ZFS mailing list, and nobody blames them.)
What you describe is a standard problem faced by all journaling and/or distributed file systems. Or for that matter any distributed ("shared data") system. You simply cannot guarantee anything (efficiently) when many asynchronous agents are involved. And it all depends where would designers cut the compromise with inefficiency (force sync of all the agents).
Judging that it took Veritas a decade to make such system (at least from reading their 5.0 papers I get the impression), I think ZFS needs much much more time to mature.
Oracle currently sponsoring development of Btrfs for Linux, which is equivalent to recently acquired ZFS. I wonder if that played any role.
P.S. Though my personal opinion is more pragmatical. ZFS doesn't seem to be extensible and obviously doesn't support all featlets of HFS/HFS+ (streams, aliases, case insensitivity) which are required for Mac OS and its applications. I guess that should have been a major bummer. Meaning that even if Apple would add ZFS support, it would very likely have different name and it would be incompatible with Sun's ZFS.
Science (like religion) is in some sort of ideal world, vacuum, where all is simple and described by a formula.
I think you're confusing (or conflating) science with mathematics. But don't feel bad; people do this all the time.
Actually that one was a stone at physics;)
Math is abstract by definition (hey, I'm in some part a mathematician too, applied one). Math doesn't deal with real world. With no world at all. Math *allows* one to create their own world - and that's how physicists routinely abuse math all the time.
And in fact that what makes science the way it is: scientific method to work, subject has to be understood by a human. And inner working of human understanding relies on several "lies": generalization and interpretation among others. In other words science can have rules and methods - because those are treats of human behavior and cognition. Thus scientists often sees its subject as they want to see it. Because they can. (*)
Engineering's "it has to work" is pretty unnatural to our brain. It inhibits engineers from seeing the reality the way their brains try to see it.
(*) My classical example is research of "time travel": any 5yo kid understands that "time" is only part of how we observe the world around us, it is part of our cognitive process - not part of the world. Yet, since math models allow to actually put t (time) at left side of equation, some start interpreting it as (variable) part of the world.
In engineering, you are generally working with tools and materials whose behavior is well understood, so you can concentrate on design. With software development, this isn't generally true.
I wanted to object to that, but then I read it again, seen the keyword "understood" and accepted what you way.
Because harsh reality is that many engineers are "working with materials whose behavior is well understood", yet the behavior is not well "known". Software engineers on other side, work with materials which are "known" (hey, it all can be modeled to the bits), yet they are poorly "understood" because of our limited brain capacity.
Now if we could only get the computer field to adopt the same definitions that other fields of engineering, science and mat use. But that isn't going to happen any time soon.
Software engineering is very very young. It freaked me out when in my versity times one prof said that applied algebra is very young, youngest of all mathematics - only *hundred* years old.
As software engineering would be evolving, the many application fields would be branching off. We can safely say that Web programming is going its own separate way. Decade before, finance programming went its own way too. Probably some other unknown to me fields too. The branching is happening precisely because some rules in the fields start to crystallize, making them distinct from general software engineering.
Computer Science compared to Software Engineering?
Think aeronautics. The science of aeronautics ponders the laws of aerodynamics and the laws of flight.
Engineering aeronautics is all about building the damn aircraft.
That's pretty much how I think myself.
Engineering would stop being engineering if it becomes a science.
Engineering is in deep real world, with human nature and business requirements intervening all the time. Science (like religion) is in some sort of ideal world, vacuum, where all is simple and described by a formula. They are both trying to understand a problem - but from different angles. So different - or better say orthogonal - that they are guaranteed to cross only rarely.
Writing software is a creative process, arguably even an artistic one.
Same with science. I'd say that in the respect there is not much difference.
The difference is as I try to put it above is that in engineering "it must work," while in science it doesn't even have to compile. It only has to work in some ideal world with unlimited resources and non-existent foreign factors.
That was about where I stopped reading the comment.
The modern "high-level" programmers who do not understand (nor bother to try to) how their own programs actually work, fit with the system and how system is used to implement language features deserve no pity.
Probably you should RTFM, e.g. man atexit and man exit. Then on Linux compile a small program with static objects and run it under ltrace to see the truth of how it really works.
I did once had the unpleasant experience - debugging monstrous C++ applications, ridden with static objects, which depending on temperature outside of window and direction of wind was sometimes crashing during start-up. And quite reliably crashing during shutdown. (Redundant exception throwing (as modern OO programmer like it) and infamous "singleton" of the design patterns' hall of shame - and you have the sure recipe for a disaster.)
That's actually I personally never use static objects. Very few objects in a program have no dependencies. As soon as any static object has any external dependency or internal state which has to be persistent - forget about clean shutdown.
I find on Google mentions that Python which uses ref counting detects cycles.
I doubt Apple would bother including GC in Mac OS X 10.5 + Objective C 2.0 if it didn't work properly. More than that, documentation on developer.apple.com says that (manual) reference counting isn't compatible with auto GC, meaning that it's not really ref counting based GC. It is clearly states that ref counting and GC are mutually exclusive. Provided that Core Foundation already provides quite rich set of memory management facilities, I personally do not even think that GC is all that important to Cocoa applications. It is a mere utility, provided for convenience, as new generation of developers apparently fail at resource management. (Do not tell me: I know that GC makes life easier. But unfortunately I also have witnessed many occurrences when it can make life harder.)
I'd say that Safari and Chrome are comparable. But setting speed aside, Chrome 2.0 really felt more like 0.2 when compared to FireFox. Long list of missing features, blatantly non-existent integration with Google own on-line applications...
I understand the enthusiasm about faster surfing (Chrome is about only browser which can render/. new layout in near real time), but otherwise they have quite long way before minimalist's feature parity.
Slashdot Mirror
My understanding that Sun actually themselves refused to do porting to any platform except Solaris (mainly deployment) and Windows (mainly development).
I see more Linux servers running Java, yet Sun also refused to port Java to Linux themselves. Worse: it didn't even allow *BSD people to do their own port.
As Java porting goes, Sun many times had proven themselves to be a bunch of a**h*les.
What a load of bull.
Mac OS software takes special pride in its taste and aesthetics - something Java can never achieve.
And now as more users and developers focus on notebooks, resource hungry Java applications are again bad fit. Spinning cycles for nothing is forgivable on desktops and servers - not on notebooks.
The simple truth is that for Apple, Java was always and is a secondary/tertiary technology. What I heard from Linux's Java porters in past, Sun JDK/JRE is a total mess, demanding loads of time for any sort of trivial maintenance task. As Apple uses Sun's JDK/JRE, I guess they are in the same boat as Linux (in times of blackdown.org) was before.
In my experience, code reviews are generally useless. Main problem is that very few software projects have decent documentation which can be used as base for code review. Without documentation, reviews generally end up being a R&D-wide (or worse) squabble.
As development manager, one should try to make the reviews an integral part of development process. Keyword is "integral." Results of review are hard to quantify, thus something should be done to make them useful to the other phases of development process. IOW, results of reviews shouldn't be something on their own, they should be used somewhere too.
One major use for code reviews is when their results are fed back into testing effort. There are companies which test software based solely on high level list of features. I witnessed at least once quite huge mess, caused by bogus design done by R&D: essentially trivial global option was switching code in several programs to alternative code paths. R&D on tight schedule to implement the option simply copy-pasted with minor modifications piles of code. Test department obviously had no idea about that and the option wasn't even properly documented. Code review might have discovered that sooner (e.g. before we actually had several customers attempting to deploy the feature), pushing R&D to do proper design w/o code duplication (unrealistic for commercially developed software) or at least feeding the finding to test department so that they could have tested the whole system twice (option is on, options is off).
Our code is intended for desktop, non-critical use, so I asked my boss to consider whether it was worth spending so much time on examining built code, given our experience not getting much out of it.
No results from core review is a positive result.
But there is a gotcha: if all your developers have similar/save background, then efficiency of code review would be extremely low as such developers tend to do same mistakes. For effective code review, you need people who view the software differently: e.g. developers of one component review another component. Best of all if they would also have different education and background.
But obviously developers themselves should be willing to participate in code reviews. Code review is quite exhausting (e.g. I can review only about 3.5K LOC per day - more my brains do not manage) and poorly motivated developers would do very sloppy job at that. If you can show developers with some graphs from issue tracking system that code review improves quality, then they might be more interested in the process. Yet, still, do not expect any miracles.
Honestly though code review was always my dream. As developer I do quite a number of trivial coding mistakes. When possible I adjust my coding style so that compilers can detect such errors, but commercial compilers I have to use are quite moronic (compared to GCC) when it comes to warnings. And not on one project I had seen people disabling compiler warnings altogether because ... because ... like hell I know what goes in heads of generic developers on pay roll.
Sure, they have a few franchises going (Mario, Metroid, Zelda, etc.) but they keep innovating and reinventing them in new ways, and they do introduce great new games once in a while (Pikmin comes to mind).
My point was not that I'm not interested in the rehashed, sequeled to death Nintendo games (and I have tried number of them on my DS and Wii).
My point is that none of the games are actually suited for WiiMote.
Even Metroid Prime (FPA, First Person Adventure as they say) falls flat on simple reality that it is more about running around and jumping than pointing at something. And for running and jumping you do not need the WiiMote - classical controller is better at the tasks.
I haven't played all the Wii games, but majority use it exclusively for waggle: convert motion pattern/gesture into virtual button press. Few use it as one big analogue stick. Finally, even fewer games (where WiiSports fall) use it as something everybody expected it to be used.
Then I could just wander around disney land and crashing weddings ruining peoples home videos.
You can't imagine how many husbands would be glad if you did. LOL.
And even the MPAA itself recommends using a camcorder pointed at a TV as a way to make fair use copies, creating another analog hole.
Just wait for MPAA to get a wind of watermarking and demand camcorder makers to embed watermark recognition to disable video capture of the oh-so-precious intellectual property of theirs.
[...] and "core" gamers do no want Wii-like motion based games.
Core gamers want 3D motion controls.
Core gamers do not want waggle, to which WiiMote was reduced by flood of quick-and-dirty ports from other consoles.
BTW, in my personal experience, WiiMote suffers from the same problem, as sometimes you have to keep it pointed at screen for a long time. Right hand gets tired quite fast since you can't relax it, maintaining its position at right level all the time.
It's quite ironic that list of consoles ranked by tech power matches perfectly to reversed list of consoles ranked by popularity.
games are the way non-athletes feel cool (i being one myself) but this 3d stuff, if there is no remote, the athletic people start being better and then what are we left with? back to being a loser that 's not good at anything.
I guess that would be one of the reasons why WiiMote is widely known as "WaggleMote". To make games more accessible (read: wider audience, larger market) instead of full swing (what is already possible with WiiMote) most game reduced the actions to simple wagle/flip of the controller.
To quote improperly, to "level the playing field."
Expecting different reaction of publishers on Natal is silly.
Nintendo pioneered the miniature joystick as well. The n64 had analog sticks more than a year before the dual shock debuted. Nintendo always innovates, while everyone else takes.
I wish Nintendo also "pioneered" some new games... Motion controls are great, but useless if there are no new games to take advantage of them. WiiSports seems to be more of an exception.
The only thing which "excites" me about Natal is that MS is known for pushing hard technology on developers. In other words once released, I expect better support for Natal on Xbox360 than that of WiiMote on Wii.
Though there is also a probability that (similarly to WiiMote) Natal would degrade into some sort of "Waggle HD", when you need to waggle your limbs to trigger some action in a game. At least with WiiMote one waggles only with hands.
It is also worth noting that though Nintendo itself has number of talented developers on pay roll, they are all apparently being kept busy making retro games and sequels. Rather humiliating for them I gather....
But I agree with GP - The developers are lacking. It hadn't occurred to me before his post that UR2004 could be ported to Wii.
"Developers are lacking" isn't variable. It was always like that. The point I'm trying to make, that Xbox360 and PS3 are better at accommodating lacking developers - Wii isn't. In fact, due to all packed innovations, it calls for talented developers who are rather hard to come by in any age.
Last time I seen attachment rates comparison, Wii's was about 1 point below Xbox360. I wouldn't call that abysmal. Likewise, PS3 higher attachment rate also doesn't translate into better financial performance.
Most reports indicate that Wii owners buy games, but they buy games differently but only few publishers have caught the wind.
I agree.
It would be very surprising if mechanics asked to check a car would ignore a dead body in a truck.
Filesystems often don't appear to be extensible, which is why Sun invented VFS
I think you need to read the linked article yourself.
VFS serves completely different purpose.
As soon as you change presentation of files/meta information - even by mean of VFS - from point of view of user it is already different file system. Even if it would misleadingly named ZFS+, it wouldn't be compatible with ZFS: you might be able to mount it as ZFS, yet hierarchy/files wouldn't be readily accessible.
I'm frankly more interested to see how Mac OS X can run on UFS. Because if Apple made OS independent of file system features, then really there is no barriers to adoption of ZFS.
P.S. I might look here as ZFS advocate. In reality I'm Linux fanboi. Yet, as Mac OS X goes, anything would be better than archaic HFS/HFS+. Apple needs new file system sooner than later. E.g. I do not want to find that SSD in my MBP17 is a toast year later only because HFS+ can't manage it properly. And it is a fact that HFS+ (though better than NTFS still) can't be tuned to better support needs of SSD.
Of course, the other person answering your flawed arguments about 'crap hardware' is right to the point: What good is a fault tolerant file system if it isn't tolerant of faults?
Or in layman's terms: if shit happens, system shouldn't help to spread it, but to localize it.
(The mods opting for 'informative' of your post obviously don't read the ZFS mailing list, and nobody blames them.)
What you describe is a standard problem faced by all journaling and/or distributed file systems. Or for that matter any distributed ("shared data") system. You simply cannot guarantee anything (efficiently) when many asynchronous agents are involved. And it all depends where would designers cut the compromise with inefficiency (force sync of all the agents).
Judging that it took Veritas a decade to make such system (at least from reading their 5.0 papers I get the impression), I think ZFS needs much much more time to mature.
It's actually more interesting than that.
Oracle currently sponsoring development of Btrfs for Linux, which is equivalent to recently acquired ZFS. I wonder if that played any role.
P.S. Though my personal opinion is more pragmatical. ZFS doesn't seem to be extensible and obviously doesn't support all featlets of HFS/HFS+ (streams, aliases, case insensitivity) which are required for Mac OS and its applications. I guess that should have been a major bummer. Meaning that even if Apple would add ZFS support, it would very likely have different name and it would be incompatible with Sun's ZFS.
Unix. [...] what could arguably be called the most important operating system of them all.
WinNT is the most important OS of them all: they even had UNIX reinvented dozen of times already.
Science (like religion) is in some sort of ideal world, vacuum, where all is simple and described by a formula.
I think you're confusing (or conflating) science with mathematics. But don't feel bad; people do this all the time.
Actually that one was a stone at physics ;)
Math is abstract by definition (hey, I'm in some part a mathematician too, applied one). Math doesn't deal with real world. With no world at all. Math *allows* one to create their own world - and that's how physicists routinely abuse math all the time.
And in fact that what makes science the way it is: scientific method to work, subject has to be understood by a human. And inner working of human understanding relies on several "lies": generalization and interpretation among others. In other words science can have rules and methods - because those are treats of human behavior and cognition. Thus scientists often sees its subject as they want to see it. Because they can. (*)
Engineering's "it has to work" is pretty unnatural to our brain. It inhibits engineers from seeing the reality the way their brains try to see it.
(*) My classical example is research of "time travel": any 5yo kid understands that "time" is only part of how we observe the world around us, it is part of our cognitive process - not part of the world. Yet, since math models allow to actually put t (time) at left side of equation, some start interpreting it as (variable) part of the world.
In engineering, you are generally working with tools and materials whose behavior is well understood, so you can concentrate on design. With software development, this isn't generally true.
I wanted to object to that, but then I read it again, seen the keyword "understood" and accepted what you way.
Because harsh reality is that many engineers are "working with materials whose behavior is well understood", yet the behavior is not well "known". Software engineers on other side, work with materials which are "known" (hey, it all can be modeled to the bits), yet they are poorly "understood" because of our limited brain capacity.
Now if we could only get the computer field to adopt the same definitions that other fields of engineering, science and mat use. But that isn't going to happen any time soon.
Software engineering is very very young. It freaked me out when in my versity times one prof said that applied algebra is very young, youngest of all mathematics - only *hundred* years old.
As software engineering would be evolving, the many application fields would be branching off. We can safely say that Web programming is going its own separate way. Decade before, finance programming went its own way too. Probably some other unknown to me fields too. The branching is happening precisely because some rules in the fields start to crystallize, making them distinct from general software engineering.
Computer Science compared to Software Engineering?
Think aeronautics. The science of aeronautics ponders the laws of aerodynamics and the laws of flight.
Engineering aeronautics is all about building the damn aircraft.
That's pretty much how I think myself.
Engineering would stop being engineering if it becomes a science.
Engineering is in deep real world, with human nature and business requirements intervening all the time. Science (like religion) is in some sort of ideal world, vacuum, where all is simple and described by a formula. They are both trying to understand a problem - but from different angles. So different - or better say orthogonal - that they are guaranteed to cross only rarely.
Writing software is a creative process, arguably even an artistic one.
Same with science. I'd say that in the respect there is not much difference.
The difference is as I try to put it above is that in engineering "it must work," while in science it doesn't even have to compile. It only has to work in some ideal world with unlimited resources and non-existent foreign factors.
'exit' is a system call ...
That was about where I stopped reading the comment.
The modern "high-level" programmers who do not understand (nor bother to try to) how their own programs actually work, fit with the system and how system is used to implement language features deserve no pity.
Go back to your Java cave.
Probably you should RTFM, e.g. man atexit and man exit. Then on Linux compile a small program with static objects and run it under ltrace to see the truth of how it really works.
I did once had the unpleasant experience - debugging monstrous C++ applications, ridden with static objects, which depending on temperature outside of window and direction of wind was sometimes crashing during start-up. And quite reliably crashing during shutdown. (Redundant exception throwing (as modern OO programmer like it) and infamous "singleton" of the design patterns' hall of shame - and you have the sure recipe for a disaster.)
That's actually I personally never use static objects. Very few objects in a program have no dependencies. As soon as any static object has any external dependency or internal state which has to be persistent - forget about clean shutdown.
I find on Google mentions that Python which uses ref counting detects cycles.
I doubt Apple would bother including GC in Mac OS X 10.5 + Objective C 2.0 if it didn't work properly. More than that, documentation on developer.apple.com says that (manual) reference counting isn't compatible with auto GC, meaning that it's not really ref counting based GC. It is clearly states that ref counting and GC are mutually exclusive. Provided that Core Foundation already provides quite rich set of memory management facilities, I personally do not even think that GC is all that important to Cocoa applications. It is a mere utility, provided for convenience, as new generation of developers apparently fail at resource management. (Do not tell me: I know that GC makes life easier. But unfortunately I also have witnessed many occurrences when it can make life harder.)
And how it doesn't suck then?
I'd say that Safari and Chrome are comparable. But setting speed aside, Chrome 2.0 really felt more like 0.2 when compared to FireFox. Long list of missing features, blatantly non-existent integration with Google own on-line applications...
I understand the enthusiasm about faster surfing (Chrome is about only browser which can render /. new layout in near real time), but otherwise they have quite long way before minimalist's feature parity.