3 ms·

The Amiga was its own thing; it wasn't Linux + something. That gave it its own culture, and everyone just naturally went for that as well. Replicating that toda

• vidarh 5y ago
  > Also, it would remove the distinction between processes and threads entirely: there are only threads, running in one or more memory spaces. I mean, the existing primitives get the job done I suppose, but it just looks so... inside out, I guess. This distinction has been reduced to next to nothing in Linux. clone() is like fork() but allows sselective sharing that allows both more sharing (sharing the same memory space) and less sharing than fork (e.g. it can put the new process in new cgroup namespaces etc. > (which I don't think anybody really cares about), I don't care about the look, but I do care about the spatial layout of it. It really annoyed me when Gnome dropped support for that for Nautilus. My memory is very strongly spatial, and having windows reopen in the same spaces etc. was an awesome memory aid. Other than that I agree - I'd mostly use DiskMaster II for actual file management, and most "holdouts" today seems to favour Directory Opus Magellan (which can also be used as a Workbench replacement) > The pervasive scripting would be a good start: I'd love to be able to script as much as on the Amiga in Windows or Linux. Obviously it would require some thought on security, we don't need scripts running rampant. So I actually took a look at Dbus again thanks to this discussion, and it obviously have had to deal with the security aspect, and it seems to be solved largely by a separation into multiple buses. The problem as I see it with Dbus from what I've looked at is that it wants to be a "proper" RPC system. That is, it's complex because you have to connect to a given bus, then to a given service, then find a specific object, then get the interface from the object. E.g. here's a Ruby example using ruby-dbus [1]: require "dbus" sysbus = DBus.system_bus upower_service = sysbus["org.freedesktop.UPower"] upower_object = upower_service["/org/freedesktop/UPower"] upower_object.introspect upower_interface = upower_object["org.freedesktop.UPower"] on_battery = upower_interface["OnBattery"] if on_battery puts "The computer IS on battery power." else puts "The computer IS NOT on battery power." end Whereas of course adopting something closer to ARexx way of doing things we'd expect something more like: address "org.freedesktop.UPower" if on_battery ... This omits a lot of what DBus does, of course. DBus is clearly much more capable, in that applications can expose complex hierarchies of multiple buses which have multiple services which have multiple objects which have multiple interfaces, but it makes the "default case" far more complicated for users. I think it's interesting to note that DBus is this complicated in large part because it imposes structure on the services that could have been built from a far simpler abstraction (allow messages directly to a service; provide the object/interface abstraction by using a reserved command/message name to query the service for capabilities; simple services would just process messages to the service endpoint - more complicated ones would work as before) Reading the specification, it's not as bad as it looks. It has a lot of complexity that can be hidden, and e.g. the "interface" specification is optional (you "just" risk that the target object implements multiple interfaces with the same method names, so it's up to those writing services to tell you), but it seems many clients refuse to let you omit it easily (ruby-dbus allows you to choose the default interface to specify, but it doesn't look like it lets you omit it entirely). It'd be interesting to try to tweak/wrap ruby-dbus to see if it's possible to hide enough of the complexity in a reasonable way. E.g. "guessing" the default object name and omitting interfaces unless specified would get you pretty close to decent defaults. Running an introspection tool, there certainly are quite a few interfaces registered with dbus (and one of the things with dbus that ARexx doesn't have is the ability to register endpoints for programs that are not currently running that allows "activating" them), but if people see examples like the first one above you have to be really dedicated to want to keep diving into it. > I wouldn't couple it to a specific language, and in fact I don't think that was the case with ARexx anyway: the interface was open enough that other scripting languages could have been supported on the existing ARexx infrastructure. The port/command execution is open enough, certainly. A good example would be FrexxEd (one of the co-authors was/is Daniel Stenberg of CURL fame), which used "FPL" (a C-like language) as its main scripting language, but all the editor specific commands are shared between FPL and the ARexx port. The language interpretation for ARexx is provided by ARexx - the hosts only need to provide the ability to execute commands. In terms of providing the capability, I think you really only need the ability to simply send commands to a given port, and then shell scripts or whatever language people prefer can do the rest. An "rx" variant that either lets you specify the port to address or defaults to address whatever port is specified in an environment variable would make it almost seamless. > I'm not going to do the work though ;-) Got enough going on ATM... This is the problem. So many of us miss parts of what the Amiga does, but they're conveniences that are easy to miss and want but hard to justify putting in the effort on. Especially as many of them are just sufficiently dated that they'd need some rethinking, and suddenly it's a lot of effort. [1] https://github.com/mvidner/ruby-dbus https://github.com/mvidner/ruby-dbus