Official Release - CMOS

The thing I like about RISC OS is its simplicity, for example the self-containted applications. This simplicity is a major part of RISC OS’s identity.

It is unstandable that some changes rises the fear that RISC OS loses it’s, hm, RISC OS-ness. I am sceptical about it myself, but will give PackMan a chance when I get time for toying around a bit.

Can I suggest that we all take some deep breath before posting to lower the heat of discussion?

I take the opposite view from you, it seems. I feel that a packager should restrict what it does to specified directories (i.e. location of system components plus a defined location.)

What is wrong with the “defined location” being where the user wishes to install the program?

If I put an application in a different folder, I don’t want to find that the packager has upgraded it for me.

Surely that you ought to be prompted before stuff gets upgraded?

What about someone with a RISC OS machine that is not online? (e.g. IRUG’s Risc PC).

Well, that would count all of my machines. I tend to look for package zip files and drop them on a USB key (new machines) or floppy (old machines).

All PackMan needs is a simple web server set up with the ‘package source file’ pointing to the downloaded packages.

Which part of that is “simple” for a non-geek user? It would be a lot nicer if you could draggy-droppy a file onto the package manager and let it get on with things. Sort of like David Pilling’s !Patch.

In other words, you want RISC OS to abandon the notion of self-contained application directories

Not at all!

If you now install Sunfish and SVN they get installed in $.Apps.Disc.!Sunfish and $.Apps.Development.!SVN. I was suggesting moving them to, say, $.Boot.Resources.Packages.Apps.!SVN and $.Boot.Resources.Packages.Apps.!Sunfish (removed some plings here because textile ate parts of the paths…) with the user choosing some appropriate place for the skeleton apps for !Sunfish and !SVN.

That way, you can easily find the apps, they’re all in the same directory (although a bit deep in the directory structure). And the skeleton-apps are exactly where you wanted them.

What is wrong with the “defined location” being where the user wishes to install the program?

Nothing, I’m just pointing out that my way of managing apps is different from yours. But packman supports either approach, so that is good.

Well, that would count all of my machines. I tend to look for package zip files and drop them on a USB key (new machines) or floppy (old machines)

Which is exactly why the entire packaging process must not be enforced.

People should be able to grab the zips and deal with them manually, or have them fetched automatically, but deal with the files manually, or choose where to have them installed, or go with the default and create links.

All are valid, and all can co-exist.

Chris Gransden has a point in that some of this argument is redundant now that PackMan can move the installation location of packages, eliminating the need for stubs. (WTF was the guy who invented those thinking? Actually, don’t answer that, because I directly asked him what he was thinking a couple of years ago. The answer made as much sense as you might expect.)

I’m wary of commenting too much on PackMan’s user interface as it currently stands, given that I’ve never used it, but for me to switch to package management, all of the following conditions would need to be met (collated from known problems with RISC OS packages and my experience with Linux packages):

• Allow the user to choose the installation location when the package is first downloaded, not to install it somewhere random (potentially creating useless directories like ‘Apps.Admin’ along the way) from where it must then be moved.
• Allow packages to have update checking individually disabled, in the case where a user has a valid reason for not upgrading.
• Ask permission before updating and give an option to disable or temporarily refuse.
• Work on offline systems – so you drag a package zip which you downloaded via some other app onto PackMan and it installs it as if it had downloaded it itself.
• If such an externally-downloaded zip has unmet dependencies, pop up a window which permits the user to drag those in as well (and of course any dependencies of the dependencies).
• Come to think of it, an ‘export package’ option would be useful – create a dependency-complete collection of zips for offline use on some other machine. (You may scoff, but there are a lot of RISC OS computers without network connections. Heck, there are a lot of Raspberry Pis without network connections, since we don’t have wireless networking! This caused the problems on the Pi forum thread linked to earlier.)
• Never force an installation or update to fail, even if it thinks it’s a bad idea. This includes package conflicts, and overwriting of non-managed files. By all means warn the user and recommend against it, but if they know what they’re doing, don’t stop them! I hate control-freak software in general, but especially where it clashes with RISC OS’s general attitude that an experienced user knows best.
• On the same topic, allow an installation with unresolved dependencies to be forced.
• Cut down that ridiculous list of categories! And take a leaf out of !Store’s very sensible book and allow packages to be filed under more than one, because really, trying to slice reality into that many discrete non-overlapping black and white chunks is inviting chaos and confusion.
• Most importantly – never get in the way. Package management is supposed to make maintaining a system easier. Far too often, and I’m addressing both Linux and RISC OS here, it makes it an order of magnitude more awkward.

