For which operating system do you need RunRev?

[richmond62]

Obsolete is as Obsolete does . . .

I run a number of BBC Micro computers from 1984 in my school with no hard disk, 64-96 Kb RAM and an OS called "MOS'. I use them to teach BBC BASIC (I also do this using BBC Micro emulators: but I really like authenticity). I tend to record programs on a cassette recorder via a DINN connection.

beebem.png (25.85 KiB) Viewed 5737 times

As these retail for between $10-30 at present and can be jacked into any old TV they are rather good for the purpose I use them.

Most of the computers I use in my school were made in the 2003-2009 period: they bubble along quite happily on Linux.

There are lots and lots of perfectly serviceable PPC Macs lying around running Mac OS 10.3 through 10.5, and while the "first world" may think it has "moved on" (something that slightly begs the question), the second, third and fourth worlds are doing their damndest with the scraps from the first world's table: old computers.

Now an up-to-date version of LiveCode one can install on a machine running Mac OS 10.4 or Windows 95, or a barebones Linux distro, while possibly being poopooed by the first worlders might mean that an awful lot of kids out "there" in corners of the world first worlders spend an awful lot of time pretending don't exist might have an advantage that will improve all sorts of things in their lives.

A version of LiveCode that could be deployed on varieties of UNIX would not even need the justification I banged on about above.

[richmond62]

Mark Weider stated

I'm sure the vast majority of rev developers couldn't
care less about the obsolete operating systems

in 2010.

Is that still his opinion?

While he may not see the value of developing on "other" systems he may admit
the value of being able to deploy standalones to other systems.

I hate it when someone finds something I said eight years previously and then throws it back in my face.

Kisses

I'm not throwing anything back in your face, just interested to see if your opinion has changed.

As it is now possible to compile standalones for "all" systems on "all" systems (=3), then it may have changed.

[bogs]

Well, I'm a wee bit confused then. The downloads page offers LC/RR versions going back to 4.5.0. Does that version not run on OS9?
-----------------------------
But also keep in mind that the IDE that wraps the engine may (and does) make calls into the engine that may not exist in earlier versions, so you'd probably be sticking with a stripped-down MC or the IDE that matches the engine version, which would place you many years in arrears.

The downloads page does indeed offer those versions, however they are not free for the taking, and I have no licenses for them having come as I did to the party only a year or so ago. Above all, I try to make sure I am not doing something illegitimate, even with software as old as those IDEs. I know at some point in the IDE histories, you could dev. for one version of mac on a box not running mac, but not the other, much like how ios is these days, but do not know which version that was.

For me, I don't mind sticking with, as you put it, stripped down Mc or being back many years in the current Lc, as you may have noticed, I actually prefer those IDEs to the current. That doesn't mean it wouldn't be nice to have it all in much later IDEs though, my preferences certainly are not others, and it would not affect current lovers of progress at all that I can see.

I don't know as much about the calls the IDE makes to the engine (yet), but I believe a lot of that also depends on file format version, many have said they have really old projects that have been opened and worked on in newer IDE vers, and saving to the older format they are still able to open them in those.

You loose new features doing this, but as I said, your dev'ing for a system that never had those, I don't think your going to be missing much.

For me personally, all of this is pretty much a non issue, the Mc starter kit provided me an out, but it is going to be pretty difficult to locate those as time progresses, and there are limitations on it that would hamper those that do or need more. Of course, it won't help any road if you have an embedded program to make, even though Mc had that capability it is not included in the starter kit, and it isn't going to help with upcoming platforms such as were discussed above.

I guess my weirder point of view comes from my upbringing, in my family nothing was thrown out. If it couldn't be used for the purpose it was intended, it was used for whatever it could be used for until there was nothing left to use. It makes it hard for me to understand stopping using something that does still work for the purpose it was intended to in almost any degree. I am probably close to alone in that point of view, although I never feel quite that way as others almost always come in with similar views.

Richmond also makes a lot of points that I don't have to deal with except out of preference, but I find them valid as well. Not everyone who should be able to do things can, it is their reality and it is pretty hard to find ways around it.

[mwieder]

Richmond-

Yes, I do still think that the "vast majority" of LC developers aren't really interested in stepping outside the box. I'm not saying that in a pejorative way, no finger pointing, no blame - I think that the "problem" as such is that xtalk is so easy to use and the LC environment is such a powerful production tool that there's less incentive to venture elsewhere. And I think that applies to both extrapolating from xtalk to other programming languages and to trying to extend the reach to other platforms.

Mind you, I don't include anyone who has read this far in those categories. I think anyone who was drawn in by this topic's subject line (and certainly anyone who has stayed with the discussion onto page 2 ) has more than a passing curiosity in both, and a certain dissatisfaction with the limitations of the existing product.

[mwieder]

bogs-

Good point about licensing the older versions. Since the OSS releases I completely forgot about that.

[richmond62]

stepping outside the box

Yes, well, I have been offered 25 "boxes", meaning G5 PPC iMacs with 17" displays,
for $10 (mean 7 Euros for ffffff sake!) a pop, which I would love to pass on to loads
of kids I know who have hard-working parents who just do not have the large amounts
of ready cash to set their kids up with a halfway decent "rig" to learn programming on.

