AROS Exec

General => General Chat => Topic started by: OlafS3 on December 28, 2020, 11:24:19 AM

Title: Ideas for Aros Distributions
Post by: OlafS3 on December 28, 2020, 11:24:19 AM
Just a thread what could be improved in general or in specific distributions
Title: Re: Ideas for Aros Distributions
Post by: OlafS3 on December 28, 2020, 11:33:35 AM
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.
Title: Re: Ideas for Aros Distributions
Post by: aGGreSSor on December 28, 2020, 11:41:04 AM
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 ?
Title: Re: Ideas for Aros Distributions
Post by: OlafS3 on December 28, 2020, 11:43:49 AM
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.
Title: Re: Ideas for Aros Distributions
Post by: OlafS3 on December 28, 2020, 11:56:27 AM
as I already wrote... 68k integration is critical for amiga users

 it should be possible to start a game by simple double clicking without even care that it is whdload and you are on X86. In best case without even needing to launch a program for it. The barriers between X86 and 68k should become as invisible as possible. Also resource sharing is important. There should be no basic difference if you use a 68k application or a X86 application. I know that this is propably not easy to do. I just wrote what I assume would be accepted by more people. Resources are in two directions so f.e. drives should be shared, clipboard and it should be possible to print from 68k applications. Starting emulation should happen in background.
Title: Re: Ideas for Aros Distributions
Post by: aGGreSSor on December 28, 2020, 11:57:53 AM
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.
Title: Re: Ideas for Aros Distributions
Post by: OlafS3 on December 28, 2020, 12:05:20 PM
the minimum would be a check at start of install so people just put the CD in and check if it is possible. People are very frustrated if they try to install and fail wasting a lot of time. That certainly has harmed aros very much
Title: Re: Ideas for Aros Distributions
Post by: magorium on December 28, 2020, 12:17:08 PM
... 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.


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.


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 ?


btw: You can start a small linux distro and check the vendor/hardware ID's manually with the HCL. That should be able to provide enough hint on how you could approach the implementation of your idea.
Title: Re: Ideas for Aros Distributions
Post by: cdimauro on December 28, 2020, 12:22:40 PM
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.


What's 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.
Then another simple application reads the current PC configuration (list of PCI ids) and shows if they are supported or not, what's missing, and a simple description of issues that might be possible when installing AROS on that machine (example: no GPU supported -> only 640x480 16 colors visible).
Title: Re: Ideas for Aros Distributions
Post by: salvo on December 28, 2020, 12:31:25 PM
or I have never had problems with my computers until now and I have had many
Title: Re: Ideas for Aros Distributions
Post by: aGGreSSor on December 28, 2020, 12:55:15 PM
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.  ;)
Title: Re: Ideas for Aros Distributions
Post by: OlafS3 on December 28, 2020, 01:03:46 PM
@Agressor

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 frame

If Aros shall win new users (expecially from outside the amiga camp) something like a compatibility check is urgent needed. One time installation fails means normally one user less forever
Title: Re: Ideas for Aros Distributions
Post by: nikos on December 28, 2020, 01:50:26 PM
With any hardware made last 10 years you will not have a supported network chip. You will neither have native gfx, VESA will work.
This brings in the question if there are any point to test the hardware. Maybe 90% of all PC used today are not more than 10 years old.
Without networking and native gfx it is just as good to run hosted. That will work on almost any computer.

Icaros have all that.

https://vmwaros.blogspot.com/p/versions-comparison.html?m=0
Title: Re: Ideas for Aros Distributions
Post by: cdimauro on December 28, 2020, 01:53:12 PM
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.  ;)
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.
Title: Re: Ideas for Aros Distributions
Post by: nikos on December 28, 2020, 02:07:37 PM
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 68k roms and system.
There you have a legal, ready set up Amiga 68k emulator.

The emulator boots into AROS 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.

There could even be an option to boot or switch to AROS i386 if people like to use, test that.

 
Title: Re: Ideas for Aros Distributions
Post by: OlafS3 on December 28, 2020, 02:09:03 PM
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). There are advantages and disadvantages compared to something like amithlon. The disadvantage is, it is slower than something like amithlon. On the other hand on PC it has the advantage to run on many configurations. MSchulz creates amithlone-like solution on RpI so it is for a specific system. I do not know if his project also works on different ARM-based hardware.
Title: Re: Ideas for Aros Distributions
Post by: nikos on December 28, 2020, 02:15:36 PM
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)

Yes, he kind of did, but the emulator he used is the same as there always been for AROS. Way outdated! It is not FS-UAE, it is E-UAE.

http://rcdrummond.net/uae/

Last version is from 2007. It is not that bad, but people want something better like WinUAE or FS-UAE.
Title: Re: Ideas for Aros Distributions
Post by: OlafS3 on December 28, 2020, 02:19:43 PM
unfortunately outside winuae all emulators are outdated. Even FS-UAE is not updated for a long time (linux last updated 2018)

