Welcome, Guest. Please login or register.

Author Topic: Os 3.2 development preview  (Read 135042 times)

Description:

0 Members and 4 Guests are viewing this topic.

guest11527

  • Guest
Re: Os 3.2 development preview
« Reply #434 from previous page: December 08, 2019, 04:28:28 PM »
I checked my source code, and your right there is no WFLG_ICONIFY in AmigaOS4.x.
But if it’s done on AmigaOS3.x it be nice to see the same changes on AmigaOS4.x so do not have to work different incompatibilities.

The sources are on the AmigaOs subversion. Whoever from the Os 4 team wants to pick them up from there, or ask questions about its implementation, is certainly welcome to do so.
 

guest11527

  • Guest
Re: Os 3.2 development preview
« Reply #435 on: December 08, 2019, 04:38:38 PM »
So this minor improvement over old design, as it only gives you 1 more bit, and now you allowed to use full 32 bits instead of only 31 bits as used before, the problem however is that does not give the possibility to make ISO of 32GB hard drive. So my complaint here is that they did not add support for large files (64bit large files), like AmigaOS4.x has. That’s also another incompatible way to solve it, and it does solve it fully..
It's worse than that. There is no guarantee that files larger than 2GB will work as it all depends on how careful the file systems are implemented. For example, Read() returns a LONG (which is a signed number), so you cannot read more than 2GB in one go (where to? There is no Amiga with more than 2GB memory). Seek() takes a LONG offset, and returns a LONG offset, so you can seek at most +/- 2GB in one go. If you need to seek for larger distances, you need to seek in multiple runs, and whether that works is again a matter of the file system.

The FFS surely does not support anything longer than 4GB. The CDFS may, I hope, but I haven't tested. If a file is longer than 4GB, it shows the maximum size, but you can seek within it, and read it sequentially, provided you find a DVD reader you can fit into the Amiga. Crossdos cannot handle anything larger than 4GB.

The trouble is really that the structures that are used to commucate with the file system, e.g. struct FileInfoBlock, are not prepared to handle larger sizes. The file size is there a LONG (though, as it does not make sense to have a negative size, it is used as ULONG....) This is a left-over from the BCPL legacy that has only one data type, and that is the LONG (BPTRs are just cell-offsets in a memory array represented as sequence of 32-bit signed integers). Actually, BCPL is a type-less language.

Thus, if you'd want to have larger files, you would need to enhance the interface of the dos.library, and the file systems underneath, and the programs using such structures.

Frankly, I have only little hope that an extension is a viable approach at this time. We're not getting fresh programs or new filing systems, leave alone the computing power or main memory, so it would be mostly an academic exercise to make such extensions.

I consider this as a SEP at this moment (a somebody else's problem). Not important enough to worry about.
 
The following users thanked this post: klx300r, LiveForIt

Offline LiveForIt

Re: Os 3.2 development preview
« Reply #436 on: December 08, 2019, 04:50:13 PM »
OS4 is a pile of steaming shit

It pretty good, but I do have few complaints. But all products that being developed has bugs and issues, but most issues I see posted are not issues at all, they things that are posted by MorphOS and AROS supporters who are not using AmigaOS4.x. The biggest complaint I see from users, is the fact that AmigaOS4.x can detect bugs; GRIM Repair is an asset not a problem. Replacing guru mediation with something can pin point where the bug is, is the best thing that has happened to AmigaOS, sadly not everyone see that.
 

Offline Johan Samuelsson

  • Full Member
  • ***
  • Join Date: Sep 2002
  • Posts: 243
    • Show only replies by Johan Samuelsson
    • http://www.ponnyslakteriet.com/uprough
Re: Os 3.2 development preview
« Reply #437 on: December 08, 2019, 04:56:27 PM »
Hi! Would it be possible to implement an option to hide .hidden unix files?
It’s very annoying these days working with files on a usb stick that came from a mac etc. So much clutter.
 
.\\\\ Spot / Up Rough Soundsystem //.
check it ---> http://www.uprough.net
 

Offline Tygre

Re: Os 3.2 development preview
« Reply #438 on: December 08, 2019, 07:50:35 PM »
It was supposed to be a bugfix and update of 3.1, instead it pulls in components from 3.5/3.9 as well as OS4 and introduces tons of new bugs and issues.
...
In fact, you really bewilder me: At the one hand, you ask for experimental components like 4-way adapter support, which we cannot test to the amount necessary to make it a product as robust as I would like to have it, at the other hand, you deny any development of components you don't appreciate and that are not even central to the Os experience. For example, the GUI will still be gadtools-based, thus rather lightweight, so why do you speak so hateful about reaction as it does not impact you at all. It may, however, improve the experience of other users that wait to have it.
...

It's what bullies like Kolla do: angry if you do, angry if you don't.

Thomas, thank you for your great explanations and amazing work! :)
 
