Why not support Aros 68k instead of patching old binaries?

[cunnpole]

patch may NEVER be released!

Is a standalone binary patcher not possible?

[kamelito]

The problem with AROS is that it's (unfortunately) not a practical replacement for 68K AmigaOS. Unless AROS can run at a "Usable" speed on a 68020 Amiga with 512KB ROM and 4 MB Fast RAM with a high degree of compatibility to 68K AmigaOS it never will be practical.

That's why I still code (and patch) for my classic 68K Amiga's from time to time. But I'm not sure if will release any more patches for AmigaOS or any third party stuff either. It's just not worth the hassle of defending your patches against people acting as "Self-appointed" lawyers of the copyright owners (who have long since abandoned the Amiga scene or just really don't care what happens).

Sorry folks, my A3000 scsi.device patch (now supporting RDBF_SYNC and some other improvements) and

My A2091/A590 scsi.device patch (14MHz scsi timings, obsolete xt.device removed and now supporting RDBF_SYNC) and

My 7/14MHz jumper select GURU ROM* patch may NEVER be released!

*The author has the patched ROM binary and could release it any time he wants.

If we get LLVM/CLANG working one day, maybe the generated code will be fast enough for that.

Kamelito

[eliyahu]

@SpeedGeek

to be clear the issue on amiga.org isn't so much binary patches, with distributing complete binaries with the patch already applied. for example if one releases a small patch for cybergraphics.library, it can only be used with people who have the original. whereas if someone releases a full copy of cybergraphics.library with the 'new' patch applied, they are distributing someone else's (commercial) software and would need permission to do so. see the difference?

-- eliyahu

[Oldsmobile_Mike]

Aros 68k together with Rom Replacements from Toni Wilen.

I run four of Cosmos's patched libraries on my A2000.  And three on my A500.  Along with several of Thomas Richter's libraries, and Peter K.'s fabulous icon.library...  I doubt many of my libraries at all are "original", anymore.  For me this works great, gives me a very "modern" and fast environment, I can't speak for others.  Honestly sometimes I'm surprised my systems don't just burst into flames, running both Cosmos's libraries and THoR's.  

Question though: I've always heard that AROS 68k libraries are huge "resource hogs", and "run like a dog" on native 68K systems.  Not to bash all the hard work I know the authors have put into them, I just don't think (based on what I've heard) that they're right *for me*.  Can anyone confirm performance of the AROS 68K files on actual classic Amiga hardware?  Maybe that would motivate people to switch?

Heck, if Cosmos put his excellent optimization skills into AROS 68K, maybe they wouldn't be so slow?  :lol:

[warpdesign]

you cannot recreate a breakthrough by including the same design errors in a modern re-creation, let it be morphos, os4 or aros. The classics are - classic old computes in a classic old environment.

Rather, if i want to have some fun with modern machines, i'd rather go for a modern os and play with that. Works, too.

+1000

[SpeedGeek]

Is a standalone binary patcher not possible?

Yes, possible but not likely.

@SpeedGeek

to be clear the issue on amiga.org isn't so much binary patches, with  distributing complete binaries with the patch already applied. for  example if one releases a small patch for cybergraphics.library, it can  only be used with people who have the original. whereas if someone  releases a full copy of cybergraphics.library with the 'new' patch  applied, they are distributing someone else's (commercial) software and  would need permission to do so. see the difference?

-- eliyahu

I see the difference but not everyone else does (e.g. ThoR). Also, once a binary patch has been released it can be used by anyone to distribute the full version of copyrighted software (it's makes no difference if it's commercial or non-commercial it's the copyright and the license to use that copyrighted software which makes all the difference).

[psxphill]

I see the difference but not everyone else does (e.g. ThoR).

He does see the difference between distributing patches and full copies, you don't appear to understand what his objection is.

Think of it like two religions arguing over which is right. Some people want to release binary patches rather than rewriting stuff and using a modern compiler, others want to rewrite stuff and use a modern compiler but see the binary patches as a reason not to bother (because it essentially is).
 
Using aros would be the most logical, but like when religion is involved logic goes straight out of the window once someone is convinced they are doing the right thing and others support them. The best way of derailing a good system is to make a bad one popular, like how Windows has become the no 1 OS.

[ncafferkey]

You cannot recreate a breakthrough by including the same design errors in a modern re-creation, let it be Morphos, OS4 or ARos. The classics are - classic old computes in a classic old environment.

Rather, if I want to have some fun with modern machines, I'd rather go for a modern Os and play with that. Works, too.

So-called modern OSes have their roots in even older designs than AmigaOS, with their own design flaws. For instance, Linux, as you know, has its roots in 1970s Unix, and I was reading today how compatibility with the Unix behaviour of recording file access times is viewed as a major performance bottleneck when strictly adhered too. AmigaOS thankfully never used the concept of last access time. And AmigaOS has always had asynchronous I/O support, unlike Unix and its descendants.

IMHO AmigaOS has a lot of good design features as well as its drawbacks, which is why I don't want to leave them in the past. It has its own heritage, like the mainstream OSes, but hasn't had the same investment.

[QuikSanz]

So-called modern OSes have their roots in even older designs than AmigaOS, with their own design flaws. For instance, Linux, as you know, has its roots in 1970s Unix, and I was reading today how compatibility with the Unix behaviour of recording file access times is viewed as a major performance bottleneck when strictly adhered too. AmigaOS thankfully never used the concept of last access time. And AmigaOS has always had asynchronous I/O support, unlike Unix and its descendants.

IMHO AmigaOS has a lot of good design features as well as its drawbacks, which is why I don't want to leave them in the past. It has its own heritage, like the mainstream OSes, but hasn't had the same investment.

+1

[guest11527]

So-called modern OSes have their roots in even older designs than AmigaOS, with their own design flaws. For instance, Linux, as you know, has its roots in 1970s Unix, and I was reading today how compatibility with the Unix behaviour of recording file access times is viewed as a major performance bottleneck when strictly adhered too.

But you are aware of the "noatime" mount option, are you? Besides, that's really *not* one of the problems of Linux. There are quite a couple of points I could think of that are not ideally solved, but this is none of them.

AmigaOS thankfully never used the concept of last access time. And AmigaOS has always had asynchronous I/O support, unlike Unix and its descendants.

Since when does Unix *not* have async I/O? O_NONBLOCK exists since ages, and select() exists since ages to wait on such I/O. There is no 1 to 1 correspondance between SendIO() and read() or write() or select(), but there are certainly means to achieve the same.

IMHO AmigaOS has a lot of good design features as well as its drawbacks, which is why I don't want to leave them in the past. It has its own heritage, like the mainstream OSes, but hasn't had the same investment.

There are certainly a couple of good features, such as the virtual file system of Tripos or the automatic backing store of windows (aka SMART_REFRESH), but the problem is that some of the design decisions are real roadblocks. So for example, as long as Forbid() exists, and as long as that refers to a freely accessible memory location in exec, there will be no SMP. As long as Supervisor() exists, there will be no secure system. As long as resources can be handed over between tasks, there will be no resource tracking and no stable system that can recover from program faults.

So the problem is actually a different one: Unix was designed as a main-frame system, and designed as a "safe multi-user system with access control and resource management" because that was actually a requirement from its users (AT&T, namely). So all essential features you consider as of today as relevant are there, by design. Other features such as "handling of removable devices" were not relevant, and a lot of energy is used to provide a good user experience (think of layers over layers on dbus, hal, udev...).

Amiga was designed as a consumer device, a toy (actually, the hardware was designed for a flight simulator). So features such as stability and scalability were considered irrelevant for this target audience and did not make it into the system. However, while it is certainly possible to add "removable device support" to a main-frame system (see Linux), making AmigaOs a safe stable system is a much harder, if not impossible attempt. The whole concept was never designed to be secure, and never designed to be a scaleable multi-user system. There are essential design flaws which are real road-blocks for any further development.

[SpeedGeek]

He does see the difference between distributing patches and full copies, you don't appear to understand what his objection is.

Think of it like two religions arguing over which is right. Some people want to release binary patches rather than rewriting stuff and using a modern compiler, others want to rewrite stuff and use a modern compiler but see the binary patches as a reason not to bother (because it essentially is).
 
Using aros would be the most logical, but like when religion is involved logic goes straight out of the window once someone is convinced they are doing the right thing and others support them. The best way of derailing a good system is to make a bad one popular, like how Windows has become the no 1 OS.

Really? It appears you don't understand what his objection is. He simply objects to any patching or updating of anybody's code (unless it's public domain or open source) without the owner's express consent. It makes no difference to him whether you release a binary patch or the complete software.

He doesn't care if your patching abandon-ware or just releasing a bug fix, if you don't have the author (or copyright owners permission) then you have no business messing with their code PERIOD.

The real problem is that copyright laws (originally written to protect published writers and artists works) aren't really suited for computer software which becomes outdated, obsolete and finally abandoned in very short time periods as compared to what the laws were originally written for.

[vxm]

Congratulations. With two evidences:

the first which is a software solution, "Unix was designed as a main-frame system, and designed as a "safe multi-user system with access control and resource management""

and the second which is a hardware solution, "the hardware was designed for a flight simulator"

you conclude a real fake truth, "There are essential design flaws which are real road-blocks for any further development."

The fact that a car does not make the job of a tractor and vice versa does not induce stopping their respective development.

[guest11527]

The fact that a car does not make the job of a tractor and vice versa does not induce stopping their respective development.

Look, you may want to work with a machine that crashes every five minutes and that has no security against virii in the internet age. Maybe. I don't. It's nice to have an old machine to play with, out of historic interest, but that still doesn't make this a *good* machine by today's standards, leave alone a racing car.  

What you might have forgotten: The world kept rotating, the racing car is from 1950 and forgotten in a barn, and tractor engines got so much more powerful that any tractor it can overtake your racing car without a problem. Actually, in every possible aspect.

Sure, it's nice to have the old stuff in the barn and take it out for a Sunday ride. But that still doesn't make it sensible to consider this as a future direction for computing. It isn't. Too many constructional weaknesses.

[guest11527]

Really? It appears you don't understand what his objection is. He simply objects to any patching or updating of anybody's code (unless it's public domain or open source) without the owner's express consent. It makes no difference to him whether you release a binary patch or the complete software.

Thanks for telling me what my objection is. Allow me to correct you - BTW, you got it wrong.

Point one is that I'm not (primarely) concerned about copyright, at least not right now. Copyright is a much more serious matter for commercial use than it is for hobby use. Point is simply:

If you patch a program, make a good attempt reaching the author. If that fails, try again, or ask somebody else with contacts to him. See what the author has to say, listen carefully and try to understand the point, whatever the point might be. For or against, no matter. Be respectful.

If all this fails, there are *still* options to probably organize improvements on old software. Probably even without patching. The danger of this binary patching stuff is: You never know what the intentions of the author might have been, you cannot read the source, and you cannot read the comments in the source. It might be just your problem that you did not understand the interface, or that there is a bug in *your* program instead of the author's code. The second danger is that this causes a chaotic "anti-development" of the software in question because somebody else might *also* have an idea what would need fixing. And probably such "fixes" do not even work with each other, or mess up the software completely. In worst case, we end up with N totally incompatible versions of the software, and program A working with version 1 but not with version 2, and program B just the other way around...

So for example, if you want to update such old software, probably try to find a group of people that are interested in the same old code, get organized, and - after some good testing - release a patch and make this group of people responsible for the code. Or try to reach the author as a group, organize a petition.... There are many ways. These ways are more complicated, but they will probably yield better software, or - gosh! - even legal software. (There is the copyright argument).

Problem is: Nothing of that happened. In fact, this was a wild-west style shoot-first-ask-later attempt at fixing a potentially, though likely bug, without any coordination and without any attempt of giving the author a chance to even react.

In this particular case, the author is even still around, can be contacted, and should at least be given a *chance* to say something about the problem. Probably not even fixing it, but probably give hints or provide direction. Whatever the answer is: Respect it. It's not your software.

If there is no answer, there is still time to do something. But only then.

[Thorham]

a machine that crashes every five minutes

If your Amiga crashes that often then there's something VERY wrong with it :p

but that still doesn't make this a *good* machine by today's standards

Who cares? They're awesome retro machines for the Retro Computerer

[guest11527]

Who cares? They're awesome retro machines for the Retro Computerer

I didn't say anything different. But one should really understand the difference between a retro machine and a state-of-the-art architecture.