I just looked and am not sure... 3.0.3 is from 2020 but am not sure if all platforms are updated
Title: Re: Ideas for Aros Distributions
Post by: nikos on December 28, 2020, 02:20:38 PM
unfortunately outside winuae all emulators are outdated. Even FS-UAE is not updated for a long time (linux last updated 2018)

That is true but FS-UAE is good enough I would say. It is based on a WinUAE version.

It is not like a lot happen from release to release.

o1i worked on a new version for Janus-UAE.
It is sad it never got finished. Janus-UAE is actually a very good program.
Title: Re: Ideas for Aros Distributions
Post by: OlafS3 on December 28, 2020, 02:23:24 PM
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
Title: Re: Ideas for Aros Distributions
Post by: nikos on December 28, 2020, 02:29:34 PM
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.
Title: Re: Ideas for Aros Distributions
Post by: OlafS3 on December 28, 2020, 03:30:34 PM
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.

You can have X86 but the borders between 68k and X86 should be as small as possible
Title: Re: Ideas for Aros Distributions
Post by: nikos on December 28, 2020, 03:35:52 PM
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 68k is used on powerful 68k hardware. It is to slow for A500 or A1200.
Title: Re: Ideas for Aros Distributions
Post by: OlafS3 on December 28, 2020, 03:39:00 PM
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.

The basic question is where you see the future. Do you see it as a retro platform running on different hardware or as platform competing with windows or linux. Depending on that your requirements are different. I see it as a retro platform.
Title: Re: Ideas for Aros Distributions
Post by: nikos on December 28, 2020, 03:48:21 PM
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.
Title: Re: Ideas for Aros Distributions
Post by: OlafS3 on December 28, 2020, 03:51:49 PM
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.

Aros is very responsive on Vampire. Aros is fast enough on it

https://www.youtube.com/watch?v=q40DrZ3iziE&t=55s
Title: Re: Ideas for Aros Distributions
Post by: nikos on December 28, 2020, 04:50:04 PM
Yes, looking fast.
I never doubt AROS to be fast on more powerful hardware. You will not notice the slowdown that is with original Amiga hardware. Lot of the code in original AmigaOS is assembler and they have optimised gfx drivers.
It is no point to target the original hardware.
Title: Re: Ideas for Aros Distributions
Post by: OlafS3 on December 28, 2020, 05:10:04 PM
The growing market is vampire. So there is indeed no point tasrgetting standard amigas

In my view the focus should be on Vampire + UAE

And transfer it to more powerful hardware like X86 or ARM

I think Aros has left the image of being a "research OS" useless for end users but still has to go some way there
Title: Re: Ideas for Aros Distributions
Post by: paolone on December 28, 2020, 05:45:24 PM

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.


Just look to this thread, with people asking things Icaros is doing for a decade.
Title: Re: Ideas for Aros Distributions
Post by: OlafS3 on December 28, 2020, 05:51:02 PM
sorry but why it is not on the same level as AOS4 or MorphOS?

People accepted Aros on 68k buit as you indiate why not on X86 if it is perfect there already
Title: Re: Ideas for Aros Distributions
Post by: aGGreSSor on December 28, 2020, 08:58:13 PM
@Agressor
you are a little sarcastic, arenīt you?  ;)
Yep, a bit
This thread is for collecting ideas, not to decide about what is possible and in which time frame
I donít understand why to pound water in a mortar.
It's known that AROS is developed by one developer. Well, ok, we can strain and measure four.
How many of them will take ideas (which are immature enough and do not take into account many factors) into work?
Zero.

Rescuing drowning people is the work of the drowning people themselves, excuse me for the moral.
The creation of the file you wrote about is the user level.
No developer is required for this.
An activist with analytic skill and knowledge of the hardware base is needed here.
When there is a clear algorithm and a regularly updated database, we can talk about programming.

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.
If you can spend a year discussing ideas, then you can spend a year developing a Janus-UAE2.
Title: Re: Ideas for Aros Distributions
Post by: Johndoe on December 29, 2020, 01:56:04 AM
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.
Title: Re: Ideas for Aros Distributions
Post by: cdimauro on December 29, 2020, 07:52:28 AM

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.
Indeed. And here come two suggestions:


1) AROS should allow to boot (at least) and use (much better) a FAT32 formatted partition. This will definitely solve the above problem, while also allowing to play with the USB Pen content (adding, changing, deleting stuff), making experiments, without the burden to either do it every time after the installation and/or using a FAT32 partition as a "bridge" to share some files to modify the SFS partition.


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.
Quote
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"

Which is a completely different thing from the that specific part of the discussion, albeit PCITool might be a starting point on AROS side.




Quote
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.

VESA support is another area of improvement. The available VESA modes might be queried and selected from inside AROS, instead of doing it from GRUB.

This requires an 8086 emulator to cheat the VGA BIOS and allowing to make the required calls to it, to achieve the goal.

in my view 68k integration is the most important feature for amiga user

It's already there with Amibridge, as paolone already reported. So, nothing is needed to already use it as you wish.

