[opsotta]

Has anyone read that report? http://www.osnews.com/story.php?news_id=421
The author compares OS X with BeOS and shows some very interesting points
OS X (and so we) is just missing. Can't get it out of my head...
It is interesting that we don't miss something when we don't know that
it exists!

[moki]

Originally posted by opsotta:
<STRONG>Has anyone read that report? http://www.osnews.com/story.php?news_id=421
The author compares OS X with BeOS and shows some very interesting points
OS X (and so we) is just missing. Can't get it out of my head...
It is interesting that we don't miss something when we don't know that
it exists!</STRONG>

heh -- well, with all due respect to the BeBox sitting in our office closet, the BeOS is the last OS that should be complaining about missing features.

[sadie]

Hey, i never dreamed of moving to Be with its applications and features, but there's a lot about it that Apple could learn from. Like metadata. Hint hint, nudge nudge.

[ChaChi Boy]

What do you mean compared to a modern operating system. OSX is a modern operating system.

[miro7]

what...comparing OS X's modern OpenGL and modern Network Stack to BeOS's lack of either?

Without trying to sound trite, the author of said article mentions at least the rewrite of the Network Stack for BeOS (BONE), don't remember if he mentioned OGL.

[DannyVTim]

Yes, but the point of the article is not to talk about what is missing from BeOS but what is missing from OS X. OS X certainly has a long way to go in many areas before it can be considered on a productivity level with NT. Of course all the mac zealots here won't admit as much or don't use other OSs enough to know the difference. So, you can start the blindly defending OS X now.

[ChaChi Boy]

Originally posted by DannyVTim:
<STRONG>OS X certainly has a long way to go in many areas before it can be considered on a productivity level with NT. </STRONG>

Sorry, that is the first time I heard "Productive" and "NT" in the same sentence.

[miro7]

Of course all the mac zealots here won't admit as much or don't use other OSs enough to know the difference. So, you can start the blindly defending OS X now.

And this is contrary to the NT will always be better than OS X just admit it posters, how? And in what way does that help said platform, other than indirectly?

Anyway, as for my part, I'll gladly acknowledge any short comings in OS X--as long as that short coming keeps me from being productive or that said additional feature would increase my productivity. As far as NT, 2k or XP are concerned I haven't seen a feature there that increases my productivity over OS X, save that MS OSes run AutoCAD whereas Apple OSes don't (least not anymore).

[Millennium]

The logical fallacy you use is, unless I'm mistaken, called "poisoning the well". In other words, putting a strongly negative spin on the article before people read it, to manipulate their attitudes toward what's written.

Not the first time I've seen it. In the PB days, whiners would often point to John Siracusa's articles, but exploit his "positive first, then negative" formula by linking only to the negative section, rather than the whole article.

Now, for those of you who want the truth about the article, it's actoually positive. Scott Hacker, the author, proclaims that OSX is his new favorite. He does, however, have a couple of gripes, as opsotta pointed out:

• Speed. Tell us something we don't know.
• Filesystem issues. Yes, we all know that BeFS is better than HFS+ (except as concerns unique file identifiers).
• Support for outside filesystems. This would be nice, though not as critical in a networked world, where the protocol abstracts the filesystem details out.
• App-binding policies. OSX's biggest flaw; it's de-evolution to relying on the obscene hack of file extensions. Hacker has this dead-on.
• Spring-loaded folders. Again, nothing new.
• Long filename support. He has this half right; Apple has made it too difficult to move Carbon apps to long filename support. Cocoa is another matter, though Cocoa doesn't have proper metadata or unique-ID support.

So in other words, his problems with OSX are nothing that we haven't already heard, and like many of us, he doesn't let them stop him from enjoying OSX for what it is.

[iNeusch]

I guess we can now close the topic... all has been said

[opsotta]

No reason to feel hurt, that was not my intention! :-)
I just like the mentioned report for it's important
aspects and hope that we can see these in OS X some
time to come.

Of course is OS X a modern system, maybe I chose the
topic a bit too sensational. :-)

However, how would it be if - after Apple has a guy
from FreeBSD - Apple would hire a guy from the BeOS
team so that they could profit from his experience
in making a fast OS?

