AROS World Exec
General => Help => Topic started by: Mysha on March 01, 2024, 01:58:08 PM
-
All these people who have problems with programs: I don't have those. I've downloaded <AROS-20240229-linux-x86_64-system.tar.bz2>, I think from 29 February, and now that I've gotten it to the right computer, it tells me that the file is not a bzip file.
Any known problems, or should I just try anew with a more recent archive?
-
What OS do you use, and what program do you use to unpack?
-
What OS do you use, and what program do you use to unpack?
OK, that suggests it's not a problem throughout. Let me see: I run Ubuntu Mate (let me check for that computer) - here I am again - 22.04. Engrampa is doing to unpacking; curiously, it's doing the unpacking of the contribs (I think) fine, while I'm typing t his. This looks like it's going to be a redownload.
-
I have no problem with Windows, I unzip quietly with WinRAR or 7-Zip
Make sure the archive you downloaded is not corrupt !
-
I have no problem with Windows, I unzip quietly with WinRAR or 7-Zip
Make sure the archive you downloaded is not corrupt !
Thanks. The archive I downloaded is OK, but the copy I had on my memstick I'm a bit in doubt about.
BTW, when I unpack AROS on a memstick, would that be a CD or a harddisk with floppy? I never do that, but I noticed that only a harddisk version has a floppy with it.
-
I don't use Linux, but I think you can build a CD ISO, to make it Bootable you should have the knowledge !you cannot create a Live Pendrive, you can create it later using InstallAROS
My AROS One x86 Distribution, you can download it as an ISO or as a USB image that you can burn to a Pendrive or External USB Hardisk.
-
I have no problem with Windows, I unzip quietly with WinRAR or 7-Zip
Make sure the archive you downloaded is not corrupt !
Thanks. The archive I downloaded is OK, but the copy I had on my memstick I'm a bit in doubt about.
Sent it over by sneaker-mail again. (I always wonder if we could write out an actual sneaker-mail protocol.) This time everything went fine. Thanks for reassuring me that it worked for you.
So, this is now a non-topic. Is there a way to get rid of it, now that it's no longer relevant?
-
Can serve for other users !
-
All these people who have problems with programs: I don't have those. I've downloaded <AROS-20240229-linux-x86_64-system.tar.bz2>, I think from 29 February, and now that I've gotten it to the right computer, it tells me that the file is not a bzip file.
Any known problems, or should I just try anew with a more recent archive?
The automatic builds rotate every night when there was a succesful build so i can't check/verify with the exact same archive that you downloaded.
Simply replace the numbers of the date to match the current date, and in case the link fails check on the www.aros.org (http://www.aros.org) download-page
which was the latest date that had a succesful build (and change the numbers accordingly).
Download the archive:
$ cd temp
$ wget https://sourceforge.net/projects/aros/files/nightly2/20240301/Binaries/AROS-20240301-linux-x86_64-system.tar.bz2
Check type of file:
$ file AROS-20240301-linux-x86_64-system.tar.bz2
AROS-20240301-linux-x86_64-system.tar.bz2: bzip2 compressed data, block size = 900k
download and verify MD5 checksum:
$ wget https://sourceforge.net/projects/aros/files/nightly2/20240301/Binaries/AROS-20240301-linux-x86_64-system.tar.bz2.md5
$ md5sum -c AROS-20240301-linux-x86_64-system.tar.bz2.md5
AROS-20240301-linux-x86_64-system.tar.bz2: OK
unarchive:
$ tar -xf AROS-20240301-linux-x86_64-system.tar.bz2
Start AROS:
$ cd AROS-20240301-linux-x86_64-system
$ boot/linux/AROSBootstrap
... and AROS should be showing its face.
Note that, in case nothing changed all this time, that the archived build that you downloaded is not compatible with deadwood's work (https://axrt.org/downloads-aros) (which is a fork and is using ABIv11 for 64-bit).
-
BTW, when I unpack AROS on a memstick, would that be a CD or a harddisk with floppy? I never do that, but I noticed that only a harddisk version has a floppy with it.
With regards to the specific archive you downloaded ? Neither.
You need the native version in case you want to natively boot AROS. So for a 64 bit machine that would be the archive that is listed on the download page as: pc-x86_64-boot-iso
The imo easiest way to get that to work is to boot that iso from a virtual machine, attach a thumbdrive to your VM and use the AROS installer to install AROS to that thumbdrive. Once done you can use that thumbdrive to try and boot AROS natively on your hardware.
As noted by AMIGASYSTEM, both AROS one and icaros also provide a (raw) thumbdrive image that you can directly write to a thumbdrive to safe you the hassle of preparing it yourself.
Please do not bother writing ISO's to a physical CD-Rom (it more often goes wrong than that it actually works) and none of the available tools that allow you to boot (Linux/windows) ISO files is able to boot AROS.
Do note that not every hardware is supported by AROS and that it requires older hardware that is compatible with AROS in order for this to work. It is finicky.
My rule of thumb: if the hardware is too new to be able to boot AROS then the hardware is usually fast enough to be able to enjoyable run AROS hosted (on your main OS) or running it inside a VM
-
Thanks for the description. It has no direct equivalent to what I actually do, but it's a nice overview to work off of.
The one thing I am not sure about is the closing bit about AB1.*, though it can well be that that's my confusion.
I have 86*64 machines; I usually run Linux, though admittedly the one I now loaded AROS to, could be made to run AROS natively. The last time I paid attention to the OS versions, I believe AROS had a restructured version as its target, that the 64 machines were moving towards, while your 32-bit (ah, it'll come back to me) distribution was a bit more conservative.
Is this all still the case, or have the goal posts moved?
-
Is this all still the case, or have the goal posts moved?
It is complicated but I'll try to give it a spin.
As natural progression the 64-bit version of AROS came into play. A long story short, that resulted in the 64-bit version of AROS taking some other approaches than the 32-bit version did.
Because 64-bit AROS never came to full frutation as the 32-bit version did (distro's available, people porting software) deadwood made the decision to make a spin-off of the 64-bit version of AROS with the aim to make the experience as close as possible to the 32-bit version, also backporting new features from the original 64-bit version into AROS 32-bit (development of AROS 32-bit practically came (or was) to an hold at that time).
So, now we have 32-bit and 64-bit versions of AROS that are almost up to par with the original AROS implementation and deadwood came with another idea, named axrt (aros executable runtime environment). This allows for AROS compiled software to run natively on your Linux machine. This in the hopes to increase interest for porting 32-bit software to 64-bit and perhaps also attract some more souls as development can be done natively on Linux and for missing functionality you can fallback using Linux API, so be able to gradually port software).
I am sure i forgot to mention some tings here and there or perhaps there are other goals but you would have to ask one of the AROS developers about further details.
Point being that afaik none of the original AROS developers hang around here anymore (they reside on slack) and here we mostly focus on work done by deadwood's forks. Do note that things are ported back'n'forth between the different repositories of AROS that do exist, though afaik original developers completely seized 32-bit development of AROS.
Does that help you in having a better understanding ?
-
Oof - Legendary member talking to a Newbie (Though "Legendary" would suggest you are no longer part of the project, and "Newbie" would suggest I'm completely new to it.)
Ok, so thanks for the story, but the short is: (The developers, who are no longer at the mailing lists, have gone where I can't take part, and) The version for me to get, would be for 86 - Nightly ABI1, to catch the problems, and Nightly ABI0 to be usable.
That would brings us to the icon manager tool, that can be run without doing more harm than HELP. Any progress?
And obviously, this would suggest a tool to make a disk bootable, that'll work on memsticks. Is it there yet, or will I have to move things over from memstick do harddisk each time?
-
Ok, so thanks for the story, but the short is: (The developers, who are no longer at the mailing lists, have gone where I can't take part, and) The version for me to get, would be for 86 - Nightly ABI1, to catch the problems, and Nightly ABI0 to be usable.
uhm, no. Not exactly :)
@deadwood: in case I got something wrong here then please add your (valuable) input.
The people that make distributions (AROS one for instance) and develop software (miker for instance) use the new ABIv0 created by deadwood. It leave things incompatible to older distributions such as Icaros Desktop and AspireOS. www.aros.org also does not support that old(er) ABIv0 anymore.
Deadwood backports new features from 64-bit ABIv1 back to his (alternate) version of AROS ABIv0 and can be found here (https://www.axrt.org/) and on his github here (https://github.com/deadwood2/AROS/tree/alt-abiv0).
The date mentioned in the downloadable archive names is the date that signifies the changes (up to that date) that were made in AROS 64-bit (ABIv1) that can originally be found at www.aros.org and https://github.com/aros-development-team/AROS.
That was the information concerning the (32-bit) ABIv0.
Then we have 64-bit (ABIv1 at www.aros.org) which is forked by deadwood as ABIv11 and is entirely focused on 64-bit AROS. ABIv11 and ABv1 are incompatible with each other.
That would brings us to the icon manager tool, that can be run without doing more harm than HELP. Any progress?
I am not entirely sure what you meant with icon manager tool but am assuming you are referring to the work that user Miker is doing on his icon tools ?
And obviously, this would suggest a tool to make a disk bootable, that'll work on memsticks. Is it there yet, or will I have to move things over from memstick do harddisk each time?
The only way to install AROS is either by physical booting a CD-rom and use the installer or boot AROS from a memory stick and use the installer.
Those are currently the only two options that are available to make it possible to try AROS to run native on hardware.
Actually there is a third, namely using a raw HD in a VM, boot AROS from ISO or memory stick in the VM and install AROS to the raw attached HD. Afterwards, move the HD physcially from your VM machine to the final hardware where you want to have AROS run, but that is tiresome, not for the fainthearted and thus not for everyone.
-
@deadwood:
Writing the above actually made me realize if it would be an idea to make a (humble) request/issue to try and explore if it would be possible for AROS to be used with something like ventoy and what would be required (if any) to accomplish such task.
I am aware that such request was made in the past and was denied for obvious reasons (each solution booting ISO's requires its own solution) but looking at how a more mature tool like ventoy approaches this it might perhaps be something that makes it worthwhile ?
Oh, and I am aware that hosted with USB enabled should be able to do the trick as well but I can't seem to get that to work (last time I checked it was not enabled by default but that might have its reason(s))
-
That would brings us to the icon manager tool, that can be run without doing more harm than HELP. Any progress?
I am not entirely sure what you meant with icon manager tool but am assuming you are referring to the work that user Miker is doing on his icon tools ?
I'll do an easy one first. (I know: Not the developer way, but I'm a bit too busy for the other parts.) To get icons working, we got PNGs first. To that more parts of icons were added, and more types of graphics. Obviously, having the IFF system, this is easily cobbled together.
For simplicity's sake, for icons the PNGs would be allowed as a stack of images, and anything beyond that be stored in the IFF. That way, everyone would be able the handle the icons, but the content of the IFF would be on a "don't know - don't touch" basis.
Anything more complicated could be handled by more complicated software, as long as they understood the basics: Get images, get IFF; if more than one image, check the IFF to read their purpose. More complicated icon formats: Support them as long as you are able to translate them back to PNG-IFF.
Easy as cake, but later approaches seem to be make a pie of some sort out of it....
Simple approach: Convert entire install to to PNG-IFF. Do whatever you want to do to their images. Do whatever you want to do to their IFFs. Regenerate VerySpecial icons out of them if you must.
That was all that was about, except that I can't find my way around here, much, so I tend to ask rather general questions to see what I catch with it.
-
Please forgive me Mysha for still not quite understanding what you are referring to. I have been using Amiga OS for so long that it is difficult to imagine someone not knowing/being aware of some of the details.
Traditionally Amiga OS adds supports for icons using the icon format. There has been a couple of iterations of that format to add support for different other formats (newicons, glowicons etc) to compensate for some of the shortcoming that the original icon format had.
AROS adopted the png icon format, basically the OS supports that you place png image into a directory, give it the proper icon filename extension (.info) and the 'desktop' allows you to add icon related properties. You can even merge two png images together to have a separate image for the selected and unselected state.
Miker is working on some tools that f.e. allows you to manipulate (the colours of) icon images, put two images together to create an icon etc. His work can be found on this board at this subforum (https://ae.arosworld.org/index.php?board=5.0) (see topics: iconsplitter, iconpress and icontoolkit) but he moved his discussions over to arosworld.org here (https://www.arosworld.org/infusions/forum/viewthread.php?thread_id=1146&sort_post=oldest)
Other than that the aros archives (http://archives.aros-exec.org/) provide other icon related tools.most notably processicon (http://archives.aros-exec.org/?function=showfile&file=utility/workbench/processicon.i386-aros.zip)
So, in light of that I (still) do not fully grasp what you are trying to tell/ask with your post other then what I am able to interpret and that seem to suggest to add yet another icon storage format ?
-
@magorium
User Mysha may be referring to the default AROS "Gorilla" Icons that are in the images IFF format
@Mysha
I still don't understand what you write, you could make your requests more simply and concisely !
-
Hi,
Please forgive me Mysha for still not quite understanding what you are referring to.
You are forgiven.
Other than that the aros archives (http://archives.aros-exec.org/) provide other icon related tools.most notably processicon (http://archives.aros-exec.org/?function=showfile&file=utility/workbench/processicon.i386-aros.zip)
See, I told you somebody should be able to manage icons. I'll have to check that it's for the right blood type, and it's rather Swiss Army knife, instead of a specific tool, but if it matches, it'll get things done.
-
... I'll have to check that it's for the right blood type, and it's rather Swiss Army knife, instead of a specific tool, but if it matches, it'll get things done.
Hm, It doesn't seem to be the right blood type, after all.
- So, there was an older ABIv0, 32 bit, no longer supported by AROS.org itself, but possibly still in use for IcAROS. Obviously, leaving that situation behind means once again split in user base. We seem to be quite fond of that.
- Then there's a newer ABIv0, also 32 bit, well if we call the first one ABIv0.0, then this would be ABIv0.1. That's in personal locations, and it's a moving target.
- Next we get a 64 bit target, let's call that one ABIv1.0. It's supported on AROS.org. I take it that is a moving target as well, though.
- And then there's ABIv1.1, which is possibly the axrt version, in which case for optimal unusability that one too is a moving target.
Add to that, that I now realised that rather than the "original developers completely seized 32-bit development of AROS", it should read "original developers completely ceased 32-bit development of AROS", and options are rather limited. Things come down to either ABIv0.0 from IcAROS, which we already know won't work in my case, or recompiling every offering myself since there are no other stable versions to create software releases for.
Well, not tonight; I'm going to bed.
-
So, there was an older ABIv0, 32 bit, no longer supported by AROS.org itself, but possibly still in use for IcAROS.
Obviously, leaving that situation behind means once again split in user base. We seem to be quite fond of that.
Affirmative on both accounts.
Then there's a newer ABIv0, also 32 bit, well if we call the first one ABIv0.0, then this would be ABIv0.1. That's in personal locations, and it's a moving target
Strictly technically speaking old ABIv0 (Icaros) and alt_ABIv0 (https://github.com/deadwood2/AROS/tree/alt-abiv0), but yes.
Next we get a 64 bit target, let's call that one ABIv1.0. It's supported on AROS.org. I take it that is a moving target as well, though.
ABIv1 exist for 32-bit, 64-bit, m68k (it always was ABIv1 for m68k since ABIv1 was introduced), arm, ppc etc as listed here (https://github.com/aros-development-team/AROS).
And then there's ABIv1.1, which is possibly the axrt version, in which case for optimal unusability that one too is a moving target.
It really is referred to as ABIv11 but yes again. See here (https://github.com/deadwood2/AROS) (master/main branch)
Axrt resides at the same repo but in another branch, here (https://github.com/deadwood2/AROS/tree/alt-runtime).
Add to that, that I now realised that rather than the "original developers completely seized 32-bit development of AROS", it should read "original developers completely ceased 32-bit development of AROS",
Indeed, one of my more ... shall we say ... finest moments ? :-[
and options are rather limited. Things come down to either ABIv0.0 from IcAROS, which we already know won't work in my case, or recompiling every offering myself since there are no other stable versions to create software releases for.
Alt_ABIv0 is as stable as it gets, and the same is true for ABIv11.
Deadwood tries to keep breaking changes to a minimum (I can't even remember the last breaking change). Both ABI's do get constant updates and Axrt is really a moving target (though deadwood did indicate it to be reasonably stable but he might change his opinion for the better good, as it is an experiment after all).
To try and make your head spin even more, updates, fixes and other improvements gets committed back 'n' forth between different repo's and/or branches. See for example this commit history (https://github.com/aros-development-team/AROS/commits/master/) in main AROS Development team repo/branch.
There are at least two distributions that that are based on alt_ABIv0, namely Tiny AROS (https://tinyaros.flazio.com/) and AROS One (https://arosworld.org/infusions/forum/index.php?viewforum&forum_id=16). The only thing I currently do not know is if both distro's also support ABv11 (but the idea/intention is to move forward).
Deadwoods next effort seem to be a 32-bit AROS emulator for 64-bit AROS but you would have to ask him about the details because I have not had the time to get into that particular project
I do not know what exactly you wish to contribute but you could always opt for going the safe side and commit to the original AROS Development Team repository. Changes made in that repo will usually and eventually find their way back to the other ABI('s).
BTW: Don't let the member status fool y'ah, it is just an indicator for the postcount. Thus many questions asked will get you there as well ;)
-
And then there's ABIv1.1, which is possibly the axrt version, in which case for optimal unusability that one too is a moving target.
It really is referred to as ABIv11 but yes again. See here (https://github.com/deadwood2/AROS) (master/main branch)
Ah, I thought that was a missing dot. OK, the 11th version AROS; we have come along way, apparently.
Add to that, that I now realised that rather than the "original developers completely seized 32-bit development of AROS", it should read "original developers completely ceased 32-bit development of AROS",
Indeed, one of my more ... shall we say ... finest moments ? :-[
Oh, you score quite high on the list. (I work in a school.)
and options are rather limited. Things come down to either ABIv0.0 from IcAROS, which we already know won't work in my case, or recompiling every offering myself since there are no other stable versions to create software releases for.
Alt_ABIv0 is as stable as it gets, and the same is true for ABIv11.
That's good to know. That should mean that people can add compiles for other branches to their software distributions.
To try and make your head spin even more, updates, fixes and other improvements gets committed back 'n' forth between different repo's and/or branches.
OK, thus any OS-y corrections will eventually percolate to all relevant versions.
I do not know what exactly you wish to contribute but you could always opt for going the safe side and commit to the original AROS Development Team repository. Changes made in that repo will usually and eventually find their way back to the other ABI('s).
No, that's the type of fine moment I tend to do; I shift the viewpoint without warning the reader. The software development I was referring to above, is the type done by other developers. If there are no stable branches, we have to tell everyone to let their users compile it themselves. If their is a limited number of stable branches, we can invite those developers to distribute pre-compiled versions for those. (Apparently, at the moment we could do so; but I don't know if we have the contacts.)
That's also why I said /I/ would have to compile it myself if I was on a different branch from the one in The AROS Archives. (I'll probably start anew, after work today, but I'll probably need recompiling anyway.) But where changes are concerned: There usually are improvements to be made in any program; but I guess here I'd prefer to let the Uploader/Author know.
-
Ah, I thought that was a missing dot. OK, the 11th version AROS; we have come along way, apparently.
Tbh I do not know if secretly/internally it actually does stand for 1.1 but when deadwood named it I seem to remember that it was done to make it more distinct to the other ABI's. 11 sounds more impressive than 1.1... perhaps depending on your point of view.
Oh, you score quite high on the list. (I work in a school.)
I take any compliment I can get :P
OK, thus any OS-y corrections will eventually percolate to all relevant versions.
Corrections, yes for sure. When it comes to new features than that is dependent on the viewpoint of the maintainer(s).
No, that's the type of fine moment I tend to do; I shift the viewpoint without warning the reader.
As is your prerogative :)
The software development I was referring to above, is the type done by other developers. If there are no stable branches, we have to tell everyone to let their users compile it themselves. If their is a limited number of stable branches, we can invite those developers to distribute pre-compiled versions for those. (Apparently, at the moment we could do so; but I don't know if we have the contacts.)
As far as my understanding goes atm there are developers that get asked to compile software for a distro maintainer or to bring software to AROS (bars'n'pipes is an example of that) so that things get ported and can be added to such distro. What happens after that, I have no idea and might depend on the agreement between distro maintainer and porter. It is different for each individual situation.
AROS does have the contrib repositories that are maintained but which software ends up exactly were is a bit unclear to me atm so you are not wrong there..
That's also why I said /I/ would have to compile it myself if I was on a different branch from the one in The AROS Archives. (I'll probably start anew, after work today, but I'll probably need recompiling anyway.)
Yes, unfortunately. Though depending on the chosen branch/distro you might be in luck if someone already did it for you.
On a sidenote, and if I recall correctly (old) ABIv0 software (fe. from the AROS archives) should be able to run on alt_ABIv0 but afaik it is not guaranteed to work. On that same note, alt_ABIv1 compiled software should be incompatible with old ABIv0.
I certainly have been out of the loop for too long....
But where changes are concerned: There usually are improvements to be made in any program; but I guess here I'd prefer to let the Uploader/Author know.
I do not know if there is a recommended way nor what (if any) path should be taken there.
For sure, and as you already concluded, it is a fine mess and almost incomprehensible to understand.