What can be improved is something like what I've suggested for the supported hardware configurations: a database (again: might be a simple CSV file) of 68K games and applications, reporting the needed 68K config (CPU used, chipset used, min/max amount of chip/slow/Zorro2/Zorro3/processor-card ram, if and how many floppy to be configured, if and how many and the capacity of physical hard drives, RTG card, audio card), the AROS config (clipboard sharing, networking sharing, hard drive sharing, etc.), and the Amibridge sharing (screen, window, coherence mode).

This way you can immediately use the 68K games and apps without any configuration needed. If the game or app is not yet added to the database, then the first user that is able to integrate it on Amibridge just sends its config (maybe from Amibridge) to the database maintainer, which updates it.

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.

AROS, and the Amiga o.s. in general, is not POSIX-compatible.
Title: Re: Ideas for Aros Distributions
Post by: paolone on December 29, 2020, 02:30:57 PM
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?
Title: Re: Ideas for Aros Distributions
Post by: aGGreSSor on December 29, 2020, 03:27:05 PM
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
Title: Re: Ideas for Aros Distributions
Post by: Mazze on December 29, 2020, 06:43:39 PM
If you look at the bottom of
https://aros.sourceforge.io/pictures/screenshots/
you'll see 2 screenshots from 1997 when AROS was using with X11 windows :-)
Title: Re: Ideas for Aros Distributions
Post by: aGGreSSor on December 29, 2020, 08:58:34 PM
If you look at the bottom of
https://aros.sourceforge.io/pictures/screenshots/
you'll see 2 screenshots from 1997 when AROS was using with X11 windows :-)
I decided (perhaps foolishly) to install a Docker Desktop with WLS2.
It totally slows down AROS that is launched in Virtualbox: all rendering becomes frame-by-frame.
And long ears become visible X11. In normal operation this happens very quickly and the user doesn't see it.
But this extra redrawing happens all the time. It's necessary to record a video as AROS slows down. :D

No sooner said than done. Demonstration of very slow AROS:
https://www.youtube.com/watch?v=nmnf5lECH4Q
Title: Re: Ideas for Aros Distributions
Post by: cdimauro on December 29, 2020, 10:13:38 PM
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?
I'm using Windows, so I don't know how to do it with my machine.


But AFAIK Linux supports SFS, so it should be enough to do what you already reported (the .vmdk file will be the 5-6GB SFS "disk" where you installed Icaros), and after that use a dd command to make a raw dump of the complete SFS disk to a single file. This file should be the one to be flashed to the USB Pen.


Flashing this file to an USB Pen then should take a only a few seconds, since it's a verbatim copy directly writing the data to the USB Pen's sectors (you don't have to copy thousands of small files that takes ages with the current process, and it's also error prone, as you already know).


I hope that this helps and... works! :)


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

Yes, I know that Linux isn't fully POSIX-compliant. :)

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. :-/
Title: Re: Ideas for Aros Distributions
Post by: Johndoe on December 30, 2020, 04:44:58 AM
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

Okay, forget about Posix. Anyway, does the idea of replacing the Zune with another DE seem interesting to you?
How difficult is it technically to implement? How interesting is this idea to developers? Or maybe your community doesn't accept anything other than vanilla Zuna?
It seems to me that creating distributions using alternative DE will attract new people, which will be beneficial.
Title: Re: Ideas for Aros Distributions
Post by: aGGreSSor on December 30, 2020, 08:10:07 AM
I'm using Windows, so I don't know how to do it with my machine.
It explains everything

But AFAIK Linux supports SFS
Where 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).

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.
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.

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.
Title: Re: Ideas for Aros Distributions
Post by: cdimauro on December 30, 2020, 08:51:39 AM
I'm using Windows, so I don't know how to do it with my machine.
It explains everything
Where did you saw that I don't know Linux?
Quote
But AFAIK Linux supports SFS
Where do you get this nonsense?
1) Linux is kernel.
Really? What an incredible "new" you gave me...
Quote
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
Quote
I hope that this helps and... works! :)
Why do you write something that you don't know and haven't tested?
Because... I can? Do you know that this thread about ideas? Do you understand the topic of thread before start writing on it?

And just to clarify: I'm pretty sure that the dd command will work out, since I've used it some times at work for dumping or restoring entire partitions.

BTW, probably the SFS support isn't needed if paolone just installs Icaros on a raw disk with VMWare. I mean: if it doesn't require to work on that partition from Linux.
Quote
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.
I never have written non-sense about POSIX: this is only in your imagination.
Quote
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.
First, fork is one of the most used APIs in the Unix world.

Second, pthreads are an horrible patch over the consolidated process model in the Unix world.

Third, since fork is used a lot in the Unix world, you need to rewrite the existing code trying to see if there can be another API or workaround. 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.).

Now let's see how long you need to continue trolling to satisfy your ego...
Title: Re: Ideas for Aros Distributions
Post by: aGGreSSor on December 30, 2020, 10:27:16 AM
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/sfs
So 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.
These are private things that simply accompany any porting, and not a universal disaster.

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?
Title: Re: Ideas for Aros Distributions
Post by: cdimauro on December 30, 2020, 11:43:32 AM
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.
You're making wrong assumptions, as usual, since you don't understand what people is writing, and therefore you reply with non-sense.