In general, I really think we need an ethos change around here. Something is not automatically good (or bad, for that matter) because Linux does it. And it shouldn’t take the clamour of a hundred users to tell you that lifting complete solutions from the Linux environment and shoehorning it into the very different RISC OS one is unwise. Just look at the Firefox port! A hell of a lot more careful thought about how packages could best be adapted to serve RISC OS’s needs and fit neatly into its environment ought to have gone into the original design of LibPkg, rather than religiously copying Linux just because it works for that very different system. It may well have done, but does this look like Linux to you?

Which part of that is “simple” for a non-geek user?

I was thinking simple as in it doesn’t have to do much. I see an opportunity for someone to write a package source mirroring application to serve machines locally or even add the facility to !Packman.

It would be a lot nicer if you could draggy-droppy a file onto the package manager and let it get on with things. Sort of like David Pilling’s !Patch.

If you drag a package to the !PackMan iconbar icon it puts the package in the cache. Then when you install the application it installs it from the cache without having to download it.

Martin Bazley…

^ wot ’ee sed

(^_^)

I think some are confused why yourself, Steve F. and possibly others are making such a fuss over a Package management application that has a certain amount of control over where things are installed.

I’m not surprised that you’re confused, as I’m not making a fuss over it. I know that you keep throwing that straw man at me, but I have no issue with the use of PackMan and haven’t had since I first wrote about why people might want to use its predecessor 8 years ago for Archive magazine.

• I objected to users being forced to use PackMan, because it is very clear that many will not do so. I think the clear consensus is that Jan-Jaap is on his own with that one.

• I’ve not packaged my software yet, because the time taken to get it up and running seemed disproportionate to the number of people in the existing user-base who would use it (see previous bullet point). I’ve already made it clear that moves with the Pi were making me re-evaluate that situation.

• I objected to the statement that free software in PackMan should not also be made available via !Store, because !Store is likely to be more palatable than PackMan to the people in the first bullet point and so having software in both is desirable. So far, the two people responsible for that idea haven’t come back to justify it further.

Sure, there are things that could be improved with PackMan (such as the GUI, which is far from intuitive even for someone who uses the Linux equivalents on a regular basis). But I really can’t see where I’ve said that PackMan is a bad idea for those who want to use it.

There is one other thing that I would like to pick up on, though. Your sarcastic

I don’t know whether you’ve noticed or not but !PackMan is installed by default in the recently launched Raspberry Pi distribution

is actually very pertinent, although maybe not for the reason that you think. For non-Pi-owning developers, it’s actually very hard to see what’s going on. I certainly didn’t know about PackMan 0.7. I don’t know how many developers don’t have Pis, but unless I’m in the minority this is something that really needs considering as continued misunderstandings like this aren’t conducive to productive cooperation.

I don’t know how many developers don’t have Pis, but unless I’m in the minority

It is actually quite simple to get the Pi distro running on an RO 4.x Risc PC (Soft loading the IOMD ROM and network drivers). Everything (expected) appears to work OK. I would think the same would apply for running it on an emulator or on an Iyonix.

“I don’t know whether you’ve noticed or not but !PackMan is installed by default in the recently launched Raspberry Pi distribution”
is actually very pertinent, although maybe not for the reason that you think. For non-Pi-owning developers, it’s actually very hard to see what’s going on. I certainly didn’t know about PackMan 0.7.

Interesting point Steve, which raises the question: Why not include !Packman in the other builds by the simple expedient of adding it to the HardDisc4 image development and thus open up a situation where ROOL allow those wishing to take new version Boot elements and new ROMs to do so directly by selecting a development rather than stable update.
As Jess has pointed out the Pi image works on RPC hardware (and presumably RPCEmu) but a full distro may be a bit much.

objected to users being forced to use PackMan, because it is very clear that many will not do so. I think the clear consensus is that Jan-Jaap is on his own with that one.

You seem to be basing your objections on one developers decision to retrict their application to be available solely under package management. Your definition of the word fuss must be different to mine thats all.

There is one other thing that I would like to pick up on, though. Your sarcastic