While it is perfectly possible to run LiveCode 6.something on these machines,
and as such kids can get up to reasonably good speed with LiveCode . . . that would
only be as far as 6.something goes.

Down in what, politically incorrectly is called the "Dark Continent"
(mainly because the first world is doing its utmost to keep things "dark"
down there, getting them to grow fancy veggies for their supermarkets
while buggering up the water table), the first world keeps dumping
old-but-gold computers that, because of the insane upgrade obsession,
cannot be used to keep up to speed with educational dev.

So, Yup! Why not be different (pace Apple's grammatically wrong slogan) and
let LiveCode step outside the box, and just possibly, be seen as some sort
of saviour of all that potential programming talent that is going to waste
in the "Dark Continent" and other "murky" places.

[FourthWorld]

So, Yup! Why not be different (pace Apple's grammatically wrong slogan) and
let LiveCode step outside the box, and just possibly, be seen as some sort
of saviour of all that potential programming talent that is going to waste
in the "Dark Continent" and other "murky" places.

Sounds like a very good crowdfunded community project.

[richmond62]

a very good crowdfunded community project

I'm in

[FourthWorld]

a very good crowdfunded community project

I'm in

Make it so, Number One:
https://grow.indiegogo.com/crowdfunding-on-indiegogo/

[bogs]

Good point about licensing the older versions. Since the OSS releases I completely forgot about that.

I had actually been actively scouring the net looking for a way to do just that, in fact, but was only able to find shady ways of making it happen, which I would certainly avoid.

It turns out to be a lot tougher than you would think it might or should be Until a special someone had turned me onto an express edition designed for Linux from the earlier ventures RR / Lc had tried, I was really in despair of ever getting to an earlier version of Lc's efforts certainly.

Slightly before that help came along was when I started finding the Mc starter kits, and as I say, made myself a legitimate work around of sorts. So I am fixed up no matter what else happens, but I suspect others have different needs, and as I say, it shouldn't affect anyone that doesn't to include those in current editions.

To the extent that the IDE hooks into the engine, simply determining the ultimate standalone should allow a branch decision to use an older engine, stripping any features not supported. Which is why I don't think it would be such a big deal or eat a lot of the primary dev's time. We do something similar all the time with the if in dev environment / vs/ standalone environment statements.

[richmond62]

Make it so, Number One:
https://grow.indiegogo.com/crowdfunding-on-indiegogo/

Absolutely hilarious.

The initial impetus still has to come from LiveCode central.

[FourthWorld]

Why? The code you'd be working with is GPL.

[richmond62]

The code you'd be working with is GPL.

Really?

The particular problem is that I programming languages
I currently know are LiveCode and BBC BASIC:
neither of which . . .

[richmond62]

I own a G4 iMac, and about 3 years ago I installed Lubuntu PPC
on it on the theory that that would somehow be better than the
Mac OS 10.4.11 that was running on it.

This was a huge mistake as everything became glacially slow.

Thinking "Oh, well, maybe that's just Lubuntu PPC."
I tried 3 other PPC Linux distros to no avail.

It now chunters along quite happily on Mac OS 10.4 with Mac "Classic"
for joyous things such as RunRev 1.1.1, MetaCard and HyperCard.

So I would tend to say, "Don't waste your time with a Linux PPC version."

As one can run Linux on a very large number of old non-Apple machines
I wonder if what is really needed is NOT a series of LiveCode variants to
run on all sorts of old, obsolete systems, BUT the ability to make standalones
that will run on all sorts of old, obsolete systems.

AND, are BSD and OpenSolaris obsolete when they are still being developed,
and deployed?

I am also less sure about the need for, say, deployment to systems such
as Haiku OS when there seems to be no evidence that it has any traction at all.

So, a series for previously widely deployed operating systems might make
more sense than a series for up-coming systems that have spent such a
long time up-coming one wonders if they will ever come at all.

If the reason for this exercise is ONLY for educational purposes then it
would seem that the first move should be to perform some serious
survey (unlike the one here) as to what systems are deployed on
educational machines in places such as the Indian subcontinent, Asia,
Africa and South America and to target those.

The reason for this exercise should NOT be because Richmond
feels hard done by because he cannot program LiveCode on some
ancient machine running Mac OS 7, or OS2 Warp.

If one can envisage a country that has an educational system that
is seriously strapped for cash and relies for computers on Pentium IIs
running FreeDOS, and both teachers and school kids who are
keen as mustard to get on with some sort of computer programming
that will have some sort of relevance when they apply for scholarships
and whatnot at universities in the States and Europe, then one can
see the value of having a LiveCode "distro" that runs on FreeDOS.

[FourthWorld]

The code you'd be working with is GPL.

Really?

The particular problem is that I programming languages
I currently know are LiveCode and BBC BASIC:
neither of which . . .

You would not be obliged to keep the funds yourself. Most crowdfunded projects requiring engineering use the funds to hire engineers.