The following users thanked this post: klx300r

Offline CBH

Re: Os 3.2 development preview
« Reply #439 on: December 08, 2019, 09:29:32 PM »
OS4 is a pile of steaming shit

It pretty good, but I do have few complaints. But all products that being developed has bugs and issues, but most issues I see posted are not issues at all, they things that are posted by MorphOS and AROS supporters who are not using AmigaOS4.x. The biggest complaint I see from users, is the fact that AmigaOS4.x can detect bugs; GRIM Repair is an asset not a problem. Replacing guru mediation with something can pin point where the bug is, is the best thing that has happened to AmigaOS, sadly not everyone see that.

My perception of it is from 4.1FE on Classic. It's an abysmal experience, I have no idea why they insist on supporting hardware that is much too slow to use it properly. Actually, supporting is a bit much because the damn thing wouldn't boot unless I removed it's broken fastata driver. Running it was nothing but an exciting way to make my 1200T run out of ram.
 

Offline my_pc_is_amiga

Re: Os 3.2 development preview
« Reply #440 on: December 09, 2019, 02:00:49 AM »
. In 3.2, the System-Startup was designed to limit the impact of ROM bugs as many RAM components can be upgraded from disk without requiring the installation of a new ROM, and without requiring a reboot.

Looking forward to 3.2 and looking forward to the "no reboot"! 3.5, 3.9, 4.x all require a reboot and so this will be nice to have an easier up-gradable "ROM" built into the system.  Thanks Thomas.
 

guest11527

  • Guest
Re: Os 3.2 development preview
« Reply #441 on: December 09, 2019, 05:22:04 AM »
Looking forward to 3.2 and looking forward to the "no reboot"! 3.5, 3.9, 4.x all require a reboot and so this will be nice to have an easier up-gradable "ROM" built into the system.  Thanks Thomas.
Just to get this right: Installation of 3.2 on top of any other system with software only *will* require a reboot. However, once you have a 3.2 ROM chip, many - but not all - components can be upgraded without a new ROM and without a reboot.
 

guest11527

  • Guest
Re: Os 3.2 development preview
« Reply #442 on: December 09, 2019, 05:31:45 AM »
More components: Commands in C.

As said before, the C: commands now respect the error output, so you can redirect errors to a separate file with "*>". By default, ">" redirects both, error output and regular output, to avoid compatibility problems, but you can separate the error messages out.

The LIST command: Well, lists the directory contents. A couple of fixes and changes:

- If the list command found a directory name that looked like a wildcard, it took this name as wild card to match for listing its contents. This is really a bizarre bug that was caused due to the way how list handles its recursion.
- Speaking of recursion, "list" allocated its stack for directory recursion for unknown reasons from MEMF_CHIP, not MEMF_ANY.
- LFORMAT did not prepare its output in a way that is compatible to the shell syntax. That is, if directory or file names were found that contained asterisks or quotes, those asterisks or quotes are now escaped if lformat prints the arguments within quotes.
- It is unfortunately a bit more tricky with file names listed that contain wild cards, i.e. file names that contain # or ? because *some* AmigaDos commands *do* parse wildcards, and some *do not*, so list cannot really guess for which sort of command the output shall be formatted. I'm still looking for a solution for this. There will probably be a command line switch to escape wildcards optionally.
- The LFORMAT keyword accepted %s for the file name, but not %S. Otherwise, all format options are case insensitive, but %s was not.