Unless you're affected by functional illiteracy (which requires actions on your side), you should first understand what was written, and only AFTER that write something (IF needed, and makes sense, of course).

Specifically, you've assumed that I didn't know Linux only because I cannot check something on my machine because it has Windows.

Have you understood your logical fallacy now, or should I draw a chart?
Quote
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"?
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.
Quote
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!
Who cares when it was written.
Quote
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.

Here's an example which I've found with a quick search:
https://src.chromium.org/viewvc/chrome/trunk/src/base/process_util_posix.cc?pathrev=58558
Code: [Select]
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().
Quote
Its implementation is hidden
If it's hidden it means that it's still there, elementary logic at hands, and so the problem remains...
Quote
or replaced by another.
Same as above: irrelevant. It only proves that you're a noob in the Unix world.
Quote
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?

So, you're a noob in the Amiga world as well.
Quote
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? 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.

Enjoy...
Quote
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? Have I ever stated that fork is the only problem when porting apps (to the Amiga land)?

You continue to don't understand what people has written, making wrong assumptions, and falling in logical fallacies...
Quote
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.
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.
Quote
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.
Quote
but there are plenty of theoreticians.
Clap clap clap. You made the dig of the day. What's next?

And at least theoreticians have knowledge, which is clearly missing to you, which don't know neither Unix nor the Amiga/AROS worlds.
Quote
Do you understand the topic of thread before start writing on it?
Do you understand the difference between an idea and an unscientific fiction?
Unscientific fiction? Like this one that you've written:
"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."

?

Which shows that you don't even have a clue about how problems should be solved. And you're supposed to be a coder, from what you've written 'til now. But with almost zero problem solving mindset, as it was shown by your non-sense proposal that you've written me.

So, yes, your statement can be clearly classified ad sci-fi in the programming world.

But my ideas are not, on the exact contrary, because they are practical solutions to real problems, which only need to be implemented, since they are technical feasible.

And if you don't understand this and continue to talk about "unscientific fiction", it only shows how limited are you on both technical knowledge and coding skills.

So, go learn something because you've deep gaps to be filled, instead of tickle people which, on the contrary, knows very well what he speaks about...
Title: Re: Ideas for Aros Distributions
Post by: aGGreSSor on December 30, 2020, 02:31:32 PM
@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.
We will write the application somehow: we will rely on your file."
Why do you undertake to propose if you cannot do such a simple thing? are you waiting for someone else to do it? Who?

Title: Re: Ideas for Aros Distributions
Post by: OlafS3 on December 30, 2020, 03:32:54 PM
@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.
We will write the application somehow: we will rely on your file."
Why do you undertake to propose if you cannot do such a simple thing? are you waiting for someone else to do it? Who?

I would say from what I sometimes read that Aros earns it to be called "research" and not taken seriously. The difference between MorphOS team and the Aros devs is that the team feels responsible for the "package". User do not know or care who is responsible for what part, they want something they can easily install, works stable and offers what they expect... in Aros world devs do not care about that, Kal openly said that. And even your comments sound a little like that. That is different what I see around Vampire and Aros 68k, the interest there is to have something people like to use and not just some fiddling around by some devs who do what they just like (and drop it if they are no longer interested). That is a basic difference and one of the biggest weaknesses of Aros. I f.e. do some windows programming. There might be a chance to create a software that detects hardware but it makes no sense to invest time without the needed informations about the components (what is supported and what is not). And the devs say it is not their responsibility. So it will not happen. People will try to install and fail and then spread in forums what a shit aros is. And devs will moan that people not support their great work...

To me the discussions demonstrate why aros never was really accepted in the community... at least on 68k I can solve many problems with 68k components. One of the basic problems is, what devs are interested in is not necessarily what potential users are interested in. It is more interesting to work on "USB3" (as example) than bugfix wanderer. or other components. The other problem is driver support. But for that the few distribution maintainers left and the aros devs /X86 related) should agree on a common concept or goal and hardware aros targets. As long this not happens I do not see Aros really progressing. Latest after ISA switch of MorphOS (propably AMD64) Aros will look pretty old. It had a huge advantage of many years compared to other amiga related platforms but not used it. There is a chance that it further lives on 68k and even makes progress there, on X86 (or AMD64) it will propably fail. And that has much to do with attitudes of the aros devs (unfortunately). Those problems cannot be solved by just distribution creators. It must be solved in cooperation between devs and maintainers. If this not happen it will fail., Or better... Aros on X86/AMD64 will stay "research" and become obsolet finally
Title: Re: Ideas for Aros Distributions
Post by: cdimauro on December 30, 2020, 03:38:27 PM
@aGGreSSor: don't try to change the cards on the table. You attacked and me, even before your previous comment, and I've just reacted. Don't hit the dog if you don't want to be torn...

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.

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.

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.
Title: Re: Ideas for Aros Distributions
Post by: aGGreSSor on December 30, 2020, 08:52:39 PM
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 didnít 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?

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.
Title: Re: Ideas for Aros Distributions
Post by: Johndoe on December 31, 2020, 02:24:54 AM
Quote
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.