This topic is to do with the official release of the Raspberry Pi after all.
It doesn’t take much to find out what is happening with the latest version of !Packman. All you have to do is type “Packman ‘risc os’” into google.
It’s not as if there hasn’t been enough discussion about what’s happening with the raspberry pi distribution. It only takes £30 and about 10 minutes set up to find out.

Other people have expressed opposing opinions in this thread but it doesn’t mean they have to justify them. It’s just a discussion point that others may or may not agree with.

It only takes £30 and about 10 minutes set up to find out.

Words completely fail me. You really don’t get it, do you?

I’m just taking part in the discussion. Hopefully things are a bit clearer to others now. I have no idea what you’re trying to do!

You seem to be basing your objections on one developers decision to retrict their application to be available solely under package management.

No, I wasn’t basing anything on it. I was objecting to it. As it’s now clear that no-one here agrees with Jan-Jaap, I’m happy that it’s not a problem. How is that not clear?

simple expedient of adding it to the HardDisc4 image development and thus open up a situation where ROOL allow those wishing to take new version Boot elements and new ROMs to do so directly by selecting a development rather than stable update.

I think this has been the intention all along. It’s just take a long time to get where things are now. See this topic.

I think this has been the intention all along. It’s just take a long time to get where things are now. See this topic.

Ta, hadn’t seen that. I’ve spent a lot of time over the past few years working days and then coming home and working so I’d missed the developments.
Surprisingly it wasn’t the Pi that brought me out of the woodwork but a “disillusionment” with the paid occupation. They now get a round number of hours outside the contractual ones.

To clear up some things:

PackMan 0.7: Alan is currently preparing an ‘official’ release for non-RPi images – which will go on riscpkg.org for download or upgrade of previous versions. 0.6 has a number of problems with it, so I strongly suggest you don’t comment on PackMan without trying 0.7. Again, the Pi release has been the deadline we had to meet – is it a big deal that it takes a week or whatever before it’s released to other machines?

Packages on !Store v PackMan… one thing I discussed with Andrew R was a feed of PackMan/RiscPkg packages to !Store, so that they can be made available via that route too. Andrew at the time was busy with getting !Store out the door so an automated database upload wasn’t available at that point, but it’s a possibility for the future. It needs so thought so that it isn’t confusing. In addition, there is the question of how well new users cope with manual installation (which people here have as second nature but people seem to be really struggling with on the RPi forum).

Why PackMan? I didn’t choose it for ideological reasons. It was there, it (mostly) worked, it is reasonably well engineered, a server-side infrastructure (mostly) exists, and there was already a substantial body of software in that format. It has a large number of areas where it could be improved, but many of these are relatively cosmetic. If someone writes another system that is able to tick these five boxes, then it’s worthy of serious consideration as a replacement. Meanwhile, the aim was to get the job done in a short timescale by maximum reuse of things that already existed. A package manager has to be bomb-proof – if it breaks once, it can render itself inoperable for all time, so it’s not a trivial thing to write. It remains to be seen how robust PackMan actually is in a wide-scale deployment, but the underlying architecture is fairly good. I’d be much happier if there was a decent test suite, though. (Test suites: another idea mostly lacking on RISC OS)

PS You can now use PackMan to upgrade your RC5 Raspberry Pi to RC6 in just a few clicks

is it a big deal that it takes a week or whatever before it’s released to other machines.

Nope. Nice to know it’s in the pipeline.

Again, the Pi release has been the deadline we had to meet — is it a big deal that it takes a week or whatever before it’s released to other machines?

Not at all, if only we knew that!

In fact it wouldn’t have mattered if we didn’t know, except for the fact that 0.7 seems to have fixed the main “problem” that gets cited for users not accepting package management. And that most of this thread has been discussing that “problem”, with several of us unaware that it had been fixed.

I have no idea what you’re trying to do!

Trying to develop software for all RISC OS users, I think.

Chris Gransden has a point in that some of this argument is redundant now that PackMan can move the installation location of packages, eliminating the need for stubs. (WTF was the guy who invented those thinking? Actually, don’t answer that, because I directly asked him what he was thinking a couple of years ago. The answer made as much sense as you might expect.)

I expect it made a lot of sense, you just didn’t agree with what he was saying. I’ve been in contact with original author of the package system many times and he always seemed to make sense to me. Unless this is some email you sent to me, then I can only apologise if I failed to get my points across clearly.

I’m wary of commenting too much on PackMan’s user interface as it currently stands, given that I’ve never used it, but for me to switch to package management, all of the following conditions would need to be met (collated from known problems with RISC OS packages and my experience with Linux packages):