Then, we have one new command line argument for list, namely "FLAT". If this is given, then LFORMAT does not enter a directory if the given argument is a directory.
 
The following users thanked this post: rxxic

Offline kolla

Re: Os 3.2 development preview
« Reply #443 on: December 09, 2019, 06:34:18 AM »
- If the list command found a directory name that looked like a wildcard, it took this name as wild card to match for listing its contents. This is really a bizarre bug that was caused due to the way how list handles its recursion.

Quote
- LFORMAT did not prepare its output in a way that is compatible to the shell syntax. That is, if directory or file names were found that contained asterisks or quotes, those asterisks or quotes are now escaped if lformat prints the arguments within quotes.

Quote
Then, we have one new command line argument for list, namely "FLAT". If this is given, then LFORMAT does not enter a directory if the given argument is a directory.

Sheesh, who is that person who reports and requests such obscure features.
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
A600/A6095
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM440 and Mac minis with MorphOS
 
The following users thanked this post: rxxic

Offline kolla

Re: Os 3.2 development preview
« Reply #444 on: December 09, 2019, 06:41:58 AM »
My perception of it is from 4.1FE on Classic. It's an abysmal experience, I have no idea why they insist on supporting hardware that is much too slow to use it properly. Actually, supporting is a bit much because the damn thing wouldn't boot unless I removed it's broken fastata driver. Running it was nothing but an exciting way to make my 1200T run out of ram.
Emulators are nice. I have OS4.1FE on my A3000/CSPPC/CVPPC (and what... 640MB RAM?), but due to the Roadshow component having ancient bugs that were fixed on Roadshow/68k years and years ago, it cannot reliably go online. It really sucks that Olsen cannot update Roadshow for OS4. This is the type of scenario I expect to arrive on 68k OS3 as well - authors having updates, but Hyperion having zero interest in organizing "boingbags" and publishing them.
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
A600/A6095
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM440 and Mac minis with MorphOS
 

Offline my_pc_is_amiga

Re: Os 3.2 development preview
« Reply #445 on: December 09, 2019, 07:07:49 AM »
One thing I've noticed with list is a different behavior when listing a directory versus listing the filename in the directory, when a new file is currently getting copied by workbench into that directory:

1) Listing the directory containing the new file, I don't get any DOS errors and everything is fine.
2) Listing the file in the directory by itself, I get a "No information for <filename>: object is in use"

 

Offline kolla

Re: Os 3.2 development preview
« Reply #446 on: December 09, 2019, 07:54:30 AM »
I don't really see this as a bad thing, I see this as a necessity.
And why is that? And what is wrong with the direction?

It is clearly a legal necessity, since code has been trickling down from OS4. Right?

(Unless a certain entity buys out entire Hyperion - who knows, that would solve a lot)

You already know what I find wrong with the current direction, so no need to answer that again. Especially since all you do with any answer I give is to call me a "hater" and question my mental health. 

Quote
what is wrong with a printer.device that prints correctly, an animation datatype that multitasks correctly and a CD file system that supports UDF? All these components came somehow into 3.1.4 through integration of 4.x components, just ,reviewed and bug-fixed to the amount necessary
Nothing wrong with that per se, but by nilly-willy pulling in OS4 components, the legal situation of the code gets even more entangled.
Quote
The 3.x series is a very conservative approach to the development, quite unlike 3.9 was and much less than 4.x attempted to be.
Unlike 3.9? Really. I don't find 3.5 and 3.9 to be very "radical" compared to 3.1, nothing fundamental was changed. With 3.2 there will be quite a few fundamental changes though, like system-startup, loading kickstart components from disk and setting up various devices pre-boot.

Quote
In fact, you really bewilder me: At the one hand, you ask for experimental components like 4-way adapter support, which we cannot test to the amount necessary to make it a product as robust as I would like to have it

And this bewilders me - IDEFix97 is named this for a reason - it came about in 1997 - it is more than 20 years ago. And support in other operating systems came along within a few years. And as it turns out, OS3.9 and OS4 also has had support all along... so, is it really experimental? Or do you prefer to name anything you have not had any hands-on experience with "experimental"?

How can it be, that the AmigaOS team is lacking so much in terms of hardware?

And refrain from using emulators as test cases?? This is _exactly_ what makes WinUAE so extremely useful, it has pretty much accurate emulation of _tons_ of Amiga hardware - and then the OS developers refuse to touch it? I find this ridiculous!

Quote
, at the other hand, you deny any development of components you don't appreciate and that are not even central to the Os experience. For example, the GUI will still be gadtools-based, thus rather lightweight, so why do you speak so hateful about reaction as it does not impact you at all. It may, however, improve the experience of other users that wait to have it.
"hateful"? You should save your superlatives to the times when they are truly needed.

Regarding the Reaction classes, I have two issues
* they are not the most efficient, nor the visually prettiest, often looking out of place
* more importantly - they are now considered Hyperion property and part of the "arsenal" against a better future.

Quote
You seem to have a very one-sided view on the development. "Only what I want, everything else is shit".
No, "anyone free to have whatever anyone wish" is what I would prefer.

Quote
To make matters worse, many of these bugs are in the kickstart chips that still are being sold.
Oh, worse, Cloanto sells 3.1 ROMs or 3.x ROMs ("developped without a license" (tm)) with even more bugs in it. Why isn't that bad? I believe it is actually worse, selling the old shit again, with the old bugs in it.

Old bugs that are _well known_ - which makes a huge difference.

Quote
We all understand, and you should appreciate this as well, that with a small developer group and - more important  - a small group of beta-testers, our means are limited, yet we try the very best to fix what we broke.
Your resources are limited by choice - you could have tons more beta-testers (and more hardware available) if you chose a different approach.

And again I recommend to make a release candidate or two available in the wild for public testing at least for a month or two before burning and selling kickstart chips - it would _REALLY_ help a lot.

Quote
In 3.2, the System-Startup was designed to limit the impact of ROM bugs as many RAM components can be upgraded from disk without requiring the installation of a new ROM, and without requiring a reboot.
I do not mind rebooting, I don't know why so many care so much, makes me wonder if their systems are so unstable that boot time is so important. For me it is more important that systems are easy to debug, that they don't do unexpected things (like picking up some random ROM component from a filesystem that owner is using as download area)

Quote
3.1.4.1 fixes many, but far from all these bugs, and 3.1.4.1 will be the last "free update",
Apparently, you know more about the 3.1.4 updates than I do.
Well, if you know different, then please feel free to elaborate.
I have seen people asking if there will be a 3.1.4.5 or so, but no answer has been given as far as I have seen, so...

Quote
as 3.2 will be another product, and one with a vast amount of changes that go well beyond what OS 3.9 did, more and more becoming "OS 4 for 68k".
I'm not quite sure what you mean. Don't you think it is necessary to advance the 3.x line a bit?

Necessary? Not at all - cool, but not necessary. But that was not what I was writing, was it - I was writing that what is presented here, with this 3.2 line, is much more of a change over 3.1 than what OS3.5 and 3.9 ever was.

Quote
It is a less radical update than 3.9, the GUI stays pretty much the same.

The "GUI" was not changed in 3.9 either, less so, as it was still good old 3.1 Intuition.

Now we have Intuition.library v45 - based on original sources and rewritten from scratch, as the OS4 advert says... :)

