@saimon69

Quote:

Well, i didn't see os-x users complain about the fact that their new Mac OS was built on top of a unix kernel, since at the end was behaving like Mac OS...

The problem here is that OS 9 was crap. The users knew it, and were happy with anything better even if it was radically different. Amiga OS4, hell OS 3.1 does what it does *well*. I don't personally feel "Amiga" users would feel happy with a Linux kernel and some Amigaish fluff on top.

_________________
Blog

@Aslak3

I am not sure if that was saimon was meaning. I think he means nobody cares what kernel is below as long as the OS is behaving like expected. So when there is a linux kernel but on top of it something that looks like Amiga, behaves like Amiga and has the API like Amiga noone will care about the lowlevel/driver stuff.

@OlafS25
Quote:

So when there is a linux kernel but on top of it something that looks like Amiga, behaves like Amiga and has the API like Amiga noone will care about the lowlevel/driver stuff.

news post;
"Difference between aeros and arix will be that aeros comes with a fully working linux environment while arix uses only the linuxkernel for hw abstraction."

And so...Problem solved.

Now there is no need for those that want something other than AmigaOS to run their very own idea of what an Amiga should be can do so, and the next generation AmigaOS people can get on with what they're doing, at their own pace, on their own hardware. Everybody’s happy.

_________________
Tinkering with computers.

@Signal

Quote:

Now there is no need for those that want something other than AmigaOS to run their very own idea of what an Amiga should be can do so, and the next generation AmigaOS people can get on with what they're doing, at their own pace, on their own hardware. Everybody’s happy.

i really, really hope so!

-- eliyahu

_________________
"Physical reality is consistent with universal laws. When the laws do not operate, there is no reality. All of this is unreal."

@Aslak3

Quote:

Such things, beside 64bit since that is just a "size of your pointer" concern, are mutually exclusive with Exec's (and thus the rest of the system) core design principles.

The 64-bit pointer one is a big issue as Exec is a 32-bit kernel and structures. Exec would need to have a private 64-bit ExecBase that makes a 32-bit ExecBase public with pointers being 32-bit IDs to 64-bit addresses mapped by the MMU. Or at least I think.

Another isuue is the ExceptionContext struvture which is locked to PPC. It would need obsoleting.

Quote:

So long as the OS is based on pointer-passing, SMP and MP will remain elusive.

They could reserve shared memory for those messages. And sandbox old style apps to that same memory.

If the efficient message passing is to be replaced by comparitively inefficient copy on send a slab of messages could be allocated for the job or per task.

Of course whatever is in a message, any pointer is a no-no as it is a direct reference to anotrher tasks memory making resource tracking hard to free.

Either way, when moving from pointers or messages to seperate entities, it looks like direct references will need to be replaced by IDs such as a PID and not a task ID as it is now like the address. We have problems now like looking up a message port and needing to lock the system down to send a messaage to it. So this pointer problem has been around along time.

@Signal

Quote:

And so...Problem solved.

would be great. but having an experience with pointing people, who demand os4 on x86 to aros and being told that it is not the "true amigaos" in response, because they were continuously conditioned with this kind of statements, i dont think anything will change.

@OlafS25

The point is that Linux kernel is monolithic and won't work like AmigaOS, if AmigaOS was monolithic we wouldn't have been able to use a lot of hardware. Linux is opensource and AmigaOS isn't. There's no much sense in choosing a monolithic approach. There's a possibility of using drivers as modules but Linux kernel maintainers modify the driver interfaces from time to time. Not very Amiga-like IMHO. I would prefer that it used some *BSD kernel. Its license would be more AmigaOS compatible and porting Linux drivers shouldn't be too hard.

Anyway give the path choosen by Hyperion it would make a lot of sense: python, non-shared objects, MESA & Gallium and a lot of Linux stuff that IMHO doesn't really fit well in AmigaOS nor follows Amiga phylosophy.

_________________
The only spanish amiga news web page/club: CUAZ

@Crumb

Python is grate language, it's easy to use and learn, and it's fast, It no more or no less Amiga then basic in my option, it hell more system friendly then AMOS. By the way AMOS is a import from TOS/Atari.

I must say my experience whit it is not that great, but I found it was easy to list files and execute shell commands from it, it was in fact easier than doing it as AmigaDOS script.

