The virus threat as Windows OS is exposed to nowadays, especially when connected to the Internet, is in itself a reason not to use it.

You completely understand my views in all those posts of your's above, and I especially like this line:

"To bring bad programming practices from PC to Natami is not an option."

Porting massive spaghetti open source software from linux (and windows) is mostly a waste of time, and that is astonishing to say, considering how much work was put into that software!!!!!

But really, having programs with dependencies on other programs that have dependencies on YET OTHERS (and others still), that may, or MAY NOT be "up-to-date" enough to WORK even!!!!!

If working on "new" software for the NatAmi is "reinventing the wheel".... I know that it IS worthwhile, as do most, heck, 99% of the people here do too.

Just today on my widows 7, I ran a program I seldom use that needed an update. I know what I did, but really, undoing it will be a monstrous ordeal, IF POSSIBLE! I accepted one of those optional choices when using shareware, similar to a toolbar add on and now Chrome is not working too good.... and where precisely do I email my complaint???

Ok, what can be done: Os notification, the os becomes aware of whenever a user modifies a script and then compiles or pre-processes it on demand. A solution? Maybe, the user can change the script, the os boots fast nevertheless. But it needs a daemon process or some other checking process to be running. Which might break, or which is something the user is not aware of. Or which might him give the feeling of losing control.

So we're back to where we started. Ok, make it configurable? Then you run into trouble of users not understanding the configuration, or not willing or not able to read the documentation that came with that, so again more complexity.

You see, there are *many* decisions you have to make as an Os designer, and many compromises you have to find, and no matter what you do, you do it wrong.

In case of doubt, pick the easiest alternative. Which is: Let the system run the scripts all over. Simple, understandable, reproducable, every dummy knowns how to edit and modify them, least surprises. Probably five seconds more boot time in worst case. Who cares?

Did I say that my Laptop boots in 10 seconds (of which 7 are spend in the bios?) from an SSD? So it's really not a problem.

Megol . wrote:

Why load stuff (that will be swapped out later) at boot time that isn't needed?

What makes you so sure that it isn't needed? Probably it is loaded exactly for the reason you gave above? Probably because the Os can concieve that this *might* be needed later, and it will save time later? So exactly for the reasons you gave?

Megol . wrote:

Even BIOS could be mostly bypassed reusing hibernation mechanisms for standard boot.

So it does. But it requires an Os organization that supports that. AmigaOs doesn't.

Again, I'm playing a bit the devil's advocate (a role I seem to appreciate). It is absolutely non-trivial to come up with a reasonable design - and many decisions have lead to the systems we find today. I do not know how stupid Windows is, but I believe that the small decisions that made the system to look like it looks today may have been, individually, all be very reasonable. That the end looks so unreasonable is just because some people are more used to it than others.