Is it difficult to implement support for a X-server in AROS?
Title: Re: Ideas for Aros Distributions
Post by: Samurai_Crow on December 31, 2020, 04:04:17 AM
@Johndoe

X11 is very difficult to implement on non-POSIX platforms like AROS.  Not impossible but impractical.  KDE is based on Qt framework which is a huge monstrosity compared to both Zune and the closed source MUI it is based on.
Title: Re: Ideas for Aros Distributions
Post by: cdimauro on December 31, 2020, 07:34:43 AM
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.
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?

You continue to don't understand what people is writing, and taking different conclusions. So, it's not a question of educating me (which I don't need: I was participating to the discussion in a polite way, before that you decided to attack me), rather than someone should help solve your evident problems here.

Anyway, the messages are there and readers can sequentially look at them and realize who shit outside of the pot.
Quote
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 didnít 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.
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).

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.

So, and again, no. It's not as simple as you want to sell it.
Quote
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).
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.
Quote
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).

Then the invoked application should transparently send the collected data somewhere (e.g.: an email to an address, invoking a simple http/https API from a specific server, committing a simple patch to a git repo, etc. There are multiple way to achieve it, and this should be defined as well), with a fallback solution if this isn't possible (e.g.: no internet connection -> writing the information to a file -> show a requester to the user with DETAILED instructions on what to do, to manually send it somewhere).

Once received, the information will be checked against the existing database, and updated if it's the case. A human intervention will be required in case of conflicts.

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.
Quote
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.
Again? What's not clear to you about this:
"Ideas for Aros Distributions"
and this:
"I've other, personal projects which keep me busy"
?
Title: Re: Ideas for Aros Distributions
Post by: aGGreSSor on December 31, 2020, 11:08:09 AM
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
In Russian you are called "offended" (English is very scarce, very few shades of words), welcome. Aren't you tired of complaining?

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.

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.

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.
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.
Is that correct? In turn, I see no problem discussing ideas with their implementation together.
Title: Re: Ideas for Aros Distributions
Post by: cdimauro on December 31, 2020, 08:15:48 PM
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
https://www.collinsdictionary.com
Quote
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...
Quote
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.
Quote
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,
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.
Quote
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
There's nothing like that in this thread, but you can show me it, in case (see above).
Quote
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.
Irrelevant: I've already reported all possible cases / scenarios, and what you're saying applies only to some.
Quote
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.
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.
Quote
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.

IF a developer wants to create a multiplatform application he already knows that he'll find some way to do it (e.g.: searching and then tinkering), if he hasn't experience about it.
Quote
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.
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.

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...
Quote
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.
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.
Quote
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
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.
Quote
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
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.

And based on my knowledge and experience, AROS is an anarchy land, where developers do whatever they want, since they work for fun on this project (unless if someone is interested on some bounty. And even there, they'll pick what they like), and to the parts that they like.
So, if someone is interested on a task, he'll pick and work on it, without waiting that someone (who, since this project is head-less?) is "offering" him to do it...
Quote
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.
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).

In fact, from the above sentence, the first and central parts are false, and only the last is true. Elementary logic at the hands.
Quote
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.

And I refused because, as I've said, I've other projects. But even if I had spare time AND wanted to work on something on/for AROS, I would have picked completely different tasks, since, as a developer, I'm interested on (very) different topics.
Quote
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.
Quote
In turn, I see no problem discussing ideas with their implementation together.
Me neither. Since it's a thread -> discussion is a natural thing.

IF you, as a developer, want to implement something, and it's your problem, but don't draw conclusions about other peoples.

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?
Title: Re: Ideas for Aros Distributions
Post by: x-vision on January 01, 2021, 10:37:26 PM


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
Title: Re: Ideas for Aros Distributions
Post by: magorium on January 02, 2021, 10:46:17 AM

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.
The special script you crufted for that works splendidly (thank you for that) but indeed it would be much simpler that way. 

It is that i have an interest in AROS so i am willing to spent some time in order to learn how to install/configure/use it but at the same time if i wish to try out any other distro i'm lazy as hell as well and just want to 'burn' the iso to a pen-drive/sd-card/hd and be up and running as quick as possible.

Quote
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.

Just look to this thread, with people asking things Icaros is doing for a decade.
Indeed. It is really depressing to still have to witness such things.

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  :'(



And yes, the support for iso 'burning' has been discussed in the past as well, so i am/was expecting a "asked and answered" reaction, which is also fine.

