Official update to OS 3.1 from Hyperion

[ma693541]

Cloanto use pirated software in their packages, just look at some games in AF and C64F so I don't understand why they issued a DMCA notice to GitHub. Cloanto aren't better than you and me, the common Amiga user. Just do it as before, reverse engineer the parts of the AOS that you folks want to improve, but think on compatibility. Heck, if I want a improved AOS 3.9 i would donate either thru Kickstarter or Indiegogo.

[wXR]

Thanks for that link @kolla I will take a listen right away.

[Olaf Barthel]

Originally Posted by Locutus

Its GPL'd : https://github.com/jjuran/metamage_1/tree/master/relix

Thank you, that is a bit buried within the author's repository...

From how this looks, it appears to be a POSIX environment within which the shell commands, and git, will run. Something not unlike the ixemul solution (GeekGadgets, ADE, etc.) for the Amiga.

The "git" command sits next to this repository and it appears that it's the genuine article, although quite a bit behind the currently stable master version. Because it was forked off the original Git, it needs a working Perl setup.

It appears that this is a dead-end

A feature-complete Git client for the Amiga still seems to require more work. Sebastian Bauer has been working on it (https://sonumina.de/jenkins/job/sgit.amiga/), but so far it seems it is available only for AmigaOS4 and a plain 68k version is not provided.

[Olaf Barthel]

Originally Posted by kolla

You mean like this?
http://www.386bsd.org

Now that you mention it, I remember seeing this pop up on Hacker News.

I suppose that the authors found it a bit easier to keep the project running on existing hardware, as compared to the Amigas of yore.

While most of the machines of that age wound up in landfills (and maybe the attics of collectors), they were still making computers that could run 386BSD some 10 years after the last maintenance release. The Amiga was not quite so lucky.

[phx]

In my opinion Git makes no sense on AmigaOS, because it has ridiculously high resource requirements. Even if there was a port, it would be no fun to work with it on a 68k system.

[Locutus]

Originally Posted by Olaf Barthel

Now that you mention it, I remember seeing this pop up on Hacker News.

I suppose that the authors found it a bit easier to keep the project running on existing hardware, as compared to the Amigas of yore.

While most of the machines of that age wound up in landfills (and maybe the attics of collectors), they were still making computers that could run 386BSD some 10 years after the last maintenance release. The Amiga was not quite so lucky.

I'm sure the release is more for historical value then anything else. Jollix/386BSD was a monumental release as one of the first really usable full blown UNIX's available for PC which wasn't either insanely expensive or too feature limited and it also laid the foundation for Free/Net/OpenBSD.

As for hardware, anyone doing OS dev work uses QEMU for that. I don't want to think of the pain of having to do such things on real physical hardware and i see no reason why.

Historical value is the other reason why the OS3.1 source 'leak' was so fascinating, reading the RCS and code told more about Amiga history then anything else you can read.

[brknck]

If you want to see who owns the rights of AmigaOS then the settlement judgement from the Amiga Inc Vs Hyperion court case gives some interesting insights.

The settlement the way it is worded (to me anyway) appears to make it a legal minefield as 3 seperate companies are involved.

The link is here: (You can download a PDF as well)

https://docs.justia.com/cases/federa...245/148/1.html

[Olaf Barthel]

Originally Posted by modrobert

Perhaps obvious, if it ever comes to that, is to store the whole source code (tags and all) in a "read only" public SVN repository for preservation and historic purposes, and push the latest "working" 3.1 version mix to GitHub and let it fork off from there, starting fresh.

This is likely to take a lot of work to compensate for the loss of (for lack of a better word) "metadata" which the individual module history tags represent. I expect that this would likely to impact productivity more than the productivity gains attainable from switching to Git could compensate for.

With the tags gone, it becomes difficult to track which release each collection of files corresponds to. And let's not get into the bigger problem of matching those tags against the respective operating system release which they are a part of. There are V36 components in Kickstart 2.04 (V37), 3.0 (V39) and 3.1 (V40), there are V39 components in 3.1, etc. The version numbers of components were usually changed only if the respective code would no longer work with earlier releases, which explains why it looks like patchwork.

The tags are like "thumb tacks" (there's a pun there somewhere, I suppose) which pin down the collection of files that makes up a specific version. It's fundamentally what "software configuration management" tools are supposed to be doing, so it's not an "expendable" property of the subversion repository.

[wawa]

Originally Posted by Olaf Barthel

This is likely to take a lot of work to compensate for the loss of (for lack of a better word) "metadata" which the individual module history tags represent. I expect that this would likely to impact productivity more than the productivity gains attainable from switching to Git could compensate for.

With the tags gone, it becomes difficult to track which release each collection of files corresponds to. And let's not get into the bigger problem of matching those tags against the respective operating system release which they are a part of. There are V36 components in Kickstart 2.04 (V37), 3.0 (V39) and 3.1 (V40), there are V39 components in 3.1, etc. The version numbers of components were usually changed only if the respective code would no longer work with earlier releases, which explains why it looks like patchwork.

The tags are like "thumb tacks" (there's a pun there somewhere, I suppose) which pin down the collection of files that makes up a specific version. It's fundamentally what "software configuration management" tools are supposed to be doing, so it's not an "expendable" property of the subversion repository.

It shouldnt be impossible to import the commit history into a modern source management system. Except it might be more difficult with more orthodox formats. But then, how can you browse comit history stored lile that today?

Ideally sources should be imprted to git or svn as far as possible while keeping the originals for reference.

[wXR]

Hailing the Sakura-IT guys, who figured out a way to do this (their repo is git, but they work on Amiga)...

[wawa]

Originally Posted by wXR

Hailing the Sakura-IT guys, who figured out a way to do this (their repo is git, but they work on Amiga)...

you sure? how?

[Ffin]

I think this new release may be intended primarily for the Tabor A1222, see the UBoot image below:

[Heiroglyph]

Originally Posted by Ffin

I think this new release may be intended primarily for the Tabor A1222, see the UBoot image below:

That looks possible for sure.

It seems more in line with their existing business plan as well.

[Heiroglyph]

wXR, there is a lot of good info on ownership in that podcast. He seems really level headed.

Cloanto claims to own the copyright to everything up through 1993. 1994 and newer is not owned by them.

They also seem open to the idea of open source so that it isn't lost.

I don't know about anyone else, but an open source version of what we had in 1993 would still be worth while.

Everything after that could be rebuilt if people could legally get at the source.

[eXeler0]

No single party seems to be able to prove ownership of 3.5 and 3.9 that would be valid to this day. (At least nothing that holds in court, or the situation wouldn't be what it is).
If the 3.1 source was "open" I imagine it would be possible fairly easily get to the 3.9 level and work from there.

But... who *holds/keeps* the 3.9 source? Still Haage-Partner or someone else?

Skickat från min LG-H850 via Tapatalk

[modrobert]

Originally Posted by phx

In my opinion Git makes no sense on AmigaOS, because it has ridiculously high resource requirements. Even if there was a port, it would be no fun to work with it on a 68k system.

I remember reading something about an old Sun box being used for cross compile of the 3.1 sources by Commodore back in the day, and it will not compile entirely on a classic Amiga, but perhaps that's easily fixed.

Originally Posted by Olaf Barthel

This is likely to take a lot of work to compensate for the loss of (for lack of a better word) "metadata" which the individual module history tags represent. I expect that this would likely to impact productivity more than the productivity gains attainable from switching to Git could compensate for.

With the tags gone, it becomes difficult to track which release each collection of files corresponds to. And let's not get into the bigger problem of matching those tags against the respective operating system release which they are a part of. There are V36 components in Kickstart 2.04 (V37), 3.0 (V39) and 3.1 (V40), there are V39 components in 3.1, etc. The version numbers of components were usually changed only if the respective code would no longer work with earlier releases, which explains why it looks like patchwork.

The tags are like "thumb tacks" (there's a pun there somewhere, I suppose) which pin down the collection of files that makes up a specific version. It's fundamentally what "software configuration management" tools are supposed to be doing, so it's not an "expendable" property of the subversion repository.

Thanks for explaining, and considering what phx pointed out, when developing on a classic Amiga, then SVN (or CVS) makes even more sense.

[wawa]

i think being able to compile on itself should be a feature or at least aim of a regular operating system. but im not sure amiga operating system components have all fulfilled this demand ever, especially as we hear that the build process is so complicated. neither im certain if os4 compiles on itself, since its closed source we are not supposed to know, so its very hard to prove, and rather improbable.

[wawa]

one pattern i observe in the posts in this thread is repeating. the impossibility to compile the whole os in one go. perhaps this is less due to technical issues, but rather because none is allowed to do that and there are rather few people having access to the compete source. at least what concerns os4, as i doubt the sources of execsg are shared among the developers. it may be the case with a number of other os modules, as it seems that the license and distribution agreements have been made about the binaries rather than the sources. so maybe its all more due to politics rather than feasibility.

[idrougge]

If compiling the OS in one go was technically useful and technically feasible, it would have been made possible by now.

[modrobert]

wawa and idrougge,

Yes, my mistake was assuming that the source code requires cross compile when pushing for GitHub in previous posts, not even thinking about doing this on a 68k Amiga.