Where do you find such programmers? And more so, where do you find users that appreciate that? (-;

I think that the kernel manages the hardware and the OS manages the user. This is both basic and simplistic so subject to controversy.

Second point of disagreement: Zero risk does not exist. Boot speed should not be opposed to the safety or solidity. If the last two are defeated, a very short startup time is required for some uses.

About the Amiga and its propensity to self reset, I think its boot speed is not a luxury. This is a very nice perfomance for an old hardware.

NB: currently, I use DEBIAN.

Thomas Richter wrote:

And more so, where do you find users that appreciate that? (-;

Here! I appreciate it. I always appreciate your work on the MMU, and your tool COP. Excellent contribution!

a MPU(Memory Protection Unit) What would be the minimum requirements?

Right, exactly nothing. One thing is a low-level abstraction mechanism, the other a matter of complex software and wrapping abstraction layers around abstraction layers.

The additional cycles for any type of address lookup are nothing but a little noise in the overall timing. However, if you look a bit into *why* windows or browsers are slow on low-RAM machines, you would notice that there are many software services involved in just making a browser work. Not only a simple network stack, and the http stack. Freely scalable fonts, that will be offloaded from disk and then processed, CSS script processing, html decoding, dynamic page layout, java-script interpretation just to name a few. In other words, the amount of software you need just for plane simple browsing is quite large. *That* makes things slow, not the couple of cycles in between.

And, you may ask, do you need all the services? Yes, you do. How many webpages render correctly without CSS? How many function without javascript? How many look acceptable without scalable fonts?

The point is, we're no longer in the 1980's, and yes, this stuff costs power, but yes, you need it for a productive system. Of course you can blame the designers of html, CSS, javascript why they created such a messy spec in first place. But no matter what you complain, you won't change it. Face it, a system has to deal with that. And a 10 year old Pentium III with 128MB RAM, even fast at its time - won't.

It's not window's fault. It's not the fault of the MMU. It is simply because this is no longer the 80's, but we have 2012.

Again, if you believe that you can cure the problem by discussing the low-level functional design, you're wrong. The problem *is not* at that end. Not even a little bit.

ThoR you do know that the MMU is one of the harder parts to scale just like the decoder.

I am against the TLB not because it is a bad thing I am against one because it's redundant as a system since Programers should use Relative addressing in their programs anyhow!(P.I.C. F.T.W.!!!)

Remember a Engineer is someone who is done when there is nothing else to remove from a design.(Most forget this, hence featuritis)

I care about what *should* be done, and this is a "stable system". Yes, you need some kind of memory management for that. Some kind. But don't use any high-level user experience as an argument here - it really doesn't matter.

What does a TLB have to do with relative addressing?

Responsive system is not my main concern about the MMU and FPU for that matter, it's more about compatibility where i stub my toes.
adding something that is compatible cost space.
adding something that isn't still cost space.
So i rather would advertise the use of EC style CPU's.
And have a stronger chipset, if you catch my drift.

Yes. And? This has exactly nothing to do with what an MMU and a TLB do. Relocation is done by the dispatcher that loads code from the harddisk to RAM before execution. It doesn't matter whether your code uses relative addressing or not, the dispatcher will fix all of the fixed addressing. If you consistently use relative addressing, the dispatcher may take a millionth of a second less for doing its job. That's all.

a TLB offers virtual addresses, and thus looking at a program in memory during run time there are a few minor differences.

A TLB is for translating virtual addresses to physical addresses. Each program can use all of the addressing space in virtual addresses, it can use addresses that other programs are using, too, without any conflict because the same virtual addresses map to different physical ones. If a process needs more RAM at some point in time, additional address ranges can be assigned to it that seem to be contiguous with the address ranges already assigned to the program. Nonetheless, this additional RAM can be at any physical address. You can also manage more virtual RAM than is physically available and use a swap file. You can detect and prohibit accesses outside the scope of a program.

This is what MMUs and TLBs are for.

further passing a pointer for what the Amiga used it is VERY HARD if not impossible when a MMU is required!

Bullshit. Why should it be so difficult to set up an OS function that translates a pointer from the address space of one program to that of another? After all, the OS does such translations all of the time. You want to pass a pointer to a different task? Well, you need the task handle of that task anyway. Just call something like "mapvirtual2virtual()" with your pointer and the task handle of the task you want to send the pointer to. And don't tell me the 100 processor cycles involved to do this will cause the OS to come to a grinding halt...

What I don't like about many of the SASOSes is that they rely on software constructs to secure behaviour and operation. Hence my interest in mmu internals that do not require flushing of every mapping when switching processes or modes.

Well Intel provides what you want already: address space identifiers per TLB entry. Something MIPS and others have had for ages...

BTW. most programs don't even need any form of installation so you could just grab folder with application and run it directly. If you have problems with it then you are probably doing it wrong...

Odd can you tell that to the Microsoft programmers since they use the TLB to trick a program to think it has a continues 2GB of RAM space to use (32bit programs PAE disabled).
Of course this only gets funny when your system runs out of physical Memory. ;)