Seems fair – unfortunately limited development time means it’s unlikely to all get considered and possibly fixed in a short period of time. I just wish you wouldn’t spend so much effort on dismissing PackMan and the LibPkg back-end at every opportunity. I would also like to point out PackMan isn’t at the stage where it is the finished article, it still does not implement everything that the Packaging back-end allows.

Allow the user to choose the installation location when the package is first downloaded, not to install it somewhere random (potentially creating useless directories like ‘Apps.Admin’ along the way) from where it must then be moved.

Well the locations are not random, they’ve been considered by the application authors. The move works well, but I can see your point that you would like to do it in one step.

Allow packages to have update checking individually disabled, in the case where a user has a valid reason for not upgrading.

This is in the back-end and RiscPkg, but it hasn’t made it to PackMan yet.

Ask permission before updating and give an option to disable or temporarily refuse.

PackMan never does automatic updates, it always shows what it is going to do in dialogues before doing any install/update, so you can always refused to do it.

Work on offline systems – so you drag a package zip which you downloaded via some other app onto PackMan and it installs it as if it had downloaded it itself.

That’s partially there. It requires two steps, drag to PackMan where it is added to the list, then install it from the list.

If such an externally-downloaded zip has unmet dependencies, pop up a window which permits the user to drag those in as well (and of course any dependencies of the dependencies).

Good idea.

bg. Come to think of it, an ‘export package’ option would be useful – create a dependency-complete collection of zips for offline use on some other machine. (You may scoff, but there are a lot of RISC OS computers without network connections. Heck, there are a lot of Raspberry Pis without network connections, since we don’t have wireless networking! This caused the problems on the Pi forum thread linked to earlier.)

Not sure about this one. I can see why it would be useful though.

Never force an installation or update to fail, even if it thinks it’s a bad idea. This includes package conflicts, and overwriting of non-managed files. By all means warn the user and recommend against it, but if they know what they’re doing, don’t stop them! I hate control-freak software in general, but especially where it clashes with RISC OS’s general attitude that an experienced user knows best.

I think this may be harder to achieve as the Package manager probably doesn’t want the system in a bad state, but I’m not sure. The latest PackMan alleviates this a bit by prompting to back up any conflicting files and then retrying the install.

On the same topic, allow an installation with unresolved dependencies to be forced.

PackMan doesn’t allow this at present.

Cut down that ridiculous list of categories! And take a leaf out of !Store’s very sensible book and allow packages to be filed under more than one, because really, trying to slice reality into that many discrete non-overlapping black and white chunks is inviting chaos and confusion.

Reasonable suggestions, I haven’t any plans to fix this though, Sections are decided by Package authors using the guidance of the Policy Manual and not really under my control.

Most importantly – never get in the way. Package management is supposed to make maintaining a system easier. Far too often, and I’m addressing both Linux and RISC OS here, it makes it an order of magnitude more awkward.

I do find the current RISC OS packaging system makes it easier for me to maintain multiple RISC OS computers. However I’m not complacent, I’m sure there are edge cases where it can make things more awkward, I just haven’t come across them yet.

In general, I really think we need an ethos change around here. Something is not automatically good (or bad, for that matter) because Linux does it.

I agree 100%, it just seems to me that people sometime use the fact that the package system uses some terms and documentation from the Linux packaging system to mean it hasn’t taken into account that it is fore use with RISC OS.

And it shouldn’t take the clamour of a hundred users to tell you that lifting complete solutions from the Linux environment and shoehorning it into the very different RISC OS one is unwise. Just look at the Firefox port! A hell of a lot more careful thought about how packages could best be adapted to serve RISC OS’s needs and fit neatly into its environment ought to have gone into the original design of LibPkg, rather than religiously copying Linux just because it works for that very different system. It may well have done, but does this look like Linux to you?

I still have seen no evidence that this happened with the Packaging Project. It looks to me as if the original author considered carefully what it means to be a RISC OS application and what Packaging means and used the Linux experience as a helpful guide rather than something that needs to be slavishly copied.

Interestingly we both have looked at the existing Packaging system and have seen it completely different ways. I think it is well designed and thought out and you seem to believe it is slavishly copied from Linux. I did not have any axe to grind either way before I looked at it and do not use Linux that often to be considered a Linux fan of any kind. I evaluated on what it did for me on RISC OS.