Basically what is lacking in AmigaDOS scripts is, proper handling of strings, this is where python rocks, ARexx is pretty old in my option and out dated, but it's good for what it does.

MESA is similar to MiniGL we have been using for years, or OpenGL that is industry standard, the lack of a modern 3D api has been holding Amiga back for years. We can hide behind a rock say to our self that Warp3d is best thing ever, but we be lying to our self.

Here is something that is not Amiga in my option, SH/Bash/ABCShell, but whit out it you can't port games and programs from Linux, or its going to be extremely hard.

Because it does what AmigaDOS/Shell does but in different way, SH is more advanced then AmigaDOS but it also less understandable. If you want do something bit more advanced then starting/executing programs in sequence then I suggest Photon maybe in some cases Arexx, depending on what you want to do.

Last edited by NutsAboutAmiga on 29-Oct-2013 at 08:00 PM.
Last edited by NutsAboutAmiga on 29-Oct-2013 at 04:36 PM.
Last edited by NutsAboutAmiga on 29-Oct-2013 at 04:30 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@NutsAboutAmiga

MESA is more Amiga than any of the other things listed as the very first version was written on an Amiga 3000 with WB2.0. :)

@NutsAboutAmiga

Quote:

Python is grate language, it's easy to use and learn, and it's fast, It no more or no less Amiga then basic in my option,

Amiga Python ports require an instance of the entire interpreter&modules in memory for each program you run. If python+external modules eat e.g. 5MB it will eat 5MB*number of python programs running. OS4 (non)Shared objects won't help as multiple copies will spawn in memory. That's IMHO very inefficient and not very Amiga-like. ARexx in constrast uses shared libraries so only one instance of the module/library is used.

Quote:

MESA is similar to MiniGL we have been using for years, or OpenGL that is industry standard, the lack of a modern 3D api has been holding Amiga back for years. We can hide behind a rock say to our self that Warp3d is best thing ever, but we be lying to our self.

A Linux port using OS4 (non) shared objects causes that all (non) shared objects have to be instanced in memory, one time per opener. Gallium is unoptimized and is slow. Not very Amiga like.

IMHO the Linux shared objects don't fit very well for AmigaOS programs, it's ok for a quick port but I don't think that important components should use those unix-like objects.

The only "advantage" of those OS4 (non) shared objects is reducing the size of some quick ports at the cost of confusing the user. It won't save any RAM and will eat your RAM quickly.

The Amiga way is using Amiga shared libraries, not "external static objects".

_________________
The only spanish amiga news web page/club: CUAZ

@Crumb

I think Krashan's lua.library is the most Amiga-like way of having one of the modern scripting languages.

Much better than a quick and crappy port of a *nix version using .so libraries.

@resle

Quote:

TEN years spent reinventing the wheel make obvious that unconsciously, the amiga people DO NOT want their small garden to become a big amusement park again. Otherwise - instead of struggling with the OS 3.1 legacy, Hyperion or the Morphos team or whoever else, in those TEN years could had just - taken the Linux kernel - add kernel-level UAE emulation - add subsystems to mimic the main OS 3.1 features - add macros to match amigaDOS commands - Skin the whole thing as AmigaOS Done, you have a new AmigaOS that bears all the things you love about amiga, runs most of the legacy stuff, frees the whole thing from old/expensive architectures, etc. etc. - and if you don't go digging deep under the hood you won't know at all it has a linux kernel underneath. If you think the above is more difficult than developing a whole OS, you're very very oh so very wrong.

Good points.

Linux has become a compendium of pragmatic OS design -- it would take year to catch up, if that is even possible.

As far as macros to match AmigaDOS commands, one would be better off writing a new shell if they wanted this done right. I wrote a bash macro that emulates the Amiga assign command, but it's not quite right.

Other than for fun...

Last edited by bison on 29-Oct-2013 at 07:09 PM.

_________________
"Unix is supposed to fix that." -- Jay Miner

@KimmoK

Quote:

So far no linux flavour "feels" like AmigaOS.

That's because it's never really been attempted.

Interest in the Amiga is asymptotically approaching zero in the Linux community, and the Amiga community is too small and unfocused to do much in that direction.

_________________
"Unix is supposed to fix that." -- Jay Miner

@Aslak3

Quote:

Aslak3 wrote: The problem here is that OS 9 was crap. The users knew it, and were happy with anything better even if it was radically different. ... I don't personally feel "Amiga" users would feel happy with a Linux kernel and some Amigaish fluff on top.

