Single "application suite" process vs group of normal apps?

[amn]

Hi all,

I am new here. I am into operating systems and operating system concepts.

Now that that is out of the way, i was wondering (aren't we all).

If we assume a software developed by a group of a tightly teamed developers, say in a company like Google, Adobe, Apple or Microsoft, software that decides to do a lot of small things - an "application suite", sort of. Assume that this software is in a form of a single process that runs many of different tasks of this suite, like calendar, web browser, email, etc, a bit like what GMail and Adobe Creative Suite has grown to be, but not in a web browser like the former, but rather as a desktop application, like the latter. Now the key question itself, would you under any circumstances consider it to be advantage in terms of resources for this software to run better as that single process, designed, developed and compiled by this tight team of devs, rather than having a group of not-related (in terms of development teams) processes all functioning in their own way, with potentially their own little memory management schemes, frameworks and libraries?

I would say a single process that incorporates a lot of functionality in a modern OS like Linux or Windows is a big advantage for a number of reasons, except of course the mere fact that it is hardly modular, and you depend on a single developer to deliver a whole group of applications contra having the possibility to use different products as you may wish. But this is MY opinion.

I would like to know yours.

Thanks, and I must say this is a useful board, many knowledgeable people here as far as I could see scooping around here for some time.

[01000101]

As long as the kernel design was modular, I would deffinately agree with the 'application suite' being developed as one core process. The modularity would allow upgrades/patches to be able to take effect on that application (as opposed to trying to upgrade/patch the kernel itself everytime that application needs servicing).

Application suites that work as a single program often utilize the internal resources of all the little programs better than say... a bunch of individual little programs. Also, because they are programmed that way, it is probably safe to assume that they have optimized inter-functionality and probably work much better interleaved than as seperate programs.

Take Apple's iMail, iAddress(?), iCalender for instance. They all are seperate mini-programs that are tightly wound together, and they work beautifully together as far as communcations. Say you update an address/email/phone in iMail, the rest of them will follow suite, this is great functionality that complete seperate programs would have trouble mimicking.

[geppy]

Now the key question itself, would you under any circumstances consider it to be advantage in terms of resources for this software to run better as that single process, designed, developed and compiled by this tight team of devs, rather than having a group of not-related (in terms of development teams) processes all functioning in their own way, with potentially their own little memory management schemes, frameworks and libraries?

On multi CPU machines I would go for separate process for each app because they may well work faster here regadless if that takes more resources(which it is).
On single CPU multiple processes likely to be slower than single process with asynchronous code organization. Gotta remember though that OS needs to provide decent means of creating and profiling such asynchronous code. But code needs to be virtually bug free because if process fails - all apps fail (great examples are: any web browser where you open multiple windows and go to website that exploits some vulnerability, or "explorer.exe" which you can kill using task manager and enjoy results)

[JackScott]

Take Apple's iMail, iAddress(?), iCalender for instance. They all are seperate mini-programs that are tightly wound together, and they work beautifully together as far as communcations. Say you update an address/email/phone in iMail, the rest of them will follow suite, this is great functionality that complete seperate programs would have trouble mimicking.

Don't forget Outlook though... it's even more tightly integrated than that.

The thing that annoys me is though, when you have two seperate programs to do the same thing, but with different functionality. For instance, the load time of Windows Mail is virtually nil compared to Outlook, but only Outlook will synchronise with my fancy phone. And switching between the two is difficult, because the contact list (Windows Contacts) and calendars (Windows Calendar) don't auto-update into Outlook. Now THERE is something that pisses me off.

I'd argue the best design is to integrate the data structures into the operating system: like Windows Vista has attempted to do with mail, contacts and calendar. Then all the other apps just work with those data structures. Because to do anything else is to be silly.

$0.02

[amn]

Thanks guys. Now that I have your precious opinion data, I will write a post shortly, where I will present you with some smart schemes, and surprises. The question was asked so we could move on to step 2 of my little theory. The implementation of the theory might be of use on this board, and to OS development in general, although I by no means think it is anything new or untried. It might just be right for the time and the place. But, I need some time to cook up the post, so laters

Meanwhile, please add your meaningful answers


By the way, keep in mind we are talking about a SINGLE PROCESS vs multitude of processes on a modern OS, with more or less todays hardware, and say one and a half physical CPU/core. Hehe. The point about crashing a single process taking down with it whole suite or windows (like IE on Windows) is valid indeed.

I really doubt the iCal, iMail and iCalendar are really one iProcess. I am pretty sure they are separate processes, and even though you are right about the advantage them sharing data structures and being quite synchronized in terms of GUI and functionality they offer, it is not really on-topic, although interesting.

Also, it is certainly an advantage when different components can understand each others data, which is why it may be a good thing for the OS to serialize and deserialize data, like email addresses etc, like you said. In fact, our filesystems are rather ancient, because they allow applications to store data in files, but since each file may potentially be own proprietary format, or variation of a public format, a such variation that makes deserialization impossible for another application, in reality our apps do not interact much. Microsoft was once touting the WinFS, which is basically filesystem-on-database (or database-on-filesystem, will never know), but the project was unsurprisinly scrapped, since Microsoft innovates only on paper mostly. However, the idea is not new. Our filesystems will slowly migrate to become database system, where any application, given permissions may retrieve and possibly alter any data on disk, with data retaining structure.

-amn.

[Craze Frog]

Take Apple's iMail, iAddress(?), iCalender for instance. They all are seperate mini-programs that are tightly wound together, and they work beautifully together as far as communcations. Say you update an address/email/phone in iMail, the rest of them will follow suite, this is great functionality that complete seperate programs would have trouble mimicking.

That doesn't mean they don't run in different processes.

[amn]

Ok, what are the advantages of having multiple processes, i.e. a group of applications from different vendors not participating in any kind of "suite"?

I can think of only two:

1. Different vendors reduce end-users dependency on a single vendor which would create monopoly-like environment, not to mention same sort of bugs in the application, and possibly even "suite-wide" bugs. Also by default any suite will be by nature immodular, and that is a clear disadvantage if you ask me. Having a swarm of multiple small separate tools that are connected one way or another, f.e. like piping in Unix, is a very good idea that proves itself very well in the world of Linux today. You can replace any part, provided you maintain the interfaces in between.

2. Resource isolation and protection in case with multiple processes in a modern OS, although it is debatable whether it is an inherent advantage, as I believe it can be done without CPU assistance and thus CPU assisted task switching, memory protection etc. More on that later.

I honestly struggle to come up with more clear examples of advantages with using multiple processes versus a suite style applications. Which in no way indicates my preference towards either, I am just trying to map out factors and issues, and I think together it is easier to think...

[bewing]

It reduces the temptation for the suite developer to create proprietary formats.