Regards,
Alan

.

Package management on Linux started in order to avoid “dependency hell”; this was a big issue on Linux systems before effective package management systems like apt-get became widespread. On Linux you can’t choose where to put the files—but normally there isn’t a good reason to change from the default positions.

The only real alternative to package management is something like the “push button installer” system used by some of the BSDs—where the application package includes all of the dependencies and is installed in a directory of its own. This can lead to multiple copies of the same file but it does avoid package management and “dependency hell” too.

[note to reader: this started out as a quick reply… um… yeah… put the kettle on, pull up a chair, and see how many varied references you can spot in amidst this wall of text ;-) ]

I’ll never use a package manager – don’t care how brilliant it is.

Back in the day, it was taken for granite ☺ that an application was its own country and everything it would need would be in the OS or !System.
And in many cases that was true. Applications were easy to find. An Acorn User cover disc? Or Arcade. What wasn’t on Arcade would be on Digital Databank. And there was peace.
As time passed, utilities began to appear. Utilities that more than one program used. So the people began to wonder if it was wise for version x.xx of something to go with one program and version y.yy with another. It was considered more logical for resources shared by several programs to be a shared resource. We still had some disparity for a program shipped whatever the version with that program was – but so long as the installer didn’t trash a later copy with an earlier, then all was okay. And there was peace.
Now we enter the age of the network. Where once we proclaimed the beauty of the Baud, we ditched that long ago when kilobits and megabits became available at our disposal. Always connected, all the time, everywhere and nowhere all mixed in together. The old BBS scene evaporated. Who wants to call one specific system at national rate when you can have the world, first at local rate and then for a fixed tariff that for most people amounts to “free” (I pay about €60/month which is 0.0014 cents/minute but includes phone calls and a mobile contract and……..). This has all changed how software can be distributed. No longer do you need to have your application come on a tidy little disc that the user inserts into the machine. No longer do you need to provide all the resources you need. No longer do you have to provide two screenfuls of instructions telling people what to do if it is anything more complex than drag’n’drop.
No, we can reduce a complicated install process to a simple drag’n’drop. We can distribute a bare-bones application and tell the installer where to find the “dependencies”, all that third-party guff. So now you will always be pointing to the latest release no matter how old your program is (well, within reason, obviously!). The centralisation of the package repository doesn’t mean a hundred different websites to remember; and woe is you if the website vanishes or the service is suspended (GeoCities; could happen to any Google product if they lose interest in it…).
And yet, somehow, this is a bad thing?

Granted, package management on RISC OS is far from ideal as I personally think it borrows too heavily from the other OSs it is trying to work with – one of which is a godforsaken mess (it it /bin? /sbin? /usrs/bin? /usrs/sbin? something else which is really a symlink to /usrs/bin?) and the other which seemed to promote the idea of "every bit of cack that looks like it might be a library belongs in C:\Windows\System³² regardless of whether or not anybody else uses it or ever will). DLL Hell indeed. None of this fits in with the RISC OS philosophy, which may be why it might seem a bit alien.

I use RISC OS for fun.

Ditto.

I have to put up with install programs on other machines and had to learn how to undo the mess that they create. It seems to me you either learn how to install things or learn to uninstall.

Been there, done that, on my old W98 box. Oddly enough the programs that gave the most trouble were ones I possibly shouldn’t have been installing in the first place.
And Norton Antivirus. Horrible piece of <beep> that is frequently preinstalled. I get that people need antivirus because in general they are too frigging STUPID to do this of their own volition (I speak from bitter experience, that is why when a local ex-pat asks me if I can “just look at Dave’s computer” I say I charge thirty euros an hour). This, however, doesn’t justify an antivirus that refuses to die. I don’t know if Norton needs to be beheaded or if a stake in the heart would be better, I just know that if I come across a machine with it installed, it’s time to warm up the Holy Water, shake the Haraegushi, light candles, and clap twice. Oh, and fetch the garlic. Lots of garlic. Then a person might stand a chance of defeating that gourd-bellied codpiece illigitimate offspring of the ugly-pink-shirt guy.
[no, I really do not like Norton AV, or Symantec AV, or whatever it calls itself these days]

However, do not let the brokenness of other systems blind you to attributes that it may bring to us.

Someone mentioned the Apps Directory – completely useless. It looks like a folder but you can’t drop things into it – never use it.

