Apple released today MacOS 9.2.2 and the upgrade is available fo download. The new version improves Classic application compatibility in MacOSX and delivers updated support for Macintosh systems that are based on the PPC G3 or G4 CPUs. MacSlash also reports that “John Siracusa, author of many great in-depth articles on OSX at ARSTechnica has begun a petition to try to convince Apple to continue using metadata in the filesystem. Basically, without the metadata OSX relies on file extensions to know what type of document each file is, just like Windows. For a more in-depth explanation read John’s ‘Metadata, The Mac, and You’…” Sign the petition.In other MacOS news, Connectix has released an updated version of Virtual PC. Some notable features include support for MacOSX , multiple processors (on MacOSX), DVD mounting, ISO image mounting, and undoable drives. Also includes improved networking and bug fixes. The software, which supports both Mac OS 9 and OS X, comes in separate versions for PC-DOS, Windows 98, 2000 or XP. The PC-DOS and Windows 98 versions are available immediately; the others are not expected to go on sale until late December. Besides running Windows within Mac OS 9 or X, Virtual PC 5 lets people drag and drop files between the operating systems. An upgrade costs $79. The full PC-DOS version sells for $99, while the Windows 98 version costs $199.
MacOS 9.2.2 Released
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
If Apple were only humble enough to adopt the BeOS file system, it would solve almost all of the filetype problems.
http://www.beosbible.com/exc_filetype.html
and lots of it…
Metadata is the consept of data thats is NOT the data (attributes are just BeOSes name of it’s implementation).
but yes, it would be nice if MacOS X used a BFS-a-like, hell all OSes should use a BFS-a-like.
I’d kill for attributes (free-form-metadata) and live-querys under linux when writing webpages, no more .dat’s and other nasties…
CXFS or XFS from SGI. They have imho the Best feature set for FS,and they’re the most proven with JFS (I doubt IBM would licence such thing).
XFS is Open sourced now,I see no reason why Apple can’t use it.
It’s GPLed, so they should licence the XFS’s sources used to create CXFS in order to be able to integrate XFS into Darwin. Apple does not mix GPL with APSL licence code. SO in order to use XFS apple needs to license it from SGI, that simple
It’s GPLed, so they should licence the XFS’s sources used to create CXFS in order to be able to integrate XFS into Darwin. Apple does not mix GPL with APSL licence code. SO in order to use XFS apple needs to license it from SGI, that simple
I hope SGI licenses it for $0 or very little dollors.
Nice to see that the “world’s most advanced operating system” is moving backwards in time by removing innovative filesystem features in favour of old school DOS and UNIX “features”.
I’ve very impressed, Apple. Bravo!
Maybe MacOS 11 can return us to the days of 8-character filenames with 3-character extensions.
– chrish
I hear MacOS 11 is going to be terminal-based. Talk about eye-candy! 😮
Maybe I still need to learn more about MacOS X.1, ( I managed to install it on a 7300/604e!) and OS9. Doesn’t the meta-data dictate what program the file needs to be opened with ? When I try to open a normal jpg, it will say the program used to create the file is not available. Isn’t this metadata preventing me from using a standard picture viewer program? Or do I have to load the viewer, select ‘open’, find the file, etc. I think the BeOS method works the best though, first tries to find the preferred app, and if not, then look at the extension.
As a Mac users since the twentieth century (1990, to be precise), this “dumbing down” of the file system to rely on extensions instead of resource forks is inexplicable. Apple’s big problem in the past (well, one of them) was that they were too far ahead of the curve (e.g. The Newton was a great device; they just couldn’t get the size and price down to a level needed to achieve success). Now they are embracing standards, and that is a “GOOD THING”, but they need to be willing to still lead from time to time, instead of just following normal practices. I see the value, as a web designer of attaching “.jpg” to JPEGS, but I see NO value to attaching, say, “.doc” to “Doc’s”, unless you are genuinely intending to share them with Windows types.
I think that perhaps it is wise to include extentions, but rather than just leave it at that, perhaps apple could look at a way to make use of them that will maintain compatability with windows and Unix but also give an advantage to them……..I am sure they are looking at somthing along these lines, just give it time, you have to start somewhere.
this was posted by Dundou(sp?) on macslash about the petition and OSXs metadata support.
The problem with Siracusa’a petition is that many of his suggestions have already been implemented or attempted by Apple.
Application bindings are already totally configurable by the user–both globally and on a file-by-file basis. If an appropriate icon is available, the file icon will change to match those preferences. This system and interface is vastly superior to the classic style creator code system. To boot, this custom binding information is stored as metadata in each file (or in a funny hidden file on UFS systems–not ideal, but it works).
Apple recommends HFS+ as the default for all systems (except *nix development setups which stupidly rely on case sensitive file names).
Users can have full control over full file names at all times (Finder Preferences->Always show extensions, or Show Info->Name and Extension).
File types and creators are still fully supported and given maximum priority by the system, except when overridden by user-configurable bindings.
A globally configurable interface for metadata-to-extension conversions and a so-called metadata framework existed in OS 9 as the File Exchange control panel and APIs. The idea of automatically typing incoming and outgoing files with this interface was a good one, both on Apple’s part then and on Siracusa’s part now, but in reality the scope of the service was limited by terrible Application support (*cough* Internet Explorer) and the general ambiguity of when such conversions should take place (resulting in the hated “????” phenomenon when downloading certain files). The general network transparency of OS X would make such a service, while nice, almost impossible to implement.
His other more “radical” suggestions while nice, also have huge feasibility problems: moving to a new filesystem would create numerous irritating conversion and formatting problems for existing data, plus a whole new set of issues concerning conversion of journaling attributes when transferring between new drives and legacy HFS+ drives–this would be orders of magnitude more difficult than the relatively painless HFS to HFS+ transition a few years back. His phrasing on how to accomplish this whole step is especially vague:
Transition Mac OS X’s “native” metadata representation to one based on the new volume format and new metadata standards. Deprecate HFS/HFS+, type/creator codes, and other vestiges of classic Mac OS (while providing easy translation to and from that representation via the metadata frameworks, of course).
Easier said than done.
His only suggestion that makes a lot of practical sense is to restore the requirement of HFS file type generation as a standard application function, and to remove any system dependencies on file extensions. This, if combined with OS X’s already very flexible and intuitive typing and binding system would create a more functional system without sacrificing existing compatibility.
just though this could be useful to the discussion.
<blockquote>I hear MacOS 11 is going to be terminal-based. Talk about eye-candy! :o</blockquote>eye-candy? Talk about frame-rate!
MacOS XII has support for punch card readers
When I try to open a normal jpg, it will say the program used to create the file is not available. Isn’t this metadata preventing me from using a standard picture viewer program?
***(Whoops, pressed the wrong button…SORRY!!!!)***
gsc wrote: “When I try to open a normal jpg, it will say the program used to create the file is not available. Isn’t this metadata preventing me from using a standard picture viewer program?”
If done correctly, it shouldn’t. Take BeOS for example, which uses metadata. When I double click a jpeg or other image file, the MIMEtype image/jpeg is associated to open with the image viewer by default. I’d have to right-click and use “Open With…” to have an image loaded into, say, Gobe Productive’s image editor. Or, I’d have to load Gobe first and load the image from there.
I think this concept is independent of whether an OS depends on metadata or not. It’s just a matter of picking a default program to launch, be it a simple view or a full-blown editor.
On my fiance’s Mac with OS 8.6, however, clicking a jpeg will load PhotoShop by default, even if you just want to view the image. Talk about overkill