The idea of "I don't want no Linux kernel because the shell is so complicated" is absolute nonsense.

Some people here might remember the Atari-ST, his OS is related to MS-Dos, it uses the same mechanism for system calls and a lot of internal APIs are the same.

But only a minority will aver have used a dir command on the ST (it did not have a shell)

It is the same like Linux and Android, iPhone, iPad and embedded devices like BluRay players or the router you are using now.

The kernel is absolute independent from GUI or command shell. Systems like AmigaOS and even WindowsXP might have deeply embedded GUI system but Linux (and BSD) can be tailored in such a way that most people woul not notice any difference (when done right).

_________________
AmigaONE. Haha. Just because you can put label on it does not make it Amiga.

I borrowed this comments from here (#27 & #28):
http://amigaworld.net/modules/newbb/viewtopic.php?topic_id=38873&forum=2&start=20&order=0

@IntuitionAmiga and @Crumb

Where to start?

Python is highly adapted to amigaos with full support for many amigaos features.

Yes it uses shared objects and yes these aren't shared is the sense that there is only one copy in memeory at a time but...

Python is 2Mb in size not 5Mb

It only loads those modules that it needs. Perl is a bit bigger (but then perl is) but it still only loads external modules that it needs.

Previous ports (for amiga 3.x and less) of python / perl etc had to be staticaly compiled and could not load binaray modules.

Shared Objects give access to shared data which amiga shared libraries don't, since many of these languages and application reply on that it vastly simplifies porting.

Shared Objects also allow sharing of code between each other. That means when python or perl loads one module all other modules can see that module.

A good example of why this is essential is my previous port of perl 5.8 to AmigaOS 4.0 breacuse it was restricted to using clib2 it could not use shared objext and thus I had to contrive away implmenting dynamic modules, I managed but they still could not see each others code. Thus when I came to perlSDL and subsequetly Bubbles I couldn't just load perlSDL module and use from the Bubbles module code I to had build perlSDL into the bubbles module statically. Making it huge!


Now I certainly wouldn't use shared objscts for a pure amiga program like SketchBlock (except very indirectly via python scripts I suppose) but they are exceptionaly useful for certain types of project. Thier usage does not imply anything quick or dirty.


ARExx is great I use it alot , but python is faster, a bit slower of the starting block but for longer scripts with alot of striing and file processing python runs very quickly.

I recently wrote an ARExx script to parse the SDK and extract certain data from it, took half and hour to run.

I even more recently wrote a similar script in python, it took 2.6 seconds to run.

Python, perl and some others can also drive application vua ARexx ports so that aspect of amiganess is not lost.

Horses for courses but shared objects do not diminish AmigaOS. And they certainly don't use up all your memory.

Last edited by broadblues on 29-Oct-2013 at 07:27 PM.

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

@KimmoK

Quote:

So far no linux flavour "feels" like AmigaOS.

http://www.hd-zone.com/amithlon/

@broadblues

Quote:

Horses for courses but shared objects do not diminish AmigaOS. And they certainly don't use up all your memory.

But that doesn't detract from the fact that Krashan's lua.library is the Amiga way of doing things.

@IntuitionAmiga

Quote:

But that doesn't detract from the fact that Krashan's lua.library is the Amiga way of doing things.

I dont know what Krashan's lua.libray can do. Can it do all the above I described? Not sure if lua supports dynamic modules, if so can Krashans version load them? Is the code maintainable? And aspect I missed out in the above is that the reduced changes to the source make for easier upgrading.

Personally I would only use shared objsct when porting an app that needed someform of dynamic module loading, otherwise I would build it statically.

Also the two are not mutually exclusive, for example blender uses shared objects primaraially for python support, but ofcourse MiniGL is an Amiga style shared library (as are acouple of other dependencies IIRC) and it uses amiga shared libraries for it's plugins as there was no data or code sharing requirement (just a simple callback) and I implmented that aprt before I got shared building working.

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

@Crumb

Quote:

I would prefer that it used some *BSD kernel.

do you think it would be a better solution than mounting arix atop of linux? there is an amiga (68k) bsd maintainer, who also introduced a lot of amiga hardware to bsd support, perhaps he could be moved to work out such a solution given some kind of bounty?

@Crumb

What is 5Mb of ram when you have 2Gbytes in your system? Nothing

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS