Hyperion announces OS 3.1 update

[kolla]

The more relevant question is probably "will there be a printer.device". Quite frankly, which printers do you want to connect to the Amiga, and how? Parallel printers are hard to get, except in a museum, and printers you can get are most likely not supported by any printer driver we have. So what exactly do you plan to do?

Print to network printer or to file, like I always did.

I have a Commodore MIPS 1200P line printer :laughing:

What plans are there regarding prefs apps in general? Just leave them as is? Especially I am curious about workbench prefs, since I get the impression that workbench.library v45 will be used.

[kolla]

Just port DCL already, hehehe :p

Holy crap, I should be careful with what I suggest! :roflmao:

http://aminet.net/package/misc/emu/AmiVms

[kolla]

How bad does it have to be, before you throw your hands in the air and decide to rewrite from scratch?

[kolla]

Considering the large number of Amiga FFS implementations, one would think it's a well understood filesystem.

[kolla]

We have an awful lot of file systems for such a small market.

Yeah, it's ridiculous.

[kolla]

Right, and NetBSD also implements "ADOS" filesystem, Linux has affs, AROS and MorphOS also have their implementations. One would think some sort of cooperation would be beneficial.

[kolla]

I would rather see work progress on AmigaOS4.2 and finished AmigaOS4.1 for looooooooooooooooooooooong  awaited A1222.

Hyperion are all about OS3 now, they don't care much about OS4 anymore

[kolla]

Frankly, I have no insight into the company policy or what the plans with 4.x are.

Neither do anyone else, apparently.
And from that one can conclude that not much is really going on.

[kolla]

In my view, and this is both for OS3 and OS4, it would be better to decouple the various OS elements and let individual developers work on their components individually, without too much coordinated "upper management". Components should be individually replaceable anyways.

[kolla]

I think it's funny that Gunnar complains about old scsi.device, shouldn't he be more concerned with getting the SD card device driver of the Vampire cards working properly? Anyways, nothing stops his team of brilliant engineers from doing their own version of scsi.device for the Vampire cards.

[kolla]

And as far as I know the sagasd device driver is working properly.

Except that it's slow, unreliable and you cannot boot from it. Yes, I suppose that passes as "properly"

Glad you find entertainment value in my Apollo Core slamming.

[kolla]

I suppose everyone knows the "amiga connection" of gdb?

[kolla]

Nope. Where is all this nonsense coming from.

IRC Freenode, #apollo-team - ever been there? It's a crazy place, they make up truths as they go, revision history and badmouth everyone else. It's like a late night dive bar, except they're not even drunk.

[kolla]

and for what purpose are you there?

I am not, I left long ago.

[kolla]

This CDFS has nothing to do with old L:CDFileSystem (aka cdfs.library 40.11), which be gone? Sounds good to me. There have been some queue-handler replacements around too, don't know if you know about them? One is versioned 50.something, so I wonder if maybe it comes from OS4.0 or OS4.1 for classic.

[kolla]

Woop woop!

Great to see gadtools replacement prefs for Workbench and ASL!
(btw - http://aminet.net/package/util/misc/AslToRT - patch all programs to use ASL instead of ReqTools etc)

Also very nice to see old Ed getting some love, it's pretty much the "vi of Amiga" (while c:edit is the "ed of Amiga" ironically, btw your very own SED could very well be included, super useful!). Really looking forward to more reliably be able to run Ed remotely over serial and TCP connections. I presume the old problem of Ed "clearing" protection bits when writing files is taken care of too?

Oh no, guess I will be repeating myself now, but here goes...

Links in filesystems, softlinks - Workbench now indicates them with underline, which is great, but from CLI they just looks like directories. C:List should be able to indicate that they are links and more important, display where they point to.

Ram-handler? I think I have mentioned before that "version RAM:" could/should output version of ram-handler that is used, if at all (there are other means of setting up RAM: after all) to be consistent with FFS (and PFS3 and others).

Formatted output from C:Info - Info DH0: LFORMAT "Size of %d: is: %s, its name is %n and it is %p%% full, using %u bytes, having %f bytes free!"

I better stop... :rolleyes: