Amiga.org
Amiga computer related discussion => General chat about Amiga topics => Topic started by: sim085 on June 30, 2010, 11:02:26 AM
-
Hi,
I was reading the AROS FAQ and came accross the following;
Several hundred Amiga experts (that's what they thought of themselves at least) tried for three years to find a way to implement memory protection (MP) for AmigaOS. They failed. You should take it as a fact that the normal AmigaOS will never have MP like Unix or Windows NT.
So why is it so hard to have memory protection for the Amiga? Is there anywhere where I can read more about this?
-
So why is it so hard to have memory protection for the Amiga? Is there anywhere where I can read more about this?
It's due to the way the "kernel" was designed. I think this post sums it up pretty good:
http://groups.google.com/group/comp.sys.amiga.advocacy/msg/7d0bf445a2c22d67?hl=en& (http://groups.google.com/group/comp.sys.amiga.advocacy/msg/7d0bf445a2c22d67?hl=en&)
-
So in other words memory protection is not possible to implement because the developers of these operating systems (AROS and AmigaOS) want the OS to be backward competible (allow software from 3.1 to run) right?
-
basically yes. Mp would break all existing software
-
It is not just that it breaks existing software. It is not possible implement memory protection without complete redesign of API.
-
So if they drop backward compatibility and decide to re-do the kernel then they can include memory protection right!? Or there is something in the AmigaOS philosophy that still makes this a hard task to achieve?
-
So if they drop backward compatibility and decide to re-do the kernel then they can include memory protection right!? Or there is something in the AmigaOS philosophy that still makes this a hard task to achieve?
Well there was as chance with both MorphOS and OS 4.0 to make a clean break and sandbox 3.X apps, and make new API's and basically start over fresh.
Both approaches didn't do that, however, probably to maintain backwards compatibility within the older applications. Plus, defining all new API's is basically re-writing everything from scratch. Maybe that was too much work given the available budgets and resources.
If it was me, and I had unlimited resources and time, I would sandbox legacy apps and start with a clean slate, adding features like SMP, etc.
-
Well there was as chance with both MorphOS and OS 4.0 to make a clean break and sandbox 3.X apps, and make new API's and basically start over fresh.
Both approaches didn't do that, however, probably to maintain backwards compatibility within the older applications. Plus, defining all new API's is basically re-writing everything from scratch. Maybe that was too much work given the available budgets and resources.
If it was me, and I had unlimited resources and time, I would sandbox legacy apps and start with a clean slate, adding features like SMP, etc.
Yup. I seriously wish AROS had done this.
-
If Apple can move from OS9 to OSX with compatiblity for OS9 applications (IIRC, it is in an emulation layer, but compatible none the less,) then...
-
If Apple can move from OS9 to OSX with compatiblity for OS9 applications (IIRC, it is in an emulation layer, but compatible none the less,) then...
From the wiki page on the history of MacOS X:
http://en.wikipedia.org/wiki/History_of_Mac_OS#Mac_OS_X
"...This is a compatibility layer in Mac OS X (in fact a Mac OS X application, originally codenamed the "blue box") that runs a complete Mac OS 9 operating system, so allowing applications that have not been ported to Carbon to run on Mac OS X. This is reasonably seamless, though "classic" applications retain their original Mac OS 8/9 appearance and do not gain the Mac OS X "Aqua" appearance."
So, it looks like they basically sandboxed older apps, and in fact the entire OS 9 to run on top of MacOS X. Sort of like runnine E-UAE now on OS4, or WinUAE on Windows, although they made it appear more seamless, I think.
-
If Apple can move from OS9 to OSX with compatiblity for OS9 applications (IIRC, it is in an emulation layer, but compatible none the less,) then...
Yeah and that particular implementation was REALLY well done IMO... I have often hoped that the new version of AmigaOS would include support for multi-processors as well as good memory protection... It would really be nice since a rewrite of the OS is required to implement these items, then add these items and provide a modern OS providing backward compatibility similarly to the OS9 support model used by Apple...
Sadly, I doubt this will ever happen and we will continue to have two very different camps with different goals...
-
@outlawl2
Well there are more than 2 "camps" if you wish to use that terminology :)
1) Classic users
2) OS4 users
3) MorphOS users
4) AROS users
5) Emulation users (amithlon/winuae)
6) Other (users of minimig, NatAmi), sort of classic users
Of course, many people are a mix of some or all of the above ;)
-
That is true, but most of your abovementioned flavors were created with one of two things in mind.. Either:
Backward compatibility (MorphOS, Emulation users.)
Or
AmigaOS for the modern world and modern hardware. (supposedly) (OS4)
-
I think many users wanted backwards compatibility, thus you see the limitations on the modern incarnations of OS 3.x today. Done that way probably because it would have taken too much resources to do it the way Apple did.
-
It is not just that it breaks existing software. It is not possible implement memory protection without complete redesign of API.
I disagree here. I think it would be possible to have minor changes to the API and provide memory protection to programs that follow certain policies. By the latter I mean no data allocation on the stack that has to publicly available, obey the MEMF_PUBLIC/MEMF_PRIVATE meaning, etc.
Programs could in the executable or during start-up indicate that they follow these policies (with the consequence they may be killed when not following them). Programs not having this indicator won't be able to have MP.
For this to work you have to implement a MP that fits with the Amiga API. This means not trying to enforce the Windows/Linux MP with address spaces for each process/task but getting your inspiration from single address space operating systems and similar systems.
The main extension of the API would consist in extending the memory pools API so programs can indicate which other programs may access certain memory pools in read and/or write mode.
greets,
Staf.
-
@Fats
Such MP would be quite pointless to be honest (any non-MP app could easily nuke the whole OS or other apps, including the MP aware ones).
How would the OS know if the caller if MP aware? What about 3rd party libraries the app might use? (remember that with AOS library stuff executes directly at the callers context). If one thing would use the flags wrong it'd lead to very hard to spot bugs.
You also forget that in order to have MMU access limitations to certain memory areas they need to be aligned by page size (start & len). With a shared global memory space OS this leads to massive address space fragmentation. And not all memory is allocated via memory pools. In short: You'd need a massive overhaul of the APIs and rewrite the apps anyway.
The issue of MP has been debated for at least 15 years. The best you can get is the mmu.library protected executables. It protects code and read only data. Anything beyond that would require massive overhaul and API redesign, plus app rewriting.
From time to time some individuals come up with claims of generic trouble free MP for amigaos. Needless to say none of them have ever delivered. Some nameless OS even falsely claims to have MP while it really doesn't. Hint: The same OS was supposed to get automatic stack enlargement.
-
Windows may have memory protection since XP (as well as all versions of NT of course but that's not a desktop OS) BUT Windows still gets ass raped at the mere sniff of a TCP/IP connection so why is it so important?
-
Windows may have memory protection since XP (as well as all versions of NT of course but that's not a desktop OS) BUT Windows still gets ass raped at the mere sniff of a TCP/IP connection so why is it so important?
(http://www.lolblog.co.uk/wp-content/uploads/2009/08/doublefacepalm.jpg)
-
@Amiga_Nut
(http://static.rcgroups.com/forums/attachments/2/7/7/9/3/9/a2926156-219-Facepalm%20jesus-facepalm-facepalm.jpg)
-
@Fats
Such MP would be quite pointless to be honest (any non-MP app could easily nuke the whole OS or other apps, including the MP aware ones).
How would the OS know if the caller if MP aware?
You could sandbox all non MP apps into one blob. A simple tooltype or binary chunk could flag an app as MP-aware. A new programs private memory would always be secure. This would apply to workbench and new kernel as well.
But let´s remember. Amiga OS has in the past worked pretty well without memory protection. So as of now it is of lesser importance than some might believe.
-
So as of now it is of lesser importance than some might believe.
I would quickly argue against this point at the very least for security sake.
-
I disagree here. I think it would be possible to have minor changes to the API and provide memory protection to programs that follow certain policies. By the latter I mean no data allocation on the stack that has to publicly available, obey the MEMF_PUBLIC/MEMF_PRIVATE meaning, etc.
Why this MEMF_PUBLIC insanity? There should be no reason why application should use this stupid brainfart. Remove memory usage restrictions and you are closer to real MP.
Of course all software I have written for Amiga allocates data on the stack and never cares about MEMF_PUBLIC. Believe it or not this coding practise works just fine. It works just fine even on Linux and Windows.
Programs could in the executable or during start-up indicate that they follow these policies (with the consequence they may be killed when not following them). Programs not having this indicator won't be able to have MP.
For this to work you have to implement a MP that fits with the Amiga API. This means not trying to enforce the Windows/Linux MP with address spaces for each process/task but getting your inspiration from single address space operating systems and similar systems.
It could be done using UAE kind of solution. Run every program in its own sandbox.
The main extension of the API would consist in extending the memory pools API so programs can indicate which other programs may access certain memory pools in read and/or write mode.
This is only minor detail. It does not fix the OS.
-
With a shared global memory space OS this leads to massive address space fragmentation.
You can alleviate that by virtualising the address space, although that causes other problems.
-
Windows may have memory protection since XP (as well as all versions of NT of course but that's not a desktop OS) BUT Windows still gets ass raped at the mere sniff of a TCP/IP connection so why is it so important?
I ran NT4 as a desktop OS, then switched to windows 2000.
Back then it was no more vunerable than any other OS.
These days I wouldn't trust any other desktop OS.
-
You can alleviate that by virtualising the address space, although that causes other problems.
Indeed. The amiga APIs (and thus apps) are full of dependencies of single global memory space (you can add tons of various caller passed structures to system for instance, say PutMsg().. the struct Message will be added to foreign struct MsgPort. There are no strict rules how to allocate either. Many apps allocate them from stack, and that is perfectly legal with AmigaOS). It'd never work... Unless if you redesign the whole API, which in this plan was supposed to be avoided.
-
The funny thing is that Microsoft team had similar problem in Windows 3.x era and they did it solving all those problems. It's a common knowledge and in era of virtualization support in modern CPUs this should even not be discussed further but just be done. I can't imagine any commercial OS for home users or for business without MP today. I can think of some uses in embedded market without it and people are still using DOS today so in a long run you can live without it, but than you are filling niche in dying market.
-
The funny thing is that Microsoft team had similar problem in Windows 3.x era and they did it solving all those problems.
To be fair DOS virtualization is trivial compared to AmigaOS.
-
To be fair DOS virtualization is trivial compared to AmigaOS.
True. I don't compare DOS with AmigaOS but with Windows 3.x problem - mind you that they even had problem with different types of memory to solve which protected mode helped to fix. Anyway my point is that most of issues in term of theory has been solved already and this is strictly implementation problem in terms of producing code. There was a similar case in area of memory allocator when AmigaOS got it's own implementation of slab allocator and swap to make it more advance and efficient (which was a very wise move BTW).
-
True. I don't compare DOS with AmigaOS but with Windows 3.x problem - mind you that they even had problem with different types of memory to solve which protected mode helped to fix. Anyway my point is that most of issues in term of theory has been solved already and this is strictly implementation problem in terms of producing code.
Not really, unless of course if you break the backwards compatibility and run old stuff in a sandbox that is.
There was a similar case in area of memory allocator when AmigaOS got it's own implementation of slab allocator and swap to make it more advance and efficient (which was a very wise move BTW).
Slab allocator (http://en.wikipedia.org/wiki/Slab_allocation) is rather poor generic allocator, and I sure hope it isn't used as one. There seems to be great confusion about this, and everyone seems to repeat the slab mantra without really understanding the fundamentals. Slab cannot be used as a generic allocator, nor is it intended as such. I find it rather surprising that slab has been underlined so much in the new AmigaOS memory system, the actual kernel memory allocator is far more important. The original AmigaOS allocator used First Fit (http://www.memorymanagement.org/glossary/f.html#first.fit) algoritm which was okay for the first couple of minutes of system use, but degraded to crawl after some time. It'd be rather important to know if this has been replaced with something better.
Two Level Segregate Fit (http://rtportal.upv.es/rtmalloc/) on the other hand is way better, as demonstrated by TLSFMem patch (http://www.platon42.de/files/util/TLSFMem.readme) and MorphOS TLSF memory system (http://www.morphos-team.net/tlsf.html). TLSF is a generic memory allocator with constant allocation / deallocation time, regardless of the memory fragmentation.
-
(http://i47.tinypic.com/mc6b11.jpg)
Windows may have memory protection since XP (as well as all versions of NT of course but that's not a desktop OS) BUT Windows still gets ass raped at the mere sniff of a TCP/IP connection so why is it so important?
(http://i196.photobucket.com/albums/aa159/Shriana/JumbotronFacepalm.jpg)
My entire school was running NT in all of the labs. We were using the OS, on a desktop! :roflmao:
There was memory "protection" before the days of NT/XP, but it wasn't nearly as secure/effective. It was still there. sort of.
Come try to ass-rape my windows boxes with a mere sniff. I'm sure you will do your usual and mass facepalms will reign forth, followed by
:laughing::laughing::laughing::laughing::laughing:
-
Windows may have memory protection since XP (as well as all versions of NT of course but that's not a desktop OS) BUT Windows still gets ass raped at the mere sniff of a TCP/IP connection so why is it so important?
-
Back in the day, AmigaOs 3.x lacking memory protection was acknowledged, Theoretically, a lot of bad things COULD and on occasion DID happen without MP ie loss of data, OS being crashed by some rogue process. In reality, few users actually experienced the bad things about not having MP. Programmers (by good programming practices) and users (by saving often) learned to live without MP. Afterall, many fantastic apps, games, art, music, videos, were created on this OS without memory protection-look at aminet for proof of that.
The real threats of compromised security and having your computer taken over remotely, or having malware corrupt your OS are likely to come from taking your Amiga online and a third party executing ( 68k or PPC) commands/code with malicous intent. Yes it IS possible, theoretically, but REALLY how likely is that? I've heard people say "security by obscurity is no security". Theoretically no. In practice when was the last time your amiga got a virus, or had malicous code run on it? In fact, billions of users have a much higher probability of having exactly that happen to them, and millions of PC's are running malware at this very minute, and they're all using an OS that has had MP for a decade or so. I have a feeling this is the point Amiga_nutta was trying o make.
I'd argue, that as a single-user computer, MP on the Amiga hasn't been missed by the users. MP on the amiga is a more or less academic discussion that interests the (few) developers every now and then. IF you want to run legacy 68k software, hell even PPC software, then do it like we always have. Really. Just remember to save regularly.
-
I would quickly argue against this point at the very least for security sake.
Against what, exactly?
-
One more for Amiga_Nut's collection.
(http://jungle.net/tone/tramiel.gif)
-
I'd argue, that as a single-user computer, MP on the Amiga hasn't been missed by the users. MP on the amiga is a more or less academic discussion that interests the (few) developers every now and then. IF you want to run legacy 68k software, hell even PPC software, then do it like we always have. Really. Just remember to save regularly.
It hasn't been missed that much because the users that are still using AmigaOS have largely gotten used to working around it and/or sticking to applications they know are "safe".
It's battered wife syndrome. It "works fine" as long as you tiptoe around and avoid doing any of the many things you know might cause things to blow up, and explain away the bad things.
That works for existing users, who fell in love with AmigaOS when the alternatives had the same problems. Even some of us "returning" users might be able to tolerate it. Not so much everyone else who don't know/understand/care about what things they should not do and what programs they should avoid and so on.
-
MP on the amiga is a more or less academic discussion that interests the (few) developers every now and then.
I wouldn't let any Amiga powered on for weeks with lots of software running and important data unsaved. This isn't an academic discussion...
I wouldn't mind letting powered on MacOSX, Win2K+, Unix opened with lots of important stuff unsaved. Cause unless there was a powercut I know my data would be back when I'll get back.
I don't want to have to choose the software I run because it may make me lose my work... nor do I want to wait before my HD led is off before powering my computer off, nor do I want to have to check I have enough graphics memory before running a (graphics) memory hungry software because the OS isn't capable of swapping: this is the task of the OS, not mine. The OS should (and will) take down any application trying to write outside its memory mapped, the OS should close all apps and power the computer down when no app is writing to the disk, and the OS should automatically swap memory for my apps...
This was acceptable 15 years ago. I think it's not today. Much like monotasking OS isn't acceptable, even for a phone... Would you use some DOS-like monotasking OS today ? don't you think having a GUI or not is an academic discussion ? after all you can do everything you want with just a simple console, right ?
-
Not really, unless of course if you break the backwards compatibility and run old stuff in a sandbox that is.
Something that is actually always preferable. Unless stupid short-sighted 'budget considerations' are ruling it out.
-
I'd argue, that as a single-user computer, MP on the Amiga hasn't been missed by the users.
Nonsense, many users left Amiga due to lack of MP when Internet became "the thing" to do with computers in early/mid 90ies - the lack of MP was also a major reason why Amiga users went on to create Linux and NetBSD for Amiga computers back then.
And as for abusing Amigas online, I know that _I_ have "broken" into remote Amigas that due to malconfiguration and lack of MP meant a lot of fun for me, and maybe not so much fun for someone else. The highlight was to dump prefs files into remote ENV: and watch the confused target rave about his problems on IRC :laughing:
-
You can sandbox and make it work. Somehow.
There are two problems with this:
1. You end up with 1% New World apps, and 99% Old World apps. Doesn't really change much if you mostly use an Old World app? Could get real fast reboots though.
2. There is no echosystem to shift the 1 - 99 balance. (That is what Windows and Apple had. And a firm whip.)
-
@Fats
The issue of MP has been debated for at least 15 years.
Yes, and that's just on the WWW! The usenet debates/flames about Amiga MP and resource tracking went back almost to the beginning. People have been thinking about it for almost a quarter century, and as Piru has pointed out, no one has delivered yet.
-
You can sandbox and make it work. Somehow.
There are two problems with this:
1. You end up with 1% New World apps, and 99% Old World apps. Doesn't really change much if you mostly use an Old World app? Could get real fast reboots though.
2. There is no echosystem to shift the 1 - 99 balance. (That is what Windows and Apple had. And a firm whip.)
If I understand things right, this is what MorphOS did with abox, and look what happened - abox is all there is, and little has changed.
-
Indeed. The amiga APIs (and thus apps) are full of dependencies of single global memory space (you can add tons of various caller passed structures to system for instance, say PutMsg().. the struct Message will be added to foreign struct MsgPort. There are no strict rules how to allocate either. Many apps allocate them from stack, and that is perfectly legal with AmigaOS). It'd never work... Unless if you redesign the whole API, which in this plan was supposed to be avoided.
Back in the day I theorised about having friend processes. Any process that you talk to would be allowed to access any of your memory. However you'd automatically have to become friends with any of your friends friends as they may pass your memory on. There are some things you would have to change to make that work, because anything talking to a filesystem would end up with a lot of friends.
-
Just what the world needs, an OS that behaves like facebook :lol:
-
just what the world needs, an os that behaves like facebook :lol:
farmville-os
-
Just what the world needs, an OS that behaves like facebook :lol:
Facebook isn't that bad. It's more like http://www.imdb.com/title/tt0196217/
-
@Fats
Such MP would be quite pointless to be honest (any non-MP app could easily nuke the whole OS or other apps, including the MP aware ones).
As said in another reply MP programs are protected from non-MP programs. When a non-MP program crashes the whole non-MP space may need to be cleaned-up. Call that a sandbox if you want, but it is different to most other proposals where the amiga(-like) sandbox runs on top of the core system which in my eyes is MP but not amiga-like.
How would the OS know if the caller if MP aware?
The executable is marked, executables without the mark won't be able to get MP. During task switch the OS knows if the task to switch to has MP or not.
What about 3rd party libraries the app might use? (remember that with AOS library stuff executes directly at the callers context).
MP programs that use a library function that violates the MP policies will get killed.
If one thing would use the flags wrong it'd lead to very hard to spot bugs.
No it would lead to MP programs getting killed like in any other MP OS.
You also forget that in order to have MMU access limitations to certain memory areas they need to be aligned by page size (start & len). With a shared global memory space OS this leads to massive address space fragmentation. And not all memory is allocated via memory pools.
Memory not allocated with the pools will be either fully public or private. I'll need to test what works best. The memory surely won't be protected and shareable with other programs at the same time.
In short: You'd need a massive overhaul of the APIs and rewrite the apps anyway.
Who said it was easy ?
I think the big mistake made during the MP discussion was that people wanted to make a magical change to the OS and make all programs protected. I don't see this as possible. What I disagree with is that you need massive changes to the API to be able to introduce MP.
I also agree that programs that want to use MP will need to be changed and I need to test how involved these changes will be but ATM I think it is much less effort then lead to believe by some people.
The issue of MP has been debated for at least 15 years. The best you can get is the mmu.library protected executables. It protects code and read only data. Anything beyond that would require massive overhaul and API redesign, plus app rewriting.
I did not say it was easy, all I wanted to say that you can have almost identical API with extensions so program could protect their own memory and other memory could still be used to communicate with other programs in an amiga way.
From time to time some individuals come up with claims of generic trouble free MP for amigaos. Needless to say none of them have ever delivered. Some nameless OS even falsely claims to have MP while it really doesn't. Hint: The same OS was supposed to get automatic stack enlargement.
Was that system called pOS ? ;)
Why this MEMF_PUBLIC insanity? There should be no reason why application should use this stupid brainfart. Remove memory usage restrictions and you are closer to real MP.
Of course all software I have written for Amiga allocates data on the stack and never cares about MEMF_PUBLIC. Believe it or not this coding practise works just fine. It works just fine even on Linux and Windows.
Then you are not implementing an amiga OS anymore IMHO. One thing - again IMHO - that at least is needed for an amiga-like OS is message passing by pointer passing and for that to succeed you need to have single address for the memory accessible in between different protection entities.
Also to be able to have stack extension no data that is to be shared may be allocated from the stack. This way the stack would be private memory space and it could have the same vritual address or overlapping addresses for different programs.
It could be done using UAE kind of solution. Run every program in its own sandbox.
No, because you can't send messages in between the sandboxes.
Yes, and that's just on the WWW! The usenet debates/flames about Amiga MP and resource tracking went back almost to the beginning. People have been thinking about it for almost a quarter century, and as Piru has pointed out, no one has delivered yet.
Unfortunately there are a lot of other AROS things to do and I have very limited time for programming. You'll need another quarter century probably until it is available or I have found out it is unmanageable.
Probably best to delay this discussion until the time is come I can actually start programming and prove the non-believers wrong :).
greets,
Staf.
-
As said in another reply MP programs are protected from non-MP programs. When a non-MP program crashes the whole non-MP space may need to be cleaned-up. Call that a sandbox if you want, but it is different to most other proposals where the amiga(-like) sandbox runs on top of the core system which in my eyes is MP but not amiga-like.
I'll be very interested to see that in practice.
The executable is marked, executables without the mark won't be able to get MP. During task switch the OS knows if the task to switch to has MP or not.
Not all tasks/processes originate from binaries via execution. You have some thinking to do.
MP programs that use a library function that violates the MP policies will get killed.
Which means all but some very few existing libraries will be useless.
No it would lead to MP programs getting killed like in any other MP OS.
So you're also enforcing some new magical testing scheme that'll test all the code for all possible execution paths? Amazing!
Memory not allocated with the pools will be either fully public or private. I'll need to test what works best. The memory surely won't be protected and shareable with other programs at the same time.
You didn't address the problem I presented.
I think the big mistake made during the MP discussion was that people wanted to make a magical change to the OS and make all programs protected. I don't see this as possible. What I disagree with is that you need massive changes to the API to be able to introduce MP.
We disagree. I'm sure massive changes are necessary.
I also agree that programs that want to use MP will need to be changed and I need to test how involved these changes will be but ATM I think it is much less effort then lead to believe by some people.
Well you know what you have to do. :)
I did not say it was easy, all I wanted to say that you can have almost identical API with extensions so program could protect their own memory and other memory could still be used to communicate with other programs in an amiga way.
Theory and practice are a two separate things. I'll be expecting an update from you. Let me know when you have the thing working.
Also, would you comment this:
Indeed. The amiga APIs (and thus apps) are full of dependencies of single global memory space (you can add tons of various caller passed structures to system for instance, say PutMsg().. the struct Message will be added to foreign struct MsgPort. There are no strict rules how to allocate either. Many apps allocate them from stack, and that is perfectly legal with AmigaOS). It'd never work... Unless if you redesign the whole API, which in this plan was supposed to be avoided.
How are you going to handle messaging?
-
I wouldn't let any Amiga powered on for weeks with lots of software running and important data unsaved. This isn't an academic discussion...
I understand what you're getting at but, I'm going to have to disagree with this to some extent. I did an experiment back in '93-'94 where I ran an A1000 continuously for nearly a year and half without a single problem. Never powered it down or gave it a three fingered vulcan nerve pinch. It was running several apps, including a BBS. So while there is risk, imho this needs to be considered in terms of opportunities vs. percentage of failure. I agree it's not academic, it has to be based on your real situation.
I wouldn't mind letting powered on MacOSX, Win2K+, Unix opened with lots of important stuff unsaved.
I can't speak in terms of MacOSX, but I can tell you that the company I work for has lost hundreds of thousands of dollars in trying to use NT, Win2K, and XP on systems requiring long term use and round the clock up time.
Cause unless there was a powercut I know my data would be back when I'll get back.
I'm not saying Amiga is better in this aspect but, I've been using Win based systems for years and none have ever given me a sense of data security. Quite the opposite in fact. I have done several studies on data loss with these WinOS based systems and the occurances of data loss is alarming especially when you factor out power loss events and operator caused conditions. If the Win based systems are so great in this respect then why is there such a large market for data recovery products and services. I've just spent the past year developing a methodology and software to work around many of the data loss short comings that exist with WinOS.
I don't want to have to choose the software I run because it may make me lose my work... nor do I want to wait before my HD led is off before powering my computer off, nor do I want to have to check I have enough graphics memory before running a (graphics) memory hungry software because the OS isn't capable of swapping: this is the task of the OS, not mine. The OS should (and will) take down any application trying to write outside its memory mapped,
Agreed! I can't wait till someone develops this!
the OS should close all apps and power the computer down when no app is writing to the disk
This doesn't sound like memory management to me.
-
I wouldn't let any Amiga powered on for weeks with lots of software running and important data unsaved. This isn't an academic discussion...
I wouldn't mind letting powered on MacOSX, Win2K+, Unix opened with lots of important stuff unsaved. Cause unless there was a powercut I know my data would be back when I'll get back.
I don't want to have to choose the software I run because it may make me lose my work... nor do I want to wait before my HD led is off before powering my computer off, nor do I want to have to check I have enough graphics memory before running a (graphics) memory hungry software because the OS isn't capable of swapping: this is the task of the OS, not mine. The OS should (and will) take down any application trying to write outside its memory mapped, the OS should close all apps and power the computer down when no app is writing to the disk, and the OS should automatically swap memory for my apps...
I think you're overstating the real world significance of these things.
This was acceptable 15 years ago. I think it's not today. Much like monotasking OS isn't acceptable, even for a phone... Would you use some DOS-like monotasking OS today ? don't you think having a GUI or not is an academic discussion ? after all you can do everything you want with just a simple console, right ?
Actually I've never used a single tasking OS. Started on the Amiga and moved on to Win98SE-which crashed at least as much as my Amiga, suffered much more malware issues, but it did have MP, I suppose.
I don't think the CLI vs GUI argument is the same thing.
I understand the MP is A Good Thing. Really I do, and I would rather have it than not.
But the REALITY is that millions of users for decades used AmigaOs 3.x without MP to develop god knows how many, apps, tools, utilitities that didn't bring the OS down, or if they did it was rare, even when dozens ran at the same time. Then look at the volume of art, animation, music, video, DTP that was actually created which could not have happened if the apps kept crashing the OS. And you can STILL do that with the same hardware and software today without MP. So how much of a hindrance was the absence of MP in practice?
Personally I think you're overstating the way users were on tenderhooks just waiting for the next imminent crash. It really didn't happen that way. Most of the time.
-
Nonsense, many users left Amiga due to lack of MP when Internet became "the thing" to do with computers in early/mid 90ies - the lack of MP was also a major reason why Amiga users went on to create Linux and NetBSD for Amiga computers back then.
Many users left coz they couldn't play Doom. At a user group we used to get 500-600 show up, and I honestly can't recall ANYONE saying, "I'm leaving Amiga beacsue it doesn't have MP."
I can recall a pirate acquaintance (they always had the high spec hardware) with a warp engine A4000 downloading, uploading, IRC'ing, browsing burning on 3 burners in a scsi box, all the while connected through his 56 k modem, running a monster DOpus config, MCP and a host of hacks, cracks and kludges. The thing was up for months at a time. Don't think he missed the lack of MP, like most people.
And as for abusing Amigas online, I know that _I_ have "broken" into remote Amigas that due to malconfiguration and lack of MP meant a lot of fun for me, and maybe not so much fun for someone else. The highlight was to dump prefs files into remote ENV: and watch the confused target rave about his problems on IRC :laughing:
No doubt it happened. But 1. How often and 2. If I look at the patches released for Windows and internet software eg web browsers that runs on Windows that aim to patch another hole "where a remote user can access/add/change files on your computer", it would seem that the same risks are still there even with MP. Oh and similar patches are being released for Linux and Linux internet software.
-
Im pretty sure people left because Commodore went bankrupt in early 94.
-
Im pretty sure people left because Commodore went bankrupt in early 94.
I think a lot did. I remember all these souped Amiga's suddenly going for bargain prices in The Trading Post when Commodore went broke.
What is surprising is that so many stuck around for so long afterwards.
-
@Fats
Then you are not implementing an amiga OS anymore IMHO. One thing - again IMHO - that at least is needed for an amiga-like OS is message passing by pointer passing and for that to succeed you need to have single address for the memory accessible in between different protection entities.
Message passing is only minor detail in OS design. What about features like AddPort(), AddSemaphore(), AddTask() and other system calls? How do you protect system against rogue applications? I could add dummy uninitialized message port with invalid name tag. The entire OS could crash when it scans ports next time.
You can of course deprecate those functions. But then we are not talking about minor changes anymore. We are also having problem with layer hooks, global semaphores and other design flaws (from MP POV) added in Kickstart 2.0. Shared address space design is present everywhere.
Also to be able to have stack extension no data that is to be shared may be allocated from the stack. This way the stack would be private memory space and it could have the same vritual address or overlapping addresses for different programs.
And how are you going to implement stack extension with limited 32bit shared address space?
No, because you can't send messages in between the sandboxes.
You would obviously need an API extension to communicate safely with boxes. New applications would have to support it. Old applications could share sandbox.
-
I did an experiment back in '93-'94 where I ran an A1000 continuously for nearly a year and half without a single problem. Never powered it down or gave it a three fingered vulcan nerve pinch. It was running several apps, including a BBS.
I believe it was Dr. Peter Kittel of CBM Germany/Escom that used to speak of how he ran his A1200 24/7/365 without problems or crashes. He was very careful with his system configuration, and carefully checked out any new software with enforcer/etc and did not run any software that was not clean. Sort of a software Whitelist, and it worked for him. But I'll bet he did not have as much fun as the rest of us :)
-
Message passing is only minor detail in OS design. What about features like AddPort(), AddSemaphore(), AddTask() and other system calls? How do you protect system against rogue applications? I could add dummy uninitialized message port with invalid name tag. The entire OS could crash when it scans ports next time.
Start with total isolation per app. Break down just the isolation you need to get a functioning system, bridging messages where necessary.
Most Amiga apps don't need to share all that much information between them outside of a well defined set of messages to system services - ARexx messages, shared access to the same file systems and devices, windows being composited onto the same screens, input events. That's more or less it for the vast majority of applications.
Many of these can run as separate tasks/threads in the same "sandbox" as the applications that uses them. It is not necessary for the console.device to run in it's own address space on Amiga OS for example. Many other pieces of system code can reasonably run in the applications address space, further limiting the types of messages that needs to be possible to bridge to other processes.
So yes, you could add a dummy uninitialized message port with invalid name tag, and in the proposed model it would take down the tasks running in that one process for that one application, instead of taking down the entire OS. For "cross-process" message ports the kernel would necessarily need to do careful validation of all arguments.
-
What you seem to be suggesting is "emumiga" for all apps, not just 68k ones...
-
What you seem to be suggesting is "emumiga" for all apps, not just 68k ones...
Sort of, maybe... Emumiga (as well as Janus UAE and for that matter AROS hosted) is at least a good "proof of concept" that validate part of the idea.
Unlike Emumiga or Janus UAE, this sandboxing obviously wouldn't need to emulate the CPU or custom chips. It also would need far less bridging work since it doesn't have to deal with endianness issues. Compared to Emumiga the overhead would be trivial.
Both UAE and AROS hosted also already demonstrates the viability of part of the bridging (e.g. sound, filesystem access and input events are/can be bridged from the host, and can be shared across multiple instances of the hosted system). Janus UAE takes that further by also bridging individual windows to windows on the host instead of opening a single window for the emulation.
-
If I understand things right, this is what MorphOS did with abox, and look what happened - abox is all there is, and little has changed.
Well not really. Abox is there but has more or less direct access to teh hw (drivers are inside teh ABOX). Th eprob is not Abox itself, but lack of Qbox and lack of drivers for virtualized hardware that Abox would need to use then if fully boxed.
But we all know that Qbox will probably never come. If the developers really had too much time I think it would be wise to consider a kind of "Qbox reloaded" to cope with an ISA switch, 64 bit migration, SMP, full resource tracking and maybe, maybee not MP and some other nice stuff. But probably the developers have a life and not the required time...
-
Many of these can run as separate tasks/threads in the same "sandbox" as the applications that uses them. It is not necessary for the console.device to run in it's own address space on Amiga OS for example. Many other pieces of system code can reasonably run in the applications address space, further limiting the types of messages that needs to be possible to bridge to other processes.
But you would have to start new instance of console.device for each sandbox. And not just console.device but almost every other OS service. Drivers must get moved out of sandbox of course.
What about USB stack? I dont think it could stay inside this sandbox. But if it is outside sandbox how it runs? How do you modify USB stack to run there? Or is it just its own box? How about its own drivers?
It wont be easy :)
So yes, you could add a dummy uninitialized message port with invalid name tag, and in the proposed model it would take down the tasks running in that one process for that one application, instead of taking down the entire OS. For "cross-process" message ports the kernel would necessarily need to do careful validation of all arguments.
I dont think old PutMsg() would be suitable for cross process communication anymore so you would define new API to do that, anyway...
-
But you would have to start new instance of console.device for each sandbox. And not just console.device but almost every other OS service. Drivers must get moved out of sandbox of course.
As with most things on AmigaOS, console.device is extremely lightweight, and contains minimal state. The vast majority of the "cost" of the console.device is the code pages - which are trivially shared - and the data structures for each individual console unit, which aren't shared no matter what. console.device is a perfect example of a device that don't need a separate sandbox, but can run in the same context as the application that opens it.
What about USB stack? I dont think it could stay inside this sandbox. But if it is outside sandbox how it runs? How do you modify USB stack to run there? Or is it just its own box? How about its own drivers?
It wont be easy :)
Why do you think it needs to be modified to run in its own sandbox? What is needed is a thin shim/bridge for messages between users of the USB stack in other address spaces and the stack itself. This is not much different than, say, the UAE or hosted AROS sharing of the host filesystem with the sandboxed apps.
And it's the same approach for any shared resource.
I dont think old PutMsg() would be suitable for cross process communication anymore so you would define new API to do that, anyway...
This can be dealt with for current apps either by adding information to the message ports, or by creating proxy ports, but it's possible it'd be more efficient to provide a new API for new apps.
-
Aaaeee, buggy forum software deleted my posting.
So only short question now: if USB stack mounts a USB masssstorage device woudnt filesystem for that USB drive run in UBS sandbox context?
-
Aaaeee, buggy forum software deleted my posting.
So only short question now: if USB stack mounts a USB masssstorage device woudnt filesystem for that USB drive run in UBS sandbox context?
That's an implementation detail / performance vs. stability vs. development time tradeoff. But yes, that's one option. Another option is for the USB stack to be modified to spawn the filesystem in a separate sandbox and communicate via a cross-sandbox port.
Consider this: On a typical Linux system, almost all filesystems (except FUSE filesystems, and they're not used much) and all drivers run in the kernel context with 100% access to the entire system. Only applications are segregated. That's enough to get sufficient stability.
While the Amiga model in theory lends itself well to separating filesystems from the core OS, I think filesystems are less likely to affect system stability than random apps a user installs - for starters there are fewer of them, and they receive more widespread testing since if they fail they not only impact the system uptime but potentially corrupt data...
In other words, while the purist in me would love to see every task in it's own address space, segregated from each other, the pragmatist in me sees that that's neither necessary nor practical...
It's down to finding a happy medium that provides enough protection for stability on par with modern OS's and little enough to keep the 'cost' (in developer time and overhead) down.
-
Which means all but some very few existing libraries will be useless.
On AROS you have the source code for most of the libs.
So you're also enforcing some new magical testing scheme that'll test all the code for all possible execution paths? Amazing!
No, the program is killed at the moment the non-compatible code wants to access a memory address that is protected. Not when it enters the code.
You didn't address the problem I presented.
You said that not all allocation is done through memory pools. I replied that protected memory regions have to be allocated through memory pools otherwise it won't have (full) memory protection. I also said that programs that want to use full memory protection will need to be adapted.
What am I missing ?
I'll be expecting an update from you. Let me know when you have the thing working.
If I ever come to it, I will do my work in AROS so you can find the announcements over there. I do have some other big projects that have higher priority: AROS ABI V1, sanitizing the AROS build system, unified build environment for MOS, AOS and AROS so in one go a binary is built for each of these OSes from the same source code, ...
How are you going to handle messaging?
There will be helper functions provided to ask for the memory region associated with a message port so you can allocate memory that has the right protection for the programs that will receive the messages through a port. Once this is OK you can just use the normal message handling functions. An alternative implementation is that during creation of a memory pool a list of ports can be provided and from then on memory allocated from this pool can be sent to these ports.
greets,
Staf.
-
There will be helper functions provided to ask for the memory region associated with a message port so you can allocate memory that has the right protection for the programs that will receive the messages through a port. Once this is OK you can just use the normal message handling functions. An alternative implementation is that during creation of a memory pool a list of ports can be provided and from then on memory allocated from this pool can be sent to these ports.
I count this as massive API change. Regardless how you do that you'll end up having to perform changes to the way application works, and you need to manually check all code for improper usage.
Then again if you're doing this on AROS you don't need to care about compatibility anyway.
-
@Fats
And how are you going to implement stack extension with limited 32bit shared address space?
In a MP program the stack can contain only data private to the program that can never be exported to other programs. This way all stacks of all programs could start on the same virtual address. (For security maybe some randomization of the start address could be introduced)
I am undecided if I should provide programmers the possiblity to choose for a fixed stack size with the advantage they can choose the protection of the memory from the stack. I think it is better to let all protected memory allocation happen through memory pools. In the latter case max. needed stack size should be much lower than on Linux/Windows.
I agree there may be some inefficiencies on 32bit machines and that you will not be able to effectively use the full 4GB adress space. How much you will loose will need to be tested and optimized.
For x86 I hope most of the people who need heavy duty programs would go 64 bit and for legacy m68k/PPC systems I think for most systems the ratio of virtual address space over physical present memory is big enough to allow some inefficiencies in the usage of the virtual address space.
greets,
Staf.
-
Then again if you're doing this on AROS you don't need to care about compatibility anyway.
With AROS I mean m68k AROS included with the ability to run old m68k code unmodified and not under emulation but without MP.
greets,
Staf.
-
In a MP program the stack can contain only data private to the program that can never be exported to other programs.
Making stack private will break a lot of things. Another large API change, requiring a lot of attention in all existing code.
-
I count this as massive API change. Regardless how you do that you'll end up having to perform changes to the way application works, and you need to manually check all code for improper usage.
It is a matter of terminology. Like BOOPSI, memory pools and AVL trees were not available in original OS 1.x and people needed to adapt their code to use them; memory pools with MP were not provided until now and people will need to adapt their code to use them.
If a MP programs want to send a message it needs to make sure the other side can read the memory it sends it. If two MP programs want to send messages to each other but protected from other programs than they need to have a way to get some memory region shared in between them. These facilities will always need to be provided if you stick to the message passing by pointer passing from amiga and will thus need API extension.
If you call that a major API change it is fine by me. If this means we agree, even for the better.
greets,
Staf.
-
Then again if you're doing this on AROS you don't need to care about compatibility anyway.
Amen!
-
With AROS I mean m68k AROS included with the ability to run old m68k code unmodified and not under emulation but without MP.
So all arch of AROS need to suffer for a version that is not even being maintained?
-
So all arch of AROS need to suffer for a version that is not even being maintained?
For people who see it otherwise there are alternative projects like Anubis, DragonFlyBSD, .... If I wouldn't find source and backward compatibility important I would already have switched to DragonFlyBSD a long time ago.
And I don't think the other archs have to suffer because of it.
greets,
Staf.
-
It is a matter of terminology. Like BOOPSI, memory pools and AVL trees were not available in original OS 1.x and people needed to adapt their code to use them; memory pools with MP were not provided until now and people will need to adapt their code to use them.
None of these required mandatory changes. The old code functioned just fine. What you're proposing requires changes to the code, or the application will not work.
This is exactly what I'm talking about. Major API change so that you must go trough all your code and fix it manually.
-
What you're proposing requires changes to the code, or the application will not work.
No, what I am proposing is that the changes are required if the application is to have MP; the newly introduced functionality in the OS.
If they don't do the changes it will function just as before: without MP and being able to be killed by other bad behaving programs.
It's true that it is an all-or-nothing approach: if you decide to go MP you'll need to overhaul your whole program or it will crash at some point. And this is a difference with the examples I have given, I agree.
There exists some clever code analysis tools that with some adaptation should be able to help in finding most of the wrong struct allocation on stack and suspicious message passing with PutMsg()/SendMsg().
greets,
Staf.
-
In a MP program the stack can contain only data private to the program that can never be exported to other programs. This way all stacks of all programs could start on the same virtual address.
This causes serious side effects. Consider following example:
void foobar(char *name)
{
struct FileInfoBlock fib;
TEXT buffer[108];
BPTR fh;
strcpy(buffer, name);
strcat(buffer, ".txt");
Printf("Open file %s\n", buffer);
fh = Open(name, MODE_NEWFILE);
Write(fh, buffer, sizeof(buffer));
ExamineFH(fh, &fib);
}
Looks like you have to fix dos.library first. You are going to have other indirect implications. Think about this:
void PlaySound(BYTE *buffer, LONG bufferlength)
{
io->Command = CMD_WRITE;
io->Buffer = buffer;
io->Length = bufferlength;
DoIO(io);
}
Ooops? You must document what API calls can take data stored on the stack. This is why I dont like MEMF_PUBLIC crazyness.
-
This causes serious side effects. Consider following example:
void foobar(char *name)
{
struct FileInfoBlock fib;
TEXT buffer[108];
BPTR fh;
strcpy(buffer, name);
strcat(buffer, ".txt");
Printf("Open file %s\n", buffer);
fh = Open(name, MODE_NEWFILE);
Write(fh, buffer, sizeof(buffer));
ExamineFH(fh, &fib);
}
Looks like you have to fix dos.library first.
I did not say that you could use libs without any change. And it will not only be dos but also exec, gfx, intuition, ...
In this example I don't see anything that can't be handled by dos internally, although the proof will be in the pudding.
You are going to have other indirect implications. Think about this:
void PlaySound(BYTE *buffer, LONG bufferlength)
{
io->Command = CMD_WRITE;
io->Buffer = buffer;
io->Length = bufferlength;
DoIO(io);
}
If the buffer is allocated from stack this will cause problems. I agree.
Ooops? You must document what API calls can take data stored on the stack.
On Linux this is solved by having kernel code run under the kernel context without access to all memory without any restrictions. On a MP amiga OS this may sporadically be needed for efficiency reasons and limit the cases where API restrictions are needed on passed pointers to lib functions.
I would like to limit the code running under this 'god' context though and not evolve to a monolithic kernel; from the other side I am for some pragmatism and not some almost religious following of OS concepts like most of the microkernels guys have been doing.
This is why I dont like MEMF_PUBLIC crazyness.
To me it is not about enforcing MEMF_PUBLIC/MEMF_PRIVATE or not.
It is about how to put public data on stack and make the stack auto-extending. Do you have another solution for that ?
greets,
Staf.
-
I did not say that you could use libs without any change. And it will not only be dos but also exec, gfx, intuition, ...
In this example I don't see anything that can't be handled by dos internally, although the proof will be in the pudding.
It must be handled by dos internally. It is way too much work for user code to always copy filenames etc to temp buffer.
It is about how to put public data on stack and make the stack auto-extending. Do you have another solution for that ?
Go 64 bits ;-) There you should have got enough address space for next 10 years...
But anyway... experiment it and tell us how it went ;-)
-
Turing Award to be given to individual that successfully implements MP on Amiga. (Is it really so important?)
-
unified build environment for MOS, AOS and AROS so in one go a binary is built for each of these OSes from the same source code, ...
This is what I've been talking about from the get-go. Fats, you have my total support on this and anything can do to help bring this about, don't hesitate to ever ask me. :)
After reading this, I realize that you and I have argued in the past, for no reason, as we both wanted the same thing. You have my sincerest and most humble apologies. :(
-
Appropriate amount of elegant line of codes would do the trick. Sort of like the time-proven classical UNIX approach.
-
i've just stumbled on this thread ..
it's alway good to see more discussion about MP.
one way or another something must be done for stability on amiga-like OSes.
if some them (amiga-like OSes) prefer to stay true to original os3.x api, good for them though i prefer emulators for that.
i hope in the lot (aros, os4, morphos) there will be at least one which will keep the look and feel and general user experience but whose base will improve and evolve a bit.
in 2010 basing an OS api on 80s and 90s standards, and planning to keep it that way for the foreseeable future sure looks a bit sad to me..
especialy sad since if i remember correctly, the original dev team of amigaos planned to introduce MP in some later system update which unfortunately never came. the commodore bankrupt and all. they hadn't time to introduce this update in amiga api and that's too bad.. we'd be a lot better today if they had time to deliver this update.
imho the goal of aros, os4 and mos should be that.. guesstimate what the original team envisionned for that MP update and do it.
for classic software needs there's emulators (uae).
memory gestion in os3.x api is just not good enough.
so far all 3 mentioned above OSes are still as weak as amiga OS 3.x was. meaning any bad behaving app or system component or anything can, and DO crash the whole system.
i can't believe it each time it happen and how many times .. it's ridiculous.
there must be some kind of general rule that make it possible to kill properly an app and free all its resources nicely. any bad behaving program should be killed by that rule before being able to do any harm on the system and other apps.
the crashs must stop..
be it by implementing MP, or any anything else, black magic, chicken sacrified in a red and white checkered pentagram i don't care but something must be done
-
crashing like that was tolerable when the other did as bad or worse..
at the time, macOS7,8,9 and windows 3.11,95, 98 and "me" were all as bad ..
but now, windows and macos changed some flaw of design, they got updated and they are a lot .. a hell of a lot more stable. there's nothing you can compare with amiga-like OSes anymore, be it aros, os4 or mos ..
it's seriously time someone make the necessary update to os3.x api too ..
having all our amiga "ng" focusing on backward compatibility at any cost is too bad .. specialy when the cost is so high it places you below average standard...
i'd say, keep the look and fell, OS filesystem layout/structure with libs: fonts: c: sys: and so on, keep the general idea, but , make a rock solid base and screw the backward compatibility ... at best include, integrate uae .. like macOS did when transitionning from macOS9 to maOS X, they create "classic" environment to execute from inside OSX
lacking proper tracking resources and means to kill apps in amigaOS is a proof of serious design flaw.
-
My only contribution to this thread, (which, by the way is a cracking read):
This was acceptable 15 years ago. I think it's not today. Much like monotasking OS isn't acceptable, even for a phone... Would you use some DOS-like monotasking OS today ? don't you think having a GUI or not is an academic discussion ? after all you can do everything you want with just a simple console, right ?
PS3 runs a monotasking OS. Whilst not a desktop computer, it is in general use by several million people as a web browsing, file (mis-)managing, incredibly restrictive monotasking OS (albeit with a GUI).
Carry on...
-
imho the goal of aros, os4 and mos should be that.. guesstimate what the original team envisionned for that MP update and do it.
The whole contribution of the original team is some forward looking text file which throws in the air some things you should keep in mind in order to stay future system compatible. The instructions are incomplete and contradicting (for instance use of MEMF_PUBLIC). You can't blame them really, there's no way they could foresee the future development of multicore, memory management units in all CPUs etc.
Doing complete rework of the OS design to allow full memory protection and then running old apps inside UAE, what's bad in that you ask? If you're going to cook up your own design you'll in for 10+ year project reinventing the BSD/Linux wheel. Well, why bother with that, why not use use Linux and run UAE on top?
No, I personally don't feel like doing that.
Something like running your own lightweight kernel and userland and on top of linux kernel might make more sense. You wouldn't need to bother with the low level things then. Sounds much like Amithlon, with the exception that you'd replace the userland with newer one and perhaps not bother that much with HW emulation.
Everyone, feel free to steal that idea (albeit it isn't exactly original).
For now I'll rather keep working on MorphOS as it is now.
-
Something like running your own lightweight kernel and userland and on top of linux kernel might make more sense. You wouldn't need to bother with the low level things then. Sounds much like Amithlon, with the exception that you'd replace the userland with newer one and perhaps not bother that much with HW emulation.
Everyone, feel free to steal that idea (albeit it isn't exactly original).
For now I'll rather keep working on MorphOS as it is now.
That was Anubis-OS plan actually.
-
"So, it looks like they basically sandboxed older apps, and in fact the entire OS 9 to run on top of MacOS X. Sort of like runnine E-UAE now on OS4, or WinUAE on Windows, although they made it appear more seamless, I think. "
Apple actually did a good job with this. When flakey ass 0s9.2 would rear it's ugly head.... just force quit the os9.2 app and viola. What a relief not to have a crash bring down the whole system. The whole way it ran 68k, and PPC on the same system was quite well done.
-
Windows may have memory protection since XP (as well as all versions of NT of course but that's not a desktop OS) BUT Windows still gets ass raped at the mere sniff of a TCP/IP connection so why is it so important?
(http://forum.i3d.net/attachments/battlefield-series-news/943198618d1263840017-no-console-bad-company-2-facepalm_implied.jpg)
-
@piru
The whole contribution of the original team is some forward looking text file which throws in the air some things you should keep in mind in order to stay future system compatible. The instructions are incomplete and contradicting (for instance use of MEMF_PUBLIC). You can't blame them really, there's no way they could foresee the future development of multicore, memory management units in all CPUs etc.
we can't blame them of course. but (!) what we can see is that they deemed adding MP important and *it was planned for a later update*.
it was meant to be, they just had not enough time to finish it and deliver..
so maybe yes the documents they left were incomplete and contradictory,
but what's important here is to notice they wanted this for amigaos.
iirc, when i read about this, there was even a mention about inevitably breaking compatibility a bit for that update. (that wouldn't have been the 1st time) but anyway that was at a time aos devel was looking forward..nowdays all we have is focusing on backward compatibility..
like if it was everything ..
Doing complete rework of the OS design to allow full memory protection and then running old apps inside UAE, what's bad in that you ask? If you're going to cook up your own design you'll in for 10+ year project reinventing the BSD/Linux wheel. Well, why bother with that, why not use use Linux and run UAE on top?
well, with the work that went thru the creation of all the 3 "ng" systems (aros, os4 and mos) such platform would exist already.
what i'm saying is that when each of those project got started, the vision was not good enough from the start. the goal was to have amigaos 3.x api compatible "ng" OSes.. so they got what they wished for.. aos with all its strong points and weaknesses too ..
the strong points are obvious:
small size, small footprint,
responsive
customizable
look and feel (user interface)
simple and logical system structure
(almost too good to be true list)
the minus:
(now here's the catch ;)
prone to crash, very much so
a better objective would have been to create a strongly amiga inspired OS
keeping *as much as you can* from amiga, but at least have the memory gestion area reworked.. and maybe some other amiga little weaknesses here nd there corrected too.
you have to take in account the original dev noticed the problem and wanted to correct it themselve too... current os3.x api wasn't meant to be final. obviously for an OS, being able to kill tasks, and free their alocated resources properly is a crucial point.
Something like running your own lightweight kernel and userland and on top of linux kernel might make more sense. You wouldn't need to bother with the low level things then. Sounds much like Amithlon, with the exception that you'd replace the userland with newer one and perhaps not bother that much with HW emulation.
as the solution mentionned above, both could be interesting, which one would fit best, i can't say this is something that need to be tested..
using a linux kernel with an amiga layer on top could be interesting, but only if the linux kernel is really in charge... not like amithlon or morphos.
(in mos, the abox runs on top of qbox .. even if qbox remain stable and untouched, the abox can freeze thus needing a reboot anyway even if qbox is just fine, so the MP and stability problem isn't addressed .. same for amithlon using a linux kernel but it's not in charge of amiga layer .. which just use the usual exec)
using a linux kernel, along the line of what anubis wanted to do would solve a lot of problems, stability and driver wise.
For now I'll rather keep working on MorphOS as it is now.
i don't know how you can ..
it's looking good, it's fast, small, customisable ..great, but crashy.
i just can't be interupted in the middle of a lenghty post like this, to have the machine freeze because of other tasks running in background may or may not have caused havoc in memory .. having to retype all again ..
having to suspect or fear sudden freeze all the time, forcing me to save all the time, "just in case", in the middle of an irc chat, being rebooted all of sudden ... you left the machine on to finish some downloads and you come back in the morning and it's all frozen download only progressed by few percent before everything froze .. and such
so, sure the os looks nice, logical, simple, it's fast and customisable and all but, this stability problem it spoil everything . at least for me .
-
@piru
plus, and i'm not saying this is the way to go but,
no need to reinvent unix/bsd wheel, no need to reinvent everything..
it's possible to pick bits and bobs here and there and customize and mix it all together..
linux kernel can be modified to use a filesystem structure that look like the one on amiga. there are already such project .. gobolinux is one example, but surely not the only one... anubis wanted to do that too.
linux kernel can be cutomized a lot, there's even distribution that fit on one floppy.. so size too isn't a problem.
look at what osx did .. (in its own (kinda bloated) way) .. using linux kernel doesn't mean the result will look like "yet another linux distro.
of course there's also the possibility of creating a new original OS with its own kernel (with MP and resource tracking) but that would take longer to create i think .. so unless there's ppl motivated enough for that, why not simply reuse and customize the existing ..
what i don't understand is why aros, os4 and mos users can't properly kill tasks and free their resources.
-
Would running Aros on a Linux Kernel mean that when I launch a new Aros app. that the Linux Kernel would create another space to run that app?
Sorry, I am back to studying c++, but I am not fully versed yet.
I would not have a problem with a Linux distro that is Amiga/Aros oriented.
http://www.xamiga.net
This could be a possible roadmap to a better Aros os with all we want in it.
-
The Syllable OS team was creating a version of Linux for server purposes. It would have there own gui and libs, if I remember correctly.
-
@trekiej (http://www.amiga.org/forums/member.php?u=1537)
syllable isn't very amiga-like ..
what i was refering too was more like having amiga filesystem structure supported in the modified linux kernel, modified to have structure like:
sys:, c:, libs:, fonts: and so on .. instead of /usr, /etc, /bin which is the traditional unix structure..
at least .. and of course a GUI layer .. be it using xorg or something else but that should look and behave like amigaos: workbench or dopus magellan lookalike
that should be possible to have something snappy and that look and behave like workebench using only xorg libx11.. on linux there's even a project that does this: amiwm .. with draggin screens too .. it's usable and very small and fast.
there's no file manager though, and many features are yet unimplemented, but as a proof of concept it's there.
it's too bad half the remaining amigans don't understand the MP necessity or what is it exactly, and the other remaining half seem to prefer solution like aros, os4 or mos which all replicate os3.x with all its weaknesses
where what i want is different. it's a system that's small, whose structure is logical and simple like amiga, where the gui is looking nice and customizable, snappy..
well ..an amiga-like os, minus the crashs ..
and about xamiga.net, it's just another emulation running on top of linux.
emulation is not good enough, there's still no MP. everything inside the emulated environement is just like usual. no MP, no resource tracking .. plain old os3.x 68k emuated.
be it by redesigning current kernels or using unix ones i don't care but .. the crashs and instability i can't accept
anyway .. i just have to wait .. either all thoses system will eventually evolve or die.
it's just i want MP and resource tracking for yesterday..
-
what i don't understand is why aros, os4 and mos users can't properly kill tasks and free their resources.
I believe the problem here is that ressources aren´t limited to the task claiming them. It is perfectly legal to have one task claiming e.g. RAM giving the pointer to another task, waiting for the task to finish and then releasing the memory. Or the second task may release the memory for the first one.
In fact there is a garbage collector for Amiga Oberon that does just that: tracking the memory of Oberon-programms and releasing it, when there is no reference left. Of course it will also free them if the task is killed. But that is because every allocation or copying of a pointer is tracked by a special library.
There is some beauty in both concepts.
-
what i don't understand is why aros, os4 and mos users can't properly kill tasks and free their resources.
Global shared address space. Everything depends on it, from the very basics of the messaging system. From time to time some people claim to have invented a way to introduce a reliable and bulletproof memory protection scheme to amigoid system. It always ends the same way, all the sudden these people fall ominously quiet and the idea is forgotten for the next couple of years.
If you change the very basic concept of the global shared address space you will completely break all the existing APIs and applications. You'd need to have completely new set of applications, which would most likely be ports of open source apps. If so, how will it be any better than YALD?
-
Global shared address space. Everything depends on it, from the very basics of the messaging system. From time to time some people claim to have invented a way to introduce a reliable and bulletproof memory protection scheme to amigoid system. It always ends the same way, all the sudden these people fall ominously quiet and the idea is forgotten for the next couple of years.
If you change the very basic concept of the global shared address space you will completely break all the existing APIs and applications. You'd need to have completely new set of applications, which would most likely be ports of open source apps. If so, how will it be any better than YALD?
well why not ?
all linux kernel need is a good GUI .. see osx(i know mach kernel from bsd branch .. but it's unix familly still)
osx didn't reinvented the wheel, they just took kernel bits and bobs and made their sauce ..
and their product is kind of popular..
first thing first, such a modified kernel with amiga paths and filesystem structure would be a fresher from the traditional unix layout..
then a nice snappy customisable gui ... could be interesting ..
the problem most linux distro have is that their changes aren't very apparent, most run gnome or kde, and beside little changes here and there, for example what package manager do they use, or such small changes most distro are very similar to each other.
few like apple did real customisation on top of an unix kernel..
i'd bet something with the simple and logical amiga structure, and snappy customisable GUI ala workbench/magellan would interest many.
the merit are stability , and drivers ..
softwares like mui or reaction could be replicated to run on this new kernel, and become the basis for the whole interface, pretty much like cocoa does on macs, but done amiga style: small and efficent
well all that idea pretty much seems like what anubis would have been.
but it'd not mandatory to use a linux kernel .. it's just convenient because it's there..
and "amigaoid" systems badly need a core update ..
backward compatibility it's good enough while transitionning .. see osx, at first they had classic environment running inside osx .. after a few year, classic env went away ..
problem with amiga, is that it frozen at that transition moment in time..
without completely achieving it
how long the wish for backward compatibility will hold us from progressing ?
68k software from 90s .. will it still be regarded as important in 2015 ?
i sure hope not ..
i hope dev from amigoid "ng" will make a clean table, and start making a solid base . where app and resources can at least be killed and freed.
i was reading about atari the other day, they have MiNt..
so even atari got MP .. unfortunately for them they got no new hardware. and probably an even smaller community. still they adressed this important problem quite a while ago. at first they were in the same boat as amigans..
-
well why not ?
Sure. Go ahead, I'll be waiting for your product release.
It's far easier to give advice than to actually produce something tangible.
And btw Apple used years on Mac OS X, and had budget of hundreds of millions.
-
Lets also not forget all those years and millions before it has a name change and was NeXT OS.
freeaks, I'd love to test your
all linux kernel need is a good GUI .. see osx(i know mach kernel from bsd branch .. but it's unix familly still)
osx didn't reinvented the wheel, they just took kernel bits and bobs and made their sauce ..
and their product is kind of popular..
first thing first, such a modified kernel with amiga paths and filesystem structure would be a fresher from the traditional unix layout..
then a nice snappy customisable gui ... could be interesting ..
the problem most linux distro have is that their changes aren't very apparent, most run gnome or kde, and beside little changes here and there, for example what package manager do they use, or such small changes most distro are very similar to each other.
few like apple did real customisation on top of an unix kernel..
i'd bet something with the simple and logical amiga structure, and snappy customisable GUI ala workbench/magellan would interest many.
the merit are stability , and drivers ..
softwares like mui or reaction could be replicated to run on this new kernel, and become the basis for the whole interface, pretty much like cocoa does on macs, but done amiga style: small and efficent
well all that idea pretty much seems like what anubis would have been.
but it'd not mandatory to use a linux kernel .. it's just convenient because it's there..
and "amigaoid" systems badly need a core update ..
backward compatibility it's good enough while transitionning .. see osx, at first they had classic environment running inside osx .. after a few year, classic env went away ..
problem with amiga, is that it frozen at that transition moment in time..
without completely achieving it
how long the wish for backward compatibility will hold us from progressing ?
68k software from 90s .. will it still be regarded as important in 2015 ?
i sure hope not ..
i hope dev from amigoid "ng" will make a clean table, and start making a solid base . where app and resources can at least be killed and freed.
i was reading about atari the other day, they have MiNt..
so even atari got MP .. unfortunately for them they got no new hardware. and probably an even smaller community. still they adressed this important problem quite a while ago. at first they were in the same boat as amigans..
when you have completed it.
-
Wow, nearly 5300 views for this thread! Hot topic.
-
osx didn't reinvented the wheel, they just took kernel bits and bobs and made their sauce ..
and their product is kind of popular..
OSX is a bad example. Apple needed a new OS and spent alot of money on it, without it they wouldn't have been able to jump to yet another CPU & would be struggling to compete.
Take a look at how they solved the problems:
Old apps are run in an emulator, we can use UAE for that.
New apps run in a completely different environment, this is where your problems start.
You could base your new environment on linux. To make it practical you'd have to drop any idea of keeping C: S: LIBS: etc. An Amiga lookalike window manager is doable (in fact I think it's been done), unfortunately it looks pretty dated.
Or you could start from AROS, but you've just gone round in a circle. It's hard to do memory protection in AOS because the way it was designed makes it hard. Your only option is to change the API, but that one change will ripple through everything. Even if you ever succeed you'll end up with another AOS alike system that will get ignored.
Your only real option is to make AROS compatible with AOS4.
-
Wow, nearly 5300 views for this thread! Hot topic.
and its posted/asked about once a month and still all these people just can't get over how easy it is to do and why hasn't anyone done it in the last XXXXXteen years? Why all us programmers must be sitting on our ass thinking 'gee, that MP/SMP amiga OS topic is just too damn easy, I need something much harder to work on....'
-
Lets also not forget all those years and millions before it has a name change and was NeXT OS.
And before that it was a student project.