It is a virtual folder, a place where you can put frequently-used programs for easy access. This is because our metaphor tends to either cover the pinboard in icons, or bury stuff deep in subdirectories. We don’t have a “Start Menu”.

Even as a power user, why should I open $ then Apps then DTP then OvationPro and finally click on !OvnPro when I could just open Apps and doubleclick it there?

Probably introduced to mirror the Windows start menu – and we know where that’s gone.

Gee, now RISC OS 3 (when Apps first appeared) came out in 1991.
Windows95 (the first with the Start menu) came out in 1995 (clue in the name).

I’m all for advocacy speech – but advocacy needs to be logical and consistent. This…clearly wasn’t.

How many people using windows know they can delete a ‘shortcut’ without deleting the application or even that it isn’t the application.

It isn’t the OS’s fault if the users are retards.
There is a lot wrong with Windows, but I see it at a technical level, stuff that most of the users I know wouldn’t understand. Instead, I get “my harddisc is getting full, can I delete Windows, it’s HUGE!”. No, I’m not yanking your chain. Another person washed their keyboard. Under the tap. With water. Then wondered why it all went wrong. I’ve made (small amounts of) cash restoring the harddiscs of people who turn the machine off by cutting the power (this is the UNMOUNTABLE_BOOT_VOLUME BSOD at boot). Easy to fix, but not through Windows. I’ve made more cash from the same people who, after being told why shutting down properly is important, carry on yanking the power cord “because it worked most of the time before”. The average computer user does not impress me. If you think I’m being an elitist dick, go read the comments on a YouTube video. Any YouTube video. You’ll lose faith in the continuance of our species…

Actually, sometimes (but not consistently), Windows does tell you when you are deleting a shortcut that it does not remove the program, only the shortcut pointing to it. But most of the time it doesn’t. Perhaps because you are supposed to “install” and then “uninstall”. Simply deleting random stuff is a good way to get an unstable pile of poo, which is obviously going to be Microsoft’s fault because no retard wants to admit to being a retard.

BTW, for added link fun, there is a path on my PVR that points to a location further up the path. I don’t remember the location, but you can follow this to end up with crazy stuff like (this is made up, don’t have PVR hooked to ’net and am too lazy to go plug it in): /var/usr/app/video/app/video/app/video/app/video/app/video/ (you get the idea…)

People are confused with RISC OS because they don’t know how it works.

You know, even as a smart user of RISC OS, I think that a one-click-to-install thing is a good idea.

I just have two-and-a-half requirements:

1. Write what you’re doing to a log file and drop it into the application directory, so if something screws up, I can look to see what the installer actually DID.
2. I don’t CARE what the package manager author thinks should and should not be protected. There should be an “expert mode” where instead of refusing to do this or refusing to do that, the package manager will say “You’re about to start World War Three you halfwit – Continue?” with the options “예” (yae) and “아니요” (aniyo). ;-) And when you answer in the affirmative, it will go ahead and do that. Without whinging.
3. [the half] It would be nice to have a “revert” (possibly also from the command line) that can remove the program and restore everything back to how it was. Just in case.

Maybe it can now? It’s been >year since I last looked at package stuff.

Cluttering it with alternate ways to do the same thing just adds to the confusion.

Hahaha! Nyahahahaha! Gu-hu-hu!

Really.

A fair few applications are a little bit more complicated than “open arc, drag stuff out, bob’s yer unc”. I would say not only do we have a hundred alternate ways to do the same thing (some different only in subtle but nonetheless important ways), but the onus is on the user to notice and know how it all fits together and keep track of it all.

By the time my mother learned where A: drive was and how to get to it, they stopped releasing stuff on floppy. And it’s no good saying “insert CD into tray, go to D:” because it is E: on her old machine, E: and F: on my old box, Z: on the crusty laptop, D: and F: on the NAS box; and the machines we use right now don’t even have CD drives. I’m afraid my mother, if I gave her a RISC OS computer, would get exactly nothing done if it wasn’t very clear and simple. She isn’t stupid, but to her computers are too…. I’m not sure exactly. I guess they don’t have a specific defined purpose which makes them infinitely more complicated. A toaster is a toaster, it toasts bread, it has a button and a dial (raw, lightly browned, good, burnt, incinerated) and a specific job to do. A computer, however, is the jack of all trades (thus master of none is implicit). If you are handing a luddite a machine with so many variables you really don’t want to arbitrarily introduce even more. This is why people drop serious coin on Apple tat. For all we can say for or against Apple; one thing they did realise is that many people find computers (etc) to be nasty complicated annoyances. So they did what they could to make a solid, functional, useful, yet friendly system. Sad Mac Face? No, Sad Mac is what a user experienced when fitting a modem to a machine with a serial mouse meant a cheap expansion card, a lot of claptrap about IRQs, and yet more guff about COM-this doesn’t play well with COM-that. Remember those days? <grin>

