Hyperion announces OS 3.1 update

[kolla]

Thomas: if you had the 3.9 sources and rights, would this update exist?

If that was the case, we would have a maintained 3.9, or maybe even 3.10.

There is a lot of 3.1 in OS3.9 still, (and pre 3.0 too) and I suspect that many of the bits and pieces that are updated in this 3.1.4 are also relevant for 3.9.

[guest11527]

Thomas: if you had the 3.9 sources and rights, would this update exist?

I'm not quite clear what you are asking. This update (3.1.4) exists. You mean an update for 3.9? Of course we would update 3.9 if we had all the rights and sources, but we don't. Some of the components are lost because H&P never checked them in (IPrefs from 3.9) so we had to reimplement parts of it. Other components where never checked in by other parties, so we had to replace them completely (The Os 3.9 Execute by Heinz is just lost), others we don't have the rights to (HDToolBox by Joanne Dow). The situation is complicated.

But, as said, I'm always trying to pick the latest and greatest component I can get hold of, and this also implies that *some* of the components are later than those in 3.9. This is either because I had newer sources (diskfont, asl) or because I made newer components (layers, shell) or because I reimplemented them for the purpose of just this project (queue-handler, clipboard.device, port-handler).

So this update is really "somewhere between" 3.1 and 3.9, and beyond 3.9.

I think not, but would like an honest answer, because it otherwise does seem a pointless back to the future update.

See, that's the best we can do with the components we have. That's all I can say. I'm not removing anything from 3.9 because I'm a mean guy.

[Niding]

Im looking forward to the update, and I intend to use it with Vampire. I also are following Olafs developments with AROS Vision, but unlike some, I dont feel that they are mutually exlusive. I like to think the variety compliments eachother.

I do feel a bit ...sorry (?) for you Thomas, having to deal with the legal minefield, but again, looking forward to the end result.

[LoadWB]

I will have a system ready to try this out when it's ready.  I have both bare 68000 and 68020+ I can give a whirl.  Of course, if I ever bothered with UAE or AmigaForever I'd have much more versatile configurations available

[guest11527]

T
I'm guessing that your improved 3.14 will be compatible with all Amigas, even the most basic configurations?

Yes. This is all strictly 68K only. You will probably need more RAM as we will likely not be able to sweeze the new workbench into ROM. It just doesn't fit there. The workbench - as I see it - is shorter than the 3.9 edition because I could play a couple of compiler tricks there (and in icon as well) but it is not short enough to fit into ROM.

[olsen]

@gizmo350

That's a great idea! Hyperion should include an install option to update current OS3.5 or OS3.9 systems in addition to fresh installs. That way it could double as a Vampire V4 install disc or a Classic machine library update disk :cool:

Yes, this would be very worth having. Figuring out what to copy, and what to omit, whether there are potential conflicts between the different versions (e.g. SetPatch, IPrefs, etc.), will be a really tough nut to crack, though...

I can see this happening, eventually, but I expect that the initial release of the 3.1.4 update will focus on getting the update ready to ship.

[olsen]

Thomas and Olaf, I'm very excited about what you are doing.  I very much look forward to trying it out.   Thank you!  

I'm guessing that your improved 3.14 will be compatible with all Amigas, even the most basic configurations?  Asked differently, your improvements and bug-fixes will not crash an otherwise stock A500 that is equipped with an updated rom?

That is very much the plan. The baseline build of the operating system and its components is still all-68000 code, with only the ROMs for the Amiga 1200 and Amiga 4000(T) requiring an 68020 (the A3000 expects an FPU to be present, but that's a different story).

While building operating system components specifically for the 68020 and beyond would result in significant ROM space savings, as well as disk space savings, it would open a big can of worms.

[olsen]

I did not say it IS secure, I'm saying that should be one if possible direction of development.

The security aspects have been discussed before, but the Amiga operating system architecture is not designed with security in mind. If anything, the focus was on making the most of very little available RAM and squeeze as much performance out of the CPU as possible.

Security measures are built from layers of isolation which limit what a program or operating system function may accomplish. These are completely absent in the Amiga operating system. Compare this to the then (1985) contemporary Macintosh or Atari TOS designs which use "software interrupts" to call operating system functions. There is at least a context change implied, which could be leveraged to enforce permissions to perform an action. Nothing comparable exists on the Amiga, except perhaps the Envoy server which has a single point of entry (authentication) to either grant or deny access to a resource.

Retrofitting operating system designs not intended to offer security measures typically produce compromises which end in tears.

You could redesign the system, of course, but then you'll invariably have to "triage" the software that is expected to still work with it. A more secure Amiga operating system is guaranteed not to work with the vast majority of currently available software.

[Oldsmobile_Mike]

My A600 for example doesn't have an O20 or greater in it. This means 3.5/3.9+ are off limits. This is true for a lot of systems that 3.1ish works on. I hope the 3.1.4 or 3.14 update works with 68000 3.1 ROM'ed Amigas as well.

People need to let the 68000 go, lol. :lol:

[kreciu]

A more secure Amiga operating system is guaranteed not to work with the vast majority of currently available software.

I thinks AmigaOS4.1 don't work with most available software and I don't think it is more secure then older version?

[guest11527]

The A3000 expects an FPU to be present, but that's a different story.

That's just the matter of compile time options. It currently selects the FPU-only version of mathieeesingbas for the A3000, but that is a poor choice if people upgrade the system with an "Economy Class" CPU. Well, frankly, mathieeesingbas was always a poor choice to begin with, but now that workbench is on disk, there should be enough ROM space available to fit the full ieeesingbas in. Or, even, remove it from ROM completely as it is really not worth having...

Which is a shame given the amount of time I spend to compile mathieeesingtrans. Oh well...

[kreciu]

Look, if you don't want it, don't buy it.

Yes, it is VERY true.

[kreciu]

The security aspects have been discussed before, but the Amiga operating system architecture is not designed with security in mind. If anything, the focus was on making the most of very little available RAM and squeeze as much performance out of the CPU as possible.

Security measures are built from layers of isolation which limit what a program or operating system function may accomplish. These are completely absent in the Amiga operating system. Compare this to the then (1985) contemporary Macintosh or Atari TOS designs which use "software interrupts" to call operating system functions. There is at least a context change implied, which could be leveraged to enforce permissions to perform an action. Nothing comparable exists on the Amiga, except perhaps the Envoy server which has a single point of entry (authentication) to either grant or deny access to a resource.

Retrofitting operating system designs not intended to offer security measures typically produce compromises which end in tears.

You could redesign the system, of course, but then you'll invariably have to "triage" the software that is expected to still work with it. A more secure Amiga operating system is guaranteed not to work with the vast majority of currently available software.

So, you tell me that AmigaOS4.x will never be secure?

[gary2000]

I would be happy to purchase update (3.1.4) for my A2000/030 (currently running classicWB advsp) and A500s (3.1).  

That is, if it was a fully functioning OS as classicWB tries to be, with all the patches and bells and whistles.  I would rather pay then have to install this stuff manually.  Too much to hope for?

Running OS 3.9 on the 2000 used a lot of resources without anything running and was a good starting point, but required a lot of additions, patches, etc.  to get it up to snuff.

3.1 is just a blank slate.

Well, I would probably still purchase it even if it was just a modest update.  These were just a few thoughts.

[kolla]

People need to let the 68000 go, lol. :lol:

Nah, the Minimig is probably the most rock solid Amiga system I have

[kolla]

now that workbench is on disk

Which workbench.library will 3.1.4 come with?