BeOS Engineer to Apple

The Register USA www.theregus.com is reporting today that Dominic Giampaolo, who wrote the file system for BEOS was hired last week by apple to work as a file system engineer. Does this mean that apple might be working on a big surprise? Maybe for the update after 10.2?

i don't see that anywhere on theregus. do you have a link??

Here's the link. Good article.

http://www.theregus.com/content/4/24485.html

"while Dominic, we are delighted to learn, has subsequently joined Apple as a file system engineer. He started last week.":cool:

If Apple can overhaul their filesystem, that would be incredible!! Also, they have to make it work right. Unlike the way M$ doing it....


With Dominic at Apple this really increases our chance of a evolutionary file system happening.

Anyone out there ever used BeOS and tried out queries on the filesystem??

Matthew

With Be they had *zero* legacy to support. Everything they did was new in the context of a computer OS. The engineers did come from UNIX and Mac/Windows and knew how they worked (or didn't) and so they set out to do something COMPLETELY different.

Apple cannot do this because they have a decade of legacy to support and millions of existing customers with tens of millions of disks all in legacy Mac formats (or DOS or UNIX or whatever).

This is primarily why Rhapsody was an utter failure; throwing out ALL legacy for the sake of the future appealed to no one outside of Amelio/Hancock who actually had to make apps for and use the Mac computer.

Mac OS X definately with its substantially extensible inner core has a better advantage to move past its legacy baggage than Windoze. The file system is abstracted and layered all to hell to read Mac disks and whatnot already in Mac OS X. Journaling as default shouldn't be too far off esp. for a more robust server-capable OS that Mac OS X begs to be.

Mac OS X 10.x is just the transitional phase, the real advanced stuff has yetto come. I'd rather Apple be on time than 10 years ahead of everyone for the upteenth time technology-wise. Newton anyone?

I can't see Apple just making the switch right over into a journaling file system given the difficulties that this would impose (transition). But if I had to pick one person on the earth to go work at Apple's file systems group, it would easily be this man, creator of perhaps the most advanced filesystem ever implemented. Whatever he can lend, however subtly it will affect the OS, it will be a positive thing.

blakespot

Originally posted by Sayer
With Be they had *zero* legacy to support. Everything they did was new in the context of a computer OS. The engineers did come from UNIX and Mac/Windows and knew how they worked (or didn't) and so they set out to do something COMPLETELY different.

Apple cannot do this because they have a decade of legacy to support and millions of existing customers with tens of millions of disks all in legacy Mac formats (or DOS or UNIX or whatever).

This is primarily why Rhapsody was an utter failure; throwing out ALL legacy for the sake of the future appealed to no one outside of Amelio/Hancock who actually had to make apps for and use the Mac computer.

Mac OS X definately with its substantially extensible inner core has a better advantage to move past its legacy baggage than Windoze. The file system is abstracted and layered all to hell to read Mac disks and whatnot already in Mac OS X. Journaling as default shouldn't be too far off esp. for a more robust server-capable OS that Mac OS X begs to be.

Mac OS X 10.x is just the transitional phase, the real advanced stuff has yetto come. I'd rather Apple be on time than 10 years ahead of everyone for the upteenth time technology-wise. Newton anyone?

Okay, if the "problem" is legacy systems, the support for that can simply be programs and drivers. Not direct OS. Drivers are used not by PowerPrint and Hayes. In theory UNIX is designed and set up to interface with EVERYTHING. In theory one could add a PCI card to any Mac and add parallel port, ISA, PS2, Serial, PCL, composite video.

Once the "resource" is available to chooser or a super chooser, then it should be accessable by any compatible application. The purpose of the driver is to make it as accessable to as many apps as possible.

Rocketman

Once the "resource" is available to chooser or a super chooser, then it should be accessable by any compatible application. The purpose of the driver is to make it as accessable to as many apps as possible.

This is a somewhat flawed generalization. It is true that UNIX is designed to be able to communicate with hardware, viewing it as a file. But just because UNIX can see it does NOT mean it can interact with it. In order for communication to take place, the software driver must be in place to setup rules and pipes for communication between the kernel and the hardware.

For example, if you add a network card to the system, it doesnt automatically work because UNIX can see it. No matter how many "compatible" apps there are for the network card, they would not be able to access its resources unless there was a piece of software telling it how to communicate and which protocols to use. The network card does not connect to the internet, the driver does. Hardware is hardware is a resource and cannot do anything without being told so.

Then the software asks the kernel for the internet, and the kernel, using the driver, sets up communication.

The reason all of this is relevant is the sheer amount of legacy hardware to be supported will be staggering at best.

How much that man would be making now?

Somebody mind summarizing or pointing us less informed folks a a link that offers the pros and cons of a journaling filing system.

Thanks,

Eirik