[HN Gopher] Personal Computing on an Amiga in 2021
___________________________________________________________________
Personal Computing on an Amiga in 2021
Author : shortformblog
Score : 173 points
Date : 2021-08-05 12:48 UTC (10 hours ago)
(HTM) web link (thedorkweb.substack.com)
(TXT) w3m dump (thedorkweb.substack.com)
| dekhn wrote:
| when i arrived at college in 1991 with a 286 and a broken hard
| drive, my roommate showed me his amiga. where I was stuck in DOS
| textland, he had a fully interactive windowing system with high
| quality graphics, audio, and video capture. I stuck with PCs and
| I don't think I had anything that was nearly as "pretty" even 10
| years later.
| technothrasher wrote:
| I arrived at college in 1990 with my trusty Amiga 2000 in hand.
| I then quickly discovered the school's Unix workstations. I
| have to admit that the Amiga soon after started collecting a
| lot of dust.
| icedchai wrote:
| Are you sure? By the time Windows 95 came out, the Amiga was
| looking pretty long in the tooth.
| dekhn wrote:
| that was 4 years later, which was an aeon in internet time.
| icedchai wrote:
| Well, you said "10 years later" after 1991, which would put
| us at 2001-ish.
| dekhn wrote:
| Duh, yes I see now. I actually went away from DOS/Windows
| between 1993 and 2001+, so I don't know much about what
| their UI was doing at that point. I really meant it took
| Linux desktops a long time to be as useful as Amigas (and
| even then you would have to find a compatible video
| capture board, compatible 3d graphics card, etc).
| bitwize wrote:
| Windows 95 ran like a dog compared to Amiga. PCs couldn't
| match a 25-MHz Amiga for responsiveness until they were in
| the hundreds of MHz in the late nineties.
| mixmastamyk wrote:
| Had to do with whether you had 4mb of RAM or 8 or more. 4
| was unusable.
| kstrauser wrote:
| That's so true. Amiga didn't have an RTOS, but it sure felt
| like it. Windows had so much latency in comparison that I
| couldn't bear to use it for the longest time.
| AlanYx wrote:
| The maneuver that always astounded me at the time was
| right clicking on the menu bar and pulling it down, to
| reveal whatever application was open on the "screen"
| behind it. (The Amiga had separate windows and screen
| abstractions, though I don't recall if I'm using the
| right terms.) No matter how heavily loaded the system
| was, whether it was doing floppy I/O at the time, etc.,
| that pull down motion never became choppy. It did feel a
| lot like an RTOS in that respect.
|
| You could overload the system in other ways though,
| particularly disk I/O in Workbench.
| kstrauser wrote:
| Those are the right terms.
|
| Even more mind blowing is that the visible screens could
| have different resolutions. The display hardware could
| switch modes _per scanline_ while keeping the same output
| frequencies, so you could have a low-res /high-color
| screen on the top half of the monitor with a high-
| res/low-color screen on the bottom half.
| rasz wrote:
| Those are your memories. Win95 on contemporary 1995 Pentium
| system will display explorer window full of icons in split
| second. Workbench when opening a HDD drawer will paint
| icons one at a time taking several seconds, even with
| fastest accelerators possible and fast cf IDE drive.
| squarefoot wrote:
| The reason behind Win95 showing icons much faster than
| any Amiga was due to the relatively slow filesystem used
| by the Amiga, not by its hardware speed, which in fact
| was a bit faster than PCs in a MHz to MHz comparison.
| icedchai wrote:
| Also the Amiga was slow due to the simplistic way
| metadata / icons were handled. There was a separate
| "file.info" file, containing the icon and some other
| metadata, for each actual file on disk.
| bcrl wrote:
| The complete lack of a disk cache integrated with the OS
| on the Amiga hurt as well. Even MS-DOS was shipping with
| disk caching software to make use of high memory on 386
| systems in the early 1990s when AmigaOS had just launched
| 2.04.
| anthk wrote:
| >1995 Pentium system
|
| Then bitwise is right.
| rasz wrote:
| Pentium 75-120 != hundreds of MHz in the late nineties
| anthk wrote:
| 120 is still a hundred.
|
| Windows 98 crawled under a Pentuim@133 and 64MB of RAM
| (we had that in the library), but Windows 95 without that
| crapware called IE4 + ActiveX was fine.
| markus_zhang wrote:
| Dreaming about getting my own Macintosh plus and be productive on
| it, too. Wonder anyone doing the same? It's also a good way to
| learn low level programming on a 68000 chip.
| Palomides wrote:
| I'd recommend a later machine with a 68030 at least, the plus
| is pretty damn slow
|
| maybe a classic II or an SE/30 if you want the original form
| factor
| NoGravitas wrote:
| The SE/30 is actually a pretty amazing machine. It could run
| A/UX, which meant a very decent Unix workstation in the
| classic Mac form factor, with X apps running alongside MacOS
| (classic; System 7-era) apps. One of my hallmates in uni had
| one.
| markus_zhang wrote:
| Thanks! Both look awesome. I'm going to run some emulation to
| see whether I'm comfortable with any and check out the price
| and inventory.
|
| I guess most of the expense is spare parts and shipping?
| floren wrote:
| SE/30's have become harder to find cheaply, because they
| now have the reputation as The Best Compact Mac. I've been
| looking for one here in the San Francisco area for a while
| now and had no luck; I don't want to get one shipped
| because I don't trust it to arrive intact.
| icedchai wrote:
| I managed to get one for about $600 on ebay, a few years
| back. I always wanted one in my youth. It took almost 30
| years to fulfill my dream.
| cronix wrote:
| Several of the key personnel at Commodore went on to create
| products that have touched the ears of most people on this planet
| in a way that Commodore didn't. They went on to found Ensoniq, a
| digital synthesizer company, who was later acquired by Emu
| Systems. Both Ensoniq and Emu synths/samplers were used in a wide
| array of music crossing many genres in the 80's, early 90's.
| Kraftwerk, Depeche Mode, Madonna and a ton more on top-100 radio
| all used them.
|
| > Ensoniq was founded in 1982 by former MOS Technology engineers
| Robert "Bob" Yannes (designer of the MOS Technology SID chip for
| the Commodore 64 home computer), Bruce Crockett, and Al
| Charpentier. Their first product was a software drum machine that
| ran on a home computer.
|
| > In January 1998, ENSONIQ Corp. was acquired by Creative
| Technology Ltd. for $77 million, and merged with E-mu Systems to
| form the E-Mu/Ensoniq division. The fusion with E-mu sealed
| Ensoniq's fate: after releasing an entry-level E-mu MK6/PK6 and
| Ensoniq Halo keyboards - essentially keyboard versions of the
| Proteus 2500 module - in 2002, the E-Mu/Ensoniq division was
| dissolved and support for legacy products was discontinued soon
| afterward.
|
| https://www.keyboardkountry.com/blog/the-amazing-ensoniq/
| zandorg wrote:
| I once emailed Bob Yannes in 1998 about the C64 SID chip. I
| mentioned my soft synth (SoftSID) and the Elektron Sidstation.
| But all he was bothered about was his Ensoniq Fizmo. I'd love
| to get my hands on one of those now.
|
| I told him of the bad review in Future Music. He was a bit
| annoyed but explained what they had missed in the review.
|
| A nice guy.
| krylon wrote:
| I have heard/read enough people sing high praises of AmigaOS that
| I wonder how intimately it is tied to the hardware platform.
|
| In other words, would it make sense to port it to the PC or maybe
| Raspberry Pi? It sounds like it would be fun to play with it, but
| I lack the hardware, and I am not sure I'm willing to sink money
| into it without having an idea of what I am getting into.
| agent327 wrote:
| Yes and no. One problem is that it is kind of hard to describe:
| most features sound like something Linux sort-of has, and
| whenever you try to describe them people tend to disregard them
| as something that has been incorporated into Linux, and thus of
| little interest. What they can't know is just how much more
| convenient those things generally were on the Amiga, how much
| easier it all worked. You really have to experience that to
| know.
|
| The nr. one thing any new OS should learn from the Amiga is its
| motto: "simple things should be easy, complex things should be
| possible." Not "Simple things should be possible, complex
| things should be Dark Souls"!
|
| The next biggest thing would be the use of pervasive inter-
| process scripting. ARexx (I wouldn't choose it today but it
| worked) gave you amazing power to combine applications and
| automate various tasks - a bit like the Linux command line
| does, except it works everywhere. To illustrate, there was an
| ARexx script that combined a mail application with a chess
| playing game to create a chess-playing robot: you could mail it
| a board and it would make the next move, and mail it back. You
| could get two Amigas to play chess against each other, and thus
| avert nuclear annihilation.
|
| "Screens", we would now call them virtual desktops, were way
| better than virtual desktops because applications are aware of
| them, and can be configured to run on a specific screen. Thus
| you don't waste time setting up new virtual desktops, moving
| windows across, etc., it's all automatic.
|
| Assigns let you add globally valid short names for directories
| and devices. An assign can refer to multiple directories, and
| it can be deferred, meaning it is hidden until you refer to it.
| I really miss those on other OSes. Yes, you get links. No, they
| aren't the same. You don't have to create an assign in a
| location (they are always global), you don't need weird syntax
| for creating links, and you can delete them without fearing for
| your data.
|
| The OS is essentially a microkernel that uses message passing
| for asynchronous communication, and that uses dynamically
| loaded drivers for things like devices and file systems. For
| modern usage you would really have to add memory protection (it
| wasn't available on the hardware of the time), and resource
| tracking (it wasn't finished in time for the Amiga launch).
|
| And its culture was just different. The Amiga had so many
| small, simple productivity tools (it also lacked big, complex
| productivity tools, but that's another story). You had simple,
| yet powerful programming languages, music creation tools,
| drawing tools, etc. The tools of today are orders of magnitude
| better, but that power has come at the cost of considerable
| complexity. DPaint 2 can't hold a candle to the Gimp, but at
| least I knew how to draw lines with it. And is there even a
| single music creation tool for modern OSes that isn't either a
| sample arranger or a fullblown score editor?
|
| So it can certainly be done. The question is, will you end up
| with the same joyful platform and the same joyful culture? I
| sort of doubt that: without a captain on that particular ship,
| odds are it will quickly turn into a Linux reskin. The world
| already has enough of those, and even if that weren't to
| happen, part of its magic was in the applications it ran. Just
| ports of existing Linux tools wouldn't have that. So I'd love
| to see a proper AmigaOS port to modern PC hardware, and it
| would totally rock - but I just can't see it gain the same
| momentum it had back in the day.
| classichasclass wrote:
| Basically, you want AROS.
|
| https://en.wikipedia.org/wiki/AROS_Research_Operating_System
| squarefoot wrote:
| You can experience something very close to it with AROS, which
| is free both as in speech/beer, can be used either native stand
| alone or hosted, that is, as process under other operating
| systems without requiring any installation. There's also an ARM
| port which runs native on the Raspberry PI or hosted under
| Android devices.
|
| https://aros.sourceforge.io/
| chriswarbo wrote:
| AmigaOS/Workbench relied pretty heavily on custom parts of the
| Amiga hardware, which is how it performed so well compared to
| other architectures with similar specs.
|
| That can be overcome with enough brute force; although
| emulators like FS-UAE can still struggle to keep realtime with
| some workloads.
|
| There are FPGA reimplementations of Amiga hardware, if you
| wanted something more 'realistic'.
| marcodiego wrote:
| I don't want to bash amiga, actually I really envy the history
| and capabilities of that system. Nevertheless, posts like this
| are almost always seen through a bit of rose tinted glasses.
|
| The part about DataTypes:
|
| "Datatypes describe a file format and tell the OS how to handle
| it. Any datatype-aware program can use any file format as long as
| a relevant datatype is present."
|
| Doesn't looks that different from how codecs are used in modern
| OS's. AFAIK, as soon as ffmpeg or gstreamer learns new formats or
| how to use hardware codecs, so does every program using them
| without the need of even recompiling. Of course, doing that 30
| years ago is another thing.
|
| And:
|
| "RAD: is a fixed-size bootable RAM disk that survives soft
| reboots. Equivalents exist for most modern Operating Systems.
| They're worth trying out. You don't really know how useful they
| are till you lose them."
|
| Maybe I can change my mind if I use them, but I really don't feel
| the need. On my notebook, I simply close the lid and when I open
| it, it is mostly in the same state I left; some system I used are
| stable enough to have months of uptime; using /tmp/ seems enough
| for me. I once had I power failure and recovering whatever was on
| /tmp/required booting from a keychain but it was easy to do and a
| very rare occurrence.
|
| The "RAD:" may be interesting on not specially stable, non high
| uptime, /tmp/-lacking systems but I can't see how they can be
| relevant on modern OS's.
| icedchai wrote:
| It was a different world then. RAD: was pretty amazing in 1989,
| when I added another couple megs of RAM to my Amiga 500. It
| took 30+ seconds to boot off of floppy, and a few seconds to
| boot off RAM disk.
| AlanYx wrote:
| The appeal of RAD: makes more intuitive sense if you think of
| it as a kind of clipboard that you access via filesystem
| operations, rather than clipboard operations (though the Amiga
| had a clipboard too). It did make more sense in an era when
| disks were slow and a huge proportion of Amigas had no hard
| disks. Thinking about it now, it might be interesting if
| someone developed a FUSE interface to the system clipboard on
| modern OSes.
| vidarh wrote:
| The actual Amiga clipboard is actually quite interesting.
| When an application posts a clip to the clipboard device, it
| resides in that applications memory until the clipboard
| device requests it "post" that data somewhere. This makes
| sense on a low memory system - if an application can ensure
| the "clipped" data isn't modified, it can just keep it as is
| without making a copy until it's asked for it.
|
| When "posted" to the clipboard (either in response to
| pasting, or because the application itself wants to, e.g.
| because it's being closed), the clip is written as an IFF
| file to the assign "CLIPS:". Like any other assign, CLIPS:
| can be reassigned anywhere, including RAD: or RAM: or disk.
| Unless I misremember badly, CLIPS: defaults to a directory in
| RAM: possibly indirectly via T:
|
| Since AmigaOS will request volumes that aren't currently in a
| drive, you could even reassign the clipboard to a floppy with
| a given label, and the OS would pop up a requester asking for
| it to be inserted as needed.
| zozbot234 wrote:
| > Since AmigaOS will request volumes that aren't currently
| in a drive
|
| That's a great feature and it should be forward-ported to
| modern OS's.
| vidarh wrote:
| It was, but it's a feature that's much less important
| today with less tight integration of removable media.
| Though it meant e.g. software on multiple volumes could
| just try to access a file on one of the other volumes and
| let the OS deal with prompting for it, even that is a
| quite rare operation today.
|
| You could do it with FUSE relatively easily: Make a FUSE
| filesystem that acts as an overlay, so, say when you
| access /<path to the fuse system>/foo it looks for /<path
| to mount>/foo and if it doesn't find it, pop up a window
| with "Please insert volume 'foo'"
|
| Frankly there are a lot of these things that would be
| quite straightforward to support on Linux that'd be "nice
| to have" but are not quite essential enough to motivate
| someone to do it.
| fogihujy wrote:
| RAD isn't really relevant anymore, but it was very handy on a
| floppy-based system without a hard drive.
|
| Data types, on the other hand, were absolutely amazing. Sure,
| ffmpeg covers some of it, but datatype support was, and remain,
| a killer feature of AmigaOS. Want almost universal support for
| a new format, including support by legacy applications?
| Datatypes. Want to replace a common format's encoder with
| somerhing else? Datatypes.
|
| The other killer feature of AmigaOS applications was the AREXX
| support, which allowed advanced scripting far before it was
| available on other consumer platforms.
| ithkuil wrote:
| Another thing RAD was useful for, namely there is a reason you
| rebooted more often an Amiga that you'd reboot your modern
| laptop: due to lack of memory protection / virtual memory (due
| to the lack of a HW MMU) when an application crashed it brought
| down the whole OS (the (in)famous guru meditation failures).
| After rebooting the content of the RAD was still there (unless
| overwritten by a buggy program)
| vidarh wrote:
| There is a fundamental difference in that you can drop in a new
| datatype without any program like ffmpeg or gstreamer having to
| learn new formats.
|
| More importantly, how many applications actually use these as
| their primary means of accessing file types?
|
| Chrome doesn't learn a new image type if I drop in a file.
| LibreOffice doesn't. Certainly not from the same one. Gimp
| doesn't. There's no reason why all of those should not be able
| to load a new image type without updating the applications
| themselves, just by dropping in a datatype/codec.
|
| The concept isn't anything magical - or new -, but it's still
| largely forgotten and ignored outside of small islands of use.
|
| We _have_ all kinds of little API 's to do this for specific
| types of files, like e.g. ImageMagick's "convert" for images,
| ffmpeg for video etc. as you mention, but what we lack is a
| unified API, the ability to drop plugins in for new file types,
| and for applications to _actually unify around using a specific
| standard_.
|
| Heck, we even have a workaround to avoid needing application
| support: A FUSE filesystem to trigger conversion to suitable
| target filetypes.
|
| This is the same issue with a lot of the things we're missing
| from AmigaOS. They're not hard to do. E.g. "assigns" are
| conceptually largely a OS-provided way of creating PATH's for
| everything you'd like, for example - it can also easily be
| provided via a FUSE filesystem. Dbus "almost" gets us to what
| AREXX provided, but is just not supported as widely or as
| simple for regular users to get started with.
|
| What was special with the Amiga in that respect was that these
| things were embraced fully across the board, and integrated
| into the culture surrounding the Amiga.
| AnIdiotOnTheNet wrote:
| Indeed. Systems like the Amiga show us what we have lost from
| the world of personal computing. Things we could do in the
| 80s and 90s have disappeared and been replaced by hodgepodges
| of barely interacting components. It is, frankly, disgraceful
| and we should be ashamed as an industry that we've regressed
| so far.
| tialaramex wrote:
| > There is a fundamental difference in that you can drop in a
| new datatype without any program like ffmpeg or gstreamer
| having to learn new formats.
|
| It's not an interesting or useful difference. The thing
| Datatypes lets you do is pointlessly spell things
| differently. Once you spot that you ask yourself, "Why am I
| doing this?" and the answer is only that you need to
| interoperate with other people who hadn't settled on one way
| to spell things so the best route forward is consolidation.
|
| Most applications gain _nothing_ from having, say, yet
| another mediocre bitmap graphics format. You just made your
| system more complicated without any improvements whatsoever.
| Clearly we should agree to just stop doing this. And we did.
|
| > Gimp doesn't
|
| Actually Gimp does. Gimp's file format handling is all via
| plug-ins. As with ImageMagick in this context maybe you
| actually needed to rescue crappy 1980s files you found on a
| floppy disk or whatever. But this helps us see what's going
| on - because Gimp's image file format handling is only for
| import and export of necessity Gimp itself is richer than any
| of these formats. Its native XCF format reflects a superset
| of the features you can care about.
|
| But anything Gimp's native images can't do, you can't "add"
| using these plug-ins. The SVG plug-in for example can't
| magically make Gimp understand vector images, it just has to
| render the vector image as pixels because that's all Gimp
| understands.
|
| So in the end any innovation is rendered pointless by this
| abstraction, the only way for an innovative idea to flourish
| is to sidestep a "datatypes"-like abstraction altogether.
|
| > actually unify around using a specific standard.
|
| You've almost understood. Instead of adding a layer of
| abstraction, and then unifying around this unnecessary layer,
| we instead chose to just use a specific standard format. The
| problem you're intent on solving _vanished_.
|
| Didn't you ever wonder why Datatypes seemed so brilliant for
| image files, and kinda sorta OK for music, and then basically
| of no value at all for most other file formats? It's because
| there really were sixty different crappy pixmap formats that
| were completely interchangeable and half a dozen PCM audio
| formats likewise. But that's not what happened in other
| domains, because it's pointless.
| vidarh wrote:
| > Most applications gain nothing from having, say, yet
| another mediocre bitmap graphics format.
|
| Applications gain a tremendous amount of usability for me
| by being able to read or write the formats I actually use.
| Instead we rely on a hodgepodge of scripts and tools to do
| format conversion manually.
|
| Amiga applications released decades ago can load webp files
| for example, whether or not the people who wrote them are
| still releasing updates or are even around. It might not
| matter to you. It matters to me that files keep being
| easily accessible.
|
| Today there are plenty of tools I use regularly that can't
| load or save various formats I regularly use directly.
| _That_ is pointless, when providing a mechanism to reuse
| conversion was a solved problem decades ago.
|
| > Actually Gimp does. Gimp's file format handling is all
| via plug-ins.
|
| But it's not reusing system-wide plugins, which was the
| point.
|
| > You've almost understood. Instead of adding a layer of
| abstraction, and then unifying around this unnecessary
| layer, we instead chose to just use a specific standard
| format. The problem you're intent on solving vanished.
|
| Unfortunately you failed to understand. We _haven 't_
| unified on a standard format. We never will, because we get
| new requirements regularly, and people also create new
| formats for arbitrary and stupid reasons as well. Format
| conversion will _always_ be necessary to handle formats
| produced by different tools.
|
| We can choose to do that "out of band", or we can choose to
| re-implement it for applications time and time again, or we
| can move towards a unified system. Today we do the first
| two. A tremendous amount of time is wasted implementing
| conversion and loading and saving for different
| applications, and a tremendous amount of time is wasted on
| doing out-of-band conversion. I've spent the better part of
| the last month dealing with crappy data conversion because
| a tool I need to feed data into implements it's own
| conversion in a badly broken way instead of reusing a
| better one, forcing me to go via another format. The amount
| of developer effort wasted on this bullshit is massive, and
| the amount of inconvenience for users is too.
|
| > Didn't you ever wonder why Datatypes seemed so brilliant
| for image files, and kinda sorta OK for music, and then
| basically of no value at all for most other file formats?
| It's because there really were sixty different crappy
| pixmap formats that were completely interchangeable and
| half a dozen PCM audio formats likewise. But that's not
| what happened in other domains, because it's pointless.
|
| No, I didn't wonder that, because the limitation there was
| that Commodore went bankrupt and datatypes was not
| progressed to cover additional domains, and the Amiga
| community was not large enough to take on the task of
| covering more complex structured data options. Meanwhile we
| still depend on conversion filters for all kinds of other
| formats _all the time_ for e.g. office suites. So no, it 's
| not pointless.
| rbanffy wrote:
| > But anything Gimp's native images can't do, you can't
| "add" using these plug-ins. The SVG plug-in for example
| can't magically make Gimp understand vector images
|
| No, but an SVG datatype can present itself as both bitmap
| and vector and an application that wants a bitmap can still
| read an SVG as if it were a bitmap.
|
| > It's because there really were sixty different crappy
| pixmap formats that were completely interchangeable
|
| Any data type that's generic enough can present itself in
| multiple ways as long as it's possible to translate (even
| if with losses) to those ways.
| vidarh wrote:
| And indeed there's an SVG datatype, with an associated
| generic vector superclass on Aminet, updated last month,
| as well as a Cairo based SVG class that renders to
| bitmaps.
| kstrauser wrote:
| > Most applications gain nothing from having, say, yet
| another mediocre bitmap graphics format. You just made your
| system more complicated without any improvements
| whatsoever.
|
| WebP is much newer than most Amiga applications. Since
| someone wrote a WebP datatype, an Amiga word processor
| written in 1994 can embed one in a document. An Amiga
| graphics app released in 1997 can open one and edit it.
| Literally every Amiga app that can use the datatypes API
| now supports it, without a single recompile or changed line
| of code, because someone wrote that loader. That's pretty
| powerful.
| tialaramex wrote:
| > That's pretty powerful.
|
| That's literally just spelling. The exact same _pictures_
| could have been added to the document in 1994, only the
| file format changed.
|
| People keep doing this, as others have observed. And they
| always get stuck in the same place, they can make
| different raster image formats work, although each time
| this happens they find there are fewer anybody cares
| about, and they can do the same trick with PCM audio,
| although again not many options anybody cares about (MP3
| is about as exciting as you get these days) and then they
| run out of steam.
|
| This is not a rich seam of unexplored possibilities, it's
| a small hole in the ground that people keep clambering
| down into - certain they'll find treasure and then
| disappointed when it is in fact just a small hole in the
| ground.
|
| It's the Oak Island money pit of technologies.
| rbanffy wrote:
| > What was special with the Amiga in that respect was that
| these things were embraced fully across the board
|
| That's just because it's part of the OS. On a Mac you have
| lots of high level APIs to interact with programs and data
| that form the visible layers of the OS. On Linux there is a
| hard border between GUI and OS and a mechanism like this
| would be more at home in Gnome or other desktops.
|
| Another factor that drove adoption is software scarcity. Back
| then it wasn't trivial to just link to a library that reads
| GIF files and it was much easier to use OS services for that.
| The cost comes in portability. I can write a Mac or Linux app
| that can be compiled and runs on mostly anything, but the
| moment I use OS services, it's no longer portable.
| vidarh wrote:
| The thing is there's nothing preventing making a portable
| API providing the most important capabilities datatypes
| did. It's one tiny little library. The challenge is
| cultural, not technical. Without a reasonable hope of
| adoption, there's little value.
|
| It's also not as simple as it being part of the OS, though
| space constraints certainly would favour OS libraries - the
| Amiga world is full of APIs that were adopted across the
| board despite not being part of the OS.
|
| E.g. XPK is a good example: If you want to support
| compression in an Amiga app, you'll most likely use XPK,
| which gives you instant support for every compression
| algorithm someone wrote an XPK library for.
|
| What is more likely to have mattered was in general whether
| or not a potential user would be likely to already have a
| library installed. My first hard drive was 20MB. What an
| application chose to install was a big deal, and that
| certainly encouraged people think about sticking to options
| that were popular and that likely to would save space.
|
| Regarding the "hard border", it's worth keeping in mind
| that while datatypes could be used for visual elements, it
| could also be used for "headless" load/save/conversion.
| Putting something like it in e.g. Gnome would be less
| valuable than providing the "headless" part, because the
| format conversion is the most valuable aspect. And that
| part is incidentally also the easiest part to make
| portable.
| nitrogen wrote:
| _unified API, the ability to drop plugins in for new file
| types, and for applications to actually unify around using a
| specific standard._
|
| There have been attempts, such as OLE and ActiveX on Windows,
| or KParts in KDE 2 (and dcop from Qt 2) (or was it 3?), or
| Intents on Android, or WebIntents, but yeah, none of them
| became universal, and many of them had security problems.
| vidarh wrote:
| I think all of these illustrate part of the challenge:
| They're all tremendously complex compared to the basic
| functionality of datatypes. That is part of the problem
| with many of the attempts to do the same again. A lot of
| the constraints AmigaOS had to deal with became strengths
| in that these APIs had to be simple because they had to
| work on machines with memory measured in kilobytes or
| megabytes.
|
| Of course it's also more complex to do on a system where
| you expect security (no memory protection on Amiga's made
| that rather moot), but I think a targeted attempt to do
| _just_ the minimum datatypes does - or even _less_ , would
| still be valuable. E.g. many of the security issues are
| related to embedding a widget, but _just_ providing a
| unified mechanism for _loading and saving_ which could
| easily be sandboxed and interfaced to via a dumb pipe
| (still security issues in validating what 's passed over
| that of course).
| agumonkey wrote:
| I cannot shake some fondness for those old blocky UIs. It's so
| less capable than 2020s js/css3 but still it's so grounded to me.
| tomxor wrote:
| They are _far_ more capable. UI is a strange type of visual
| functionality. The late 80s and 90s UIs manage to minimise
| ambiguity and make implied function painfully clear... never
| did anyone hunt for a button amongst a sea of non-interactive
| content in any of these UIs.
|
| To be blunt, a lot of modern UI are like pretty glass Norman
| doors... lest you dirty our pretty frosted glass with your
| filthy hands for the sake of usability, what will the stake
| holders think!
|
| I am not blind to aesthetics, but I believe form should emerge
| from function, as per Dieter Rams. Hopefully we will swing back
| towards prioritising function, but it doesn't have to look
| dated.
| ant6n wrote:
| What's less capable about it? To me it looks less slick, but in
| terms of affordances it's way better.
| agumonkey wrote:
| dom + css (+ layered compositing) is an extremely versatile
| and free form UI system
|
| the old ui widgets can't really (I assume) vary that much in
| properties or location (the layouting is stricter and will
| break if you push it too hard)
| herio wrote:
| You'd be surprised how flexible some of the GUI toolkits on
| the Amiga actually were. MUI is based on the concept that
| layout is dynamic and flexible.
|
| It would dynamically calculate a minimum window size based
| on the components inside and you could then resize the
| window as you wanted with things calculating and resizing
| as you go, adapting to font selections and themes.
|
| The actual implementation is archaic by todays standards
| but it did use attributes on UI objects to determine
| min/max sizing and other things, similar to CSS in concept.
| eludwig wrote:
| A lot of computer history is filled with machines that were
| obviously a link in a chain between earlier times and later
| times. They felt "transitional", in a sense. To me, both the
| Amiga & the original Mac had a "ding an sich", a such-ness that
| made them feel timeless. They stand alone as objects (art?) that
| can still be enjoyed today in and of themselves, no excuses
| needed.
|
| There are probably a bunch of other machine candidates that feel
| this way to someone out there!
| sdoering wrote:
| Not long ago I dismantled my first ever computer. An old
| Macintosh Classic with 4mb RAM and 40 MB harddisk. It was
| broken beyond repair and since then I am looking for a way to
| connect the old disk to anything modern. Sadly I can't find a
| connector that is halfway decently priced.
|
| I will keep looking, but breaking up the thing that was in one
| way or the other part of my life for >25 years felt very
| strange. So many memories. So many firsts. And I believe that
| this is a big part of that feeling of specialness such things
| have.
|
| A new laptop doesn't provide any firsts for me. Nothing new.
| Maybe faster. Maybe a better keyboard. But nothing new.
| drewzero1 wrote:
| I had similar feelings when breaking down my family's old
| Gateway 2000 for scrap. That was the computer on which I
| started learning about how operating systems work (or don't,
| if you delete system files to free up space). The experience
| from that computer and the Apple ][e that preceded it has
| really shaped my trajectory since then.
|
| PCI SCSI controllers are around and fairly cheap, looks like
| there are even some PCIe ones out there (not as cheap). I've
| never gotten as far as the software side of it though. I
| imagine one might create an image of the disk, and use it
| with Mini vMac, but I think I still need to figure out the
| SCSI setup. (I have a PCI SCSI card that I was attempting to
| use to interface with some tape drives-- different story.)
| munificent wrote:
| _> To me, both the Amiga & the original Mac had a "ding an
| sich", a such-ness that made them feel timeless._
|
| I know the exact sensation you describe here. But I can never
| decide whether it's a property of the thing itself, or where I
| was in my life when I stumbled onto it. My hunch is that it's
| mostly the latter: artifacts feel seminal when they hit as a
| formative time when we first gained a new capability.
|
| I'll always have a fondness for the Apple IIe and the early
| Macintosh because those were what I had when I first started
| using computers to create. I'll always love late 90s
| electronica because that's when I fully discovered my love of
| music. My Lodge Dutch oven will hold a special place in my
| heart because I got it right when I was really learning how to
| cook.
| Baeocystin wrote:
| We're probably of very similar age, as I feel much the same.
|
| That being said, I _do_ think there is something special
| about that era of machines, even outside of our right-place
| /right-time nostalgia for them. I cut my early computing
| teeth first on a Timex 1000, later on a Commodore 128, and
| finally an Amiga.
|
| The Timex was... ok. It was fun enough to pfaff about with,
| but so limited that it didn't really capture my attention in
| a special way. The Commodore? Amazing. It is responsible for
| my entire technical career trajectory. I loved exploring its
| edges. It was a powerful-enough system that Real Things(tm)
| could be done, yet still simple enough that the entire
| machine could live in your head, so to speak. The Amiga? It
| was amazing, but it was almost too much. I couldn't hold the
| whole machine in my mind any more, and had to rely of greater
| level of abstractions to get things done. What was doable was
| incredible, but there was an undeniable sense of loss, too.
| At least for me.
| TheOtherHobbes wrote:
| It's the thing itself.
|
| Some designs are made by passionate talented people pushing
| the limits of their own skills and imaginations to explore
| _what might be possible._
|
| And others are made by mediocre people throwing some some
| minimal-cost low-effort derivative crap together to make as
| much money as possible.
|
| One is an inspiration. The other is kind of offensive.
|
| I suspect a lot of computer nostalgia is really about chasing
| that first feeling. I also suspect that's a lost cause,
| because you can't find the limits of imagination on the
| trailing edge.
|
| Of course you can get echoes of it. Which is almost
| reassuring - but I really wish there were more high-skill
| high-imagination projects in computing today.
| cat199 wrote:
| vaxstation/microvax + 4.3BSD + printed USENIX manuals is pretty
| much the quintessential mid-80s internet machine
| anthk wrote:
| Just use SIMH, tun/tap, Xephyr and xhost.
| dm319 wrote:
| To me the Amiga felt less transitional and more like a branch
| cut short. These days everything is better, but also nothing
| is.
| marban wrote:
| Still using my heavily upgraded G4 Cube on a regular basis. The
| transitional part your're referring to is the Dot-Com times
| this Mac reminds me of -- In addition to simply being a joy to
| look at.
| EamonnMR wrote:
| I think it probably is age related because I feel the same way
| about the iMac G3. That machine was kicking around schools well
| beyond its actual useful life. Even when they upgraded them to
| OSX the OS9 login screen was still burned into the phospor.
| dep_b wrote:
| I love that demo. You can definitely see how much better
| something on the Amiga can become once you can feed it better
| samples and images. It looks so much newer while it's the same
| A500 I started with mid 80's!
| bovermyer wrote:
| Wait, so... Amiga OS 3.2 is newer than 3.9?
| herio wrote:
| Yup.
|
| They also were not developed by the same company. 3.5 and 3.9
| were developed by Haage & Partner, 3.1.4 and 3.2 were developed
| by Hyperion Entertainment.
|
| There's even an AmigaOS 4.0 from Hyperion which is PowerPC
| only.
|
| For extra bonus points, there's MorphOS which is a heavily
| AmigaOS influenced OS. PowerPC only, runs on some of the older
| PPC Macs.
|
| And there's also the open source AROS reimplementation of
| AmigaOS 3.1 (with a lot of extras).
|
| (I'm sure I got a lot of details wrong, been years since I last
| did Amiga stuff.)
| Perstone wrote:
| Yes. Both are updates to Amiga OS 3.1.
|
| Amiga 3.5 and 3.9 were created by a German company back in
| 1999/2000 and require a 68020 or better processor.
|
| https://en.wikipedia.org/wiki/AmigaOS#AmigaOS_3.5,_3.9
|
| 3.1.4 and 3.2 were created by Hyperion Entertainment. 3.1.4 and
| 3.2 by the looks of it support all the 68000 series processors
| and these as stated in the article are more recent.
| schemescape wrote:
| Does anyone have any idea how much of this could be done on stock
| Amiga hardware (without hardware upgrades)?
|
| I'm not anti-upgrades---just curious :)
| mnd999 wrote:
| Depends on the system. My A1200 (6mb Ram, HD) is same spec as
| it was back in the day will run Wordsworth, Protext and DPaint
| IV just fine but doesn't really do web browsing. I added a
| basic PCMCIA WiFi card though and it copes with ftp okay over
| open WiFi.
|
| Don't expect a screen resolution anything like the ones shown
| in the article though and RAM and the 68020 become an issue
| fast working with a lot of recent files. The author has a lot
| more RAM than me and it definitely shows.
| rbanffy wrote:
| > Don't expect a screen resolution anything like the ones
| shown in the article
|
| Up to the 3000, IIRC, Amigas were tied to TV frequencies, so
| you wouldn't get more than 200x640. You could do interlacing
| and get 400 lines, but you'd want to claw your ever out in 10
| minutes.
| zandorg wrote:
| I had an Amiga 1200 and got it working with a VGA monitor
| soldered onto the connector (like a VGA adapter on Ebay
| now) and a setup VGA file in Workbench 3. It looked great
| in 640x480, no chunkiness. So it is possible.
| coldacid wrote:
| Only Amiga Makes It Possible!
| myth_drannon wrote:
| There is a coffeetable style book on Amiga demoscene
| https://www.editions64k.fr/index.php/product/demoscene-the-a...
|
| Volume 2 is on IndieGOGO
| herjazz wrote:
| Just have to say I loved my Amigas back in the day. First an A500
| and then a dual floppy 1500. Never quite recaptured that feeling
| with Linux.
| jacquesm wrote:
| If you ever have an opportunity play around with an SGI Irix
| box, an Indy or an Indigo.
| incanus77 wrote:
| When I went to engineering school in 1995, most of the
| computers on campus were UNIX machines... Sun SPARC in the
| dorm, IBM AIX machines, a few others. But the fastest and
| shiniest by far were the SGI IRIX machines. They not only had
| a webcam built in, but ran at (IIRC) 200MHz. These all were
| my introduction to not only UNIX, but also the internet. I
| first got ImageMagick compiled and running on an Indy, and
| later, even played DOOM in the lab. <3
| jacquesm wrote:
| That webcam is the very reason why I wrote that first
| version of live streaming video on the web :)
|
| It was the first camera that came with a computer and it
| had a pretty easy interface from C so that + a small
| embedded HTTP server and we were off to the races.
|
| The funniest bit to me is still that people simply would
| not believe they were looking at a live image from the
| other side of the world. More than once I had to go in
| front of the cam and wave at people or show them some tekst
| :)
|
| Eventually I automated that by putting a remote controlled
| fan + light (and a mobile of paper cranes) in front of it,
| but then people would claim that I was faking it. Tough
| crowd :)
| vidarh wrote:
| I went from an Amiga at home to an Indy at university (my uni
| got a massively got deal from the SGI distributor to outfit a
| couple of the computer science labs; nothing like rows of
| Indy's placed next to tired old Sun terminals white
| monochrome screens to make SGI look like the hot new thing),
| and while I never particularly liked Irix, it certainly felt
| closer to "home" in a way that Windows or even Linux didn't
| at the time.
| icedchai wrote:
| I had an SGI Indy on my desk, back in 1997 or so. Definitely
| a fun machine. I remember the web cam, and doing full video
| conferencing (and bandwidth hogging most of a T1!)
| jacquesm wrote:
| I can beat that :) We were bandwidth hogging the
| transcontinental backbone to the point that I got a testy
| email from the maintainers that they were going to block
| port 2047 in a couple of days so if I wanted to act it had
| better be quick. That's how we ended up with an office in
| Canada (300 meters from Front 151 with a nice fat fiber).
| marcodiego wrote:
| I've got such opportunity. Now, every time somebody jokes
| about the "it's a UNIX system. I know that!" I have to
| explain that that file manager actually exists but still
| looks like sci-fi for mere mortals even today.
| jacquesm wrote:
| Irix was the most clean and integrated Unix for the desktop
| that I've ever used, even Sun didn't come close with their
| offerings.
| rbanffy wrote:
| The most shocking thing on the Suns back then compared to
| the SGIs was the mouse movement. While the SGIs had a
| smooth movement, Suns mouse ended up jumping dozens of
| pixels between refreshes.
|
| Suns were not really designed for desktop use - they more
| or less aimed for the generic case. SGIs, however, were
| built to be experienced.
| [deleted]
| marcodiego wrote:
| I remember the first time I used a Sun Workstation. From
| a PC background, I was impressed by the fact that the
| keyboard housed the beeper, the keyboard was a serial
| device and the bios equivalent had a built-in command
| line.
|
| It is a shame that such a small set of features jumped
| from workstations to the PC.
___________________________________________________________________
(page generated 2021-08-05 23:01 UTC)