@aGGreSSor: at the least you have some hands on action vouching for you  8)
Title: Re: Ideas for Aros Distributions
Post by: aGGreSSor on January 02, 2021, 12:17:31 PM
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.

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...
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.

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.
Title: Re: Ideas for Aros Distributions
Post by: aGGreSSor on January 02, 2021, 12:36:03 PM
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
Seem 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.  ;)
Title: Re: Ideas for Aros Distributions
Post by: cdimauro on January 03, 2021, 07:51:24 AM
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.

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  :'(
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).

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
I agree, and for the same problem. So, yes: see my reply below.
Quote
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.

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...
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.
Another irrelevant wall-of-text. Here you forgot the context: what we were discussing about. Which was porting applications, and writing portable code.

Specifically, I've spoken about GUI applications, and it still applies what I've said, and the example about a WPF application which requires a different way to implement the business logic (definition which still applies) compared to other platforms & toolkits.

You replied with your usual rants changing again the cards on the table.

To me you not only have problems understanding what people is saying, but your clearly lack experience on other platforms/toolkits: you look like the typical Linux geek which knows something about his world, trying to apply his knowledge / extended his vision to the rest of world (which... works differently)...
Quote
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.
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.
Title: Re: Ideas for Aros Distributions
Post by: magorium on January 03, 2021, 02:59:28 PM
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).

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.

Based on that then yes the discussion on this particular topic is using up more space than it would have in a code-editor  :P

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.

What was it again... live long and prosper ?  ;D
Title: Re: Ideas for Aros Distributions
Post by: magorium on January 03, 2021, 03:28:53 PM
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
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.

I guess the saying "You reap what you sow" doesn't really ring a bell, does it ?  ;)

So, keep on bashing aGGreSSor and see where that ends you guys up. It was done before but perhaps the outcome is different this time. After all, you never know  :o
Title: Re: Ideas for Aros Distributions
Post by: paolone on January 03, 2021, 05:50:15 PM
Well, in the end of this long and useful discussion.. any idea for a distribution?
Title: Re: Ideas for Aros Distributions
Post by: x-vision on January 03, 2021, 07:44:24 PM
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
Seem 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.  ;)

You clearly have problems. You don't have a clue but it's my advice to others (in case there is someone left which didn't realise yet). Whatever you try to do, it doesn't matter: don't help. It just sinks the community more and more.

BTW following my policy of ignoring toxic people, I won't answer any fruther texts from you. Hope you get (much) better in the future.
Title: Re: Ideas for Aros Distributions
Post by: cdimauro on January 03, 2021, 08:12:31 PM
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.
Indeed. As I've said before, the existing part might be a starting point for this new feature.
Quote
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).
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).
Quote
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.

The primary problem with AROS is that it's missing (the one which runs is really too much outdated). So, porting a new version (3.9 is the last one, which I recommend).

The second, and not even less important, is that if you decide to integrate Python as a system tool, then you can say goodbye to the original Amiga machines, even if expanded, because it requires way much more resources. I don't care so much, because today we have TONs of resources even on very low-end machines (e.g.: Raspberry Pi. Which was built around Python, BTW), but some people might be upset. This is a decision which AROS devs have to take (once Python is finally ported, of course).

But for tools like the ones which we're talking, using Python just server-side isn't a problem. It's already there: only need to be used.
Quote
Based on that then yes the discussion on this particular topic is using up more space than it would have in a code-editor  :P

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.
Writing 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.

I agree that implementing some feature is much better than discussing about it. However at least some discussions about requirements is beneficial to the project, because it might catch problems quite ahead.
Quote
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.

What was it again... live long and prosper ?  ;D
Especially since we have just one. :)

I'll not reply anymore to the guy, unless there some technical (and only technical) discussion which deserves it. I've already wasted a lot of time which I could have spent acquiring some knowledge with capstone (I Python package which I need for my project), instead...

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.

You can add an hard drive to a VMWare virtual machine of a little bit 8GB (less than the space used by an 8GB USB Stick), partition it properly with GRUB, the SFS primary partition where Icaros is installed. Provide a 1GB SFS partition that might be used for storing some extra (non-system) data. And another 1-2GB FAT32 partition useful for exchanging data with the external world.

Once Icaros is fully working, just use the dd command to make a rough dump of the whole device (not partition), and provide it for downloading.

It should work-out, and should be easy to "flash" on the USB Stick using tools like Rufus.

Or... do you need something else?
Title: Re: Ideas for Aros Distributions
Post by: paolone on January 04, 2021, 10:59:57 AM
Quote
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).



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.


Nothing more, nothing left.



Title: Re: Ideas for Aros Distributions
Post by: paolone on January 04, 2021, 11:13:47 AM
@cdimauro


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.
Title: Re: Ideas for Aros Distributions
Post by: cdimauro on January 04, 2021, 11:46:13 PM
Quote
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).
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.
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).
Quote
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.

Nothing more, nothing left.
Can you share some .zip file?

@cdimauro

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.
There should be some disk layout issue or some difference which is preventing it to work.

You can already create a bootable & working USB stick if you use your actual Icaros installer. So, it's definitely possible to have Icaros/AROS working from an USB stick.