If a pi distribution comes with a package manager I’ll remove it – I hope it hasn’t scattered bits all over !Boot

;-)

<note to self: release future software in package form>

see, I don’t install it uninstalling becomes more difficult. If I can’t get RISC OS on a pi without a package manager I won’t use RISC OS.

Wah.

You really would cease using RISC OS on a Pi if it makes serious use of a package manager?
It looks as if the packaging system can update the firmware (supposedly-stable at http://packages.riscosopen.org/packages/SystemDetails.html#RaspberryPi-ROM; more recent “test” versions from http://packages.riscosopen.org/testing/ABCIndex.html; and LatestGreatest from http://packages.riscosopen.org/nightly/ABCIndex.html). Are you saying that letting an automatic system update for you is much worse than downloading the archive, opening it, and then copying the files to their correct locations?

I get it, you want control. Sometimes, however, the best solution is not more control but less of it. As I get older I realise that time is a very valuable commodity. Between work and sleep, I don’t seem to have a lot left over (having spent far more than enough writing this!) so, yeah. It is great to bring a system up from scratch by assembling all the bits in the right places. The first power-up is a real thrill.
Day-to-day maintenance? Fugedabowdit. Script it, ignore it, bribe somebody else to do it. I don’t care, just don’t expect expert intervention every single time. Look, let’s put it like this – I’m busy. I am busy trying to figure out what the hell Date-A-Live is supposed to be about, I don’t want to update the firmware. Can’t I just click a button and it’ll happen by itself.
Um… Actually… It appears as if I can. Sweet. Now, I’m supposed to follow a plot that involves saving the earth from massive space/time disturbances caused by an alien girl…..by dating her? Is that trying to contend for “dumbest plot ever”? Or is it trying to be “biggest mindscrew that isn’t Gainaxy” but failed? On the other hand, another animé’s plot can basically be summed up as “Satan ends up in a human body and has to go find himself a job…in a burger joint”. <bangs head on table>
This is, of course, all vastly more interesting than updating the OS. Again. And Again. And Again.

I just think its sad that ROOL have given the process an official stamp of approval by participating in it instead of inviting people to experience the control of a computer.

Here’s a little secret for you. Don’t pass it around or everybody will want to try.
A package is a zip file.
It can be opened.
Inside you’ll find the application you want. Install it yourself.
There’s also a few control files of relevance to the packager. These can probably be ignored (though browsing them might show up any things that the program relies upon that you’ll also need to install).

My main argument with packages on RISC OS is when the package manager bluntly refuses to do stuff with no “do it ANYWAY” option; though I think it is better about this now? Or am I mistaken? I want the package manager to aid and assist, not to hinder. My last foray into packages was a while back when a program needed an updated version of SharedUnixLib but the packager refused to touch it because another version was already there (and it hadn’t put it there). No, I don’t want to remove it and then let the packager reinstall it. I want a “I don’t know this file, can I manage it for you?” prompt instead. There was another example, much the same thing, but I don’t remember what. Oh, and back then a “you will install this software where we decree that you should (b**ch!)”. Thanks, but no thanks.
I am not anti-package on the concept, only that specific implementation. Can you drag stuff to where you want to install it? Yeah, you can – right? So things are improving.

What I don’t understand is why you would choose to take the time to manually install something in minutes that a program could do in seconds; no to mention the ability to track updates, upgrade for you, blah blah blah. Package management is not “evil”, I’m not at all distressed that ROOL is making use of the idea. It needs some tweaks to fit into what RISC OS is all about, but… you know… it is an attempt to centralise and unify software installation.
And ultimately make a boring task simple for everybody.

asks me if I can “just look at Dave’s computer” I say I charge thirty euros an hour

Whoo, too cheap. I claim to be only able to work on network switches and radius servers n’ stuff.
Sadly my sisters don’t buy that one.

A package is a zip file.

Been there :)
Like too look at things first.