OS3.5/3.9 with Reaction classes was not a dramatical change over OS3.1 with ClassAction, with exception of Workbench and ASL Prefs, one could still use old 3.1 Prefs programs if that was needed.

The only really radical changes about 3.5/3.9 was Workbench with AREXX support - which 3.1.4 and 3.2 also has, and explicit need for 020 on certain components - most annoyingly the resource.library.

Quote
Though what is wrong with a GUI that is no longer based on topaz.8, without the complexity of reaction?

Nothing - I welcome this. Too bad it will be entangled with Hyperion legalese.

Quote
What is bad about iconification gadgets in system tools?
That remains to be seen - depends how it behaves in certain corner cases.

Quote
What is wrong with windows you can drag out of the screen?
Well, I prefer this turned off, as it does not fit with my "workflow" where I often push windows to the screen border, or resize against a screen border. I would very much prefer to set qualifier that I can hold if I wish to drag windows off-screen. Also, without being able to have windows larger than screen, I really see very little use for it at all.

Quote
What is wrong with TAB-expansion in the Shell?
Nothing, it should have been there twenty-odd years ago.

Quote
None of these changes are radical, just slight tweaks, without impacting the overall "feel" of the Amiga.
The "feel" of Amiga is quite different depending on who you ask, the "feel" is not really important. What is important is how these changes are coming about, the timing and the context. It is _extremely_ "Amiga", and I don't mean that in a good way.

Quote
Which brings me to...
Quote
OS 4.x is a terrible mess
Exactly.
I do not know, and I do not care too much. The reason why I don't care about 4.x is that I never understood what a re-development of a retro-os on another outdated CPU platform is supposed to become.

It makes just as much sense as development of a retro-os on an original outdated CPU - sensewise, OS3 and OS4 are in the same boat.

Quote
I do not understand AROS for the same reason. If I would develop an Os from scratch, I would certainly not re-implement all the design errors of AmigaOs from scratch - so what's the point? There are better open portable operating systems than Amiga.

And nothing prevents you. The point of AROS was to scratch an itch, not to offer a product, nor to please anyone else but the developers themselves. Not like your work has much more point.

Quote
The only point in the 3.x development is to get rid of the "rough edges" of 3.1 and to integrate functionality into the Os that was otherwise provided by patches and hacks, with all the instabilities these provide. This is not about "creating a new operating system for 68K", because if I would want that, I would certainly not start from something as absurd as AmigaOs.

Say it again, louder, so that people can hear you.

What is the roadmap, exactly what patches and hacks do you want to get rid of? At what point do you consider OS3 finished?
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
A600/A6095
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM440 and Mac minis with MorphOS
 

Offline kolla

Re: Os 3.2 development preview
« Reply #447 on: December 09, 2019, 07:59:15 AM »
One thing I've noticed with list is a different behavior when listing a directory versus listing the filename in the directory, when a new file is currently getting copied by workbench into that directory:

1) Listing the directory containing the new file, I don't get any DOS errors and everything is fine.
2) Listing the file in the directory by itself, I get a "No information for <filename>: object is in use"

You can also go around this by listing the <filename, replacing any char of its name with a ? wildcard>

What happens is that List will try to "lock" whatever object is specified as argument, and if that file is in use, it will fail. The "absurdity" is perhaps that List will not attempt to lock anything if the argument contains a wildcard... Thomas has already explained earlier why things are as they are, and while it makes total sense, it is utterly absurd UX wise.
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
A600/A6095
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM440 and Mac minis with MorphOS
 

Offline kolla

Re: Os 3.2 development preview
« Reply #448 on: December 09, 2019, 08:17:38 AM »
It's what bullies like Kolla do: angry if you do, angry if you don't.
First of all, I am not angry, not at all.

And secondly, "bullies"? I suggest you read yourself up on what "bullying" actually means and perhaps look up "sycophancy" while you are at it.