[TheBum]

Originally posted by iNeusch:
<STRONG>I guess we can now close the topic... all has been said </STRONG>

That's kind of like the head of the US Patent Office around the turn of the 20th century saying that he didn't expect the patent system to be around much longer because there's nothing left to invent. (This is a gross paraphrase).

[moki]

Originally posted by Millennium:
<STRONG>[*]Long filename support. He has this half right; Apple has made it too difficult to move Carbon apps to long filename support. Cocoa is another matter, though Cocoa doesn't have proper metadata or unique-ID support.</STRONG>

I take issue with that -- it is actually extremely *easy* to add long file name support. Apple just needs to post a nice HOWTO -- the research into *what* you need to do to make this work takes longer than actually implementing it.

Either way, I can't imagine it'd take anyone more than a day or two on a project of any size to implement long file names.

[ChaChi Boy]

Originally posted by moki:
<STRONG>

Either way, I can't imagine it'd take anyone more than a day or two on a project of any size to implement long file names.</STRONG>

Someone should ask Microsoft that.

I wonder why AppleWorks does not support it when Apple is the one writing the damn thing.

[Spheric Harlot]

Originally posted by DannyVTim:
<STRONG>OS X certainly has a long way to go in many areas before it can be considered on a productivity level with NT. Of course all the mac zealots here won't admit as much or don't use other OSs enough to know the difference. So, you can start the blindly defending OS X now.</STRONG>

Idiot troll.

I spend almost as much time on NT @ work as in OS X. Ever see how "productive" NT gets under low-memory condidtions?

I've seen OS X get pretty slow (though since 10.1, it's always been bearable, especially considering the load I was putting on it), but I've NEVER had an app just QUIT (no warning, no notice, no NOTHING!) or menus simply DISAPPEAR on OS X. This (disappearing menus) happens DAILY on my NT box. The really cool thing is, since the text rendering dies, you often can't even read the dialog boxes warning you to quit unused apps - they're EMPTY!
It took me a little bit to figure out what was going on when it happened the first time.

The five-minute logon process is pretty cool, too - log in, and you have enough time to go prepare some tea for a good start into a long work day.

Originally posted by ChaChi Boy:
<STRONG>Someone should ask Microsoft that.

I wonder why AppleWorks does not support it when Apple is the one writing the damn thing.</STRONG>