So, there are two possibilities here: either you just make a full installation of Icaros on an USB stick and then create an .ISO dumping it, or investigate the differences between this working USB stick and the other one which you created using VMWare.
Title: Re: Ideas for Aros Distributions
Post by: 4pLaY on January 05, 2021, 02:38:47 AM
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.

Title: Re: Ideas for Aros Distributions
Post by: magorium on January 05, 2021, 03:56:34 AM
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.

Such image files can then be 'copied' back to a physical device again by using the disk dump utility.

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).

There are linux distro's that are distributed as .iso file and which are constructed in such a way that you can actually use dd to write it directly to a physical device and be able to boot from it without additional work, other then booting your machine and selecting the proper boot-device) (*)

Note that when you experiment that a) there is no need for a full installation, making it work is more interesting and b) working with partitions and dd will most probably complicate things unnecessary.

I would suggest to leave those both parts for a later moment, and focus on getting it to work first.

And fwiw, it should simply work, because all you do is simply copy the raw data from one device to another (just like xcopy did back in the day with copying raw tracks from floppy to floppy, the only difference is that you use a file as a intermediate step).

Do note that the destination device must be of the same size or be bigger for this to work. In case the destination device is larger then the space not written to it will simply not be used as all (that is why f.e. the raspi automatically detects this situation and asks the end-user to 'enlarge' the disk-space by offering to also use the unwritten blocks as space for the partition)

edit: (*) See for example https://wiki.syslinux.org/wiki/index.php?title=Isohybrid in case you are interested in experimenting with such route.
Title: Re: Ideas for Aros Distributions
Post by: paolone on January 05, 2021, 10:21:34 AM
@Magorium


Thanks.
Title: Re: Ideas for Aros Distributions
Post by: paolone on January 05, 2021, 10:49:54 AM
Can you share some .zip file?


They've been in Icaros' Storage/Config for years.
Title: Re: Ideas for Aros Distributions
Post by: cdimauro on January 05, 2021, 11:28:35 PM
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.

Can you share some .zip file?
They've been in Icaros' Storage/Config for years.
OK, thanks.
Title: Re: Ideas for Aros Distributions
Post by: OlafS3 on January 06, 2021, 01:23:44 PM
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.

My intentation was what the thread is named "ideas for aros distributions". What is needed or missing from user or potential user perspective. The discussion to me only partly explains why aros never got more than a "research OS"
Title: Re: Ideas for Aros Distributions
Post by: cdimauro on January 07, 2021, 06:52:54 AM
Can you share some .zip file?

They've been in Icaros' Storage/Config for years.
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.

Usually it should be enough to identify the device (and the driver to load), but sometimes the so called Subsystem Vendor ID and Subsystem ID are needed (and maybe the Revision ID).

Anyway, this information might be a good starting point for AROS' supported peripheral database. If it's coming from PCITool it should be easy to gather also the above missing data (and extend the database).
Title: Re: Ideas for Aros Distributions
Post by: magorium on January 07, 2021, 01:33:27 PM
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.
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.

Title: Re: Ideas for Aros Distributions
Post by: cdimauro on January 08, 2021, 07:17:35 AM
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.
Indeed. And this is why I've written this:

"There should be some disk layout issue or some difference which is preventing it to work."

and suggested this:

"You can already create a bootable & working USB stick if you use your actual Icaros installer."

because with the latter you'll get a USB stick with the correct layout / content, and making an .ISO out of it will work out.
Title: Re: Ideas for Aros Distributions
Post by: magorium on January 08, 2021, 02:51:43 PM
@cdimauro
some layout issue.

Code: [Select]
--- 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"

Code: [Select]
--- 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"

At best you can make an hybrid iso which is able to install itself onto a hd/usb (and which is able to boot both ways). That is why some people believe they are the same, because they are able to dd the .iso straight to a pendrive and/or hd and it works for them.

For example:
Code: [Select]
--- 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"

It would be easier to use a simple loopback which also allows to change the image(s) (whether .iso or .img) on the pendrive for an easy update process.


edit: a quick and dirty proof of concept (the errors as can be seen in the screenshot were expected) seem to suggest it can be done with some additional tinkering.

Code: [Select]
--- 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"

Title: Re: Ideas for Aros Distributions
Post by: cdimauro on January 10, 2021, 10:54:34 PM
@magorium: the experiment looks promising. The strange thing which I see is this:
Code: [Select]
Partition 1: 34.29 MiB (35960320 bytes, 70235 sectors from 1, bootable)
  Type 0xCD (Unknown)
but might be fixed late.

In the meanwhile, just as a PoC, I've written a small Python script to dump the list of supported PCI devices, scanning the Storage/Config folder in icaros-pc-i386.iso:
Code: [Select]
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 Lenovo
The 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/) ).
Title: Re: Ideas for Aros Distributions
Post by: magorium on January 13, 2021, 12:13:44 AM
@magorium: the experiment looks promising. The strange thing which I see is this:
Yeah, i know :-)

I got to work with what the grub tools offers me (well, not really but since i am new to grub and its particularities with regards to hybrids i have to see/understand what grub puts to xorriso)