I am not the one questioning other people's mental health or resorting to name calling here.

Btw - when you do "Resident >NIL: C:Assign PURE" "to speed things up a little", and then go on to use "C:Assign" every time afterwards - how much to you think you speed things up by keeping the Assign command resident?
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
A600/A6095
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM440 and Mac minis with MorphOS
 

guest11527

  • Guest
Re: Os 3.2 development preview
« Reply #449 on: December 09, 2019, 04:18:26 PM »
It is clearly a legal necessity, since code has been trickling down from OS4. Right?
Only under the premise that Cloanto & Hyperion don't find an agreement, or Cloanto wins a case.


Nothing wrong with that per se, but by nilly-willy pulling in OS4 components, the legal situation of the code gets even more entangled.
It depends. It is already complicated with the 3.1 code alone, and it unclear to me in how far this could be released to the public either. Besides, just using 3.1 only for 3.1.4 development wouldn't have made it much simpler. It is Hyperion, after all.

Unlike 3.9? Really. I don't find 3.5 and 3.9 to be very "radical" compared to 3.1, nothing fundamental was changed. With 3.2 there will be quite a few fundamental changes though, like system-startup, loading kickstart components from disk and setting up various devices pre-boot.
The GUI changed with 3.9 due to reaction, and it was the first Os that was 68020 only. 3.2 goes into a different direction.

And this bewilders me - IDEFix97 is named this for a reason - it came about in 1997 - it is more than 20 years ago. And support in other operating systems came along within a few years. And as it turns out, OS3.9 and OS4 also has had support all along... so, is it really experimental?
You surprise me. 3.1.4 has the same sort of "support" for it, as the scsi.device is based on the 3.9 version. Believe there must be reasons in 3.9 *NOT* to enable it by default. As the code I posted shows, it was probably due to an agreement between H&P and Oliver Kastl. The technical reason is likely that, without connecting a second drive, the gates of such adapters may be floating, and then may read whatever was on the bus, so the detection is unreliable and may return false positives.

One way or another, I do not know, and I haven't tested, and what has not been tested does not work.


And refrain from using emulators as test cases?? This is _exactly_ what makes WinUAE so extremely useful, it has pretty much accurate emulation of _tons_ of Amiga hardware - and then the OS developers refuse to touch it? I find this ridiculous!
In this case? Not at all. WinUAE is certainly fine as far as high-level emulation is concerned, but otherwise, it depends very much on models of the hardware that may or may not reflect reality. As for example for the four-way adapters, I'm quite sure it emulates them fine in so far as it makes the detection code happy, but that's not quite what I need. I don't need to test the code in the easy cases. I need to test it in real life, with the effects you get then - such as reading all sorts of nonsense if there is no drive connected.

Just to give you an idea: We couldn't test CDFS audio support either because WinUAE does not emulate it properly, but we had beta testers that could perform the testing. And CDXL support is still missing from it because we cannot test properly.

Yes, it means sometimes that features will go due to lack of hardware. If I get hands on the hardware, I can add support, but only then. As soon as it goes down to the real hardware level, emulation is a fairly bad advice.

Regarding the Reaction classes, I have two issues
* they are not the most efficient, nor the visually prettiest, often looking out of place
It is not efficient because boopsis are not efficient. They use a smalltalk-like dispatcher mechanism where every item on the hierarchy compares a method ID against the methods it supports, so one big lookup per level. The boopsi hierarchy can be pretty deep, so a lot of such dispatcher mechanisms are nested to each other. This makes it inefficient.

Yes, we know, and that's why the GUI is gadtools at this moment. So, it's a complexity that does not matter for you, or for any low-end machine, because it is not used. However, why is it so bad that reaction is delivered, as an option?

* more importantly - they are now considered Hyperion property and part of the "arsenal" against a better future.
Again, why all this hate against Hyperion? The same could be said about Cloanto. Both are commercial enterprises, and want to earn money, in one way or another.


