1) As much of a moving target Win32 is, OS X is even more so.
2) WINE runs apps not available on Linux. What Mac apps are you going to run which aren't available on Win32?
3) There hasn't even been an open source implementation of the QuickTime API. How the heck are you going to support Mac apps which frequently mix Carbon/Cocoa/QuickTime/CG/HDI code?
Only a matter of time before you can run OS X on unsupported hardware with buggy unsupported drivers and Apple gets inundated with tech support calls and bad press....
What the hell do you mean by that? NuBus-based Macs indeed had configurable settings in PRAM (NVRAM). You could set the time zone, the boot disk, and the speaker volume for example.
I would like Carbon support the most, however I'm not sure how to implement FSRefs on other filesystems.
I don't know how Apple even does it. AUX did it by maintaining a/etc/FileIDSs file which associated FileIDs with paths (which was less than ideal for a lot of reasons).
Firstly I'd like to apologize for acting like some ass with tourette's syndrome.
Secondly the problem is the roles are in reverse. The FileID is like the path in UFS. You don't have a situation where multiple paths can point to one FileID because the path is more like a file attribute. In other words the FileID (or CNID) has a path, not the other way around.
On UNIXish filesystems it's the path which has the inode, not the other way around.
Slashdot Mirror
This is like two bald men fighting over a comb
Sweet? Leaves a bitter taste in my mouth. Two undigestible dead syllables just lying there.
Macintel has the same rhythm as Macintosh.
Won't happen.
1) As much of a moving target Win32 is, OS X is even more so.
2) WINE runs apps not available on Linux. What Mac apps are you going to run which aren't available on Win32?
3) There hasn't even been an open source implementation of the QuickTime API. How the heck are you going to support Mac apps which frequently mix Carbon/Cocoa/QuickTime/CG/HDI code?
Macintel dammit, not Mactel!
Only a matter of time before you can run OS X on unsupported hardware with buggy unsupported drivers and Apple gets inundated with tech support calls and bad press....
Or maybe not.
I hope it doesn't push Apple into using TC.
Do you even read what you post? Does that number even look PLAUSIBLE?
You probably meant 4.7Gs
Yes, which is why everybody is running OPENSTEP right now.
More like less standard.
It won't be Open Firmware, it won't be BIOS...
Don't forget multiply add
You get an F in history mate.
Hitler was in it for a higher purposes as well, some of them now reflected in the green party of all places.
I once converted a cordless phone into a wireless internet connection using modems.
I wouldn't challenge that terminal to a battle of wits if I were you
If the .NET code access files by path then you have a problem already.
Part of the problem is Sun wants the programs to behave the same on all platforms, which defeats the whole point.
Why the hell would I want to help Sun anyway?
I read some reviews of VAST which suggest huge gains are likely with many algorithms without any redesign in code.
No telling how well Apple's implementation will be of course.
No.
U-Boot only exists because an open source OF implementation did not.
...and not even configurable
What the hell do you mean by that? NuBus-based Macs indeed had configurable settings in PRAM (NVRAM). You could set the time zone, the boot disk, and the speaker volume for example.
A week or two? What, if you don't know what a computer is at day1?
I would like Carbon support the most, however I'm not sure how to implement FSRefs on other filesystems.
/etc/FileIDSs file which associated FileIDs with paths (which was less than ideal for a lot of reasons).
I don't know how Apple even does it. AUX did it by maintaining a
Firstly I'd like to apologize for acting like some ass with tourette's syndrome.
Secondly the problem is the roles are in reverse. The FileID is like the path in UFS. You don't have a situation where multiple paths can point to one FileID because the path is more like a file attribute. In other words the FileID (or CNID) has a path, not the other way around.
On UNIXish filesystems it's the path which has the inode, not the other way around.
Aqua isn't a library. It's a specification nobody seems to follow.
Quartz isn't necessary to run most Carbon apps. I'd start there.
You dont' move a file to another volume, you copy a file to another volume. Sheesh
And it is NOT an inode! And before you even say it, it isn't a file descriptor either.
In short Unix has something exactly like FileIDs
BULLSHIT!!!
FileIDs are not inodes. They are NOT equivalent as I pointed out elsewhere.
NOOOOOooooooooo....
I have no idea, you'll have to ask the author.
If you have multiple files or directories referring to one file that sounds more like an inode than a FileID.
BFS also lacks many of these things, most notably FileIDs.
I hope he's working on HFS++ instead of some BFS port.
BTW filename extensions still suck...what was Apple thinking?