I suspect it *might* have to do with backwards-compatibility of created documents? (Don't know, though)

-chris.

[ 12-19-2001: Message edited by: Spheric Harlot ]

[Angus_D]

Originally posted by Spheric Harlot:
<STRONG>I suspect it *might* have to do with backwards-compatibility of created documents? (Don't know, though)</STRONG>

No, it's just that AppleWorks is a lame carbon port.

[malvolio]

Spheric Harlot:

I spend almost as much time on NT @ work as in OS X. Ever see how "productive" NT gets under low-memory condidtions?

Yeah, I spend about 6 hours of each workday on a WinNT box. Performance sucks. And our poor sysadmin is on the verge of a nervous breakdown, trying to keep things at least semi-functional.

[Boondoggle]

I wonder why AppleWorks does not support it when Apple is the one writing the damn thing.

Correct me if I'm wrong, but I don't think Apple writes AppleWorks. I'm pretty sure they buy it from some company in Oregon.

bd

[Millennium]

I take issue with that -- it is actually extremely *easy* to add long file name support. Apple just needs to post a nice HOWTO -- the research into *what* you need to do to make this work takes longer than actually implementing it.

Still too difficult. This is one of those things that should have been given automatically to all Carbon apps (Services are another example). By making them optional, Apple has essentially invited developers not to do it. In the end, that's really the big beef I have with Carbon: it's not as well-designed as it could have been.

And if it's so easy, then why couldn't Microsoft have taken a few minutes out of their windows-genieing-into-toolbar coding and done it for Office v.X? Or Panic, with Transmit (the situation is improving here but the long filenames still only go one way)? Or even AppleWorks? I don't doubt it's fairly easy, but it's a design flaw in Carbon that FSSpec doesn't have 256-char filename support.

Either way, I can't imagine it'd take anyone more than a day or two on a project of any size to implement long file names.

Anyone here from the MacBU? This is an honest question here; where is the long filename support?

[RichardS]

Originally posted by Millennium:
<STRONG>
This is one of those things that should have been given automatically to all Carbon apps</STRONG>

As nice as that would be, it simply wasn't an option. Most classic apps are coded in c, where arrays are not bounds-checked. Somewhere in their code, many classic apps probably assume 31 character filenames, and so only allocate 32 (or 64, if using a double byte encoding) bytes of memory to store a filename in.

If some system function all of a sudden returns a 255 character filename, the program will happily write the extra characters beyond the programmers intended 32 bytes, overwriting whatever was there, no matter how important it may be.

A lovely message like 'The system and other applications have not been affected' would soon follow.

You don't simply change how anything in an API works, because anything that depends on that API is likely to break. And then we're right back to where we started from. Both removing FSSpecs and making them 255 char aware would break a lot of apps, making them far harder to port. I'm not a carbon programmer, but as I recall, this is why Apple suggests switching to FSRefs instead of FSSpecs. FSSpecs remain around in their current form to serve apps that still assume 32 character filenames, and Programmers can fix the 32 char limit as they switch their code over to using FSRefs.

[Rickster]

As the esteemed El Presidente pointed out, it's not that switching to FSRefs for long file name support is difficult, it's just that many developers haven't put in the effort to do it.

What I find most interesting is that most of the Toolbox/Carbon APIs that took FSSpecs as parameters weren't updated to use FSRefs until 9.1. Nine point one! Now, I'm not a Carbon developer, but this strikes me as odd, personally. It means developers couldn't fully switch to FSRefs in their Classic-based code until early this year, does it not? Had Apple prioritized parts of the Carbon transition such that all Toolbox APIs had FSRef-based versions as of, say, CarbonLib 1.0 / Mac OS 9.0, they could have "outlawed" the FSSpec-based versions on Carbon/Mac OS X, and then all Carbon apps would *have* to support long filenames.

By the way, AppleWorks is indeed developed by a branch of Apple based in Vancouver, Washington. (That's an across-the-river suburb of Portland, Oregon. Nice place to live, apparenly... WA has no income tax, and OR has no sales tax.) Said branch used to be Claris (and before that, AppleSoft), a wholly owned but independent subsidiary of Apple, and makers of ClarisWorks, FileMaker, MacDraw, Emailer, Organizer, et al. Apple "bought back" most of Claris a few years ago, but kept FileMaker Inc. as an independent subsidiary, but the offices of the ClarisWorks/AppleWorks team remained in Vancouver. So you could say that they have less of an incentive than the rest of Apple to do good Carbon ports... but then, there seem to be just as many poor Carbon ports coming out of Cupertino.

--Rick

[ 12-20-2001: Message edited by: Rickster ]

[Scrod]

Originally posted by RichardS:
<STRONG>
If some system function all of a sudden returns a 255 character filename, the program will happily write the extra characters beyond the programmers intended 32 bytes, overwriting whatever was there..</STRONG>

Only if they were using strcpy; strncpy wouldn't do that. Also, if this app acted as a server of some sort, it would be much wiser to use strncpy so as to protect against buffer overflow exploits.

[ 12-20-2001: Message edited by: Scrod ]

[lgerbarg]

Originally posted by Scrod:
<STRONG>

Only if they were using strcpy; strncpy wouldn't do that. Also, if this app acted as a server of some sort, it would be much wiser to use strncpy so as to protect against buffer overflow exploits.

[ 12-20-2001: Message edited by: Scrod ]</STRONG>

This is not about manipulating some strings. Your not the one doing the copying of the strings into buffers anyway, the APIs are. This is about have something like

<BLOCKQUOTE><font size="1"face="Geneva, Verdana, Arial">code:</font><HR><pre><font size=1 face=courier>
typedef Str255 char[<font color = blue>255</font>];
typedef Str31 char[<font color = blue>31</font>];

void oldFunc(Str31 * name_return);
</font>[/code]

You cannot just change the return value of the function. Even though all new compiles will get type errors, all old code will happily run, and pass in a buffer blindingly ignorant of the fact that the buffer adjacent memory is about to get destroyed. Good string handling protects you from overruns, but it does not make your code magicly cope with API and ABI changes. There is no way a rewritten version of the function can't protect you, because it has no way of knowing the actual length of the allocated buffer it has been passed in order to deal with dynamically truncatting, which would end in the same UI issues, but would make weeding out the problems a lot nastier since some entries would be long and some wouldn't. It is far better to just make a new call for it.

Louis

[Gee4orce]

Going back to the original article, there are some extremely positive points, and on the whole the author is very happy with his OS X experience. It's a very long read, but well worth it (there's a .pdf file if you prefer, created by OS X'x save preview as pdf function).

The bit I liked best was when he was talking about digital cameras, and the endless hassle of getting them to work with his dad's BeOS/Win box. He said in OS X he simply plugged it in and it worked, and even offered to make a web page for him. His final comment on the subject was that if he discovers a secret stash of cash, he's buying his dad an OS X box.

[sadie]

The real point isn't how OS X compares to NT (which really doesn't live up to its promises) or to BeOS (which is dead). The comparison is between what OS X is, and what it should be.

Mind the gap.

[Spheric Harlot]

Originally posted by Gee4orce:
<STRONG>Going back to the original article, there are some extremely positive points, and on the whole the author is very happy with his OS X experience. It's a very long read, but well worth it (there's a .pdf file if you prefer, created by OS X'x save preview as pdf function).</STRONG>

I find this by far the best quote:

The Mac communities are much better than the Windows and Linux communities as far as signal/noise ratio goes, but suffer from
a different kind of problem: Stubborn-ness. There seem to be endless armies of Mac users who feel that the old ways are the
best. Who kick and moan and bitch about OS X and its cursed Unix underbelly and how evil the command line is and how Apple
is off its rocker. These people would rather keep using a slow, crashy, OS with no remote administration and no appeal to
command-line power users and no position in the server niche than be dragged kicking and screaming into the modern world.

Granted, these voices seem to grow a little less loud and a little less prolific with every passing month. But they're still there, and
the fact that they're clinging to OS9 for reasons mostly beyond my comprehension are bad for us all. App vendors who haven't yet
ported point to a lack of wide-scale adoption of OS X. And whose fault is that? The very Macintosh userbase those app vendors
are here to support! Note to the stubborn ones: You're a drag on us all. Get on board.

[ 12-20-2001: Message edited by: Spheric Harlot ]

[xi_hyperon]

Originally posted by Spheric Harlot:
<STRONG>

[ 12-20-2001: Message edited by: Spheric Harlot ]</STRONG>

I suppose that quote would be too big to use as a sig. That is unfortunate.

[kangoo_boo]

Originally posted by ChaChi Boy:
<STRONG>What do you mean compared to a modern operating system. OSX is a modern operating system.</STRONG>

chichaboy i hate yer pict and i hate when you speak.
that was a flame,, please delete me.

[gee308]

Originally posted by Spheric Harlot:
<STRONG>

I suspect it *might* have to do with backwards-compatibility of created documents? (Don't know, though)

-chris.

[ 12-19-2001: Message edited by: Spheric Harlot ]</STRONG>

Well, I wouldn't call this being productive, but at least half the time I go to a flash based site such as newgrounds.com Internet Explorer quits out unexpectedly all the time. It drives me crazy.

[xi_hyperon]

Originally posted by gee308:
<STRONG>

Well, I wouldn't call this being productive, but at least half the time I go to a flash based site such as newgrounds.com Internet Explorer quits out unexpectedly all the time. It drives me crazy.</STRONG>

I would think that is more of an IE problem, not an OS X problem.

[Scrod]

Louis, you're quite right of course--I was forgetting that these strings are being passed through an API.

[godzookie2k]

spend almost as much time on NT @ work as in OS X. Ever see how "productive" NT gets under low-memory condidtions?

I've seen OS X get pretty slow (though since 10.1, it's always been bearable, especially considering the load I was putting on it), but I've NEVER had an app just QUIT (no warning, no notice, no NOTHING!) or menus simply DISAPPEAR on OS X. This (disappearing menus) happens DAILY on my NT box. The really cool thing is, since the text rendering dies, you often can't even read the dialog boxes warning you to quit unused apps - they're EMPTY!
It took me a little bit to figure out what was going on when it happened the first time.

The five-minute logon process is pretty cool, too - log in, and you have enough time to go prepare some tea for a good start into a long work day

Hmph, that pretty much sums up my OSX experience. I guess you are not 'pushing' your machine as hard as I do. I've had OSX slow to the point of unusability just by waking it up when there are a boatload of heavy apps open. I've seen apps quit w/o an error message and w/o a warning. I've also had OS"X's text go all wonky, except that X forgets kerning in its type and overlays all the letters on top of one another. As for log on/start up? I can go outside and smoke and come back (~4 mins) and X is just finishing up with starting classic. (from power off) No, this doesn't occur on an iMac, but on a dualie G4 with a gig-o-ram.

But hey, I'm not bitching, just bringing in a little bit of reality. Also, I've used NT alot (Not in ages) and found it quite productive for what I had to do (namely 3d editing). Just as X is productive just as long as you don't want to do advanced video editing, Heavy photo manipulation, or have 10,000 fonts in a library (not the folder). Get my point?


Nick

[ChaChi Boy]

Originally posted by kangoo_boo:
<STRONG>

chichaboy i hate yer pict and i hate when you speak.
that was a flame,, please delete me.</STRONG>

Another good example of why everyone hates the French.

[Eug]

Originally posted by ChaChi Boy:
<STRONG>

Another good example of why everyone hates the French.</STRONG>

By the way, isn't that Eric Estrada, and not Scott Baio?

[ChaChi Boy]

Originally posted by Eug:
<STRONG>By the way, isn't that Eric Estrada, and not Scott Baio?</STRONG>

Ya but who here knows that and I like this picture better

[xi_hyperon]

Originally posted by ChaChi Boy:
<STRONG>

Ya but who here knows that and I like this picture better </STRONG>

Only those of us who dare to date ourselves by admitting recognition of CHiPS. Hated that show, but nevertheless, I feel old.

[kangoo_boo]

Originally posted by ChaChi Boy:
<STRONG>

Ya but who here knows that and I like this picture better </STRONG>

that's just bcse you post like every 10min here (how do you do this;p) and seeiyng this pict 10/thread... plus all theses "macos is so great"
i mean, okay, you can love macos more than any os, as i do, but you should take more attention to the others os. BeOS for example here, is in fact even more than a modern os. It is the futur of os probably. OSX is more like the modern os then. But the filesystem sux compared to be, and most the things they did in BeOS was really _really_ above any os. Even so i prefer macosx, but, heh, beos run so smooth..

[Kestral]

Originally posted by Eug:
<STRONG>By the way, isn't that Eric Estrada, and not Scott Baio?</STRONG>

Eric Estrada? Damn, and here I was thinking it was Fez from That 70's Show.

[ChaChi Boy]

Originally posted by kangoo_boo:
<STRONG>

that's just bcse you post like every 10min here (how do you do this;p) and seeiyng this pict 10/thread... plus all theses "macos is so great"
i mean, okay, you can love macos more than any os, as i do, but you should take more attention to the others os. BeOS for example here, is in fact even more than a modern os. It is the futur of os probably. OSX is more like the modern os then. But the filesystem sux compared to be, and most the things they did in BeOS was really _really_ above any os. Even so i prefer macosx, but, heh, beos run so smooth..</STRONG>

Bla bla bla. Save it frenchy and go use the DEAD BeOS then.

[lgerbarg]

Originally posted by Scrod:
<STRONG>Louis, you're quite right of course--I was forgetting that these strings are being passed through an API.</STRONG>

Its easy to forget about such things, but when your trying to keep compatibility, such changes come to bite you ;-)

Louis

[iSore]

Originally posted by ChaChi Boy:
<STRONG>

Bla bla bla. Save it frenchy and go use the DEAD BeOS then.</STRONG>

Nice to see pluralism is alive and well in the most culturally diverse city on the planet.

[Spheric Harlot]

Originally posted by godzookie2k:
<STRONG>Hmph, that pretty much sums up my OSX experience. I guess you are not 'pushing' your machine as hard as I do. I've had OSX slow to the point of unusability just by waking it up when there are a boatload of heavy apps open. I've seen apps quit w/o an error message and w/o a warning. I've also had OS"X's text go all wonky, except that X forgets kerning in its type and overlays all the letters on top of one another. As for log on/start up? I can go outside and smoke and come back (~4 mins) and X is just finishing up with starting classic. (from power off) No, this doesn't occur on an iMac, but on a dualie G4 with a gig-o-ram. </STRONG>

Four minutes for boot and login? On my puny little iMac DV 400, login is done probably less than two minutes after switching the machine on, and the machine is fully usable at this point (except for Classic, which I don't load at startup). If you count in the eight or nine apps I have set to auto-start at login, maybe two-and-a-half minutes (never actually timed it - it never bugged me).

On my NT machine at work, the login script will often sit for *ages*.

Not to discount your experiences, but that actually sounds to me like you may have a problem with your OS X install - or you're including the launch of a dozen heavyweight pro applications and Classic, which isn't really fair (actually, including Classic might be, but the necessity for that is already becoming increasingly rarer).

-chris.

[Jelle Monkmater]

Originally posted by godzookie2k:
<STRONG>
No, this doesn't occur on an iMac, but on a dualie G4 with a gig-o-ram.
</STRONG>

Isn't there an equation that more RAM means longer startup time? We have an NT machine here with 640MB which takes absolutely ages to start, compared to the minutes it takes a similar machine with only 256MB.

As for Macs: my G4 jas 256MB and starts in roughly 2-3 minutes, I think. But since I never shut it down I don't really know. My iBook takes about 2 minutes with no apps starting.

[shortcipher]

Originally posted by Jelle Monkmater:
<STRONG>

Isn't there an equation that more RAM means longer startup time? We have an NT machine here with 640MB which takes absolutely ages to start, compared to the minutes it takes a similar machine with only 256MB.

As for Macs: my G4 jas 256MB and starts in roughly 2-3 minutes, I think. But since I never shut it down I don't really know. My iBook takes about 2 minutes with no apps starting.</STRONG>

the mac performs some sort of memory check upon startup, so the more RAM you have, the longer it will take. You used to be able to switch this check off under OS9, dont know about X though.

[Drizzt]

When you see the happy Mac at boot time, with OS X, it's done..

(I mean.. the RAM check thing is done.. well.. you know.. )

[ducasi]

Originally posted by Gee4orce:
<STRONG>Going back to the original article....
</STRONG>

Indeed, getting back to the point, I'd say the major flaw with the article is that many of the assumptions the author makes about Mac OS X are wrong.

OK, some are trivial - Mac OS X does not ship with IE 5.5 - but, for example, he makes serious mistakes when comparing the Be file system to HFS+.

He spends a lot of time putting down the Mac's file system, while not actually understanding it properly. HFS+ supports large files over 4GB - it uses 64 bits for the file length - this isn't a hack stuck on, this is by design. HFS+ also supports additional attributes for files (though there is little support for this in any Mac OS.)

Another point he makes is how easy BeOS supports new file systems with "add-ins". Mac OS X also supports file-system plug-ins - adding NTFS or ext2fs would be easy, all it takes is for someone to write the plug-in.

He's also wrong about AppleScript. AppleScript's foundations (the Open Scripting Architecture) allow other languages to be used rather than AppleScript itself. So, the system is open to other languages.

Some of the things he complains about in Mac OS X are rather subjective, like he doesn't like the case-insensitive, case-preserving file system -- which Windows copied, btw. This is a feature - not a bug!

A lot of the user interface areas he complains about are simply part of the Mac experience, and cannot be changed now - OK, this is part of his point, but he shouldn't expect any changes here, and he shouldn't bitch that Apple should have done it differently.

Good grief - he hasn't figured out how to add a comment to a file in the Finder - he seems to think it isn't possible.

He fails to understand the benefits of the creator codes attached to files... In fact, he regards this as a mis-feature. Well, when I'm editing some html files with BBEdit and some with Dreamweaver, I'm sure glad of them.

Over-all the article gives a good insight into some aspects of BeOS that other systems could take inspiration from, but as a comparative review it's pretty poor.

[Juggler]

The mentioned article is very positive about Mac OS X, but it also fairly points out some aspects where OS X still lags behind.

Overall, I'm happier than a pig in shit [after having switched to OS X]. What could I possibly find to complain about?

Whereas BeOS is renowned as one of the fastest and most efficient operating systems ever designed, OS X may well be one of the slowest. Problems with performance and efficiency in OS X have been discussed ad nauseam all over the net, but the BeOS user feels this contrast more acutely than most, because the BeOS user has been so completely spoiled by the amazing speed of BeOS.

...The fact of the matter is, BeOS on a Pentium 233 with 64 Mbs of memory is faster than OS X is on this so-called supercomputer. The Mac's CPU is roughly 8x faster and the machine is stocked with 10x more memory, but the BeOS machine out-performs the Mac. BeOS boots faster, applications launch faster, windows resize more smoothly, you can play more simultaneous audio and video clips without affecting system performance.

...Try this: open a Terminal window (instantaneous on BeOS, a few seconds on OS X) and run "top." Then resize its window. The resize operation is clunky and blocky. Now try the same on a far lesser BeOS machine -- the resize operation is silky smooth, even if several CPU-intensive processes are going on. I even tried this on a dual 800 at MacWorld Expo, and found the same chunky resizing behavior. Now launch four QuickTime movies and get them all playing at once. Move them around on screen, and resize them while playing. Try the same on a far lesser BeOS machine. The difference is night and day.

(Excerpts from section "The Bad and The Ugly" from the mentioned article.)

- Juggler.

[ 12-22-2001: Message edited by: Juggler ]

[Big Mac]

I'm only through about 1/5 of Hacker's treatise, but I can tell from the commentary so far that he really likes the OS and is straining to find negative points. But in the spirit of nitpicking, I'm going to voice what I consider to be the most problematic aspect OS X computing as it stands today: the lack of quality of a great number of Carbon applications.

OS X is the best system software on the planet, and while we do indeed know of places where it needs to mature, I'm confident that Apple will address the most nagging smallish concerns we have. (Maybe not meta data - that's my second biggest concern.) The thing that really bugs me is so many Carbon ports are junk. They just don't work properly.

I don't know whether this is symptomatic of the APIs needing to mature, or if it's just poor programming on the part of a lot of teams, but no one can deny that these Carbon apps just don't perform the way the should. And just so I don't get any friendly reminders, yes I do understand that crappy software can be coded in any environment - Carbon, Cocoa, Java. Yet, I haven't found a Cocoa based application yet that I've found to be inherently flawed, whereas several Carbon apps come to mind in that classification.

So, while arguing over filenames makes for really interesting and informative debate, I'd love to know people's thoughts on why Carbon applications in general are just poor performers. I do know there are exceptions - the Starcraft OS X patch, for example. Yet, as more and more of these shoddy attempts come down the pike, I can't shake the feeling that Carbon is half baked. Please prove me wrong.

[theolein]

Originally posted by ChaChi Boy:
<STRONG>

Bla bla bla. Save it frenchy and go use the DEAD BeOS then.</STRONG>

Vraiment amicable, ce con.

[theolein]

Originally posted by Jelle Monkmater:
<STRONG>

Isn't there an equation that more RAM means longer startup time? We have an NT machine here with 640MB which takes absolutely ages to start, compared to the minutes it takes a similar machine with only 256MB.

As for Macs: my G4 jas 256MB and starts in roughly 2-3 minutes, I think. But since I never shut it down I don't really know. My iBook takes about 2 minutes with no apps starting.</STRONG>

At my last job my Win2k machine would take about 5 minutes to boot. There was some problem in geting it's profile over the network. But also at the job before that the NT box I was on would also take a good 5 minutes to boot. BUT, I don't think boot time is a good thing to compare OS's anyway. I found Win2k on the whole to be pretty good and stable OS and faster in terms of response than OSX. But for web work I like OSX more.

But all this pissing in the wind about "My OS is better than yours" is a real waste of time anyway. What I don't like about Windows is the company that makes it, not the OS itself.