No, "anyone free to have whatever anyone wish" is what I would prefer.
Ah, so once again: What is so bad about shipping Reaction? Don't use it, you're fine. You have a political agenda, and its against this agenda, but I'm talking about the technical aspects.


Old bugs that are _well known_ - which makes a huge difference.
Oh, really? So what's so great about knowing that graphics may trash my memory, and that trackdisk may trash my memory, and there is nothing I can do against it? This does not make me feel very comfortable.

Quite the reverse: With 3.x, such bugs will be addressed, and whatever bugs I get aware of. So what's better? An old rotten os, or one that is receiving updates?


And again I recommend to make a release candidate or two available in the wild for public testing at least for a month or two before burning and selling kickstart chips - it would _REALLY_ help a lot.
Yeah, right... so how would that work as commercial product? Not at all... So once again: Whoever wants to help testing is welcome, but no, it makes no sense to release ROMs to the public because then there is not much of a product left that can be sold.

I do not mind rebooting, I don't know why so many care so much, makes me wonder if their systems are so unstable that boot time is so important.
But you are not the only user. You are one of many users, and there were many voices that rebooting is troublesome. Not for me either, but that is not quite the point.


For me it is more important that systems are easy to debug, that they don't do unexpected things (like picking up some random ROM component from a filesystem that owner is using as download area)
There is nothing "random" at all. What is better? Not to upgrade components if you boot from another location, say a floppy? Or take the updates from another partition? You can easily "prevent randomness" by placing the right components into the boot volue.

Well, if you know different, then please feel free to elaborate.
No, I DO NOT know. That is exactly the point. I do not make promises I cannot hold, so I don't make any. There may or may not be an update, but it all depends on the spare time of the developers.

Necessary? Not at all - cool, but not necessary. But that was not what I was writing, was it - I was writing that what is presented here, with this 3.2 line, is much more of a change over 3.1 than what OS3.5 and 3.9 ever was.
No, not really. It is just a different direction. 3.9 was supposed to target "higher end machines", hoping for more to come. This did not become true. 3.2 is a different direction. Target all the hardware that is out in the wild, but do not add features that add complexity.


The "GUI" was not changed in 3.9 either, less so, as it was still good old 3.1 Intuition.
It changed pretty much for me.

Now we have Intuition.library v45 - based on original sources and rewritten from scratch, as the OS4 advert says... :)
I don't know which intuition Os 4 has, but the one we have has still all the original comments in it and is hence based on the original. It is just a very elaborate port of the greenhill C source of intuition, which could not compile "as is" on SAS/C due to some features the SAS does not offer.

Nothing - I welcome this. Too bad it will be entangled with Hyperion legalese.
And what's the "bad" part about it? This is exactly your problem. Hyperion is a commercial enterprise, Cloanto is another. If it would be under Cloanto, it would be "entangled by Cloanto legalese".

Well, I prefer this turned off, as it does not fit with my "workflow" where I often push windows to the screen border, or resize against a screen border. I would very much prefer to set qualifier that I can hold if I wish to drag windows off-screen. Also, without being able to have windows larger than screen, I really see very little use for it at all.
I may have forgotten that v45 implements a certain "resistance" of windows getting moved out of the screen. So you have to "push a bit harder" to move them.


It makes just as much sense as development of a retro-os on an original outdated CPU - sensewise, OS3 and OS4 are in the same boat.
I don't really see that. Os 4 started as obsolete Os on new hardware, hoping for more to come. At this time, the hardware is old, unpopular, expensive and outdated, without ever reaching the market penetration. 68K hardware is old, but has a history - like an oldtimer - that is worth preserving. The difference is the software collection - there is much more 68K software than PPC software that makes the 68Ks worth using.


And nothing prevents you. The point of AROS was to scratch an itch, not to offer a product, nor to please anyone else but the developers themselves. Not like your work has much more point.
Which itch? "We cannot do an Os either?" Yes, I see that, but what's the point?