I got some very strange (sometimes even unrepeatable) results, and of course the perfect solution would be that gpt and efi support is added as well (according to kiwi devs that is possible to do with grub but nobody seems to do that and use other solutions instead, so the interwebs is pretty quiet for me atm).

Quote
In the meanwhile, just as a PoC, I've written a small Python script
That also looks promising.

Quote
... because it's not possible to find the VendorID & DeviceID couple on the PCI devices database which I've used
I think that is something you would have to learn to live with ?

For example, the nvidia ones are not even listed on the nvidia's driver website (https://www.nv-drivers.eu/driver-by-vendev.html) or perhaps no specific drivers are needed for the device

There even might be the possibility of fake or miss-reported hardware or hardware that is/was experimental or not intended for mainstream availability (developer specific hardware for example). There are quite a bunch of fake video-cards around for example.

The only person that has the relevant information is the user who has such hardware and is able to identify it correctly (and contribute that knowledge to a pci database)

I did have a quick look around though, but was also unable to find any further hints on these unknown list of devices except for a pci database about nvidia here (https://envytools.readthedocs.io/en/latest/hw/pciid.html) which for example suggest that device 0775 (MCP77) is a memory controller ( https://envytools.readthedocs.io/en/latest/hw/pciid.html#pci-ids-mcp77 )
Title: Re: Ideas for Aros Distributions
Post by: cdimauro on January 18, 2021, 07:30:12 AM
@magorium: the experiment looks promising. The strange thing which I see is this:
Yeah, i know :-)

I got to work with what the grub tools offers me (well, not really but since i am new to grub and its particularities with regards to hybrids i have to see/understand what grub puts to xorriso)
Well, it can stay there as long as your solution works. ;)
Quote
I got some very strange (sometimes even unrepeatable) results, and of course the perfect solution would be that gpt and efi support is added as well (according to kiwi devs that is possible to do with grub but nobody seems to do that and use other solutions instead, so the interwebs is pretty quiet for me atm).
Unfortunately I've no expertise in that area. I've studied how EFI/UEFI works, but GRUB is a different beast. I hope that you can find some solution to add GPT & EFI, or someone that can help.
Quote
Quote
... because it's not possible to find the VendorID & DeviceID couple on the PCI devices database which I've used
I think that is something you would have to learn to live with ?

For example, the nvidia ones are not even listed on the nvidia's driver website (https://www.nv-drivers.eu/driver-by-vendev.html (https://www.nv-drivers.eu/driver-by-vendev.html)) or perhaps no specific drivers are needed for the device

There even might be the possibility of fake or miss-reported hardware or hardware that is/was experimental or not intended for mainstream availability (developer specific hardware for example). There are quite a bunch of fake video-cards around for example.

The only person that has the relevant information is the user who has such hardware and is able to identify it correctly (and contribute that knowledge to a pci database)

I did have a quick look around though, but was also unable to find any further hints on these unknown list of devices except for a pci database about nvidia here (https://envytools.readthedocs.io/en/latest/hw/pciid.html (https://envytools.readthedocs.io/en/latest/hw/pciid.html)) which for example suggest that device 0775 (MCP77) is a memory controller ( https://envytools.readthedocs.io/en/latest/hw/pciid.html#pci-ids-mcp77 (https://envytools.readthedocs.io/en/latest/hw/pciid.html#pci-ids-mcp77) )
This week I was busy helping my daughter for a project, but at least I had the time to think about it, thanks also to your input.

IMO we shouldn't focus on and pretending to support all devices by just taking into account all vendor + device ids couples. From your above example, which value gives us knowing that we support an nVidia's memory controller? I think zero. I don't even think that AROS needs to load a specific driver to make work & use such "peripheral".

What's important is that we have a list of supported GPUs, sound cards, hard drive, ethernet controller, etc..

So, and to be short, what we need is a list of supported vendor id + device id + class id (and maybe sub-class id), taking into account only the class ids which make sense (e.g.: not a generic memory controller). Because the class id gives us the information about which kind of peripheral it is.

When I've time I'll take a look to the PCITool to see how to get the missing information, and maybe export it as well.
Title: Re: Ideas for Aros Distributions
Post by: aGGreSSor on January 18, 2021, 03:38:21 PM
OMG, Apparently, the New Year continues.  ;)
Try looking at the sources. For example (https://github.com/aros-development-team/AROS/blob/c0b2bbb772a4b437a0480499814dbd48fb25c91f/workbench/hidds/radeon/ids.c).

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
Seem 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.  ;)
You clearly have problems. You don't have a clue but it's my advice to others (in case there is someone left which didn't realise yet). Whatever you try to do, it doesn't matter: don't help. It just sinks the community more and more. BTW following my policy of ignoring toxic people, I won't answer any fruther texts from you. Hope you get (much) better in the future.
I don't see your works, your commits, etc. I would like to get acquainted with your work to understand where your authoritative tone comes from. If possible with links to understand what you are capable of "for the pop-up community".  ;)