This could be avoided if people could test and see what is supported automatically, needs configuration and what is unsupported.How should it look? Do you mean adding test to AROS:Tools/InstallAROS ?
no... when Win 10 was introduced you could download a separate software that showed you if your hardware is win 10 compatible and where problems might arise. Something like that would help to avoid frustrations by failed installations. If you know aros will not work on your hardware configuration you do not need to download aros at all. Of course it could be integrated in install also but it should be also available as separate software. Or if you own more than one device you could test what is best supported and do not need to waste lots of time trying to get it running on the different devices.You probably understand that the developers of AROS are developing AROS, and not applications for Windows, Linux and the devil in a mortar where AROS can be run? This is a completely unreal story. You can come up with the Tools / TestAROS utility that will check the existing equipment and find out whether or not drivers are found for it. Moreover, the fact that the drivers are found doesn't guarantee performance. We have ac97.audio in AHI Prefs under VirtualBOX, this doesn't mean that you will hear the sound.
... so people just put the CD in ...Now.. that is more a deal breaker for most users that are unaware of AROS and it's peculiarities. Nobody is using cd's or dvd's anymore in this day and age, and even when they do there is the multitude of those that believe it's should be no problem to write the darn thing at speed x 32 and expect to boot from it.
one idea I just had was a hardware compatibility test software. One reason for frustration propably always was people tried to install aros and it not worked or not fully worked. I know there are wiki pages with lists of supported hardware (do not know if those are up to date) but most people are propably lazy. They certainly do not look in the lists and compare it to the hardware. Very propably they download a distribution and try to install it, if it not works they put it away and say aros is useless on a forum. This could be avoided if people could test and see what is supported automatically, needs configuration and what is unsupported.A wikipage is a bad idea.
needed is a simple database (even in CSV format) that collects the list of peripherals (with their PCI ids, and maybe some comment about the compatibility level) that are supported by AROS.Attach the file hardware_database.csv to your next post. I suggest you keep it up to date.
We? Who? You? Since you're already working on AROS and seems interested on this task, you can start taking a look at how AROS gathers the PCI info from the system, and report the minimum set of data (included their type) that should go on the CSV, to define the file format.needed is a simple database (even in CSV format) that collects the list of peripherals (with their PCI ids, and maybe some comment about the compatibility level) that are supported by AROS.Attach the file hardware_database.csv to your next post. I suggest you keep it up to date.
We will write the application somehow: we will rely on your file. ;)
What could do done is to make some kind of "amithlon" system.
Take linux kernel and AROS hosted. Use an up to date Amiga 68k emulator with AROS 68 roms and system.
There you have a legal, ready set up Amiga 68k emulator.
The emulator boots into Amiga 68k workbench and from there it is possible from a menu to insert disks, adf files and change hardware configurations. Amiga 500, Amiga 4000, amount of fast ram, chip ram etc.
What could do done is to make some kind of "amithlon" system.
Take linux kernel and AROS hosted. Use an up to date Amiga 68k emulator with AROS 68 roms and system.
There you have a legal, ready set up Amiga 68k emulator.
The emulator boots into Amiga 68k workbench and from there it is possible from a menu to insert disks, adf files and change hardware configurations. Amiga 500, Amiga 4000, amount of fast ram, chip ram etc.
Pascal long ago did something like that. He used Knoppix and it booted in FS-UAE (from Stick)
unfortunately outside winuae all emulators are outdated. Even FS-UAE is not updated for a long time (linux last updated 2018)
better than 2007 in any case ;)
in my view 68k integration is the most important feature for amiga user
more important for aros than SMP or MP
better than 2007 in any case ;)
in my view 68k integration is the most important feature for amiga user
more important for aros than SMP or MP
Most people do not even know what SMP or MP is :D
You are therefore 100% correct.
If we made a free very user friendly 68k emulator it would for sure be a success.
I think the best would be if it ran from a Icon on your Windows or Linux OS.
I understand people would say "why not just run FS-UAE or WinUAE then"
Well, it is cause they are difficult to set up. On top of that you have a very powerful hosted Amiga like system to play with.
better than 2007 in any case ;)
in my view 68k integration is the most important feature for amiga user
more important for aros than SMP or MP
Most people do not even know what SMP or MP is :D
You are therefore 100% correct.
If we made a free very user friendly 68k emulator it would for sure be a success.
I think the best would be if it ran from a Icon on your Windows or Linux OS.
I understand people would say "why not just run FS-UAE or WinUAE then"
Well, it is cause they are difficult to set up. On top of that you have a very powerful hosted Amiga like system to play with.
To extend hosted would be a good idea indeed. It would solve the driver problems. Of course it would need extended support of the host system. But it would create interest in the other aros platforms. Aros 68k is now indeed used as main platform. There is no reason why the same should not happrn on other platforms. I remember when people asked why using aros when you have amigaos. And despite of that people are now using aros as main system on amiga. Perhaps it is possible to make that happen on other platforms too.
Aros is of course more demanding as amigaos on limited hardware like A500 or A1200
I see no problem there. But it is a nice option for new hardware like vampire. The current growing market (real hardware) on 68k is vampire-related. We talk of several thousands of users there currently
Aros is of course more demanding as amigaos on limited hardware like A500 or A1200
I see no problem there. But it is a nice option for new hardware like vampire. The current growing market (real hardware) on 68k is vampire-related. We talk of several thousands of users there currently
Let's hope they stick with AROS 68k. I never tried Vampire, but it is looking good from what I have seen. Not my cup of tea, as I like the original Amiga hardware and for more powerful Amiga systems I rather use AROS.
1. imho it would be more productive if users just could use one of those many pen-drive tools that allows them to install a .iso to it and be able to boot from it. That i am able to abuses hosted for it, is one thing but i do not expect a noob to be able do that.
2. Other than that, i like the idea about checking configurations. Paolone already did such a thing by allowing people to report their (supported) hardware. Since i have never heard of it again (good or bad), i can only assume that was a dead-end ?
@AgressorYep, a bit
you are a little sarcastic, arenīt you? ;)
This thread is for collecting ideas, not to decide about what is possible and in which time frameI dont understand why to pound water in a mortar.
If we made a free very user friendly 68k emulator it would for sure be a success.Take and create. What's stopping? It's just a matter of time taken.
Indeed. And here come two suggestions:1. +1, but I may say +2, +100 or +1000. I can't count how many times I had to delude people who tried to turn Icaros ISOs into USB pendrives using uNetbootin, Rufus and similar tools. There is a quite simple procedure to create an AROS installation pendrive, and I even made it even simplier with the "Create USB installation pendrive" script in the root of Icaros DVDs, but giving the damn ISO to a Rufus-like tool would be faaaaaar simplier.
1. imho it would be more productive if users just could use one of those many pen-drive tools that allows them to install a .iso to it and be able to boot from it. That i am able to abuses hosted for it, is one thing but i do not expect a noob to be able do that.
2. Other than that, i like the idea about checking configurations. Paolone already did such a thing by allowing people to report their (supported) hardware. Since i have never heard of it again (good or bad), i can only assume that was a dead-end ?
2. It's still inside the guts of Icaros Desktop and I am quite sure it is still working today. It's a pity no one reads the documentation and every day people repeat the same questions like parrots.I assume that you're talking about this:
"3.8 Sending bug reports to AROS and 3rd party software developers
[...]
Your PC specs -> open PCITool and save this information on RAM, then copy it somewhere"
Just look to this thread, with people asking things Icaros is doing for a decade.Maybe time for a quick FAQ with the relevant points? A 151 pages manual might be too much and discourage people, albeit it's a masterpiece since it has really all documentation/information needed.
With any hardware made last 10 years you will not have a supported network chip. You will neither have native gfx, VESA will work.
in my view 68k integration is the most important feature for amiga user
Okay, here's an idea: non-Zune (GUI) distro but with any other desktop environment like KDE (https://en.wikipedia.org/wiki/KDE) or MATE (https://en.wikipedia.org/wiki/MATE_(software)). I've read that AROS is POSIX compatible, so there probably shouldn't be any technical problems.
2) As a temporary solution to the above 1), provide an Icaros or AROS ISO that internally is SFS native, so that it can be immediately used after "burning" with Rufus et similia, without the burden of the complete installation process. As you already reported in your blog, nowadays we have PLENTY of resources: just use them! It's completely pointless and a waste of time trying to save some space by selecting what components/tools/applications install, when the full installation of Icaros takes just 6 or even 5 GB of total space.
So, the idea is: you "burn" the (NON-live!) ISO. Boot the USB Pen. And you have an already, fully prepared, Icaros/AROS installation. Then the only thing which is missing is configuring some user settings (language/locale, etc.), but this requires seconds, and then you can immediately use the installed o.s..
This will turn Icaros/AROS in a "quasi-live" distro.
AROS, and the Amiga o.s. in general, is not POSIX-compatible.AROS and AmigaOS 4 almost POSIX compliant.
If you look at the bottom ofI decided (perhaps foolishly) to install a Docker Desktop with WLS2.
https://aros.sourceforge.io/pictures/screenshots/
you'll see 2 screenshots from 1997 when AROS was using with X11 windows :-)
I'm using Windows, so I don't know how to do it with my machine.2) As a temporary solution to the above 1), provide an Icaros or AROS ISO that internally is SFS native, so that it can be immediately used after "burning" with Rufus et similia, without the burden of the complete installation process. As you already reported in your blog, nowadays we have PLENTY of resources: just use them! It's completely pointless and a waste of time trying to save some space by selecting what components/tools/applications install, when the full installation of Icaros takes just 6 or even 5 GB of total space.
So, the idea is: you "burn" the (NON-live!) ISO. Boot the USB Pen. And you have an already, fully prepared, Icaros/AROS installation. Then the only thing which is missing is configuring some user settings (language/locale, etc.), but this requires seconds, and then you can immediately use the installed o.s..
This will turn Icaros/AROS in a "quasi-live" distro.
That's a fuckin' great idea! I just don't know how to create such a ISO file from a SFS partition. AROS hasn't a suitable filesystem, able to handle 4GB+ large files, and I guess I could create a VM, install Icaros on it, attach the .vmdk file to a Linux machine, and then use some tool there. But... what? and how?
AROS, and the Amiga o.s. in general, is not POSIX-compatible.AROS and AmigaOS 4 almost POSIX compliant. Linux does not have full POSIX compatibility either (doesn't need it, has LSB - Linux Standard Base).KDE isn't related to POSIX. Johndoe was just joking. I liked it for a great joke. ;D
AROS, and the Amiga o.s. in general, is not POSIX-compatible.AROS and AmigaOS 4 almost POSIX compliant.
Linux does not have full POSIX compatibility either (doesn't need it, has LSB - Linux Standard Base).
KDE isn't related to POSIX. Johndoe was just joking.
I liked it for a great joke. ;D
I'm using Windows, so I don't know how to do it with my machine.It explains everything
But AFAIK Linux supports SFSWhere do you get this nonsense?
I hope that this helps and... works! :)Why do you write something that you don't know and haven't tested?
Yes, I know that Linux isn't fully POSIX-compliant. :)When you write about compatibility with POSIX and aren't joking, write the standard of what year you mean.
However at least it has the fork() API, which is missing on AROS and any other Amiga o.s./-like system. That's the major problem when porting apps from the Unix/POSIX/Linux worlds to one of those amigaoid platforms. :-/Fork() is one of 100,500+ cross-compilation problems and not the first in importance. If you are talking about POSIX, then the modern standard is POSIX threads (pthreads). I give you a link for free: POSIX Threads for AROS and MorphOS (https://github.com/BSzili/aros-stuff/tree/master/pthreads). fork() call in most cases is replaced by stubs, wrappers and emulations, even on Linux projects, for example, in SDL.
Okay, forget about Posix. Anyway, does the idea of replacing the Zune with another DE seem interesting to you?Tell me where you saw in AmigaOS something similar to display manager in X11/XOrg like xdm, gdm, kdm and 100500+ dm? Gnome and KDE apps can be ported to AmigaOS 4, MorphOS and AROS. At the same time, they will terribly slow down, but in principle, this has already been done more than once. The appearance of windows in KDE doesn't matter, Zune has much more control over application windows.
Where did you saw that I don't know Linux?I'm using Windows, so I don't know how to do it with my machine.It explains everything
Really? What an incredible "new" you gave me...But AFAIK Linux supports SFSWhere do you get this nonsense?
1) Linux is kernel.
2) No, only support for affs (Amiga Fast File System) can be compiled into Linux kernels, and offers full read, write and format support on FFS and OFS partitions of all dostypes except DOS\6 and DOS\7 (which are probably incredibly rare).After a simple search: https://github.com/nosway/sfs
Because... I can? Do you know that this thread about ideas? Do you understand the topic of thread before start writing on it?I hope that this helps and... works! :)Why do you write something that you don't know and haven't tested?
I never have written non-sense about POSIX: this is only in your imagination.Yes, I know that Linux isn't fully POSIX-compliant. :)When you write about compatibility with POSIX and aren't joking, write the standard of what year you mean.
In fact, Linux just doesn't have a POSIX certificate and, for example, MacOS X has UNIX 03 certificate. Even Windows NT has a POSIX certificate, and got it before Solaris. It's a matter of the money paid for the certificate. Open source platforms won't pay money. Amiga won't pay money. If you try to make some programming for Mac, you will see that lot of UNIX functions or their modes are missing in MacOS X, while these functions and modes are available on Linux, modern BSD or commercial UNIX such AIX. So don't write nonsense about POSIX.
First, fork is one of the most used APIs in the Unix world.However at least it has the fork() API, which is missing on AROS and any other Amiga o.s./-like system. That's the major problem when porting apps from the Unix/POSIX/Linux worlds to one of those amigaoid platforms. :-/Fork() is one of 100,500+ cross-compilation problems and not the first in importance. If you are talking about POSIX, then the modern standard is POSIX threads (pthreads). I give you a link for free: POSIX Threads for AROS and MorphOS (https://github.com/BSzili/aros-stuff/tree/master/pthreads). fork() call in most cases is replaced by stubs, wrappers and emulations, even on Linux projects, for example, in SDL.
Where did you saw that I don't know Linux?At least you are making far-reaching conclusions about the Linux ecosystem for no apparent reason.
After a simple search: https://github.com/nosway/sfsSo what? You really don't see the difference between: "Linux supports SFS" and "I found on github"?
First, fork is one of the most used APIs in the Unix world.First, statements must be confirmed. Why do you think so? fork() was written in 1962! I actually don't see a fork of 99 out of 100 modern apps. Its implementation is hidden or replaced by another. What are you going to transfer that you are so annoyed with the fork?
Second, pthreads are an horrible patch over the consolidated process model in the Unix world.Again, it isn't clear what this is based on. pthreads needed when porting often, e.g. for networked multithreaded applications. The link to one of the realizations that I personally use was given above.
you need to rewrite the existing code trying to see if there can be another API or workaround.Yes! When I port something I constantly rewrite implementations or borrow ready-made ones that have already been rewritten. I don't see a fork, but this is one of the 100500+ problems that can occur. The directive will be individually set and changed to vfork() or pthread_create() or another.
This requires time, and not even the guarantee to succeed (otherwise a lot more applications would already be ported to AROS or other o.sed.).Up to 90% of all AROS applications are ported or adapted from *nix. The only reason why large projects aren't ported is that there are no people willing to spend time on this and also there are no people willing to learn, but there are plenty of theoreticians.
Do you understand the topic of thread before start writing on it?Do you understand the difference between an idea and an unscientific fiction?
You're making wrong assumptions, as usual, since you don't understand what people is writing, and therefore you reply with non-sense.Where did you saw that I don't know Linux?At least you are making far-reaching conclusions about the Linux ecosystem for no apparent reason.
No. The goal is to read/write SFS on Linux, and whether it comes from from the master or from an external repository is irrelevant.After a simple search: https://github.com/nosway/sfs (https://github.com/nosway/sfs)So what? You really don't see the difference between: "Linux supports SFS" and "I found on github"?
Who cares when it was written.First, fork is one of the most used APIs in the Unix world.First, statements must be confirmed. Why do you think so? fork() was written in 1962!
I actually don't see a fork of 99 out of 100 modern apps.What you see or not is totally irrelevant, and at least it shows how limited is your vision and experience.
pid_t pid = fork();
331 switch (pid) {Chromium is a MODERN application (read: not from 1962) and it's clearly visible that it's using fork().Its implementation is hiddenIf it's hidden it means that it's still there, elementary logic at hands, and so the problem remains...
or replaced by another.Same as above: irrelevant. It only proves that you're a noob in the Unix world.
What are you going to transfer that you are so annoyed with the fork?Maybe because I know how AROS and an Amiga/like o.s. works, and that fork is a black beast for them?
And so? Then try to remove fork() from Chromium and give a modern browser (which is really needed. Current ones are outdated) to AROS, using pthreads instead.Second, pthreads are an horrible patch over the consolidated process model in the Unix world.Again, it isn't clear what this is based on. pthreads needed when porting often, e.g. for networked multithreaded applications. The link to one of the realizations that I personally use was given above.
And so? Have I ever stated that fork is the only problem when porting apps (to the Amiga land)?you need to rewrite the existing code trying to see if there can be another API or workaround.Yes! When I port something I constantly rewrite implementations or borrow ready-made ones that have already been rewritten. I don't see a fork, but this is one of the 100500+ problems that can occur. The directive will be individually set and changed to vfork() or pthread_create() or another.
These are private things that simply accompany any porting, and not a universal disaster.
And so? This mean nothing. Many many others are missing, even very useful ones, and you don't know if porting some of them is easy like the above 90% ones.This requires time, and not even the guarantee to succeed (otherwise a lot more applications would already be ported to AROS or other o.sed.).Up to 90% of all AROS applications are ported or adapted from *nix.
The only reason why large projects aren't ported is that there are no people willing to spend time on this and also there are no people willing to learn,Wrong. Take a look at the recent browser for MorphOS, which was written (porting Chromium, AFAIR) by a SINGLE person, and it's being continuously and frequently updated. Don't tell me that it's an easy task. But it was made by ONE person.
but there are plenty of theoreticians.Clap clap clap. You made the dig of the day. What's next?
Unscientific fiction? Like this one that you've written:Do you understand the topic of thread before start writing on it?Do you understand the difference between an idea and an unscientific fiction?
"Attach the file hardware_database.csv to your next post. I suggest you keep it up to date.Why do you undertake to propose if you cannot do such a simple thing? are you waiting for someone else to do it? Who?
We will write the application somehow: we will rely on your file."
@cdimauro
You wrote a lot of nonsense and got personal. I will not answer you point by point.
I will answer in essence. Chromium is just one application for platforms that have a fork() call.
In fact, I will give you a hint: pthread_create also uses fork().
It makes sense to make a fork() call on those platforms that have it.
On the Amiga it doesn't make sense, so the implementation changes.
However, your source code may still contain fork(), pthread_create(), anything else
This is not a problem if appropriate wrappers have been written.
aminet, os4depot, aros-exec.org has a bunch of applications and modern games ported from Linux and not using the fork () call
Well, there are ~150 of mine, of course, this isn't enough to judge. ;)Quote"Attach the file hardware_database.csv to your next post. I suggest you keep it up to date.Why do you undertake to propose if you cannot do such a simple thing? are you waiting for someone else to do it? Who?
We will write the application somehow: we will rely on your file."
Don't hit the dog if you don't want to be torn...You decided that you were offended, but there was nothing to be offended. We have different mentality. If you criticize then offer, but if offered then do. I wasn't going to re-educate you.
Chromium was just an example, and I can find others, but this isn't the point. As well talking about pthread_create isn't the point as well. The real point is that for replacing fork you should understand how the application/code works, manages its resources, and therefore if fork can be replaced by another simpler API or some alternative code to workaround the massive (all!) duplication of resources that forks normally does. So, it requires deep understanding of the application behavior, and this takes time.Yes. This is the usual porting job. Such programs in C that you can just take and compile everywhere as is are found only in dreams. AROS has done a lot to make it easier and greatly influenced the ecosystems of AmigaOS descendants (AOS4 and MOS). However, it didnt turn into "take and compile". Exactly the same in other systems (for example, porting from Linux to Windows). For the program to be cross-platform, it must be immediately designed cross-platform, taking into account the capabilities of the supported platforms. I think it's common knowledge.
Finally and regarding the CSV, before proceeding it's necessary to understand what information should be collected. So, this requires time to check what's needed, the data to be collected, and how to do it. Only after that you can define the fields on the CSV (or any other format which better suites the goal). Once defined the format, the code for gathering the data and filling the CSV can be worked on. And so on. So, and in short, it's necessary to define the requirements from the proposed idea. Only after that you can proceed.Yes. That's why I suggested doing all this (without the data collection code), and then, I could put myself in a plan to make an interface, collect data and compare them. Other developers also would cope with this task, there are people here who know Lua (I don't know him), Pascal (wrote in Pascal and Delphi for a very, very long time). Your idea rests on the human factor: who will collect and update the data. This is a whole project. Therefore, question number One: who will do it. It doesn't matter who writes the program. Anyone who is interested in the idea will write. Without data, it's like a wish for good weather.
BTW, why you're assuming that the ones which are proposing some ideas should work on them? This is a thread which just collects ideas, and where I contributed with some of them. Dot. I've other, personal projects which keep me busy. That's it.I get it. Let's try to translate an anecdote for you?
Tell me where you saw in AmigaOS something similar to display manager in X11/XOrg like xdm, gdm, kdm and 100500+ dm? Gnome and KDE apps can be ported to AmigaOS 4, MorphOS and AROS. At the same time, they will terribly slow down, but in principle, this has already been done more than once. The appearance of windows in KDE doesn't matter, Zune has much more control over application windows.
How did you come from "attacked" to "offended"? Do you know the differences between those two verbs, or should I put a link to the Collin's?Don't hit the dog if you don't want to be torn...You decided that you were offended, but there was nothing to be offended. We have different mentality. If you criticize then offer, but if offered then do. I wasn't going to re-educate you.
No: it's absolutely not common knowledge. And that's because it's up to the developer decide on which platform his application should run. Platforms can be very different, and a developer should take a decision about which one or more should be supported. Writing portable code has a cost, which some developers don't want to pay. Or, more simpler, developers can have knowledge limited to one or a few platforms, which prevents them to write code portable to others. Finally, there are developers which on purpose do NOT want to support some platforms (a notable example: the Node.js developer/s, which explicitly refused to support Windows. Then Microsoft had to pay for it).Chromium was just an example, and I can find others, but this isn't the point. As well talking about pthread_create isn't the point as well. The real point is that for replacing fork you should understand how the application/code works, manages its resources, and therefore if fork can be replaced by another simpler API or some alternative code to workaround the massive (all!) duplication of resources that forks normally does. So, it requires deep understanding of the application behavior, and this takes time.Yes. This is the usual porting job. Such programs in C that you can just take and compile everywhere as is are found only in dreams. AROS has done a lot to make it easier and greatly influenced the ecosystems of AmigaOS descendants (AOS4 and MOS). However, it didnt turn into "take and compile". Exactly the same in other systems (for example, porting from Linux to Windows). For the program to be cross-platform, it must be immediately designed cross-platform, taking into account the capabilities of the supported platforms. I think it's common knowledge.
As I've already said, the problem is defining what information is needed for the CSV, and this requires that some AROS developer (which has knowledge in that low-level field) should support.Finally and regarding the CSV, before proceeding it's necessary to understand what information should be collected. So, this requires time to check what's needed, the data to be collected, and how to do it. Only after that you can define the fields on the CSV (or any other format which better suites the goal). Once defined the format, the code for gathering the data and filling the CSV can be worked on. And so on. So, and in short, it's necessary to define the requirements from the proposed idea. Only after that you can proceed.Yes. That's why I suggested doing all this (without the data collection code), and then, I could put myself in a plan to make an interface, collect data and compare them. Other developers also would cope with this task, there are people here who know Lua (I don't know him), Pascal (wrote in Pascal and Delphi for a very, very long time).
Your idea rests on the human factor: who will collect and update the data. This is a whole project. Therefore, question number One: who will do it. It doesn't matter who writes the program. Anyone who is interested in the idea will write. Without data, it's like a wish for good weather.Since the goal is (and should always be) to make the life easy to the users, they should just select an item on a menu (like when sending the report to Icaros).
Again? What's not clear to you about this:BTW, why you're assuming that the ones which are proposing some ideas should work on them? This is a thread which just collects ideas, and where I contributed with some of them. Dot. I've other, personal projects which keep me busy. That's it.I get it. Let's try to translate an anecdote for you?
Hedgehogs come to the wise old owl and ask her: how can we make sure that wild animals do not eat us?
The owl thought and answered: hedgehogs need to become lions. No one eats lions and everyone is afraid.
The hedgehogs were delighted, thanked the owl and got ready to leave.
Then one silly little hedgehog asked the owl: how can we become lions?
The owl answered him: I have already explained the strategy to you, but deal with the tactics yourself.
How did you come from "attacked" to "offended"? Do you know the differences between those two verbs, or should I put a link to the Collin's?Who is Collin's? I can send you to the Ozhegov dictionary. :D
You continue to don't understand what people is writing, and taking different conclusions.Again you are talking about yourself in the plural. For example, I agree with OlafS3 comment earlier and didn't comment on it. Some of your unsubstantiated statements cause concern, because beginners can read them, remember and consider them true about AROS and Amiga. The problem is not that someone on the Internet is wrong (no matter), but that there are too few of us, and casual readers will no longer try to test the theory in practice. this is how a sect of believers in insurmountable difficulties appears
No: it's absolutely not common knowledge.Badly. You can open any cross platform tutorial and it will be written there on the first pages.
And that's because it's up to the developer decide on which platform his application should run. [..] Finally, there are developers which on purpose do NOT want to support some platforms (a notable example: the Node.js developer/s, which explicitly refused to support Windows. Then Microsoft had to pay for it).You have described cases where the developer does NOT want to create a cross-platform application, or when he wants to create an application LIMITED to specific platforms. I wrote about a situation when a developer needs to write an application that works, for example, on Linux, Windows and like AmigaOS. Besides the fact that there are real examples like Hollywood, flexcat, etc, I design such applications myself (mostly console).
And the more complex is the application, then more complicated is writing portable code. Think about an application that has a GUI, and you can easily have nightmares considering how many different native APIs and toolkits are available for different platforms.No. Any application is divided into logic and interface. The logic doesn't change. complexity is caused by the popularity of frameworks. The lack of frameworks and libraries from one platform to another leads to a monstrous waste of human time. Therefore the tools must be selected before development. The creation of graphical interfaces is simplified as much as possible today. You just have to create your own similar interface.
As I've already said, the problem is defining what information is needed for the CSV, and this requires that some AROS developer (which has knowledge in that low-level field) should support.I am not familiar with this AROS developer. But he would be like a developer who programs neural networks with one hand and repairs teapots with the other.
Since the goal is (and should always be) to make the life easy to the users, they should just select an item on a menu (like when sending the report to Icaros).I'm not sure if Paolo is ready to analyze these reports, I have to ask him. ;D
As you can see, it's the usual matter of writing the project's requirements (functional and non functional) and clearly defining the actors and goals.We started with this. I asked: who will do it, provide all the infrastructure and feedback. Offered to you, but for some reason you refused and offended. ;D Based on formal logic, we will see the same natural reaction from any AROS developer to whom you want to entrust this idea. The developer must have resources, a penchant for monotonous work, knowledge of the hardware in relation to the current AROS code base and work full time. it's a pity that he should not be able to fly. ;D
Again? What's not clear to you about this:Did you not like the anecdote? I'm sorry, I tried.
https://www.collinsdictionary.comHow did you come from "attacked" to "offended"? Do you know the differences between those two verbs, or should I put a link to the Collin's?Who is Collin's? I can send you to the Ozhegov dictionary. :D
In Russian you are called "offended" (English is very scarce, very few shades of words), welcome.Guess what: we're speaking English, and not Russian...
Aren't you tired of complaining?No, since you're continuing, trying to change the cards on the table, instead of admitting what you did and putting a tombstone on it.
Only to you, because you don't understand. Nothing of what I've written is "unsubstantiated". You can quote me and show me the contrary if you think differently, since it's YOUR statement, and YOU have to prove it.You continue to don't understand what people is writing, and taking different conclusions.Again you are talking about yourself in the plural. For example, I agree with OlafS3 comment earlier and didn't comment on it. Some of your unsubstantiated statements cause concern,
because beginners can read them, remember and consider them true about AROS and Amiga. The problem is not that someone on the Internet is wrong (no matter), but that there are too few of us, and casual readers will no longer try to test the theory in practice. this is how a sect of believers in insurmountable difficulties appearsThere's nothing like that in this thread, but you can show me it, in case (see above).
Irrelevant: I've already reported all possible cases / scenarios, and what you're saying applies only to some.No: it's absolutely not common knowledge.Badly. You can open any cross platform tutorial and it will be written there on the first pages.
Which... rolling drum... is the reality. And a good part of it, otherwise Windows wasn't the platform with the vast majority of software, just to give the most notable example.And that's because it's up to the developer decide on which platform his application should run. [..] Finally, there are developers which on purpose do NOT want to support some platforms (a notable example: the Node.js developer/s, which explicitly refused to support Windows. Then Microsoft had to pay for it).You have described cases where the developer does NOT want to create a cross-platform application, or when he wants to create an application LIMITED to specific platforms.
I wrote about a situation when a developer needs to write an application that works, for example, on Linux, Windows and like AmigaOS. Besides the fact that there are real examples like Hollywood, flexcat, etc, I design such applications myself (mostly console).You are you, and not the vast majority of developers, which think and act differently.
You're clearly lacking experience on designing applications with GUIs. Even the business logic can change drastically when using a specific platform/toolkit. And even a specific platform can you give different ways to do the same things: think about Windows and the GUI APIs for Win32, .NET 1.x, .NET 2.x, .NET/WinForms, .NET/Silverlight, .NET/WPF, UWP.And the more complex is the application, then more complicated is writing portable code. Think about an application that has a GUI, and you can easily have nightmares considering how many different native APIs and toolkits are available for different platforms.No. Any application is divided into logic and interface. The logic doesn't change. complexity is caused by the popularity of frameworks. The lack of frameworks and libraries from one platform to another leads to a monstrous waste of human time. Therefore the tools must be selected before development. The creation of graphical interfaces is simplified as much as possible today. You just have to create your own similar interface.
Before the advent of object-oriented programming and frameworks, a team of two or three people released their game to a dozen microcomputers. It's not a problem to know, for example, a simple and friendly m68k asm, a simple as a cork z80 asm, etc, convert graphics, since the logic doesn't change. Today we have much more opportunities.
Might be. But in this case it's required that he just knows how AROS handles the PCI (and USB) peripherals, and the minimum set of their data to be stored in the CSV.As I've already said, the problem is defining what information is needed for the CSV, and this requires that some AROS developer (which has knowledge in that low-level field) should support.I am not familiar with this AROS developer. But he would be like a developer who programs neural networks with one hand and repairs teapots with the other.
He shouldn't: this is a task better suited for a developer. Or at least someone which has enough technical knowledge about the above arguments.Since the goal is (and should always be) to make the life easy to the users, they should just select an item on a menu (like when sending the report to Icaros).I'm not sure if Paolo is ready to analyze these reports, I have to ask him. ;D
Based on the formal logic you don't know if the person which is sharing an idea is capable of contributing in some way on its implementation.As you can see, it's the usual matter of writing the project's requirements (functional and non functional) and clearly defining the actors and goals.We started with this. I asked: who will do it, provide all the infrastructure and feedback. Offered to you, but for some reason you refused and offended. ;D Based on formal logic, we will see the same natural reaction from any AROS developer to whom you want to entrust this idea. The developer must have resources, a penchant for monotonous work, knowledge of the hardware in relation to the current AROS code base and work full time. it's a pity that he should not be able to fly. ;D
As usual, yours are non-sense, since you continue to don't understand what people is writing, and drawing your own conclusions (which are wrong, of course).Again? What's not clear to you about this:Did you not like the anecdote? I'm sorry, I tried.
I concluded that you have ideas for world domination, but you do not want them to be embodied in reality, because at the moment you are busy.
I suggested that you make some kind of lightweight compromise, but you flatly refused.You aren't in a position to suggest or offer something on the AROS land, because you don't know how the things work here: see above.
Is that correct?No. You continue to draw wrong conclusions. As I've already said, I suggest you to better trying to understand what people says, BEFORE writing something.
In turn, I see no problem discussing ideas with their implementation together.Me neither. Since it's a thread -> discussion is a natural thing.
And now a final question to you: doesn't your "formal logic" suggest you that you're wasting a lot of time arguing about stupid things, instead of using it for some concrete work?
The special script you crufted for that works splendidly (thank you for that) but indeed it would be much simpler that way.
1. imho it would be more productive if users just could use one of those many pen-drive tools that allows them to install a .iso to it and be able to boot from it. That i am able to abuses hosted for it, is one thing but i do not expect a noob to be able do that.
2. Other than that, i like the idea about checking configurations. Paolone already did such a thing by allowing people to report their (supported) hardware. Since i have never heard of it again (good or bad), i can only assume that was a dead-end ?
1. +1, but I may say +2, +100 or +1000. I can't count how many times I had to delude people who tried to turn Icaros ISOs into USB pendrives using uNetbootin, Rufus and similar tools. There is a quite simple procedure to create an AROS installation pendrive, and I even made it even simplier with the "Create USB installation pendrive" script in the root of Icaros DVDs, but giving the damn ISO to a Rufus-like tool would be faaaaaar simplier.
2. It's still inside the guts of Icaros Desktop and I am quite sure it is still working today. It's a pity no one reads the documentation and every day people repeat the same questions like parrots.Indeed. It is really depressing to still have to witness such things.
Just look to this thread, with people asking things Icaros is doing for a decade.
Guess what: we're speaking English, and not Russian...This is a big drawback, but we continue the conversation. ;D
Nothing of what I've written is "unsubstantiated". You can quote me and show me the contrary if you think differently, since it's YOUR statement, and YOU have to prove it.No problems. There is enough rubbish in every answer. Read below
You're clearly lacking experience on designing applications with GUIs. Even the business logic can change drastically when using a specific platform/toolkit. And even a specific platform can you give different ways to do the same things: think about Windows and the GUI APIs for Win32, .NET 1.x, .NET 2.x, .NET/WinForms, .NET/Silverlight, .NET/WPF, UWP.Business logic is a completely different maturity level and tasks. For operating systems like AmigaOS, there are NO applications with business logic, and there never will be. Users of these OS don't need an enterprise bus or interconnect with exadata. It has nothing to do with the separation of logic (not business logic) and application GUI. A stupid calculator written in C # .NET will have the same logic as written in AmigaBasic for AmigaOS. Logic and mathematics don't change, otherwise we did not have anything to rely on. You wrote nonsense against the background of tens of thousands of projects for porting software from mainframes, old microcomputers and programmable calculators to modern platforms with only LOGIC saved! Where are the buttons in GUI and how they look - this is the hundred and twenty-fifth case, which has no meaning. The application can have interchangeable GUI and CLI interface, no problem. Please, this game was written in 1964 (http://archives.aros-exec.org/index.php?function=showfile&file=game/misc/sumeria.i386-aros.lha), I made it available to you, moreover, it can now work in any number of languages (translated into English and Russian). You think you have problems drawing a graphical interface for Zune, GTK or Avalonia ? No such problems. Will you have to rewrite the code? Yes, it will have to be reformatted. The larger the application, the longer it takes. But this is a dull monotonous job that does not require any intelligence. The only question that always arises is who needs it? If no one needs it, no one will do anything.
Try to port a WPF application to Amiga o.s.|AROS / MUI|Zune, and show me that you're keeping the same exact business logic, while "just" (!) changing the presentation part of the application. I'm taking the popcorns...
And now a final question to you: doesn't your "formal logic" suggest you that you're wasting a lot of time arguing about stupid things, instead of using it for some concrete work?Yes it is fair, but I already gave an answer to this question in a post earlier. I have nothing against you personally and I simply don't answer all your texts with which I AGREE or which NOT MATTER. I answer only to harmful conclusions. Therefore, you are receiving generally negative feedback. Communicating with me you will always have this form of conversation.
So sad to check (once more) that Amigaland only seems to attract this kind of characters. Too bad we need people, but this type is so needlessSeem to be from Spain? Here (https://github.com/aros-translation-team) a lot of work for you. Spanish is hardly supported in AROS, what was done long ago is outdated. Don't thank. ;)
Sadly, I'm afraid you are wasting your time too: I realised he is the kind of person that NEVER EVER will accept his mistakes, or barely any other idea that isn't his ones.The primary problem for me is that he's putting words on my mouth, otherwise I hadn't spent other time with him.
Indeed. It is really depressing to still have to witness such things.What was proposed and discussed is a different thing, and it isn't something which can be achieved writings a few lines of code, even using Python (which is particularly well suited for most of the needed tasks, since it has built-in libraries and requires much less lines of code compared to other languages).
As already noticed, the implementation itself would have taken less code-lines then the number of lines written in this thread on the subject. Not that it is needed as you paolone already did that back for us back in the day 8)
For sure the current implementation could perhaps be modernized but, why bother if nobody seem to have used it in the first place :'(
I agree, and for the same problem. So, yes: see my reply below.Nothing of what I've written is "unsubstantiated". You can quote me and show me the contrary if you think differently, since it's YOUR statement, and YOU have to prove it.No problems. There is enough rubbish in every answer. Read below
Another irrelevant wall-of-text. Here you forgot the context: what we were discussing about. Which was porting applications, and writing portable code.You're clearly lacking experience on designing applications with GUIs. Even the business logic can change drastically when using a specific platform/toolkit. And even a specific platform can you give different ways to do the same things: think about Windows and the GUI APIs for Win32, .NET 1.x, .NET 2.x, .NET/WinForms, .NET/Silverlight, .NET/WPF, UWP.Business logic is a completely different maturity level and tasks. For operating systems like AmigaOS, there are NO applications with business logic, and there never will be. Users of these OS don't need an enterprise bus or interconnect with exadata. It has nothing to do with the separation of logic (not business logic) and application GUI. A stupid calculator written in C # .NET will have the same logic as written in AmigaBasic for AmigaOS. Logic and mathematics don't change, otherwise we did not have anything to rely on. You wrote nonsense against the background of tens of thousands of projects for porting software from mainframes, old microcomputers and programmable calculators to modern platforms with only LOGIC saved! Where are the buttons in GUI and how they look - this is the hundred and twenty-fifth case, which has no meaning. The application can have interchangeable GUI and CLI interface, no problem. Please, this game was written in 1964 (http://archives.aros-exec.org/index.php?function=showfile&file=game/misc/sumeria.i386-aros.lha), I made it available to you, moreover, it can now work in any number of languages (translated into English and Russian). You think you have problems drawing a graphical interface for Zune, GTK or Avalonia ? No such problems. Will you have to rewrite the code? Yes, it will have to be reformatted. The larger the application, the longer it takes. But this is a dull monotonous job that does not require any intelligence. The only question that always arises is who needs it? If no one needs it, no one will do anything.
Try to port a WPF application to Amiga o.s.|AROS / MUI|Zune, and show me that you're keeping the same exact business logic, while "just" (!) changing the presentation part of the application. I'm taking the popcorns...
Yes, the problem is that one: communicating with you. You have serious problems about it, and still continue failing. I suggest you to find some specialist instead of bothering other people.And now a final question to you: doesn't your "formal logic" suggest you that you're wasting a lot of time arguing about stupid things, instead of using it for some concrete work?Yes it is fair, but I already gave an answer to this question in a post earlier. I have nothing against you personally and I simply don't answer all your texts with which I AGREE or which NOT MATTER. I answer only to harmful conclusions. Therefore, you are receiving generally negative feedback. Communicating with me you will always have this form of conversation.
What was proposed and discussed is a different thing, and it isn't something which can be achieved writings a few lines of code, even using Python (which is particularly well suited for most of the needed tasks, since it has built-in libraries and requires much less lines of code compared to other languages).Of course you might have made a proposal (and which isn't a bad one) which works differently from what is currently implemented but ..., why bother ?
The thing that stuck with me over these years is that there seem people around that try to manipulate things to such level to let others to their bidding.And now a final question to you: doesn't your "formal logic" suggest you that you're wasting a lot of time arguing about stupid things, instead of using it for some concrete work?
Sadly, I'm afraid you are wasting your time too: I realised he is the kind of person that NEVER EVER will accept his mistakes, or barely any other idea that isn't his ones.
So sad to check (once more) that Amigaland only seems to attract this kind of characters. Too bad we need people, but this type is so needless
So sad to check (once more) that Amigaland only seems to attract this kind of characters. Too bad we need people, but this type is so needlessSeem to be from Spain? Here (https://github.com/aros-translation-team) a lot of work for you. Spanish is hardly supported in AROS, what was done long ago is outdated. Don't thank. ;)
Indeed. As I've said before, the existing part might be a starting point for this new feature.What was proposed and discussed is a different thing, and it isn't something which can be achieved writings a few lines of code, even using Python (which is particularly well suited for most of the needed tasks, since it has built-in libraries and requires much less lines of code compared to other languages).Of course you might have made a proposal (and which isn't a bad one) which works differently from what is currently implemented but ..., why bother ?
right now:
- obtain data from system
- share data obtained from system
what you seem to propose:
- obtain data from system
- present user with information on already obtained system data from a "huge" database and check their specific system data against it (is it supported or not)
- share data obtained from system
That looks/smells to me as a natural evolution of code that is already in place. Might perhaps be working differently as proposed but as long as the results are the same.
The fact is that current implementation never matured because Paolone indicated back then that it was hardly used (only 2/3 people bothered, but please correct me if wrong).In this case the new tool might be executed transparently the first time that Icaros runs (just after the installation).
As you wrote yourself python having a good stack of libraries, i base my opinion on a good stack of subroutines that i (or anyone else with some decent programming skills) can take a pick from, and make use of the current infrastructure that is in place.Python is a great tool which allows to more quickly fill the gaps in many areas. In fact, it's already used on many Linux / BSD or other o.ses a system tool.
Based on that then yes the discussion on this particular topic is using up more space than it would have in a code-editor :PWriting lines to a forum isn't like writing lines to a code-editor. :) For me it's just relaxing. Taking a project and working on it requires a completely different attitude / focus, at least for me. But maybe it's just my personal problem.
So i end up with the notion of why waste time on yet another implementation (which would end up with similar results) ?
You know, you and me have been going back'n'forwards for more than a decade now, so you should know by now that i am a person of practical implementations, not hypothetical ones :)
No matter how good the intention, practise always seems more reluctant to cooperate and, that seems especially true for AROS/Amiga.
With regards to personal beef between individuals, i am not going to bother with that other than stating that life is simply too short to get upset about these kind of things even though i understand that you wish to defend yourself in case someone put words in your mouth. It is all about perception/interpretation.Especially since we have just one. :)
What was it again... live long and prosper ? ;D
Well, in the end of this long and useful discussion.. any idea for a distribution?I've already suggested what to do: provide one which is already pre-installed with all tools which Icaros provides.
In this case the new tool might be executed transparently the first time that Icaros runs (just after the installation).If all peripherals found are supported then no action is taken.If some is not found on the database, then a report is shown to the user with the current status of its machine, and asking to send the feedback (with some togglebutton which can be used to indicate if the specific peripheral is working fine, not working, or if its status is unknown. Unknown is the default status).
The information comes from the "database" (CSV), or from the user (which selects its experience with a peripheral on its system, which is reported as "unknown" from the new tool).QuoteIn this case the new tool might be executed transparently the first time that Icaros runs (just after the installation).If all peripherals found are supported then no action is taken.If some is not found on the database, then a report is shown to the user with the current status of its machine, and asking to send the feedback (with some togglebutton which can be used to indicate if the specific peripheral is working fine, not working, or if its status is unknown. Unknown is the default status).Hi. Just a question: how does AROS understand by itself if a device (video card, audio card, nic) is actually working or not? AFAIK there is no central probing system but, please forgive me if I am wrong.
Moreover, every relevant setting for hardware is included in envarc:. My old quickconfig tool just backupped relevant files in envarc: into a .zip file with the name of the system, and just allowed restoring it on another AROS machine. So, for instance, if you had an Acer Aspire One laptop, you just needed to give him the acer-aspire-one.zip file to get a working system.Can you share some .zip file?
Nothing more, nothing left.
@cdimauroThere should be some disk layout issue or some difference which is preventing it to work.
I tried creating a bootable AROS partition with vmware, then I converted it with dd into a ISO file, but all I got is a not-bootable ISO file, hence I think turning it into a USB pendrive won't work either.
I tried creating a bootable AROS partition with vmware, then I converted it with dd into a ISO file, but all I got is a not-bootable ISO file, hence I think turning it into a USB pendrive won't work either.When you dump a disk (whether it is in vmware/vbox or an actual physical disk) using dd then you do not create an iso. What you create is a raw image dump of the disk (and which is stored as an image file). Usually these get distributed using gzip or bzip to reduce the filesize.
Can you share some .zip file?
I understand the suggestion made by cdimauro, but i fail to see why the name iso is introduced there (that's an genuine question from my part).Because an ISO file is a 1:1 sectors copy of the physical content of an optical disk (as well as an USB storage), exactly like the 1:1 sectors copy made by the dd command.
OK, thanks.Can you share some .zip file?They've been in Icaros' Storage/Config for years.
Guys, give it a rest in this thread, please. You should all be grown men, above the age of 30. It should be unnecessary for me to have to tell you to behave as grown ups. Do not make me have to close this thread or worse, have to ban some of you.
I do not like to be pestered on email (x amount of times) to check a thread where so called grown ups can not behave.
The PC configuration is stored in a file called hdaudio.config: it's a text file with an "header" (a single line with the "QUERY" string. Sometimes this line is missing), and the following lines just report the Vendor ID and Device ID information in hex format.Can you share some .zip file?
They've been in Icaros' Storage/Config for years.
An important detail that is missing from that statement is that the physical content of a optical disk <> physical content of a USB storage.I understand the suggestion made by cdimauro, but i fail to see why the name iso is introduced there (that's an genuine question from my part).Because an ISO file is a 1:1 sectors copy of the physical content of an optical disk (as well as an USB storage), exactly like the 1:1 sectors copy made by the dd command.
Indeed. And this is why I've written this:Because an ISO file is a 1:1 sectors copy of the physical content of an optical disk (as well as an USB storage), exactly like the 1:1 sectors copy made by the dd command.An important detail that is missing from that statement is that the physical content of a optical disk <> physical content of a USB storage.
What is important there is the how the actual content is 'recognized'/located and subsequently booted. You can test that yourself by dd'ing the icaros iso to a disk. If you put a filesystem (partition layout) on that disk before dd'ing it will then be mounted as iso9660. Faling to create the filesystem beforehand will render the disk unrecognizable.
Please read the link to isolinux that i posted earlier (that also have additional links to el-torito, xoriso, genisoimage etc.) to understand the difference.
--- icaros-pc-i386.iso
Regular file, size 692.9 MiB (726511616 bytes)
ISO9660 file system
Volume name "AROS Live CD"
Publisher "Icaros Desktop"
Preparer "Icaros Desktop (www.icarosdesktop.org)"
Application "GENISOIMAGE ISO 9660/HFS FILESYSTEM CREATOR (C) 1993 E.YOUNGDALE (C) 1997-2006 J.PEARSON/J.SCHILLING (C) 2006-2007 CDRKIT TEAM"
Data size 692.9 MiB (726511616 bytes, 354742 blocks of 2 KiB)
El Torito boot record, catalog at 4315
Bootable non-emulated image, starts at 4316, preloads 2 KiB
Platform 0x00 (x86), System Type 0x00 (Empty)
Joliet extension, volume name "<4152><4F53><204C><6976><6520><4344><2020><2020><2020><2020><2020><2020><2020><2020><2020><2020>"
Joliet extension, volume name "AROS Live CD"
--- icaros_light_2-3-0_pendrive.bin
Regular file, size 1.868 GiB (2005925888 bytes)
GRUB boot loader, unknown compat version 180
DOS/MBR partition map
Partition 1: 1.868 GiB (2005401600 bytes, 3916800 sectors from 1024, bootable)
Type 0x05 (Extended)
Partition 5: 1.867 GiB (2004353024 bytes, 3914752 sectors from 1024+2048)
Type 0x30 (Unknown)
Amiga Rigid Disk partition map at sector 1
Partition 1: 1.866 GiB (2003304448 bytes, 3912704 sectors from 2048)
Drive name "DU0"
Type "SFS\0" (Amiga Smart File System)
Amiga Smart File System
Type "SFS\0"
--- sparkylinux-5.13-x86_64-minimalgui.iso
Regular file, size 940 MiB (985661440 bytes)
DOS/MBR partition map
Partition 2: 2.813 MiB (2949120 bytes, 5760 sectors from 172)
Type 0xEF (EFI System (FAT))
FAT12 file system (hints score 5 of 5)
Volume size 2.796 MiB (2931712 bytes, 2863 clusters of 1 KiB)
GPT partition map, 128 entries
Disk size 940 MiB (985661440 bytes, 1925120 sectors)
Disk GUID E0D9B24F-E56D-8D42-9AFE-67FB51D82D36
Partition 1: 939.8 MiB (985444352 bytes, 1924696 sectors from 0)
Type Basic Data (GUID A2A0D0EB-E5B9-3344-87C0-68B6B72699C7)
Partition Name "ISOHybrid ISO"
Partition GUID E3120080-2233-2D44-9037-BB0E17B2F6B0
Partition 2: 2.813 MiB (2949120 bytes, 5760 sectors from 172)
Type Basic Data (GUID A2A0D0EB-E5B9-3344-87C0-68B6B72699C7)
Partition Name "ISOHybrid"
Partition GUID B91D441A-536C-4343-925E-B3DB32A483F8
FAT12 file system (hints score 5 of 5)
Volume size 2.796 MiB (2931712 bytes, 2863 clusters of 1 KiB)
Partition 3: unused
ISO9660 file system
Volume name "SPARKY_64bit"
Preparer "XORRISO-1.5.0 2018.09.15.133001, LIBISOBURN-1.5.0, LIBISOFS-1.5.0, LIBBURN-1.5.0"
Data size 939.8 MiB (985444352 bytes, 481174 blocks of 2 KiB)
El Torito boot record, catalog at 42
Bootable non-emulated image, starts at 1483, preloads 2 KiB
Platform 0x00 (x86), System Type 0x00 (Empty)
ISOLINUX boot loader
Bootable non-emulated image, starts at 43, preloads 2.813 MiB (2949120 bytes)
Platform 0xEF (EFI), System Type 0x00 (Empty)
FAT12 file system (hints score 5 of 5)
Volume size 2.796 MiB (2931712 bytes, 2863 clusters of 1 KiB)
Joliet extension, volume name "SPARKY_64bit"
--- hybridaros.iso
Regular file, size 34.29 MiB (35960832 bytes)
GRUB boot loader, unknown compat version 121
DOS/MBR partition map
Partition 1: 34.29 MiB (35960320 bytes, 70235 sectors from 1, bootable)
Type 0xCD (Unknown)
ISO9660 file system
Volume name "AROS Hybrid Live CD"
Publisher "MAGORIUM"
Preparer "MAGORIUM"
Data size 34.29 MiB (35960832 bytes, 17559 blocks of 2 KiB)
El Torito boot record, catalog at 175
Bootable non-emulated image, starts at 1540, preloads 2 KiB
Platform 0x00 (x86), System Type 0x00 (Empty)
Joliet extension, volume name "AROS Hybrid Live"
Partition 1: 34.29 MiB (35960320 bytes, 70235 sectors from 1, bootable)
Type 0xCD (Unknown)but might be fixed late.AROS SUPPORTED DEVICES, KNOWN:
1002 437b Advanced Micro Devices, Inc. [AMD/ATI] IXP SB4x0 High Definition Audio Controller
1002 4383 Advanced Micro Devices, Inc. [AMD/ATI] SBx00 Azalia (Intel HDA)
1002 7919 Advanced Micro Devices, Inc. [AMD/ATI] RS690 HDMI Audio [Radeon Xpress 1200 Series]
1002 793b Advanced Micro Devices, Inc. [AMD/ATI] RS600 HDMI Audio [Radeon Xpress 1250]
1002 960f Advanced Micro Devices, Inc. [AMD/ATI] RS780 HDMI Audio [Radeon 3000/3100 / HD 3200/3300]
1002 aa00 Advanced Micro Devices, Inc. [AMD/ATI] R600 HDMI Audio [Radeon HD 2900 GT/PRO/XT]
1002 aa08 Advanced Micro Devices, Inc. [AMD/ATI] RV630 HDMI Audio [Radeon HD 2600 PRO/XT / HD 3610]
1002 aa10 Advanced Micro Devices, Inc. [AMD/ATI] RV610 HDMI Audio [Radeon HD 2350 PRO / 2400 PRO/XT / HD 3410]
1002 aa18 Advanced Micro Devices, Inc. [AMD/ATI] RV670/680 HDMI Audio [Radeon HD 3690/3800 Series]
1002 aa20 Advanced Micro Devices, Inc. [AMD/ATI] RV635 HDMI Audio [Radeon HD 3650/3730/3750]
1002 aa28 Advanced Micro Devices, Inc. [AMD/ATI] RV620 HDMI Audio [Radeon HD 3450/3470/3550/3570]
1002 aa30 Advanced Micro Devices, Inc. [AMD/ATI] RV770 HDMI Audio [Radeon HD 4850/4870]
1002 aa38 Advanced Micro Devices, Inc. [AMD/ATI] RV710/730 HDMI Audio [Radeon HD 4000 series]
1025 011f Acer Incorporated [ALI] Realtek ALC268 audio codec
1028 01da Dell OptiPlex 745
1028 01f9 Dell Latitude D630
1039 7502 Silicon Integrated Systems [SiS] Azalia Audio Controller
103c 30a2 Hewlett-Packard Company NX7300 laptop
103c 30aa Hewlett-Packard Company nc6310
103c 30b5 Hewlett-Packard Company Presario V3242AU
1043 1339 ASUSTeK Computer Inc. M51S series
1043 817f ASUSTeK Computer Inc. P5LD2-VM Mainboard (Realtek ALC 882 codec)
1043 81ec ASUSTeK Computer Inc. P5B
10b9 5461 ULi Electronics Inc. HD Audio Controller
10cf 1326 Fujitsu Limited. Fujitsu Lifebook A3040
10cf 142d Fujitsu Limited. HD audio (Realtek ALC262)
10de 026c NVIDIA Corporation MCP51 High Definition Audio
10de 0371 NVIDIA Corporation MCP55 High Definition Audio
10de 03e4 NVIDIA Corporation MCP61 High Definition Audio
10de 03f0 NVIDIA Corporation MCP61 High Definition Audio
10de 044a NVIDIA Corporation MCP65 High Definition Audio
10de 044b NVIDIA Corporation MCP65 High Definition Audio
10de 055c NVIDIA Corporation MCP67 High Definition Audio
10de 055d NVIDIA Corporation MCP67 High Definition Audio
10de 0774 NVIDIA Corporation MCP72XE/MCP72P/MCP78U/MCP78S High Definition Audio
10de 07fc NVIDIA Corporation MCP73 High Definition Audio
10de 0ac0 NVIDIA Corporation MCP79 High Definition Audio
10de 0ac1 NVIDIA Corporation MCP79 High Definition Audio
10de 0ac2 NVIDIA Corporation MCP79 High Definition Audio
10de 0ac3 NVIDIA Corporation MCP79 High Definition Audio
10de 0d94 NVIDIA Corporation MCP89 High Definition Audio
1106 3288 VIA Technologies, Inc. VT8237A/VT8251 HDA Controller
1179 0001 Toshiba Corporation Magnia Z310
1179 ff01 Toshiba Corporation PRO/100 VE Network Connection
1458 a022 Gigabyte Technology Co., Ltd GA-MA770-DS3rev2.0 Motherboard
161f 203d Rioworks Marvell 88E8053 Gigabit Ethernet Controller (Arima)
1734 10b8 Fujitsu Technology Solutions Realtek High Definition Audio
1854 0018 LG Electronics, Inc. Marvell 88E8036 Fast Ethernet Controller (LGE)
8086 2668 Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) High Definition Audio Controller
8086 269a Intel Corporation 631xESB/632xESB High Definition Audio Controller
8086 27d8 Intel Corporation DeskTop Board D945GTP
8086 284b Intel Corporation 82801H (ICH8 Family) HD Audio Controller
8086 293e Intel Corporation Optiplex 755
8086 3a3e Intel Corporation 82801JI (ICH10 Family) HD Audio Controller
8086 3a6e Intel Corporation 82801JD/DO (ICH10 Family) HD Audio Controller
8086 3b56 Intel Corporation 5 Series/3400 Series Chipset High Definition Audio
8086 811b Intel Corporation US15W/US15X/US15L/UL11L SCH [Poulsbo] HD Audio Controller
AROS SUPPORTED DEVICES, UNKNOWN:
1002 aa40 Advanced Micro Devices, Inc. [AMD/ATI]
1002 aa48 Advanced Micro Devices, Inc. [AMD/ATI]
1014 02f6 IBM
1025 010f Acer Incorporated [ALI]
1025 0110 Acer Incorporated [ALI]
1025 011b Acer Incorporated [ALI]
1025 0127 Acer Incorporated [ALI]
1025 012f Acer Incorporated [ALI]
1025 0133 Acer Incorporated [ALI]
1028 01c9 Dell
1028 01cc Dell
1028 0227 Dell
1028 0228 Dell
103c 3010 Hewlett-Packard Company
103c 3013 Hewlett-Packard Company
103c 30a5 Hewlett-Packard Company
103c 30b0 Hewlett-Packard Company
1043 1153 ASUSTeK Computer Inc.
1043 1263 ASUSTeK Computer Inc.
1043 1323 ASUSTeK Computer Inc.
1043 1338 ASUSTeK Computer Inc.
1043 13c2 ASUSTeK Computer Inc.
1043 1971 ASUSTeK Computer Inc.
1043 1993 ASUSTeK Computer Inc.
1043 81cb ASUSTeK Computer Inc.
1043 81e7 ASUSTeK Computer Inc.
1043 8234 ASUSTeK Computer Inc.
1043 cb84 ASUSTeK Computer Inc.
104d 81cc Sony Corporation
106b 00a1 Apple Inc.
10de 0775 NVIDIA Corporation
10de 0776 NVIDIA Corporation
10de 0777 NVIDIA Corporation
10de 07fd NVIDIA Corporation
10de 0d95 NVIDIA Corporation
10de 0d96 NVIDIA Corporation
10de 0d97 NVIDIA Corporation
144d c027 Samsung Electronics Co Ltd
1462 0349 Micro-Star International Co., Ltd. [MSI]
1462 034a Micro-Star International Co., Ltd. [MSI]
1584 9075 Uniwill Computer Corp
1734 10cd Fujitsu Technology Solutions
17aa 1015 Lenovo
17aa 2066 Lenovo
17aa 384e LenovoThe main problem is that several supported devices are reported as unknown (it's the second list, at the bottom), because it's not possible to find the VendorID & DeviceID couple on the PCI devices database which I've used ( https://pci-ids.ucw.cz/ (https://pci-ids.ucw.cz/) ).
@magorium: the experiment looks promising. The strange thing which I see is this:Yeah, i know :-)
In the meanwhile, just as a PoC, I've written a small Python scriptThat also looks promising.
... because it's not possible to find the VendorID & DeviceID couple on the PCI devices database which I've usedI think that is something you would have to learn to live with ?