[HN Gopher] Got an old Raspberry Pi spare? Try RISC OS. It is, s...
___________________________________________________________________
Got an old Raspberry Pi spare? Try RISC OS. It is, something else
Author : m_c
Score : 110 points
Date : 2024-05-02 19:55 UTC (3 hours ago)
(HTM) web link (www.theregister.com)
(TXT) w3m dump (www.theregister.com)
| robin_reala wrote:
| I've got fond memories of RISC OS from my school's room full of
| Archimedes. I spent a a fair bit of time designing and failing to
| build a text adventure in Basic, while my teacher tried to get us
| to learn how to use TechWriter. Best feature was being able to
| drag a slider to create a RAM disk.
|
| Amazingly you can still buy a copy of TechWriter 9.1 for PS85!
| http://www.mw-software.com/software/ewtw/ewtw.html
| z500 wrote:
| I kind of went down a rabbit hole last year after the Xerox Star
| emulator was posted here. It was really cool, but super slow, so
| I felt like emulating another old system. I ended up writing a
| GUI calculator for RISC OS in ARM assembly, neither of which I
| had exposure to before. It was a blast. Very interesting system,
| it's like visiting a country on the other side of the planet.
|
| There's a pretty good emulator, they've got a bundle fully loaded
| with all kinds of RISC OS tools.
|
| https://www.marutan.net/rpcemu/easystart.html
| wiktor-k wrote:
| It gives me strong Amiga-vibes and it seems it's open-source
| now... I like it and will definitely try it out!
| b800h wrote:
| Excellent, I've been waiting for Wifi support, it's a game
| changer. Will be mucking around with this at the weekend.
| LeoPanthera wrote:
| RISC OS has been limping on thanks to the efforts of some
| extremely hard-working volunteers, but a roadblock is coming. The
| Pi 5 drops support for 32-bit ARM code, in which RISC OS written,
| and since enormous chunks of it are written in assembly, there is
| no trivial way to port.
|
| Even so, it's heartwarming that people continue to put efforts
| into operating systems that aren't related to Unix or Windows.
| I'm happy to see people use this, and AmigaOS, and BeOS, and
| others. Computing shouldn't be a monoculture.
| fweimer wrote:
| > The Pi 5 drops support for 32-bit ARM code
|
| Note that EL0 (userspace) support is still present, but RISC OS
| cannot currently run entirely in userspace.
| ajb wrote:
| It was ahead of its time in UX, but rather behind in the
| foundations. It's a single user system with no real security, and
| there was no system of shared libraries - to share code between
| applications, it was usual to put the shared code in a kernel
| module and call the kernel. Even the standard C library worked
| this way.
|
| Amusingly, when you invoked the system console -which was at a
| lower level than the gui system, effectively pausing it - the
| command line appeared at the bottom of the screen and the frozen
| gui scrolled up as you entered more commands; until you exit the
| system console. (It was also possible to get a command line in a
| window, which could do slightly less - I forget exactly what)
| dietr1ch wrote:
| Sharing code? I like my apps bundling a whole browser to render
| a couple buttons
| amiga386 wrote:
| I'm not even sure it was ahead in its UX; it had a three button
| mouse, and daily operations needed all three mouse buttons. I
| had to use them for years at school and I feel you could never
| quite be sure what the third button would do. In some cases, it
| was like what shift-click does today, in other cases it
| selected menu items without closing the menu, in other cases it
| moved windows without bringing them to front and in yet still
| different cases it opened a _different_ menu to the one the
| middle-click did.
|
| For menus, I feel it was the worst of all systems. The Mac and
| Amiga had menus consistently at the top of the screen, and the
| Mac was good for discoverability in that it showed you the
| menus were there without you having to click a button. Windows
| also did that, but menus were attached to windows (bleh). RISC
| OS was worst of all, _every_ menu is a context menu, including
| app-level menus - and you got different menus depending on
| whether you _middle_ -clicked on the icon bar icon, or you
| _right_ -clicked on the icon bar icon.
|
| There was no standard file requester, _everything_ was drag and
| drop; to load a file, you had to drag it onto the application
| (although yes, default file associations allow you to double-
| click it). To save, first make sure you've got a filer window
| of the directory you want to save to open and visible on
| screen, then middle-click in the window of the file you're
| working on, navigate to File -> Save -> a tiny box with a file
| icon appears, you get to type the filename, then you have to
| _drag_ the file icon to the folder to save. And if you
| accidentally mouse-out of that box while typing the name, you
| lose the name.
|
| The OS was also ridiculous in some of its APIs, particularly
| that there were a million and one things under the calls
| OS_Byte and OS_Word - yes, really, API calls all clustered
| together because they return a byte or return a word. It's a
| design holdover from the original BBC Micro's OSBYTE and OSWORD
| calls. There's also a pile of crap multiplexed behind "VDU"
| calls, and much like terminal emulators, there's a lot of
| behaviour you can invoke by printing specific control sequences
| to the text screen, including mode-switching.
|
| It had a weird system where _all_ OS calls were either "I'll
| handle errors" (e.g. SWI XOS_WriteC) _or_ "let the system
| handle errors" (SWI OS_WriteC), which in most cases means that
| if the OS call ever had an error, it stopped and exited your
| entire program. The problem with this approach is lots of
| programmers chose to write software that falls over at the
| slightest provocation, rather than think to deal with every
| error and decide how much to deal with recovering it. So, for
| example, let's say you've been working in a paint package on
| your masterpiece, you save to disk, and there's a read/write
| error. Goodbye masterpiece.
|
| You can get a flavour of its programming environment from
| http://www.riscos.com/support/developers/prm/
|
| It also had its own filesystem metadata craziness; there were
| no file extensions, but rather file type metadata saved
| separately (the Mac also had this madness), and it also saved
| the "load address" along with the file.
|
| Nonetheless, what I did like about it was:
|
| 1. That the whole OS was ROM-resident and you can boot a device
| with no media needed at all, within 3 seconds of turning it on.
| AmigaOS was _nearly_ all ROM-resident, but nonetheless required
| a boot disk to get to Workbench (all you need on that boot disk
| to get to Workbench is a ~200 byte program that launches it; it
| was clearly a deliberate choice to insist on a bootdisk, and I
| think it would've been better if it didn't)
|
| 2. That it pioneered "an app is a special kind of directory",
| so you can keep all your app's assets inside a folder. Mac OS
| at this time was using the awful resource-fork system to do
| this, but by Mac OS X it had seen the light and create apps and
| resource bundles
|
| 3. That it had a built-in BASIC interpreter, and this was a
| very fine BASIC because it had a full assembler built into it
| and it had fantastic BASIC-to-machine-code interoperability.
| You could write all the bits that needed to be fast in
| assembler, while writing the rest in BASIC. There were even a
| few commercial games released written in BASIC+Assembler.
|
| Overall, AmigaOS was a much better OS than RISC OS, but I do
| still have space in my heart for the plucky British operating
| system.
| fredley wrote:
| RISC OS was the first graphical OS I ever used - my father ran
| Sibelius (the very first version I think) on an Acorn computer
| for engraving music. The three-button mouse approach is totally
| unique, I'm glad they explain it in this article!
| imoverclocked wrote:
| Wow, the article itself brings me down memory lane. The one thing
| that will not bring me into this platform: cooperative
| multitasking. (Shudder) I'm sure it feels _fast_ though!
| ChrisArchitect wrote:
| More on official post:
| https://news.ycombinator.com/item?id=40188348
| ajb wrote:
| Acorn was a curious company. It managed to get incredible amounts
| of work done, by assigning big projects to individuals instead of
| teams. My memory is not to be relied on at this lapse of time,
| but I seem to recall that in the final years there was a browser
| maintained by one guy, a port of Java by two, and an
| implementation of directX by another. Obviously all those
| projects were much smaller back then (around 98) but still, those
| devs were doing the work of what another company had a team to
| do. And in fact this does work, as communication overhead is
| reduced, but in many cases the increase in productivity loses
| strategically to the slower time to market.
| beeboobaa3 wrote:
| From personal experience it's amazing how much more productive
| I am on solo projects vs working with other people. When you're
| solo you can just go, but in a team everything needs to be
| discussed or at least communicated.
| DowagerDave wrote:
| Scaling software development has been THE vexing problem
| since day one. There's no doubt that the most efficient
| system fits in the head of a single person; the challenge is
| then what?
| silisili wrote:
| I've pretty much found the most it scales linearly is 2,
| and only then in good conditions such as working well
| together, greenfielding, and something with clear enough
| boundaries.
|
| After that, well, it basically flatlines and even seems to
| decrease at times.
| kaspm wrote:
| Efficient but not necessarily better. When I'm solo
| developing I go back later and I made some questionable
| decisions a team member would have identified.
| humzashahid98 wrote:
| Related to this subject is Casey Muratori's video about
| Conway's law and a possible extension to it. The
| communication overhead of working in teams, and the fact
| it's harder to address cross-cutting concerns in them, is a
| key theme in it.
|
| https://www.youtube.com/watch?v=5IUj1EZwpJY
|
| There is also Descartes' quote about how a work produced by
| one master is often better than one in which many are
| involved, because of the unifying vision.
| ozim wrote:
| But one master cannot go to the Moon.
|
| It takes coordinated effort of many, many people. The
| same with making a-bomb, the same with making anything
| bigger in software.
|
| It's nice that Linus started kernel and GIT but nowadays
| he's not writing much code and most likely he would is
| not able to review personally each and every PR.
| humzashahid98 wrote:
| You're right. We also have proverbs like "two heads are
| better than one" and "standing on the shoulder of giants"
| so people recognise that both sides are important and
| have their value.
|
| Right now, I'm working on my own on a personal project
| attempting to do something a little novel and I
| appreciate being able to go back and refine my
| ideas/previous code based on things I learn and
| additional thinking (even rewriting from scratch), when
| I'm more likely to face friction (like "stick to the
| suboptimal approach; it's not that bad") and cause
| trouble for teammates if I was working with someone else.
| So the value of working alone speaks more to me currently
| than the value of working in teams, but they both have
| their place.
| LordDragonfang wrote:
| I read _The Mythical Man Month_ recently (first published
| in 1975), and while some of it is charmingly dated (have a
| secretary take your code and run it down for you!), it 's
| astonishing how much of its discussion and advice for
| structuring a team of programmers remains relevant even
| today.
| abraae wrote:
| Obligatory Fred Brooks quote: "The bearing of a child takes
| nine months, no matter how many women are assigned."
| exe34 wrote:
| Hah, try getting them to sit through refinement meetings, and
| I bet it'll take a lot longer!
| fidotron wrote:
| I recall seeing a Macromedia Director player but never heard of
| a DirectX port. In any case the lack of hardware floating point
| in most of their machines was looking like a big mistake by the
| mid 90s. Their compilers were also way off the pace and that
| was getting to be a problem.
|
| Tbh I think I am slightly bitter about having stuck with Acorn
| a bit too much, and should have jumped away sooner. It is clear
| Acorn knew they were toast even before the Risc PC. A lot of
| these very impressive developments were consequently glorious
| wastes of time, which is kind of tragic too.
| dheera wrote:
| That UI looks like something out of the late 80s / early 90s. I
| can smell the VCR head cleaner and scratch-n-sniff stickers and
| hear the dial-up internet bee-bee-bee-bee-gurglegugrle-dong-ding-
| dong-ding-whooooooooosh-wheeeeeeeesh-bling! bling whooooo.
|
| Can we at least upgrade the fonts, colors, and negative space to
| make it look more 2020s?
| joosters wrote:
| _Can we at least upgrade the fonts, colors, and negative space
| to make it look more 2020s?_
|
| Of course YOU can, it's open source, feel free to hack away at
| it.
| owyn wrote:
| I know this is a joke but this OS was first released in 1987...
| I forgot all about it, but it's pretty cool that you can still
| run it on hardware.
| lproven wrote:
| That's my article -- I posted it here too:
|
| https://news.ycombinator.com/item?id=40234430
| kaycebasques wrote:
| Skimmed the article, didn't see this important bit mentioned: I'm
| pretty sure the OS is available through rpi-imager, meaning it's
| trivial to set up on an RPi and presumably has some notion of
| official endorsement from RPi org.
| 486sx33 wrote:
| " significant chunks of it were hand-coded in Arm assembly code"
| as all modern OS should be at the kernel level
___________________________________________________________________
(page generated 2024-05-02 23:00 UTC)